Jump to content

stratagems.ini


Recommended Posts

Hi @DavidW

 

There is no industry standard way way to read stratagems.ini as it isn't 'ini' file by it's technical definition. It doesn't even contain "Key=Value" pair. It's a text file with characters and numbers divided by spaces. Because of that, there is no standard way to read this configuration and present to player.

 

May I suggest to use industry standard format like ini/json/xml etc ?

Edited by ALIENQuake
Link to comment

Clever. In an INNER_PATCH or something?

 

SCS tries very hard to separate code and data, though, and since I already have an ini-reader function coded it's just a matter of changing a line in that function. (Also, that keeps the ini entries out of the global namespace - I just check them with LAF check_ini STR_VAR ini=whatever_it_is_we_are_checking RET value END. But that's more being fastidious than anything else.)

Link to comment

Oh, I believe you're missing the laziest option of all--a tpa masquerading as an ini file.

Ha! Amazing creativity when you need to "get things done" :thumbsup:

 

 

 

It's not intended to be read by anything except SCS itself, which is why it follows no particular format. However, if it would be helpful I don't particularly mind changing it to key = value.

 

I'm aware that the purpose of this file is to be read only by SCS. It would be very helpful to change the format of this file to "Key=Value" pairs because I can parse it via industry standard algorithm.

 

I notice one problem with the way how you designed the "reading SCS custom option from configuration file":

 

Steps to reproduce:
0. Download and extract SCS
1. Edit stratagems.ini and set desired options
2. Install SCS 31
4. New version is released, download and extract SCS 32 > stratagems\stratagems.ini will be introverted to default one, it will happen every time when new version will be released > reinstall SCS
Possible way to fix:
- rename stratagems.ini to configuration-default.ini (reason for renaming - I try to be one-step-ahead of what I will ask/provide by myself next)
- change 'read setting logic' to always read from configuration.ini it it is present
If you could fix this before releasing 32, you will save yourself the trouble of receiving bug reports about 'my settings don't work anymore'
Edited by ALIENQuake
Link to comment

Oh, I believe you're missing the laziest option of all--a tpa masquerading as an ini file.

 

That's my move. :laugh: My mods are full of

DEFINE_ACTION_FUNCTION
  OUTER_SET variable = 1
END

...in INCLUDEd files. The mod then uses LAF to set the relevant variable for its own purposes.

 

In one case I even chuck the .tpa file in /override, so the preferences will survive mod reinstalls.

Edited by subtledoctor
Link to comment

 

Oh, I believe you're missing the laziest option of all--a tpa masquerading as an ini file.

Ha! Amazing creativity when you need to "get things done" :thumbsup:

 

 

 

It's not intended to be read by anything except SCS itself, which is why it follows no particular format. However, if it would be helpful I don't particularly mind changing it to key = value.

 

I'm aware that the purpose of this file is to be read only by SCS. It would be very helpful to change the format of this file to "Key=Value" pairs because I can parse it via industry standard algorithm.

 

I notice one problem with the way how you designed the "reading SCS custom option from configuration file":

 

Steps to reproduce:
0. Download and extract SCS
1. Edit stratagems.ini and set desired options
2. Install SCS 31
4. New version is released, download and extract SCS 32 > stratagems\stratagems.ini will be introverted to default one, it will happen every time when new version will be released > reinstall SCS
Possible way to fix:
- rename stratagems.ini to configuration-example.ini (reason for renaming - I try to be one-step-ahead of what I will ask/provide by myself next)
- change 'read setting logic' to always read from configuration-example.ini it it is present
If you could fix this before releasing 32, you will save yourself the trouble of receiving bug reports about 'my settings don't work anymore'

 

Interesting point.

 

I am allergic to letting SCS modify itself, so that doesn't quite work as stated, but a variant would work.

Link to comment

"change 'read setting logic' to always read from configuration-example.ini it it is present"

It was a typo, I mean "change 'read setting logic' to always read from configuration.ini if it is present" similar as example below.

 

On reflection (unless I'm misunderstanding your proposal) this does have the problem that if I add new entries to stratagems.ini they won't be present in the user's copy.

Good catch. First solution for this problem which comes to my mind:

 

step 1: read configuration-default.ini file

step 2: if file exist, read configuration.ini file and use user customized values for previous keys

 

This way, you can add new config variables with default values while keeping user customized values. Thoughts?

Edited by ALIENQuake
Link to comment

ALIEN, how would you handle variables set in configuration.ini file?

 

I am currently polishing a new 1pp release and I have not yet made my decision on keeping the READNL process or transferring the variables set during install process into an ini file. I mean, I am an old bear and I don't use install tools. So it would be very easy for me to modify the default values in config.ini, then install the mod. But how BWP Install, BWS (or whatever tool) would handle this?

Do you suggest that the player should copy the original config.ini file, change its settings and save them into myconfig.ini? Thus the install tool would check for myconfig.ini and config.ini, then give the priority to myconfig.ini when installing the mod?

Edited by Gwendolyne
Link to comment

ALIEN, how would you handle variables set in configuration.ini file?

...

Do you suggest that the player should copy the original config.ini file, change its settings and save them into myconfig.ini? Thus the install tool would check for myconfig.ini and config.ini, then give the priority to myconfig.ini when installing the mod?

And if we could get a good weidu code example of this, I would be golden. I am too in a process of utilising READNL that could adapt a .ini file ... in an old mod that used it, before me, and are genuinely intrested in moving far away from it. Perhaps. Aka I won't promise DAMN a thing.

Link to comment

ALIEN, how would you handle variables set in configuration.ini file?

 

I am currently polishing a new 1pp release and I have not yet made my decision on keeping the READNL process or transferring the variables set during install process into an ini file. I mean, I am an old bear and I don't use install tools. So it would be very easy for me to modify the default values in config.ini, then install the mod.

 

First of all, it's really motivating to see modders who want to make players life easier. When I take look at READLN, it's the worst, most evil thing I could image. If my work would help you to get rid of it, I'm all ears.

 

Do you suggest that the player should copy the original config.ini file, change its settings and save them into myconfig.ini? Thus the install tool would check for myconfig.ini and config.ini, then give the priority to myconfig.ini when installing the mod?

 

The most important thing is that an user-defined/modified config file should not be overwrite by new mod version because mod updates would destroy user configuration and cause infinite amount of frustration for them. This is one of the solution which I've posted. The logic to read both files and prioritize user values has to be coded inside mod itself but the file format of such file must be 'industry standard', more about this below...

 

But how BWP Install, BWS (or whatever tool) would handle this?

Forget about the past, new install tool could present 'mod configuration' dialog with editable values, but there are few key points:

0. File encoding

It can be ANSI if it won't offer to write Unicode strings. UTF8 no BOM, it it does.

 

ANSI:

;use only english color names
Colors=Red
UTF-8:
;Put anything here, including Unicode characters
ComanionName=Pszczółka 

does weidu can read UTF8 files?

 

1. File format of such file must be 'industry standard', one for all mods. And please forget about xml :p 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 the tool can't understand. It would be too much work and errors. So let's choose one, modern 'industry standard' file format. I vote would be for INI as a first choice and HJSON (JSON doesn't' allow comments) for more advanced modders who understand benefits of such modern format. More about this at point 4.

 

2. File extension of 'default configuration file': It would be the best for the tool to use correct file extension. My test shows that .ini files are opened via notepad on default, clean windows installation. Nothing to worry CamDawg :)

 

3. The filename of such 'default configuration file' and 'user configuration file', I propose 3 solutions:

 

a) first detection/priority:

will be defined by modders via mod tp2 file and "CONFIGURATION" keyword. It doesn't exist today, I can support it if it will be introduced. But I would rather avoid to depend on weidu.

 

b) second detection/priority: will be defined by modders via "mod metadate file"
- filename is the same as tp2: modname.tp2 > modname.ini/json
- file is placed at the same directory as tp2 file
- it has simple
configuration = configuration.txt/ini/json

key=value pair. This would allow more flexibility.

 

c) third detection/priority: it will be defined via install tool itself because otherwise every mod will have different configuration file names and my only option would be then to scan mod folder for 'ini' or 'txt' or 'cfg' or something else and detect if it's a true mod configuration file. This is terrible way to do things. So this is my take:

configuration-default.ini/json - for default mod values

configuration.ini/json - for user-defined values, install tool will create copy of it when user will click "Configure Mod Options"

 

4. File content

It should follow the format definition. So if it's ini, it has only key=value pair or comments (comments for ini are ; or #) :

 

INI:

;This variable will remove the racial requirement if set to 1
;e.g. a value of 1 will allow Viconia to romance gnomes, or Aerie half-orcs
romance_racial_requirements=0
;This variable will remove the gender-based requirements for romances if set to 1
;e.g. a value of 1 will allow Anomen to romance males or Jaheira to romance females
romance_gender_requirements=0
...

 

HJSON:

{
    #This variable will remove the racial requirement if set to 1
    #e.g. a value of 1 will allow Viconia to romance gnomes, or Aerie half-orcs
    romance_racial_requirements: 0

    #This variable will remove the gender-based requirements for romances if set to 1
    #e.g. a value of 1 will allow Anomen to romance males or Jaheira to romance females
    romance_gender_requirements: 0
}

5. Presentation to user

 

When tool will detect 'configuration' file, using any of the method from Point 3, it will show "Configure Mod Options" button which will:

 

If 'configuration.ini' file doesn't exist:

- create 'configuration' file by coping 'configuration-default.ini'

- open 'configuration.ini' file using default system editor

 

If 'configuration.ini' file exist:
- open 'configuration-default.ini' file using default system editor
(there is also possible to scan and add missing values from 'configuration-default.ini' but I would have to test it and see how it works, not promises for now)
That's very simple yet effective approach. More advanced approach would be to add "key=value" pairs as a editable nodes in TreeView below all mod components :) More work but it can be done. I will post example later.

 

6. Input constraints

How about declare input constraints like "between 1 and 5" or choose only from 'green' 'red' values? Does it's something which you would like to have or it's out of scope and should be handled via mod tp2 internal logic ? It would require extra data to be included inside file but it can be done.

 

That's everything which comes to my mind, let's do this :thumbsup:

Edited by ALIENQuake
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...