I, Voyager
Implement the .tsv table system as a resource importer addon #11
Replies: 8 comments
-
|
Hey! Great proposal. I'll be able to read it in details in a week or so. I've being using this module to work with table data, but I'm happy to switch to iVoyager based later. |
Beta Was this translation helpful? Give feedback.
-
|
I'll post here after I've done some function decomposition in IVTableImporter. I'll comment everything as "import" or "post-import processing". [EDIT:] I'm also adding functionality from my own game project to read tables such as this into an array-of-arrays structure. Should be done in a week. |
Beta Was this translation helpful? Give feedback.
-
|
@Difint , I've created a new repository for the future IVoyagerTableImporter here. It's only got a README now but the readme is extremally detailed about table formatting and capability. FYI, I'm making good progress on decoupling table file reading from postprocessing. Even better, I've moved the whole system to its own directory, and I'm currently decoupling it entirely from 'ivoyager' systems (so ivoyager depends on the table system rather than the other way around). Maybe 4 or 5 days of work to do... |
Beta Was this translation helpful? Give feedback.
-
|
OK, the whole table system code has been decoupled from ivoyager and moved into the new repository ivoyager_table_importer. The readme there is very detailed. It all works but it's not a real editor plugin yet. I'm still annoyed at Godot's instructions for packaging plugins, with all the "download, extract, copy the plugin from its addon directory, paste it into your addon directory..." Really, it should be added to addons as a git submodule so devs and users can update, do pull-requests, etc. To do that, use git command (from your project directory):
That's so much easier! I've fully decoupled the table "import" (i.e., file read, parse, and preprocess) from postprocessing that requires instructions from the project (including unit conversions and enum resolution). It should be obvious where things happen now by the file names. It's all tested and working as it loads tables for my develop branch Planetarium. |
Beta Was this translation helpful? Give feedback.
-
|
@Difint, I'm going to go ahead and finish this proposal (converting this to a true editor plugin). I have a good idea how I want it to work and I'm eager to learn how to make editor plugins... |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for being MIA. I'll check everything this week as I'm getting back from Gitcoin to Development
------- Original Message -------
…On Sunday, September 3rd, 2023 at 5:18 PM, Charlie Whitfield ***@***.***> wrote:
***@***.***(https://github.com/Difint), I'm going to go ahead and finish this proposal (converting this to a true editor plugin). I have a good idea how I want it to work and I'm eager to learn how to make editor plugins...
—
Reply to this email directly, [view it on GitHub](#11 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AYITIZLDY3BL4B3TT5WDGKLXYRKPXANCNFSM6AAAAAA3O2STXU).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
No worries. I'll be releasing v0.0.1 of the editor plugin later tonight or tomorrow. It can use some external testing! [Edit:] |
Beta Was this translation helpful? Give feedback.
-
|
This is done! |
Beta Was this translation helpful? Give feedback.
-
Describe what is missing or deficient and why it should be included or improved.
I, Voyager's table system is general purpose and would benefit others if it could be distributed as an addon in Godot's Asset Library. To do so, it needs to be extracted and properly structured as an addon.
Also, a true resource importer system would:
If this is a simulation or planetarium "content" proposal, describe how the content should appear and how users should interact with it.
N/A
If this is a "code" or "development platform" proposal, describe how developers will use the new system. Provide detailed API if possible.
OK, here are the two major difficulties:
Type=REAL have specifiedUnit. E.g., "km", "au", "g/cm^3", "10^24 kg", "deg/Cy^2". These can get weird and we don't want to try to predict what a developer might need. Also, we are agnostic about how the developer wants to represent unit quantities internally. Maybe they want everything to be SI internally. But maybe something else.Type=INT have enumerations like "PLANET_EARTH", "MODEL_ROCKY_WORLD". These enumerations can be either thenamecolumn in any table (where the enumeration resolves to the table row number) or hard-coded enums in the developer's project. A table "Resource" can't know what these values are supposed to be at import time.To solve the above difficulties, I suggest that the main API for developers should not be the Resource itself, but instead an autoload singleton called "IVTableData". This singleton would do all of the following:
Unitvalues are used for unit conversion. Default can be strict SI conversion using our existing pre-made dictionaries of unit strings. Otherwise, user must provide their own MULTIPLIERS and FUNCTIONS dictionaries.nameentries).IVTableData (an autoload Node)
The API has to cover items 1, 2 and 4 above.
members - WIP (this will be the four table-related dictionaries presently in IVGlobal)
methods - WIP (this will be all of IVTableReader's current API plus methods to do 1 and 2 above)
IVImportedTable (Resource)
The API for each table (as a Resource) is kind of low level. It's going to get us intermediately processed data -- specifically, text converted to float (but not yet unit-converted) and INT columns as StringNames (not yet evaluated). This API is mainly for use by the singleton above to initialize itself. Devs might access it when debugging their own tables or if they want something very specific (e.g. what is the actual text string used for the Unit value of a particular table column).
members - WIP (intermediately processed data, column
Unittexts, etc.)methods - WIP
If applicable, provide implementation code, pseudo-code, mock-ups, diagrams, or orbital maths. Do you have any helpful tips or gotchas to watch out for?
Before getting started, do read the table README and study existing .tsv tables.
The existing code is all in IVTableImporter or IVTableReader (unit static methods in IVUnits). The main gotcha now is that table read and unit conversions are all mixed up in the same functions in IVTableImporter. Only the INT enumeration is clearly separated (as it has to be done after all tables have been read).
It may be best to wait for me to separate some of this functionality within the existing code in IVTableImporter. I can refactor the methods so there is a clear distinction between "import" and "post-import processing". The former will then go into the new resource importer and the latter will go into the new IVTableData singleton. And then all of the methods in IVTableReader can be copy/pasted as is into the IVTableData singleton.
Which of the following describes your feature? (1) A feature or content improvement for our Planetarium. (2) An improvement for game/app developers that should be in our core repositories. (3) An improvement for game/app developers that should be an optional addon.
(2)
Beta Was this translation helpful? Give feedback.
All reactions