Author Topic: Mod-configuration system  (Read 3312 times)

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Mod-configuration system
« on: November 09, 2014, 02:19:48 PM »
It is widely known that READLN is awful. Yet, if you want to bother the user for "small" input or wish to avoid combinatorial explosions, it is your only readily available recourse. I'm thinking particularly of mods like Level 1 NPCs, for which installation could credibly be featured in a description of the realm of Tartarus. But more modest mods could also benefit from a less obnoxious alternative to READLN. Some mods already implement their own configuration/preference systems, but a standardised system would have all the usual advantages.

Concept

The system includes a configuration file, located somewhere in the mod folder, which lays out key–value mappings according to some particular syntax. The configuration system should preferably explicitly support domains. Support for multiple or conditional configuration files is thus not needed. The configuration file is loaded at some point during mod-installation and values are retrieved by their associated key through some convenient means.

Implementation

The configuration file should preferably be in some standard data format. I suggest a simplified JSON format, which would feature the data types (non-exponentiated) integer (subset of number) and string. The data types boolean [1], null, as well as the complement of number, are not relevant to TP2 and are not implemented. The format can very easily be used to express domains (using the object notation). Structures (arrays and objects [associative arrays]) can be implemented but are not planned at this stage.

Going with convention over configuration, the configuration file would be located in the root of the mod folder and would be called preferences.conf, or something to that effect.

Preference values would be retrieved with the value
Code: [Select]
GET_PREF string
which would return a value associated with the key string in the configuration file. If no configuration file exists or no key string exists or if key string maps to a structure, a failure is raised.

Thoughts?

1. Unless booleans are desirable for clarity of semantics or the like. Implementation-wise, it is very easy to have them (they can just be parsed and turned into 0 or not-0 in TP2). Having booleans would be preferable from the perspective of some day maybe also having schemas.

Offline The Imp

  • Planewalker
  • *****
  • Posts: 288
  • Gender: Male
Re: Mod-configuration system
« Reply #1 on: November 09, 2014, 06:12:00 PM »
Thoughts?
Well, if this enables an option that allows the usage of previously already set values, then I am all for it. Even if it takes effort from me the maker of the mod a little bit.
Not that I have the clarity of mind to understand exactly what you are saying... possibly, but ... that's cause I am not a trained programmer, just dabbling with copy-paste-edits. And trials and errors. Ouh the errors.
Actually I would say all I need a good and simple example, but that would be only me. So don't bother.

.. hmm, this just in, if the system would have several options of reinsertion, whe heh eheh. The first one is to use all the previously set values, another one would be to use the "next previously set value" and then it asks what to do next, and yet another is to use all the preset values typed into the weidu input without actually yet approving them(so pushing the Enter button would approve it, but it allows the correction/edits). --edit: rethinking this bit, it might be best to do just the last described option.
Ouh, and it would be nice if the system would also record and allow the usage of the possible random seed values.
« Last Edit: November 10, 2014, 03:40:30 AM by The Imp »

Offline Kulyok

  • Global Moderator
  • Planewalker
  • *****
  • Posts: 6253
  • Gender: Female
  • The perfect moment is now.
Re: Mod-configuration system
« Reply #2 on: November 10, 2014, 12:23:14 AM »
I'm just wondering how it's going to look for users. (If they have to change the config file to install the mod, I'm afraid that would be rather counterintuitive, but if the process would remain the same for a user and would only change for a modder, that's great).

Offline GeN1e

  • Planewalker
  • *****
  • Posts: 267
  • Gender: Male
Re: Mod-configuration system
« Reply #3 on: November 12, 2014, 12:13:51 PM »
That's pretty much the same as ALWAYS INCLUDE settings.ini END that SCS and Revisions do, is it not?

Offline Miloch

  • Barbarian
  • Planewalker
  • *****
  • Posts: 1032
  • Gender: Male
Re: Mod-configuration system
« Reply #4 on: November 12, 2014, 12:44:58 PM »
Thoughts?
Well, if this enables an option that allows the usage of previously already set values, then I am all for it.
I am as well, if it could avoid issues like this. In other words, some sort of system that stores the READLN values and allows retrieving them during reinstallation of a component.

The existing DEBUG logs do in fact record these values (something the bigg added a while back) but I'm not sure that's a good place to look for retrieving them as well. Then again, the data's already there.

If you're talking about making something less cumbersome in the first place (e.g. all the questions posed while installing L1NPCs) then I would support that too, though I'm not sure an external file makes this process easier for the end user. Of course, a WeiGUI would, where one could just check off boxes etc. Maybe having some sort of common data structure would be a step toward making that a reality at last.

