forum.freeciv.org

i am creating a ruleset, and i commonly find myself basically copypasting sections and changing 1 or 2 things only or always adding the same thing to many similar sections, for instance the nation group requirement that i have for my advances as each belongs to a tech tree, but they share a class, so i have multiple [advance_tech_tree_*] sections with equal reqs field and class.

the idea of a meta section is that they have a section_target property which determines which sections should be affected and they somehow, add equal or similar properties to affected sections. it should be possible to at least choose affected sections by regex on the section name and property value,
and it should be possible to add a property based on other already defined properties i will provide an example
say we have various advances each belonging to a tech class like the following
[advance_tech_tree_1_example]
name = "Tech Tree 1 Example"
class = "Tech Tree 1"
req1 = "None"
req2 = "None"
root_req = "None"
reqs = {"type", "name","range"
"NationGroup","Tech Tree 1","Player"
}
...
if we aim to use the maximum of advances available you will need to write the reqs field 250 times, with meta sections it could for instance be written like this with some variation depending on how meta sections are implemented
[meta_section_tech_tree_1]
section_targets = {"type","target","value2","ruleset"
"Property","class","Tech Tree 1","techs"
}
value_to_add = {"property","property_in_section","type"
"reqs", "reqs","substitute"
}
reqs = {"type", "name","range"
"NationGroup","Tech Tree 1","Player"
}
so instead of writing reqs 250 you write once for each tech tree, for more utility we could make it so a certain sequence of characters substitute for a property so say we wanted to add a nation group req for each tech but they also have other requirements
we could then if $ is the subtitute property symbol write reqs as
reqs = {"type", "name","range","present","quiet"
$reqs
"NationGroup","Tech Tree 1","Player",TRUE,FALSE
}

i believe meta sections would make it easier to maintain and develop rulesets, as you would need to only specify where the rules are different, it could be useful to have a way to exclude sections so maybe there should be a "present" property to the section targets table. however i may be missing another even better alternative to lessen duplication of ruleset definitions if so please mention this even better idea.

Well, some macro language would be natural to be included in specfile format, but it's dubious if it worth the labour invested before replacing the format with something more generic and handy, likely somebody is doing it towards XML.

Ignatus wrote: ↑Tue Jul 12, 2022 6:56 pm Well, some macro language would be natural to be included in specfile format, but it's dubious if it worth the labour invested before replacing the format with something more generic and handy, likely somebody is doing it towards XML.

is it currently planned to replace the current format with something else? if so with what and when?
that seems like a massive undertaking, just goldkeep has like 2000 lines of game ruleset alone, and we would have to basically rewrite server/ruleset.c, the only way that is happening is if there is a fundamental and massive problem with the ruleset format as it is, if so what is so bad?

it seems like too much work with little gain, i may be wrong, if for things like meta sections we would need to rewrite the secfile parser then maybe it would be worth it but my idea of meta sections alone doesn't seem enough to need such a drastic change, so please enlighten me over what is the problem with the current format because although i found some problems none of them were big enough to make it seem worth to basically have to rewrite around 10 thousand lines of code + 40 thousand ruleset lines.
edit:
just noting that i did this numbers as a guess, i now have ran ripgrep with and summed the numbers and it gave a total of 124016 lines sure it includes empty spaces but i think this illustrates my point, to change the format is a massive undertaking that would need to rewrite more than 100 thousand lines, do note that the 124 thousand doesn't include changing the nations.ruleset which adds a further 50 thousand lines

eldritch_cookie wrote: ↑Wed Jul 13, 2022 1:07 pmis it currently planned to replace the current format with something else? if so with what and when?

There's partial xml-backend introduced in 2014, but no progress with its functionality since then (some commits have touched it for maintenance purposes)

I myself use it, purely for the purposes of having it in some kind of testing, for the database configuration file (probably the only file type for which its current
functionality is sufficient)

Maybe just add wrapper/GUI for some preprocessor, like C preprocessor?

User just click create new ruleset template, preprocessor creator shown window with tabs of some files, like tech.ruleset, game.ruleset, style.rulese, etc.

User simple write normal ruleset, but could use preprocessor directives.

When generate target ruleset was clicked, our creator will prepend each tab's content with some static text related to each file and to specify file and run preprocessor on each.


What is advantages? User could use predefined macros and define own. And also, it is very simple in implementation, it think.

One hack: Allow to output preprocessor directives and ran preprocessor until source and destination files are identical, so user could define macro such like:
#define tech(name_, class) \
[tech_##name_]
name = name_
#if class == "A" \
do_something \
OTHER_PARTS

If we introduce extended secfile syntax, there should be some basic operators supported for scalars (maybe standard Lua set with %, Boolean and maybe bitwise stuff from C), a macro definition operator (*def ID(param1, param2, opt_param?) ... and maybe also *defloc variant) and some standard macro functions (pow(x, p), defined("macname") etc.), as well as *if/*for constructions. There could be also some preprocessing functionality for lists and tables. Independently, syntaxic sugar for "fields", "nested records" and "table concatenation" would be nice. Though, that all will make ruledit task more complicated. Ruleup would be able to look if something should be done to the file (preprocessing it to the older format and looking at the final result) but will probably leave much to manual editing.