Pages: [1]
  Print  
Author Topic: OA gamepack scripts  (Read 7881 times)
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« on: November 18, 2017, 07:02:19 AM »

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:

Quote from: sago007
I have been working a bit on scripting the gamepack files. I now have a repository where I have my initial prototype: https://github.com/sago007/oagamepack_scripts I wrote it in Python despite never having done anything in that language. I had hoped to use the build in CSV functionality but I was disappointed. The idea being that you can maintain all the data in CSV files and edit them with Calc or your favorite spreadsheet editor. As described in: https://docs.google.com/document/d/1xmpfXyfEj-K2Jjw-cRO470kog62AId5NVvTteQ-tXz4/edit?usp=sharing
Quote from: Gig
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?
Quote from: sago007
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?
Quote from: Gig
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...
Quote
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...
Logged

There are nothing offending in my posts.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #1 on: November 18, 2017, 09:38:40 AM »

Quote
it will be more flexible in the long run because new items require less work.
Indeed, and we can support as many editors as possible. Hell, we could even create at some point a QuArK gamepack!

Gig has already made the relevant changes for both entities.ent and entities.def in the gamepack repo. All that's missing, then, is to update the relevant files in the gamepack script repo, I guess.

The important part to bear in mind is that the gamepack repo must have ready-to-be-used files because some compilation/installation scripts will only git-clone the repo.
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #2 on: November 18, 2017, 11:30:21 AM »

Gig has already made the relevant changes for both entities.ent and entities.def in the gamepack repo. All that's missing, then, is to update the relevant files in the gamepack script repo, I guess.

Unfortunately, it isn't so easy. We have done a lot for the most common entities such as weapons and ammo boxes, but even those still lack some keys descriptions. And many other kinds of entities still lack a lot more.

I did pause the work also waiting for developments about these scripts...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #3 on: November 19, 2017, 08:06:31 AM »

I created a branch of oagamepack that shows how I imagine it: https://github.com/sago007/oagamepack/commits/script_based

Some limitation at the moment:
No spawnflag support (except suspended)
No sorting support
No default values support
No extra entities support (like "_skybox")
Only generates the ent-file not the def.

I wonder if it is best to merge early, to not delay adding data to the CSV files.
Or later, to prevent a half done ent file.
Logged

There are nothing offending in my posts.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #4 on: November 19, 2017, 12:50:07 PM »

I vote later, in order to prevent the half-done ent file.
« Last Edit: November 19, 2017, 01:01:44 PM by Neon_Knight » Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #5 on: November 25, 2017, 11:57:30 AM »

I updated it. https://github.com/sago007/oagamepack/tree/script_based

Spawnflags support
Default values support
Extra entities support
"group" support
Sorted by name.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #6 on: November 27, 2017, 01:14:36 AM »

Good, although I still have some questions....
What do you mean with "group support"?

And about "defaults" support, I see in keys.csv a "count_default" column.... but for the default for other keys?

And about the "special cases" such as targetname_func_door or wait_func_door, why do they need to have an additional column each in the keys.csv file? Shouldn't it automatically detect that if in keys.csv you have "func_door" with "targetname/true" and in "key_text.csv" it does exist "targetname_func_door", then it have to use that description instead of the default "targetname" description?

And about the "description"s in entities.csv, such as
Quote
path_corner    /*QUAKED path_corner (.5 .3 0) (-8 -8 -8) (8 8 8)    Train path corners. Target: next path corner and other targets to fire "speed" speed to move to the next corner "wait" seconds to wait before behining move to next corner
Are they from the source code? Are those description texts currently from the old non-gpl descriptions? Do you plan to make them shorter, as the keys will be explained through key_text.csv?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #7 on: November 27, 2017, 05:54:45 AM »

What do you mean with "group support"?
It just means that some entities does not have a "box". They cannot be placed directly in the map. Like worldspawn.

And about "defaults" support, I see in keys.csv a "count_default" column.... but for the default for other keys?
Just add a column "SOMENAME_default" and it will be detected.

And about the "special cases" such as targetname_func_door or wait_func_door, why do they need to have an additional column each in the keys.csv file? Shouldn't it automatically detect that if in keys.csv you have "func_door" with "targetname/true" and in "key_text.csv" it does exist "targetname_func_door", then it have to use that description instead of the default "targetname" description?
This might be beneficial if the exception is only for one entry and only effects the text. But "health" is a boolean when applied to movers and the text can be shared among them.

And about the "description"s in entities.csv, such as
Quote
path_corner    /*QUAKED path_corner (.5 .3 0) (-8 -8 -8) (8 8 8 )    Train path corners. Target: next path corner and other targets to fire "speed" speed to move to the next corner "wait" seconds to wait before behining move to next corner
Are they from the source code? Are those description texts currently from the old non-gpl descriptions? Do you plan to make them shorter, as the keys will be explained through key_text.csv?
All texts are either from the GPL source code or written by me. I do plan to remove the key descriptions and only keep the item description in source. Otherwise there are too many repetitions in the source. But feel free to use the text.
Logged

There are nothing offending in my posts.
Pages: [1]
  Print  
 
Jump to: