How inheritance works in Ares DLL

TAK02

(I might fix this so the last bit is less like a transcript of a long-past conversation or I might not)

This is how C++/C-like inheritance (apparently that's what inspired this feature) works with Ares DLL; which for some reason isn't written in the docs with a "use at your own risk" warning on it.
Apparently due its inconsistency and potential buggy-ness.

Personally I think the feature's biggest current problem is the lack of information when something goes wrong.
From the debug log:

Code:

[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'CARGOCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'CARGOCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'CARGOCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'CARGOCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'CARGOCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'LOCOMOTIVE', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'TRAINCAR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'NAAPWR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'NAAPWR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'NAAPWR', which doesn't exist or has not been parsed yet.
[Developer warning]An INI section inherits from section 'SmallWormRipplingA', which doesn't exist or has not been parsed yet.

It wouldn't be such a pain to fix if I knew what I need to fix.
The funny thing is LOCOMOTIVE, TRAINCAR, CARGOCAR are already above anything that could be inheriting from them in the #include INI.
Heck, I even put them at the top of the #include INI's VehicleTypes list!

Spoiler (click here to read it):

rulesmd.ini bottom:

Code:

;;Ares-only section
[#include]
1=NEWRULES.ini

NEWRULES.ini snippet:

Code:

[VehicleTypes] ;;Add this into the list directly too, otherwise FA2 will screw up.
8298=LOCOMOTIVE ;;line 621
8299=TRAINCAR
8300=CARGOCAR
...
8308=0ATRAIN0
8309=0BTRAIN0
8310=0BTRAIN1
8311=0BTRAINZ
8312=0CTRAIN0
8313=0CTRAIN1
8314=0CTRAINZ
8315=0DTRAIN0
8316=0DTRAIN1
8317=0DTRAIN2
8318=0ETRAIN0
8319=0ETRAIN1
8320=0FTRAIN0
8321=0FTRAIN1
8322=0FTRAIN2
8323=0FTRAIN3
8324=0FTRAIN4
8325=MADHQ
...
8334=0FTRAINZ
8335=0ETRAINZ
8336=MONOEND
8337=MONOENGTS
8338=MONOCARTS
8339=MONOENDTS

; Train Locomotive from Tiberian Sun
[LOCOMOTIVE] ;;line 15022
Name=Locomotive
...
; Train car from Tiberian Sun
[TRAINCAR] ;;line 15084
Name=Train Car
...
; Cargo car for train from Tiberian Sun
[CARGOCAR] ;;line 15138
Name=Cargo Car
...
[MONOEND]:[TRAINCAR] ;;Westwood, edit TAK02
Image=MONOEND ;;line 15193
Name=MONOEND
...
[MONOENGTS]:[LOCOMOTIVE] ;;lines 15197-15268
[MONOCARTS]:[TRAINCAR]
[MONOENDTS]:[MONOEND]
[0ATRAIN0]:[LOCOMOTIVE]
[0BTRAIN0]:[LOCOMOTIVE]
[0BTRAIN1]:[TRAINCAR]
[0BTRAINZ]:[TRAINCAR]
[0CTRAIN0]:[LOCOMOTIVE]
[0CTRAIN1]:[TRAINCAR]
[0CTRAINZ]:[MONOEND]
[0DTRAIN0]:[LOCOMOTIVE]
[0DTRAIN1]:[CARGOCAR]
[0DTRAIN2]:[TRAINCAR]
[0ETRAIN0]:[LOCOMOTIVE]
[0ETRAIN1]:[TRAINCAR]
[0ETRAINZ]:[MONOEND]
[0FTRAIN0]:[LOCOMOTIVE]
[0FTRAIN1]:[CARGOCAR]
[0FTRAIN2]:[CARGOCAR]
[0FTRAIN3]:[CARGOCAR]
[0FTRAIN4]:[CARGOCAR]
[0FTRAINZ]:[MONOEND]
[MADHQ]:[TRAINCAR]

As to the logic itself:

IMHO it's not shaky at all. I find it logical: it all depends on the order of things. What I'm worried about is whether or not the inheritance feature itself will break/be scrapped.

Inheritance test results (#include at bottom of rulesmd.ini):
[GAAIRP]:[GAAIRC] after [GAAIRC] overrides: overrides&additions of #include INI are carried over into GAAIRP
[GAAIRP]:[GAAIRC] before [GAAIRC] overrides: GAAIRC from base rulesmd.ini (last GAAIRC the INI parser read) is copied into GAAIRP, then overrides/additions of the GAAIRP section come in.
It's as Starrku once wrote, more or less: the INI parse reads from top to bottom, anything with [X]:[Y] will have the INI parser copy-paste everything it last set for [Y] for [X], then override or add upon it, depending on what's set for [X].
It's not that hard to get your head around.

I wonder how results would differ if #include were at the top of rulesmd...
If the INI parser goes top to bottom, making detours wherever [#include] is and copy-pasting the last read settings from Y for X where it meets [X]:[Y], that might mean inheritance can only be used in a #include INI if it's at the bottom, after everything else has already been defined, to be on the safe side...

And multiple buildings can inherit from the same building.

Starkku wrote:

The biggest issue with the logic is that you can't use it safely at all without #include
It just flat out doesn't work properly within confines of just rulesmd.ini
It works if you leave the inherited object empty but if you list absolutely any key on it, it won't inherit anything
That will only work if you do it in an included file
It would be really useful if it worked properly on everything, especially for the type conversion and everything
It works on units etc from what I recall but the same [...] with the main rules vs included applies

I still think it should be mentioned in the docs.
Probably also remind/warn modders that inheritance is still largely untested and potentially problematic.

It's a great feature that saves you the trouble of having to copy-paste flags over, and then double chk them every now and then for any changes.

As to how inheritance handles Image=:

Starkku wrote:

some people could probably get confused with how it handles Image but it actually works as expected. If the section you're inheriting from has explicitly defined Image, that is used even by the inheriting section, but if not then it uses the section name - that is, the current section name, not the one you're inheriting from
No clue if you can encounter some [...] with building artwork, cameos etc. like you can with game mode INI / map overrides but if I had to guess, probably not

[GAAIRC] has no Image explicitly set, [GAAIRF]:[GAAIRC] will have Image set as default GAAIRF
If [GAAIRC] has explicit Image=GAAIRC, then [GAAIRF]:[GAAIRC] will have Image set as GAAIRC

_________________
One and only developer of the Command & Conquer Dune "C&C D" mod.

Allied General · Posted: Thu Jun 17, 2021 10:06 am Post subject:

None of the public / wip FA2 builds support inheritance as well so you would need to recompile the inis into one rulesmd.ini again.

_________________

TAK02 · Posted: Thu Jun 17, 2021 10:21 am Post subject:

^^This I forgot to mention. The map editors don't support #include or inheritance at the moment, yes.

However, you're not quite right about having to recompile the INIs into one.

You just need to paste the few flags you need for a TechnoType to be available in the current map editors.

You need to copy-paste the Type lists' contents from #include rules to rulesmd.ini, in addition to Name= (so you can actually select it) and maybe Image= (so you can actually see it); I think Owner= too if it's a BuildingType.
If you want to see the thing you're placing you'll have to copy the IDs from #include art to artmd.ini (you'll need Voxel=yes for voxel units; haven't dabbled with BuildingTypes yet but I think Image= and something for Foundation= need to be there too).