AL|EN

I was under impression that you want to keep stratagems.ini filename regardless of the headers. I would prefer to have <modname>.ini + headers. I made few commits which reflect those changes, please take look and tell me if you are fine with them. Same here, I was also a fan of having them stored outside of tp2 as soon as the concept of metadata files was on board so don't worry.

Well, that's valid too, but unless you convince DavidW, I need to keep "<modname>-metadata.ini" scheme. The source of the mod metadata is the mod itself, not some external database.

Yet another fantastic work. Many thanks for providing such valuable guide. I've mention the "users have been known to copy the mod folder from one game to another" problem here: http://forums.pocketplane.net/index.php/topic,29639.msg338652.html and people ensure me that it's one of the problems which won't fix, even if weidu would add hardcoded prefix to the backup path. Now I'm not so sure. Does enforcing hardcoded part (let's say "<gamefolder>\weidu_backup") would help fix this problem for all mods at once without need to modify/fix tp2 code? Regarding directory Junction, Powershell 5.1 way: New-Item -ItemType Junction -Path G:\Gry\Beamdog\00766\stratagems -Value D:\OneDrive\EET-BWS\Mods\stratagems You can also use very nice and helpful application: http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html#download it has "Right-Click Menu", I really encourge anyone who is dealing with Junction/Symlinks to try it!

Happy anniversary

You sure ? Cause the p5tweaks comes with one inside ... Yes, it needs to be installed first. It doesn't matter that some mod has copy of it. You should know that.

Two metadata files can coexist to provide different kind of metadata: for a mod information and for mod dependencies I requested new keywords for tp2 long time ago. The wisp conclusion was that the tp2 code is not a good place for those information. Metadata files are much better suit for such data. Code vs Data separation: modification of the metadata it can be added/modified without touching tp2 file. They are industry standard, parser and tools are very solid etc.

Forget about BWS and it's limitations, I'm not loading the content of the INI using 80's win32 API. But you really would need to put whole book into "Description" value

You concerns about 'false-positive detection" are valid. I might have been gone to far in terms of "require nothing". That is why I wanted to receive feedback from modders. You "metadata.ini" is a good suggestion. The name reflects it's purpose. With one minor defect: It would be impossible to store multiple metadata files inside one directory. So how about <*-metadata>.ini ? So it could be "modtp2name-metadata.ini" but it doesn't have to be. The important pat is thee 'metadata.ini" part. I think it's very safe and no modder will create such file by accident. As an alternative to you comment/key-value, how about using a INI "Section", let's call it [Mod] or [Metadata] inside the ini file of any given name, which will be inside main mod folder, where tp2 file is: [Metadata] Name=NPCs Enhanced for Everyone Description=This is intended to be a successor to the fantastic "Level 1 NPCs" mod. L1NPCs was never updated for the EE games, and its author is no longer active, and it is an incredible, complicated piece of work that is difficult for someone else to update. So I made this. Download=http://lynxlynx.info/ie/modhub.php?UnearthedArcana/NPC_EE Such method can also be applicable to JSON/HJSON/JSON5. I believe that combining those two requirements could be very, very safe and no false-positive detection could occur. Unless there will be a major opposition to use INI Section, and a clear message from other modders that "filename schema will be enough" I would like to go for it.

Ad 1. It display the the value. So if you enter homepage, it will display homepage. You want three separate keys for online readme, online forum/post and homepage? No problem You have to define extra ini keys, I would need to add them to parser and "Mod Info box" it will display all of them. Ad 2. Good point: INI: https://en.wikipedia.org/wiki/INI_file JSON: Definition https://www.json.org, Validator https://jsonlint.com/ JSON5: Definition https://json5.org/, it's just the same as JSON with possible comments and less rules, no online validator yet :/ HJSON: Definition: it's just the same as JSON with possible comments and less rules, online validator http://hjson.org/try.html All of those formats are "human-readable".

I knew that even such simple and totally neutral change could face doubts and hesitation. Having a file header is not necessary a bad thing. But you want me to go against one of the most basic thing in the application development/programming word, that is "ignore comments when parsing a file". In addition, you want to base the whole search algorithm on this. What you programmers sense tells you? Also, I would need to write "algorithm" to scan every mod directory for specific file extension, parse it and extract specific data. And when if fails because "one extra character", people will complain to me. From my perspective it's a road to nowhere. My proposition/design also aims for be "less selfish as possible" aka "don't require anything and if, require minimal amount" Consider the fact that you are adding extra requirement: instead of having a simple <modTp2name>.ini file with "key=value" pair, I would need to require a extra file header. Recently, I suggested that the "mod version" should be required to be able to install the mod because its absence caused many problems for players, modders and BWS. The only thing I receive was a boycott. Imagine how people will react, when instead of putting <modTp2name>.ini file, they still have to worry about the correct header of the file. They will complain because it is unnecessary under the condition of which the file has <modTp2name>.ini naming scheme. You were first one using such naming scheme, that's true. Take a look at any of the apps which you are using and try to look for their configuration files. I'm sure that 90% of them are using "config" or "settings" filename. I understand that you don't see a reason. So let me clear the clouds: "<modTp2name> scheme is, IMHO a perfect naming scheme for "mod metadata file" - please read this proposal: http://gibberlings3.net/forums/index.php?showtopic=29669 Now, when you know what I'm aim for, could you reconsider renaming stratagems.ini to settings.ini/experimental.ini/anything which doesn't have possible tp2name? SCS is a mod which everyone takes example of.

Hi, let me start from make clear statement that NOTHING IS REQUIRED. Did I say that nothing is required? Yes, that's true, nothing is required. You don't have to do anything. My proposition/design also aims for be "less selfish as possible" aka "don't require anything and if, require minimal amount". I hope that's clear now. The main idea behind this is to give back the control of mod metadata in the hands of modders. Which person know the current and most up to date mod name, description or the working link to the place where players could receive support? That's right, the modder itself or current maintainer. The first idea was to have a website where modders could provide mod metadata. Creation of such website is very simple and can be done in one day. But then there is a problem when some other people will provide 'malformed' info about other people mods. Trolling is an art. It's impossible to counter without some sophistic login/verification method. And ofc "yet another website" will be instantly boycotted, even if it would be offer a Genie in a bottle. So without website, similar to "mod configuration file", a mod could provide few important metadata like: full name of the mod itself, without version number general mod description improved alternative for README keyword - you can also put direct links to online readme's link to mod dedicated forum or forum thread link to mod persona homepage if exist direct download link to the latest version of the mod This is my take on this matter: 0. File encoding: It can be ANSI if it won't contain Unicode strings. UTF8 (no BOM), if you want to use local language characters. 1. File format of such file must be 'industry standard', one for all mods. And please forget about xml I can't write a custom parser for each mod only because it's author like to put spaces before and after '=' character. Or use TAB to separate key and values. Or include weidu commands which only WeiDU can parse with it's GLR parser. It would be too much work. So let's choose one, modern 'industry standard' file format. My vote goes for INI as a first choice. 2. File extension of 'mod metadata file': Almost irrelevant, follow the file format definition associated extension. Those files shouldn't be modified by players anyway. 3. Filename of such 'mod metadata file'. There is one, very simple solution: <modTp2name>.ini. This is what is currently implemented. - it doesn't require file header / ini sections added [Mod] require [Metadata] section header to avoid false detection - it prevents people from making multiple, outdated version of this file 4. File content: nothing is required, you can even put one, single line Key=value pair with only mod full name. The INI will have preference over data from tp2. INI: # Never copy this from other mod, always use https://github.com/ALIENQuake/ProjectInfinity/wiki/Adding-metadata-for-mod # Filename must be the same as tp2 basename, placed at the same folder where # .tp2 file is located, use "UTF8 without BOM" encoding, everything is optional # ini section header is required to avoid false detection [Metadata] # Full name of the mod, without the version number, without the list of supported games Name = Mod Example - Optional Features # Author name or nick, don't use an email address Author = AL|EN # Short description of the mod, main goals, features etc Description = This mod is a guide on how to use optional 'Project Infinity' features. # Web address of mod readme file (filename is case-sensitive!) You can link to txt, md, html, pdf etc. Readme = https://example.com/ModName-Readme.html, https://example.com/ModName-Readme-%LANGUAGE%.html # Web address of mod dedicated forum or forum thread Forum = https://www.example.com/forums/categories/forum thread # Web address of mod personal Homepage, no need to duplicate with a mod dedicated forum # Homepage = https://www.example.com # if you use Github.com, simply use https://github.com/AccountOrOrgName/RepositoryName # read more about Delta Updates https://github.com/ALIENQuake/ProjectInfinity/wiki/Delta-Updates-for-mods-hosted-at-Github Download = https://github.com/AccountOrOrgName/ModExample-OptionalFeatures Remarks: If there will be a demand, PI could use JSON with comments file or JSON5/HJSON, it has very strict rules, only for modders who wan't to benefit from the advantages of the JSON file format itself. Order of the preference: JSON > JSON5/HJSON > INI . It means that if you provide only INI, everything works. Later, if someone wan't to switch to more advanced metadata format, mod metadata will be read from them. I think that INI would be enough but I don't want to limit modders. 5. Visual representation: - mod metadata will be displayed inside "Mod info textbox" - in addition, mod name will be displayed at treeview/mod list - mod download link would be used to download new mod version (if it is supported) If you have suggestions or questions, feel free to ask.

As soon as I you wrote that SCS ini contains only experimental/debug settings, I don't want to edit it not present to user for edits. Don't worry. Discussion moves in the direction of replacing READLN or usage such config file for basic user settings, which was my only intention. Since SCS doesn't contain READLN nor basic user settings, even changing ini to be 'true ini' is irrelevant. Yet, you can still solve "overwrite default advanced configuration" problem, even if ini file is not intended for the normal user, correct? This is up to you, ofc. If you intend to do it, you should use filenames which won't be detected via tool like "configuration-default.ini", "configuration.ini" so there won't be surprises. Regardless of fixing "overwrite default advanced configuration" problem, may I have yet another future concern? Currently, the stratagems.ini falls into into naming scheme "sameAStp2name.ini", can you change it anyway to for eg: settings.ini/experimental.ini/anything which doesn't have possible tp2name?

Guys, my point was to use ini for eradicate READLN nightmare and present normal options, not to present experimental options for advanced users. So let's forget about those concerns, ok? Now we have code which can be adopted to any mod if it has READLN (level1npc, 1pp) or basic user settings (Scales of Balance) etc. Mods with debbug/experimental settings will simply not use code/example and everything will be fine for them.

Version 0.0.3: BACKUP "GlobalVariableFromIni/backup" SUPPORT "" VERSION "0.0.3" AUTO_EVAL_STRINGS ALWAYS OUTER_SPRINT config-default "%MOD_FOLDER%/config-default.ini" // default config file to read initial variable values OUTER_SPRINT config "%MOD_FOLDER%/config.ini" // user created file, not included inside mod archive, if exist it will overwrite variable values from default config file DEFINE_ACTION_MACRO Set-GlobalIniArray BEGIN OUTER_TEXT_SPRINT $GlobalIniArray("%key%") "%value%" END DEFINE_PATCH_FUNCTION Get-IniArray INT_VAR start_offset = 0 RET start_offset end_offset RET_ARRAY GlobalIniArray BEGIN SET offset = start_offset PATCH_IF (offset < 0) BEGIN SET offset = 0 END PATCH_IF (offset > BUFFER_LENGTH) BEGIN SET offset = BUFFER_LENGTH END SET start_offset = "-1" SET end_offset = "-1" SET ofsStart = INDEX_BUFFER("[0-9a-zA-Z]" offset) PATCH_IF (ofsStart >= 0) BEGIN SET ofsValue = INDEX_BUFFER("=" ofsStart) PATCH_IF (ofsValue >= 0) BEGIN READ_ASCII (ofsStart) key (ofsValue - ofsStart) TO_LOWER key SET ofsEnd = INDEX_BUFFER("[%WNL%]" ofsValue) PATCH_IF (ofsEnd >= 0) BEGIN READ_ASCII (ofsValue + 1) value (ofsEnd - ofsValue -1) SET start_offset = ofsStart SET end_offset = ofsEnd INNER_ACTION BEGIN LAM Set-GlobalIniArray END END END END END DEFINE_ACTION_FUNCTION GlobalVariableFromIni STR_VAR filename = "" RET_ARRAY GlobalIniArray BEGIN COPY - "%filename%" "override" INSERT_BYTES SOURCE_SIZE (STRING_LENGTH "%WNL%") WRITE_ASCIIE SOURCE_SIZE "%WNL%" REPLACE_TEXTUALLY ";.*" "" REPLACE_TEXTUALLY "#.*" "" COUNT_REGEXP_INSTANCES CASE_SENSITIVE "=" variable start_offset = 0 FOR (i = 0 ; i < variable ; ++i) BEGIN LPF Get-IniArray INT_VAR start_offset RET end_offset RET_ARRAY GlobalIniArray END start_offset = end_offset END END PRINT "%config-default%" LAF GlobalVariableFromIni STR_VAR filename = "%config-default%" RET_ARRAY IniArray = GlobalIniArray END ACTION_IF FILE_EXISTS ~%config%~ THEN BEGIN PRINT "%config%" LAF GlobalVariableFromIni STR_VAR filename = "%config%" RET_ARRAY IniArray = GlobalIniArray END END END BEGIN "Component 1" DESIGNATED 1000 LABEL "Main" ACTION_PHP_EACH IniArray AS key => value BEGIN PRINT "key: %key%" PRINT "value: %value%" OUTER_SPRINT "%key%" "%value%" END Looks good?

This one is breaking format rules: text =value key cannot have spaces before '='. However next one is correct: text=value spaces before key should be ignored, so key name should be 'text'.

@Gwendolyne thanks it works for me also @kjeron Just for the record, you can't set you own rules for industry standard file format like "// key must start line and cannot contain whitespace". It's perfectly fine to have whitespace before key name for ini files. Nobody will create such file in the first place but in case of such whitespace, it should work. But I'm sure that the probability is extremely low so we are safe. Thanks for contribution.

It would be a hack of well defined industry file format. Ini file is not only for the mod itself, it's also for install tool. And Install Tool can't read anything except standard industry file formats like ini/json etc

;timer11 timer11=0 ;timer12 timer12=0 ;timer13 timer13=0 Same as 3rd post.

I'm keep getting INSERT_BYTES out of bounds - file is long 34, point given is 61 ERROR: [GetIniSetVariable/default_configuration.ini] -> [override] Patching Failed (COPY) (Failure("INSERT_BYTES out of bounds")) error :/

Since we we treat keys as case insensitive, variable count should be counted by unique keys, not '=' characters. But that only for debugging etc.

You code skips last key=value from ini if there is no end line character/EOL. Can you check it please?

@Gwendolyne Does you code assumes that Ini keys are case insensitive?

I wanted to ask about possible differences but what you say is indeed that's true. I will modify my code example.

@Imp This is what you could use to make players and install tool happy: http://gibberlings3.net/forums/index.php?showtopic=29657&p=262759 EDIT: Version 0.0.2

This is what I did using DavidW code and advices: BACKUP ~GetIniSetVariable/backup~ SUPPORT ~GetIniSetVariable~ VERSION ~0.0.1~ AUTO_EVAL_STRINGS ALWAYS OUTER_SPRINT configuration-default ~%MOD_FOLDER%/configuration-default.ini~ OUTER_SPRINT configuration ~%MOD_FOLDER%/configuration.ini~ DEFINE_ACTION_FUNCTION GetIniKeyValue STR_VAR filename="" RET_ARRAY ini_content BEGIN COPY - "%filename%" "%override%" // "COPY -" means no actual changes to the file REPLACE_TEXTUALLY ";.*" "" REPLACE_TEXTUALLY "#.*" "" REPLACE_TEXTUALLY "=" " " READ_2DA_ENTRIES_NOW ini_entries 2 FOR ( i = 0 ; i < ini_entries ; i += 1 ) BEGIN READ_2DA_ENTRY_FORMER ini_entries i 0 key READ_2DA_ENTRY_FORMER ini_entries i 1 value SPRINT $ini_content("%key%") "%value%" END END PRINT "%configuration-default%" PRINT "%configuration%" LAF GetIniKeyValue STR_VAR filename="%configuration-default%" RET_ARRAY ini_content END ACTION_IF FILE_EXISTS ~%configuration%~ THEN BEGIN LAF GetIniKeyValue STR_VAR filename="%configuration%" RET_ARRAY ini_content END END END BEGIN ~Component 1~ DESIGNATED 1000 ACTION_PHP_EACH ini_content AS key=>value BEGIN PRINT "%key%: %value%" END Very simple code, but it does what we need.