Jump to content

Photo

Mod ACTION_READLN removal - brainstorming


75 replies to this topic

#76 ALIENQuake

ALIENQuake
  • Modders
  • 609 posts
  • Gender:Male
  • Location:Poland

Posted Yesterday, 07:06 AM

What about:

- Mod ships with settings defined in a default config file

- Mod includes a component which copies the default settings to a new file, and uses READLN to populate the various settings according to the user's wishes

- Rather than dealing with READLN, any user can instead make their own version if the config file. If it exists, the READLN component will be skipped.

- BWS/Project Infinity/Zeitgeist/whatever can simply skip the READLN component.

So Weidu users get a friendly question-and-answer READLN interface; power users can maintain their own settings for each mod; and non-interactive mod installation apps will work fine while supporting customization.

Good idea to populate user-config file with READLN values during first install. But BWS/Project Infinity/Zeitgeist/whatever cannot know which component contains READLN to skip it.

 

Let throw out an idea, and see if this is viable to the parties involved here. Imagine something like CONFIG as a tp2 flag, a la README:

 

CONFIG activefile [templatefile]

 

WeiDU would prompt if you wish to view (and or modify) the file, like README. It would give the modder the flexibility to name the file as they wish (and makes no imposition upon the file's actual format, content, or naming convention) and gives an easy flag for external installation tools to key off. Tweaks currently ships with cdtweaks.disabled.txt that, when renamed as cdtweaks.txt, becomes a config file. So Tweaks could use

 

CONFIG ~cdtweaks/cdtweaks.txt~ ~cdtweaks/cdtweaks.disabled.txt~

 

Where the first argument is the active config file, and the second (optional) one is a template file. If the active file is present, it's simply presented; if it's not then the template is copied to the active filename and then presented. The file itself would not be loaded or processed; that would remain for the mod itself.

Agree under the condition that second file is not optional(or it is forced via weidu) because otherwise we face overwriting user configuration problem. Also all names should be defined by weidu as constant. This is how it is coded right now for Project Infinity but the config file detection is based on filename, not some special tp2/tp3 keyword:

 

- if there is "<modname>-config-default.ini" will enable button to open it

- offer saving as "<modname>-config.ini"

- if "<modname>-config.ini" already exist, it opens this file, not default/template one

 

 

 

Let throw out an idea, and see if this is viable to the parties involved here. Imagine something like CONFIG as a tp2 flag, a la README:
 
CONFIG activefile [templatefile]
 
WeiDU would prompt if you wish to view (and or modify) the file, like README. It would give the modder the flexibility to name the file as they wish (and makes no imposition upon the file's actual format, content, or naming convention) and gives an easy flag for external installation tools to key off. Tweaks currently ships with cdtweaks.disabled.txt that, when renamed as cdtweaks.txt, becomes a config file. So Tweaks could use
 
CONFIG ~cdtweaks/cdtweaks.txt~ ~cdtweaks/cdtweaks.disabled.txt~
 
Where the first argument is the active config file, and the second (optional) one is a template file. If the active file is present, it's simply presented; if it's not then the template is copied to the active filename and then presented. The file itself would not be loaded or processed; that would remain for the mod itself.

It's a pragmatic suggestion for WeiDU as it is used today. The main problems I see is that it's another interactive feature that depends on the shell menus. I want to work towards a future where the shell menus can be axed. However, good should not be the enemy of perfect, but that brings us to the second point: READLN today is very accessible. If you can install mods interactively, you can give READLN a value. Editing config files manually is another matter altogether, and something I think a lot of users could find intimidating or bothersome. As lynx has pointed out, there is also the problem of input validation.
 
I'll gladly discuss the subject, but my preferred solution is this TP3 thing, in which config could be just another subsection, right beside, say, the component list. It would solve or side-step problems like what to call the config file, where it would be located, how you could be sure it really was config options intended for the user (as opposed to, say, internal knobs for the modder to tweak) and how to make the options available to programs other than WeiDU. Not writing the user's altered values to the TP3 itself could be solved by writing the config memory object to disk at another location (say, $GAME/weidu/config/$MOD), which would give us a standard directory for "mod state", such as backup files, debug files and other things. More on this flight of fancy will be forthcoming; I just haven't had the time to do a proper write-up.

 

I'm all for full weidu cover of such "CONFIG" functionality. The more default things will you set from the beginning , the easier it will be to support.


Edited by ALIENQuake, Yesterday, 07:07 AM.




Reply to this topic



  


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users