As for booleans, we commonly just query Y/N or the like in the READLN, so it's either an integer or (small) string, but if it's easy to support them, might as well.

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Mod-configuration system
« Reply #5 on: November 12, 2014, 01:30:53 PM »
Thoughts?
Well, if this enables an option that allows the usage of previously already set values, then I am all for it.
I am as well, if it could avoid issues like this. In other words, some sort of system that stores the READLN values and allows retrieving them during reinstallation of a component.
READLN entries are already stored in the backup folders for unattended reinstallations. If you actively select reinstall (instead of just quitting and letting WeiDU go through its onion skins) then the READLNs get re-initialized. If they were not re-initialized, then you open the scenario where a player is trying to reinstall with different options and never gets prompted for input.

Not to defend it, as it's counter-intuitive to a lot of folks, but it's that way more or less out of necessity.
« Last Edit: November 12, 2014, 01:31:29 PM by CamDawg »
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

Offline The Imp

  • Planewalker
  • *****
  • Posts: 288
  • Gender: Male
Re: Mod-configuration system
« Reply #6 on: November 12, 2014, 02:36:53 PM »
READLN entries are already stored in the backup folders for unattended reinstallations. If you actively select reinstall (instead of just quitting and letting WeiDU go through its onion skins) then the READLNs get re-initialized. If they were not re-initialized, then you open the scenario where a player is trying to reinstall with different options and never gets prompted for input.
Hmm, so if I take this correctly(a large assumption), then we should rename the "Reinstall" -option as "Reinstall with possible previously set inserts", and the "No change" as "I want to change my previous inserts" ... just kidding a bit, but essentially that's what it boils down to... which is why the people get confused about it.

Well, changing the "No changes" to implicate that it deletes the predefined insertion values would do most of the work. That is, if my assumption is even correct.
« Last Edit: November 12, 2014, 02:53:44 PM by The Imp »

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: Mod-configuration system
« Reply #7 on: November 12, 2014, 03:37:28 PM »
Sorry, I'll try to address questions and such over the weekend.

For tiresome reasons (which I had put out of my mind, apparently), I'll have to switch the GET_PREF value for a clown-car of actions and patches. Well, if we're lucky, maybe one action and one patch.
« Last Edit: November 12, 2014, 04:45:46 PM by Wisp »

Offline The Imp

  • Planewalker
  • *****
  • Posts: 288
  • Gender: Male
Re: Mod-configuration system
« Reply #8 on: November 12, 2014, 05:05:28 PM »
Sorry, I'll try to address questions and such over the weekend.
Take all the time you wish, you just up-ed the v23700, so you deserve break.
And it's not like I am holding my breath wishing for you to answer the questions, I have a whole legion of hosts to suffocate. :)

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: Mod-configuration system
« Reply #9 on: November 16, 2014, 09:04:29 AM »
.. hmm, this just in, if the system would have several options of reinsertion, whe heh eheh. The first one is to use all the previously set values, another one would be to use the "next previously set value" and then it asks what to do next, and yet another is to use all the preset values typed into the weidu input without actually yet approving them(so pushing the Enter button would approve it, but it allows the correction/edits). --edit: rethinking this bit, it might be best to do just the last described option.
I'm not sure I understand what you mean, but it sounds like you are thinking of something else. There will be no interactivity here (that's sort of the point).

I'm just wondering how it's going to look for users. (If they have to change the config file to install the mod, I'm afraid that would be rather counterintuitive, but if the process would remain the same for a user and would only change for a modder, that's great).
Let's use a hypothetical mod as an example. The mod has a default configuration (in this case, whatever values the modder put in the configuration file), which includes the two options "price of turnips" and "colour of griffons". [1] If the user just installs the mod, the default values are used and the user does not have to do anything extra. If the user wants turnips to be cheaper, that change can be effected by editing the configuration file [2] prior to installation. So no, users do not have to edit the configuration file, but it becomes easier for the modder to expose options (that the user may choose to take advantage of).

By comparison, READLN is annoying, intrusive and bothers everyone, including users who just want to install the mod and start playing. If you want to do it with subcomponents, that gives you m * n subcomponents, where m is each price option and n is each colour option. As m and n become larger, the number of combinations quickly becomes inconvenient or unmanageable (this is a combinatorial explosion).

1. Or, if you want some examples that are not made up, SCS has, among others, the options "AI_Does_Not_Detect_Items" and "fiend_staying_power" which are, by default, some values DavidW thinks are appropriate, but which the user could change if so inclined.

2. Today, that would mean opening the file in a text editor, but the point to using a standard data format is that other solutions can easily be devised.

That's pretty much the same as ALWAYS INCLUDE settings.ini END that SCS and Revisions do, is it not?
It's to the same effect, yes.

I am as well, if it could avoid issues like this. In other words, some sort of system that stores the READLN values and allows retrieving them during reinstallation of a component.
As CamDawg said, READLN input is already stored in the backup folder. However, it is only used if the mod is installed non-interactively (e.g., you have mod A and mod B installed. You mess with mod A and this causes mod B to be non-interactively reinstalled). WeiDU does not reuse READLN values for component B if component A is reinstalled interactively, because the whole mod counts as being reinstalled interactively. (I'm not saying this makes sense, it's just the way it is now.)
« Last Edit: November 16, 2014, 09:05:11 AM by Wisp »

Offline Kulyok

  • Global Moderator
  • Planewalker
  • *****
  • Posts: 6253
  • Gender: Female
  • The perfect moment is now.
Re: Mod-configuration system
« Reply #10 on: November 16, 2014, 11:32:43 AM »
Okay, let's take a simple example: Level 1 NPCs, where I have to enter lots of numbers for Jaheira's thieving points and Xan's weapon proficiencies and Coran's new kit. When/if the new mechanism is implemented, will I be able to enter the values in the screen, or do I have to edit configuration file? I'm really wary of the second option, because it may easily lead to some players abandoning the mod - thinking the mechanism is too difficult, only for advanced users, etc.

Offline The Imp

  • Planewalker
  • *****
  • Posts: 288
  • Gender: Male
Re: Mod-configuration system
« Reply #11 on: November 16, 2014, 02:44:08 PM »
As CamDawg said, READLN input is already stored in the backup folder. However, it is only used if the mod is installed non-interactively (e.g., you have mod A and mod B installed. You mess with mod A and this causes mod B to be non-interactively reinstalled). WeiDU does not reuse READLN values for component B if component A is reinstalled interactively, because the whole mod counts as being reinstalled interactively. (I'm not saying this makes sense, it's just the way it is now.)
What we; Miloch, Kulyok and I are trying to get, at least from my perspective is; Could you make it optional to keep using the already stored inputs to each of the mod components ? Or add a functionality that facilitate this in the READLN function, or make a clone function that has this. And we understand that it can lead to install failures in the other parts of the install, and in the case you add the functionality, we(aka the mod maker) can and will take the responsibility of those failures.
As in, not to use the added functionality on dependent mod components.

Yeah, sorry for miss interpreting the origin of this topic and so leading it to different rails a LOTS. Now, back to the origin of the topic. -goes to poke people to come and give their feedback in this topic. :maniacal laughter:
« Last Edit: November 16, 2014, 03:03:11 PM by The Imp »

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: Mod-configuration system
« Reply #12 on: November 16, 2014, 07:44:26 PM »
Okay, let's take a simple example: Level 1 NPCs, where I have to enter lots of numbers for Jaheira's thieving points and Xan's weapon proficiencies and Coran's new kit. When/if the new mechanism is implemented, will I be able to enter the values in the screen, or do I have to edit configuration file?
That I leave to whomever is working on L1NPCs. But the concerns about user-friendliness are noted. The long-term plan is not that the user shall have to edit the configuration file by hand.

Could you make it optional to keep using the already stored inputs to each of the mod components ? Or add a functionality that facilitate this in the READLN function, or make a clone function that has this.
No, no and no. Mostly because the stored READLN info has already been deleted by the time it's needed (as part of the automatic uninstallation that precedes reinstallation), [1] but also due to the fact the (un)installation code is the definition of spaghetti and there is no way I'm spending the next year(s) chasing regressions on account of this.

1. Yes, this automatic reinstallation is different from the other automatic reinstallation.

Offline Azazello

  • The Anti-Spammer
  • Planewalker
  • *****
  • Posts: 405
  • Gender: Male
    • Azazello’s Music Profile at Last.fm
Re: Mod-configuration system
« Reply #13 on: November 17, 2014, 03:26:58 AM »
Okay, let's take a simple example: Level 1 NPCs, where I have to enter lots of numbers for Jaheira's thieving points and Xan's weapon proficiencies and Coran's new kit. When/if the new mechanism is implemented, will I be able to enter the values in the screen, or do I have to edit configuration file?
That I leave to whomever is working on L1NPCs.
That would not be me. Sadly.

I'm just chiming in to say-- am following the topic with interest.

And--I agree, it would be great to have a more userfriendly method for users' to initialize L1NPCs. Like Miloch said, a GUI would be a better (and best) method.
Community Contributions
Level 1 NPCs * gMinion: expanded TP2 for MegaInstalls * PSM (PSQM): expanded scripts for Melanthium * non-detectable Cloak of Non-Detection ?? * Weimer's-Tactics: revised TP2 for MegaInstalls
========================================
"Deception has many faces. Truth...has only one."

 

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Name: Email:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?: