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