Open Crimsonum opened 1 month ago
The claim that game can read keys for distinct object types from different identically named sections seems dubious to me, it should have no way of knowing which one belongs to which. Reading keys for different object types from one section with shared name? Sure, vanilla game already does it with wall buildings and overlays.
The claim that game can read keys for distinct object types from different identically named sections seems dubious to me, it should have no way of knowing which one belongs to which. Reading keys for different object types from one section with shared name? Sure, vanilla game already does it with wall buildings and overlays.
It doesn't, but it basically combines identically named sections into one and, in case of duplicate keys, preserves only the last defined key's value. This logic is what, for example, the CnCNet spawner's spawnmap feature relies on.
Example:
[Sniper] ;InfantryType
Name=Sniper
Strength=100
Speed=5
[Sniper] ;WeaponType
Damage=100
ROF=60
Speed=100
The game parses the above as follows and uses relevant keys from this section for both object types:
[Sniper]
Name=Sniper
Strength=100
Damage=100
ROF=60
Speed=100
TS and RA2 are (in most cases) case-sensitive when it comes to parsing INI sections. For example,
[Rock]
and[ROCK]
are identified as different types. WAE incorrectly treats these as duplicates and removes all but one of them.Example:
In this example, WAE removes
[UMAGON]
when saving the map.The game can even parse data from multiple identically named sections for different object types. For example, a map could contain multiple instances of
[Sniper]
; one for a weapon, one for a unit, and another for a house type. Though it's questionable design and can lead to overlapping data being discarded (i.e. when the same key is defined multiple times), it's still technically possible.