In Ares, you can map a hotkey from options->kbd->development->type list
and debug log will contain the list that the game uses when you press that
hotkey in the game.
I don't use #include. FA2/AI editor etc. uses such lists, so have to merge again
for those tools.
Just for curiosity, I tried like in buildings.ini:
With 0/1/2 you're replacing what's in 0/1/2 currently, for me replacing 0/1/2/3 with GAAIRC threw GACNST and GAPOWR to the bottom of the list and completely removed GAREFN from existance. Not something I would do normally anyway, so I don't think using numbers already in use would be smart. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
In SP map the list starts with 0 and it's appended to the end of the list in rulesmd.
How Object Arrays Work says the left side of the equal side doesn't matter only the order of the list matters.
Looks like Ares #include breaks these rules and gives unexpected result. _________________
Ares doesn't break the rule. The rule is and always was applied later and still works as before.
Before the list is parsed, meaning the game uses the right-hand-side value to make the ID known, #include is applied while the INI is still being read from the file. That is, before any line has any meaning.
And there, two tags with the same name are not allowed, because the results can be random (that is, random per player and per match). Ares implemented #include in a way to remove the old value and replace it with the new one*. That's why 0= ... cannot be "reused" in an included file and still keep both values.
To create lists that "merge" well, use the key "+". This will be replaced at runtime with a "free" key name, thus never overwrite an existing key.
(The feature apparently isn't documented, and I'll yet have to see why this is the case. If I can't find the reason, I'll properly document it.)
* "As each INI file is loaded, any flag that is encountered that has already been defined will have its value updated with the newly found value." _________________ QUICK_EDIT
That's awesome! Now I can use that with my game improvements and zombie mod without them conflicting. Thanks for all the awesome stuff you do! Followup question if you don't mind, does AImd and ARTmd support included files? I tested it for ARTmd but it didn't work unless I messed up. QUICK_EDIT
I've heard it's only supported for rulesmd.ini, though I don't know why. It looks quite universal to me. I'll have to look whether it's supposed to support other INIs. _________________ QUICK_EDIT
I noticed that there is a internal WeaponTypes list and it's used by some map trigger. If you define your own WeaponTypes list you will mess up the order since the game append those unregistered to the end? I discovered this when I edit allied campaign 6 where there is a trigger calls a weapon and it calls the wrong weapon if I define my own WeaponTypes list. _________________
The type lists are added first, so indeed new things would go at the end. Ignoring the problem that the weapons cannot be added at the end of the list, because that would require them to be added after everything has been read and thus they themselves wouldn't be read because that phase is already over: changing this would break order for everyone.
Wouldn't it be possible to output the list of weapon types, then copy it into the WeaponTypes list to have a deterministic order? _________________ QUICK_EDIT
I would imagine it's everything that's used by units and weedguy hacks, listed in order from top to bottom of rulesmd.ini; But it could also be completely random, so how could we dump that into a debug.txt? _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
If you don't change anything, the order should always be the same. Ares added a Dump Types Keyboard Command. That's the way to go. _________________ QUICK_EDIT
Well now I feel foolish for forgetting that dumps everything. 203 vanilla WeaponTypes and of course, they're all in a random order.
Unrelated oddity: changing LargeVisceroid= or SmallVisceroid= to a buildable or AllowedToStartInMultiplayer unit will make some start as a visceroid with special hard-coded logics and unit-size health bar and some not in a 25/75 ratio (of 30 tries using E1).
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum