Jump to content

Read ini file > assign variable values


AL|EN

Recommended Posts

Just a thought - custom settings were specifically put into config file because modder (probably) didn't want to officially support them via tp2 subcomponents, but left a door open for advanced users who know what they're doing. So, I may by now be well behind the train when it comes to mod installation, but isn't BWS supposed to make the installation process easy for normal people, who don't know how to unpack a mod archive or edit a tp2 in notepad? Taking it a step further, IR has its weapon/armor overhaul data stored in easily accessible txt table in the mod's subfolder - done so both for the maintenance ease as well as to allow said advanced players to easily adjust the values. Would it also need to be presented by BWS to the user? Probably not, but I guess you see the direction I'm being a little skeptical of.

Link to comment

IR has its weapon/armor overhaul data stored in easily accessible txt table in the mod's subfolder

... no it doesn't, it's a text file called (item_rev/)settings.ini, which has slashes, spaces and tab's. It would be better to not have the last two... that way, the BWS can overwrite that file. But it would be better, if the file also had it's own override file optionalized in the setup.

Aka you have this:

ALWAYS
  OUTER_PATCH ~~ BEGIN
    PATCH_INCLUDE ~item_rev/settings.ini~
  END

Make it this:

ALWAYS
  OUTER_PATCH ~~ BEGIN
    PATCH_INCLUDE ~item_rev/settings.ini~
      ACTION_IF FILE_EXISTS ~item_rev/settings_autosetup.ini~ //name the file whatever youwish, as long as it's within a reasonablereference and readme mentiones it's specific name
      PATCH_INCLUDE ~item_rev/settings_autosetup.ini~
      END
  END

This way the autosetuptools need to only add the alternative file that doesn't exist there by default.

Or better yet, hide the file to a different folder and allow the optional settings.ini file in the main folder...for the user to use.

ALWAYS

OUTER_PATCH ~~ BEGIN

PATCH_INCLUDE ~item_rev/lib/settings.ini~

ACTION_IF FILE_EXISTS ~item_rev/settings.ini~

PATCH_INCLUDE ~item_rev/settings.ini~

END

END

 

 

I oversized the .ini-part, because for it to be a .txt table file, it can't have any other file extenssion but a .txt. It might have been that once, but is not so any longer.

Edited by Jarno Mikkola
Link to comment
... no it doesn't, it's a text file called (item_rev/)settings.ini

 

Yes it does, in the lib folder. It's not called "settings", but technically it's the same thing. My point is that while the ini file is more obvious, it's not the only place where users can fine tune mod's parameters before installing it. And neither is really meant to be tweaked by a casual user anyway.

 

So, when it comes to BWS, the question is whether it's really a good idea to allow ini tweaks in the first place. Like, if it lets users to customize their setup beyond what the tp2 structure offers, then shouldn't it grant access to even more obscure settings, if the main concept is to not deprive users of any customization options they might have had with traditional install process. If it is, then it might just defeat the purpose of being a lightweight solution for those who simply want to play the damn game instead of messing with technicalities. If it's not, then why include inis at all.

Link to comment

I agree with Ardanis; you absolutely dont want to have an autoinstaller algorithmically read the ini and present the options to end users. Several of SCSs ini options will definitely crash the game and only exist for my own modding/testing purposes. Others are for options I really dont recommend and dont want people to touch but put in to support a few vocal people. Others still just externalise choices for my own convenience. I actively want SCSs ini invisible to people who didnt come across it through detailed reading of the Readme.

Link to comment

I agree with Ardanis; you absolutely dont want to have an autoinstaller algorithmically read the ini and present the options to end users. Several of SCSs ini options will definitely crash the game and only exist for my own modding/testing purposes. Others are for options I really dont recommend and dont want people to touch but put in to support a few vocal people. Others still just externalise choices for my own convenience. I actively want SCSs ini invisible to people who didnt come across it through detailed reading of the Readme.

This is just a question on how you want the tool to present the factoids. In my mind, if the player wants to, he should be presented with all the options and let them figure things out for themselves.

Just like before, when the BWS was only able to customize wether or not install a mod with most of it's component, and now with the ability to choose between mod componets, I prefer the later ALWAYS.

ALIEN for example could make an exclusive GUI(graphical user interface) as a part of the install process, where most of the .ini choises are presented and so the user doesn't go blind at reading insurmountable texts, they each could have explanations in the GUI, ust like most of the components today have.

Link to comment

This is just a question on how you want the tool to present the factoids. In my mind, if the player wants to, he should be presented with all the options and let them figure things out for themselves.

Among the "options" in (my current local version of) stratagems.ini are

 

- Put_Labels_in_Workspace (changes SCS's default approach to where marker files are stored; optimistically, has no effect on in-game performance; pessimistically, prevents install)

- Debug_Variable (if set to 1 or 2, displays pages of meaningless text; if set to 3 or 4, will FAIL the install after getting part-way through)

- God_Does_Not_Play_Dice (if set to 1, disables all randomness so that you get the same result on each install)

- force_tra_rebuild (if set to 1, significantly slows install time with no effect on in-game results)

- disable_ssl (if set to 1, no scripts will be built, which will make most of the game nonfunctional)

 

 

I think the player can live without having those options presented to them.

 

 

Over and above that, there are other options that I actively think most people shouldn't use. I don't want people choosing them without really knowing what they're doing. Making sure they actually have looked at SCS's readme is a good way to check for that. A line or two of GUI text isn't. (And the very fact of an option being presented to end users in a GUI installer carries some implication that choosing the option is supported.)

Link to comment

Meh. If some players tell me "I like your mod but I'd rather not use this little piece of it..." well, who am I to tell someone how to play the game? Modding is all about letting people play the game their own preferred way. So if I can wrap that piece of my mod inside "ACTION_IF (ini_variable=1) BEGIN" without too much effort, sure I'll create an .ini option. And I think it's reasonable to give players a way to use those options with an auto-installer.

 

Again (this is the important bit), if it's not too much effort. If I have to take a class to learn JSON, whatever that is, then I'm sorry but I'm out.

Edited by subtledoctor
Link to comment

Meh. If some players tell me "I like your mod but I'd rather not use this little piece of it..." well, who am I to tell someone how to play the game?

1) There is a big difference between someone actively asking how to skip component XYZ, and someone just automatically being presented with the option to skip component XYZ at install time. In the former case, the player can be assumed to know what they're doing. In the latter case, they may not, and the implication to them is that this is a modder-supported option.

2) I am really confident that no player is every going to tell me "I like your mod but I'd rather set a variable that means it won't install properly".

Link to comment

I suppose then, depending on a mod, it boils down to the existence of two kinds of config options - one the players are actively encouraged to tweak, and another is unsupported and only exists for expert users who really know what they're doing. If so, then it could be as simple as formatting the former to be BWS-compatible on the modder's side and include it in case-by-case manner on BWS's side, rather than uniformly trying to read all settings files.

 

That is assuming I understand Alien's intent correctly, obviously.

Edited by Ardanis
Link to comment

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.

Edited by ALIENQuake
Link to comment

I suppose then, depending on a mod, it boils down to the existence of two kinds of config options - one the players are actively encouraged to tweak...

And that I too take as ALIENQuake wants to be able to edit with an automatical tool, like BWS. The "other", I don't think anyone really desires to be able to want to edit even if they are able to decipher them. And I would propose that all these settings that the player sould be able to easily edit are found in a standard file in a standard structure. [modfolder]/settings.ini ... see, as fake germans, we want to reculate and standardize everything.

Yes, the topic started at SCS forum... and from what I read, it's not really needed in the SCS's case, as there it's the "other" kind. Well, there is the options I have wanted to insist ... but "we"ll take what we can get, mostly as a replacement for READLN ... I suppose. On that note, like indicated, I am quilty on my mods.

But back to SCS: The file called settings.ini sounds very much like a standard file that should be the standard location... if you would, you might DavidW want to alter the file name to be some-any-thing else. Not that we insist on that.

Well, you do have a nice counter offer there. If it works.

 

 

... no it doesn't, it's a text file called (item_rev/)settings.ini

Yes it does, in the lib folder. It's not called "settings", but technically it's the same thing. My point is that while the ini file is more obvious, it's not the only place where users can fine tune mod's parameters before installing it. And neither is really meant to be tweaked by a casual user anyway.

 

But this, isn't really optimized result for editing, nor usability.

Yeah, the 3 files(armor_penalty_table.txt, bg2_weapon_stats.txt, ir_weapon_stats.txt) are actually more like a .2da formated individual item editing libraries. These serve different kinds of purposes... some less than others. I would say that there might be better ways to do this whole thing, BETTER. It's usability is now really restricted to mod production.

Edited by Jarno Mikkola
Link to comment

@Gwendolyne

 

- the 'configuration' was too long, point taken

- filename match pattern of *-config-default.<ini/json>

 

I can present such file to the user in a window, when user click "Save", the configuration file will be copied into "1pp-config.ini" next to "1pp-config-default.ini" Does you mod reads non-default user configuration from 1pp-config.ini? If yes, then everything is ready.

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...