So NeonKnight and Gig has been working on GPLv2+ compatible gamepack for *Radiant:
https://github.com/NeonKnightOA/oagamepack. I did aprovide the initial scripts to extract the entries from source. My original thought was to update the source, so a complete entity file could always be extracted from source.
Seemed like a good idea at the time.
There was some problems:
A lot of repetitions
Only the 1.4/1.6 format is extracted
The old format does not include type information used by 1.5/NetRadiant
Some of the problems I did not realize until NeonKnight told me about them.
I created
https://github.com/sago007/oagamepack_scripts which is a python script and some CSV fields that can potentially be used to compile any entities file format. At the moment NetRadiant files are created.
At the moment it is still in the prototype phase.
I am of course dropping short term flexibility for maintainability. However, I believe that it will be more flexible in the long run because new items require less work.
Gig suggested that I opened a forum topic about it. So that the information did not get stuck somewhere in Discord.
The initial discussion went like this:
Whoa... that seems quite good! However, one of its most comfortable features may also be a problem: if I understand correctly, you have a table which holds key descriptions and a table where you specify which keys each entity supports, and then the script "expands" them in the output file. The problem is that, while often the description of a certain key is actually the same for various entities, in some cases you may instead need different descriptions. Example: the "wait" key has different meaning for path_corner than for other entities, how to manage such cases?
Good point. I can add a basekey to each item, so you can create a key "wait_path_corner" with basekey "wait" and assign it to path_corner. path_corner will then show the description from "wait_path_corner" but just call the key "wait". This should work fine as long as the number of exceptions are either low or can be grouped together. By "grouped together" I for instance means that "wait_item" could be assigned to all items if it makes sense. Default values are also something I have also considered. I imagine that there could be a "wait_default" column in keys.csv and if it had a given value for a given item it would add (Default: the value) at the end of the description. A file to define the order would properly also be a good idea.
I mainly just wanted to show the concept. Do you believe it is a good idea? Should I continue?
I think it may be a good idea, as long as we find ways to manage the various cases in feasible ways. An alternative to write "default" values may have been to move them to the generic "Notes" section at the end of the entities, with a thing like "Default value for wait key is X. Default value for count key is Y." but that doesn't really seem the best for the reader.... your proposed version may be better. Also, I thought about something like, in the entities/keys table, other than only "false" and "true" to also accept "custom", to tell the script to read a specific description for that specific entity+key pair (in another file?)... but reading your post above made me realize that just the existence of a such additional entity+key pair may be enough to assume the script has to use it instead of the "generic" message (well, the "custom" word may still just be a reminder for who is managing the csv files?)... just brainstorming... Another thing I was thinking about were optional "in line" notes... I mean for a certain key still show the "generic" message, but also add a custom text at the end of it... which may have been like "[...] Default: X", but also like [referring to NOTFREE key for runes items] "[...] Usage of this is advisable in case of team-limited Runes"... still just brainstorming... Also waiting to read @NeonKnightOA opinions about it... since his hard disk failure a few weeks ago, I rarely see activities from him... let's hope he will be fully with us soon...
The main doubt is that, having to consider the various exceptions, this may risk to become harder to manage than doing it the old fashion way. I can't tell now how many groups and exceptions will be needed... surely, a key such as "targetname" will have a different description when talking about an ammo box or when talking about a door... However, what about creating a forum thread about this, to better follow the discussion also in the future? It looks like this will take some time...