Data Input/Output/Terminal Unit

[Wolfram]

This would be an element very similar to a Data Bank, with the exception it stores a large raw string (similar to the HTML of an Screen) that both can be read and written via Lua.

 

A few reasons this element would be useful:

- Simple and clean way to export and import data with Lua

- No need to dump large strings into Screen elements with the only purpose of copying that data, possibly less intensive than updating Screen elements

- Can be used as an table-less alternative to a Data Bank, for those who prefer to store JSON or Lua-encoded stuff directly

- Data is kept private similar to a Data Bank, only those with edit permissions could access it, maybe allow for DRM-ing of it too?

- Limits can be either similar to a Data Bank or maybe closer to what we get from Screen HTML like ~50KB

[EasternGamer]

@NQ-Ligo
Elias suggested that someone should tag you, hope you don't mind.

[Yoarii]

16 hours ago, Wolfram said:

This would be an element very similar to a Data Bank, with the exception it stores a large raw string (similar to the HTML of an Screen) that both can be read and written via Lua.

 

A few reasons this element would be useful:

- Simple and clean way to export and import data with Lua

- No need to dump large strings into Screen elements with the only purpose of copying that data, possibly less intensive than updating Screen elements

- Can be used as an table-less alternative to a Data Bank, for those who prefer to store JSON or Lua-encoded stuff directly

- Data is kept private similar to a Data Bank, only those with edit permissions could access it, maybe allow for DRM-ing of it too?

- Limits can be either similar to a Data Bank or maybe closer to what we get from Screen HTML like ~50KB

Except the size, this sounds just like another data bank?

 

What is the use case you want to solve?

 

Edit: Personally, I'd like to extend the databank or a new element that you can paste/copy larger text data to/from, like you can do with a programming board.

Edited August 12, 2022 by Yoarii

[Wolfram]

1 hour ago, Yoarii said:

Personally, I'd like to extend the databank or a new element that you can paste/copy larger text data to/from, like you can do with a programming board.

 

That's pretty much the idea, actually! It would be a much more simplified databank, that instead of having a fixed table with keys and values only stores a single large string of whatever you want (which could be JSON, CSV, Lua, logs, etc, anything that fits a string). The data could be accessed either via UI (which would be just a window with a large textarea with the contents) or could be directly copied from/pasted into similar to how we can do with Programming Boards JSON configs.

[NQ-Ligo]

This is a good topic and good ideas. Redesigning the databank element is on the table for many reasons, including the impact on performances. However, I can't promise when, how...etc but it will certainly address some of the points in your suggestion.

[Yoarii]

19 hours ago, NQ-Ligo said:

This is a good topic and good ideas. Redesigning the databank element is on the table for many reasons, including the impact on performances. However, I can't promise when, how...etc but it will certainly address some of the points in your suggestion.

Here's some additional psuedo-names for APIs I'd like to see:

 

* x.AsJson() - parses the content as Json using the C++ backend so we don't have to do it in with dkjson etc (or even better - make Json parsing available without Lua throughout)

* x.AsCSV(delimiter_char) - parses the content as CSV and returns a list of lines

* x.SetContent(...) sets the content of the database.

 

[Wolfram]

On 8/12/2022 at 1:34 PM, NQ-Ligo said:

This is a good topic and good ideas. Redesigning the databank element is on the table for many reasons, including the impact on performances. However, I can't promise when, how...etc but it will certainly address some of the points in your suggestion.

 

Looking forward for the new databanks (possibly new elements too?), I know those are quite important infrastructure pieces for players so will be nice to see them getting revamped into more efficient things! Bonus if we get a way to easily import/export data, even if text-based, I'm sure it will be much more straightforward than manually inputting and copying data from the Lua channel.

 

5 hours ago, Yoarii said:

* x.AsJson() - parses the content as Json using the C++ backend so we don't have to do it in with dkjson etc (or even better - make Json parsing available without Lua throughout)

 

This is something that would make a big difference too, @NQ-Ligo, having a C++ native way of encoding and decoding JSON. The existing library is quite okay, but not as efficient and sometimes will just cause a CPU overload when trying to work on larger data sets. I'm sure having a native method, similar to the ones under `library` would make a big difference here.