On mod metadata, and INI files

[AL|EN]

@argent77 

The PI's ini is based on Windows INI: https://en.wikipedia.org/wiki/INI_file with a few changes:
- the single line comments are determined by # (hash) character instead of ' (single quote)
- additionally, since some modders confused the Infinity Engine ini files, the // (double forward slash) is also used as single line comments determiner

Since WIT already can handle multi-line key values for ini because there is a high probability that this will happen again, I will try to do the same for PI also since this limitation has no valid justification. There might be some edge cases discovered later but for now, let's support 99% valid usage.

P.S. I see no problem sharing the source code for PI ini parser if you still want it.

[argent77]

29 minutes ago, AL|EN said:

Since WIT already can handle multi-line key values for ini because there is a high probability that this will happen again, I will try to do the same for PI also since this limitation has no valid justification. There might be some edge cases discovered later but for now, let's support 99% valid usage.

Multiline support is currently only enabled for "Description" strings, but that restriction can be lifted if needed.

[jastey]

Don't get me wrong, if there is a good reason for a changed format of what is now the ini files I'll comply, and saying that it will not scramble display in other tools is a good reason. Still, I was like "aarrgh not again" when reading the discussion because time to update mods is always scarce and anything adding to the backlog is just just just, mean.

PRs sound good, though. (They'd still leave me with releasing a new version including announcements etcpp)

[AL|EN]

1 hour ago, argent77 said:

Multiline support is currently only enabled for "Description" strings, but that restriction can be lifted if needed.

Nah, it's not needed for any other keys, better to not open this cand of worms  When I handle this on PI side, I will update the metadata template with the info that the "Description" key is allowed to have multiline so 'copy & paste' from txt/html/other won't break it.

[suy]

Please, pretty please, whatever you choose, don't go with allowing multiline entries. This is not the default behavior, and as I've shown, I've tried different INI parser libraries out there and no one supports it. It means throwing away perfectly good code that already exists in battle tested libraries, and that follows the loosely specified conventions. Going that route is a huge incentive to not support those files at all for me.

PS: the criticism of TOML is unfair. No one should care that TOML supports times and dates, because every field of a mod metadata would only contain strings. So the mod metadata of any given mod that I've ever seen is just the same as no, but with quoted values. PI should have no issue in adding a new library and linking statically, which I assume is what you are doing already for having the application in a single file. But anyway, let's ignore TOML or other formats entirely, and instead focus on fixing the INI definition, please.

[lynx]

suy, nothing is stopping you from fixing the rare (I imagine) mods with multiline descriptions. It seems odd to advocate avoiding global workarounds while the bad state persists.

[argent77]

@suy Those are certainly good points but keep in mind that modders are (usually) no software developers. Choosing any kind of advanced file format will only increase the likelyhood of malformed data or dissuade modders from adding metadata at all.

Actually, I would rather prefer a made up data format with even simpler specs than the ini format, like this example (using the template data from the PI wiki) :

Spoiler

[Name]
Mod Example - Optional Features

[Author]
AL|EN

[Description]
This mod is a guide on how to use optional 'Project Infinity' features.
Multiple lines are allowed.

[Readme]
https://example.com/ModName-Readme.html
https://example.com/ModName-Readme-%LANGUAGE%.html

[Forum]
https://www.example.com/forums/categories/forum-thread

[Download]
https://github.com/AccountOrOrgName/ModExample-OptionalFeatures

[LabelType]
GloballyUnique

[Before]
ModX
EET_end

[After]
EET
ModY
ModZ

This is just meant as food for thought. Personally I'm perfectly fine with the ini format. But if there would be a switch then I'd propose to choose something as simple as that.

[Graion Dilach]

59 minutes ago, suy said:

Please, pretty please, whatever you choose, don't go with allowing multiline entries. This is not the default behavior, and as I've shown, I've tried different INI parser libraries out there and no one supports it. It means throwing away perfectly good code that already exists in battle tested libraries, and that follows the loosely specified conventions. Going that route is a huge incentive to not support those files at all for me.

PS: the criticism of TOML is unfair. No one should care that TOML supports times and dates, because every field of a mod metadata would only contain strings. So the mod metadata of any given mod that I've ever seen is just the same as no, but with quoted values. PI should have no issue in adding a new library and linking statically, which I assume is what you are doing already for having the application in a single file. But anyway, let's ignore TOML or other formats entirely, and instead focus on fixing the INI definition, please.

Call the format PI-INI which supports multiline and bam, you defined a new format which works. Case solved.

OpenRA did this same. It has it's own YAML-derivate which uses tabs instead of spaces and lacks half of the more complicated scenarios of the format. They ended up calling it MiniYAML in the end and even filed PRs at one point to GitHUb's own parser because the syntax highlighter just rendered all the config files being marked as wrong. Yet they didn't reverted from MiniYAML to regular YAML.

Being pedantic just for the sake of being pedantic doesn't add anything to the table. The PI metadata is a moreorless a community standrad by now, and widely adopted.