Iterator character for ini keys

[pd]

I would like to propose the introduction of an iterator character for ini keys.
Let me start off with an example, which might already explain it:

[InfantryTypes]
+=E1
+=E2
+=SHK
...

The idea is to simplify list sections especially.
The iterator character (I propose '+'), if found in an ini key name, is replaced by "the next free number" in that section.

Pseudo-code:
int i = 0;
for(i = 0; sectionExists(keyName.replace("+", itoa(i))); i++) {}
keyName = keyName.replace("+", itoa(i));

This would be exceptionally useful when dealing with multiple included ini files, as you would not have to hunt and peck through all your inis in order to find out whether a key (an index) is already in use.

[Renegade (renegade)]

Don't the arrays enumerate automatically anyway?
If I place

[InfantryTypes]
BATMAN=BATMAN
SUPERMAN=SUPERMAN
IRONMAN=IRONMAN
doesn't the game convert it to
[InfantryTypes]
0=BATMAN
1=SUPERMAN
2=IRONMAN
anyway?

With that in mind, there is really no big difference between pressing "+" once, and holding down random keys for random amounts of time.
I'll be just as quick typing
[InfantryTypes]
+=BATMAN
+=SUPERMAN
+=IRONMAN
as I'll be typing
[InfantryTypes]
qqqq=BATMAN
aaa=SUPERMAN
vvvvvvvvv=IRONMAN

If you do want to simplify listing, would it not be more efficient and more of an actual change to change the recognition pattern to something like ^([^;\s]+), that is, simply allow lists like
[InfantryTypes]
BATMAN
SUPERMAN ; this is a comment and should not be recognized
IRONMAN
?

Strikes me as a better ideal to strive for. *shrugs*

[modder666 (modder666)]

Have to say that the Iterator key is a good idea, but when the game throws out all the old numbers and renumbers the list when loading it's just not that useful of a feature.

[Renegade (renegade)]

Well, that's what ModEnc says, and I'm pretty sure that's how D explained it in chat...

He'd know better, though.

[DCoder DCoder (dcoder1337)]

They do enumerate automatically, but you still need to have unique value on the left hand side. Which can be a problem or at least a complication when [#include] comes into play. Just yesterday pd tripped over this himself -
;rules
[#include]
000=rules_General.ini
; stuff
100=rules_Sides.ini
; stuff

;rules_Sides.ini
[#include]
0=rules_Side_Soviet.ini
1=rules_Side_Allied.ini
2=rules_Side_Yuri.ini
3=rules_Side_Other.ini

; rules_Side_Soviet.ini
;Soviet stuff
[#include]
0=rules_Side_Soviet_Infantry.ini
1=rules_Side_Soviet_Vehicles.ini
2=rules_Side_Soviet_Aircraft.ini
3=rules_Side_Soviet_Buildings.ini
.... oops, the [#include] entries in Soviet overwrote those in Sides. The idea itself is good, I just don't want to code it myself.

[Renegade (renegade)]

But wouldn't that be even more support for not bothering with user-written-left-hand in the first place?

If it just concatenated the existing lists firsts, and then enumerated the result, that issue wouldn't appear?

[pd (pdmail)]

There is no real way to detect whether something is a list or not. In the end, it's all key -> value assignments.

Assignments that already exist are overriden by #included ini files, which is a great feature. Other than hardcoding section names, there is no good way to find out whether a section is a list or simply a good old fashioned section.
Not sure, but we might even have sections that are both.

The numbering problem modder666 mentioned came to my mind as well.
The order of numbers would of course equal the ini (inclusion) order. However, there are not many lists where the order actually matters (buildings, animations and overlay come to my mind).
This feature would still be a great help for lists such as VehicleTypes, InfantryTypes, or even #include itself.

[Renegade (renegade)]

Well, if they're auto-enumerating in the background, then the game has to have an idea which ones are lists?

And even if the game doesn't know which ones are lists - we do. We can just tell it "From [InfantryTypes] to the next section header, every legal line content is a list item."

After all, what else would come after that?

It's not like you'd have

[InfantryTypes]
0=Superman
1=Batman
DigSound=Nuke

somewhere.

As for the accidental override problem, that really only happens when you restrict yourself to the original numbers, doesn't it?

If you change your numbering to SOV1 SOV2 SOV3 for included Soviet buildings, it should work fine, right?

[pd (pdmail)]

Of course that would work, but it still would need me to go through the list and add numbers, which is plain annoying work (especially for building types).

This iterator just makes your life easier, you don't have to worry about copy and pasting around anymore, reordering lists, whatever. Of course, if you throw it around several included ini files, it will break list orders, but that's a problem with inclusion already.
Still, it is the modder's choice whether he wants to use this feature or not, I know I do.

It also follows the INI "syntax" (unlike your simple list idea without any '=' characters), and, thanks to the choice of '+', actually looks like an addition.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in; pd wrote in revision 578:
fixed issue #923
Related to issue 923 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=578&sc=1

[reaperrr (reaperrr)]

I've been using this for quite a while, and as far as I can tell it works fine. I haven't tested this with every list type, but those I tested ( [#include], [VehicleTypes], [InfantryTypes] ) seem to cause no problems.

[Renegade (renegade)]

Closed as per comment above.