projectinfinity ACTION_READLN - replacement examples

[Wisp]

While the ALPHA version works only on windows, I'm not using "windows only" language like AutoIT. So the cross-platform is definitely possible.

Out of curiosity, what language are you using?

[AL|EN]

On 10/7/2018 at 8:11 PM, Wisp said:

 

On 10/2/2018 at 6:02 PM, ALIENQuake said:

While the ALPHA version works only on windows, I'm not using "windows only" language like AutoIT. So the cross-platform is definitely possible.

Out of curiosity, what language are you using?

 

Powershell an a bit of c#, both open source and cross-platform 

Edited January 20, 2019 by AL|EN
added "both open source and cross-platform"

[lynx]

[Gwendolyne]

 

There is a more serious problem — input verification. If you just read it from an ini, what do you do about typos? READLN can handle it nicely:

ACTION_READLN ~newmax~
OUTER_WHILE NOT(IS_AN_INT %newmax% && %newmax% > 0 && %newmax% <= 10) BEGIN
  PRINT ~Enter a whole number between 1 and 10 silly.
What should the new maximum party size be? [1-10]~
  ACTION_READLN ~newmax~
END

You ignored the verification problem. Or are you suggesting user choice should be ignored in case of mistakes?

 

I faced the problem when rewriting 1pp. I solved it with this warning:

General overhaul and re-looking:

 

- Variables needed for installation are read from 1pp-config-default.ini or 1pp-config.ini files.

The previous version interrupted installation with plain text prompts allowing players to customise components to their liking (depending on which IE game the mod is installed for and already installed components). All those variables set during installation have been moved into 1pp-config-default.ini file in 1pp folder. This file provides a 'standard' installation. If players want to define their own customized installation, they have to modify the variables involved in 1pp-config-default.ini and save this file as 1pp-config.ini. The installation process will read both ini files and prioritize user values. If a value is not set or mismatched in 1pp-config.ini, the installation process will prevent any installation failure by reverting it back to its default value.

 

*

and included the code in the ALWAYS block section.

 

Edited October 7, 2018 by Gwendolyne

[CamDawg]

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.

[DavidW]

Nothing is related to BWS/new install tool except "missing treeview nodes". The ACTION_READLN is simply bad for mods, period.

That doesn't seem quite right. As long as people are in the WEIDU paradigm and aren't megamodding, READLN has advantages: if I write a mod that gives you a cute little puppy and lets you name it, entering the name in the field of a READLN is simpler and more direct than the ini alternative. (That's even more obvious for certain tools: I routinely use a micromod that lets me label all script blocks of a given BCS for debugging purposes, and it's way easier to specify the script via READLN than via an ini.) The point (I take it) is that READLN is a problem for uninstall/reinstall stacks and does not play nice with non-interactive install tools like BWS or Zeitgeist.

 

Expecting from modders to adopt their mods for install tool is wishful thinking. Regarding blacklist: try to tell people that "Worldmap" mod is no longer available for BWS/new install tool and as a consequences 6 or more other mods cannot be installed ...

I think not all mods are equal here. There are some mods that are popular enough that if your install tool doesn't work with them, people won' use it. For instance: SCS, Tweaks, Ascension, Quest Pack, Unfinished Business, BG1NPC, probably SR/IR, some of the better-loved NPC mods, and probably a handful of others that I'm not au fait with because I haven't really kept up with that side of things for some while. You need to make sure your tool works on those mods at the outset, and that means you need to work with their authors to achieve compatibility.

 

But that list is, I think, *relatively* small. If you (or indeed Wisp) release a non-interactive GUI install tool that supports lots of mods including all the ones on that list, and that is smooth and easy to use, the pressure on other mods to adopt to it will rise sharply. (If someone releases an install tool that's incompatible with SCS, I'm going to shrug, because SCS is popular enough that the tool won't get widely adopted. If someone releases an install tool that's incompatible with Wheels of Prophecy, which afaict is way less popular, there's much more incentive for me to fix WoP to restore compatibility.)

[Wisp]

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.

Edited October 8, 2018 by Wisp

[Wisp]

(or indeed Wisp) release a non-interactive GUI install tool

Hey, I have to take issue with that. Zeitgeist is not properly released, but it is today (or indeed, as of years ago) no less useful for (un)installing mods than WeiDU on the command line. It is less a matter of Zeitgeist being unfinished (it is, but that is beside the point) and much more a matter of mods being adapted for interactive installs and more or less unsuited for non-interactive installs, regardless of how they are done (Zeitgeist, command line or otherwise). Supporting all the same mods as WeiDU itself is a given and that includes mods that use READLN. However, if you install mods non-interactively, I'd say it becomes clear that READLN is out of place, in a way that it isn't when the process is interactive. I hope READLN will eventually fall out of style, but it will remain supported. Edited October 8, 2018 by Wisp

[subtledoctor]

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.

[DavidW]

 

(or indeed Wisp) release a non-interactive GUI install tool

Hey, I have to take issue with that. Zeitgeist is not properly released, but it is today (or indeed, as of years ago) no less useful for (un)installing mods than WeiDU on the command line. It is less a matter of Zeitgeist being unfinished (it is, but that is beside the point) and much more a matter of mods being adapted for interactive installs and more or less unsuited for non-interactive installs, regardless of how they are done (Zeitgeist, command line or otherwise). Supporting all the same mods as WeiDU itself is a given and that includes mods that use READLN. However, if you install mods non-interactively, I'd say it becomes clear that READLN is out of place, in a way that it isn't when the process is interactive. I hope READLN will eventually fall out of style, but it will remain supported.

 

I'm really happy to stand corrected - but last time I tried Zeitgeist it looked as if it wasn't in official-release mode - there were some quite serious graphical glitches. (I couldn't get it to untick tickboxes, in particular.)

[Jarno Mikkola]

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.

Go a head and code that in weidu for 3 variables.

Ouh and install the worldmap mod and skip the main component that uses READLN in BGT-weidu+CtB+RoT+SoS+TDD+other mods -install, and call that a complete install of a succesful tool.

Edited October 9, 2018 by Jarno Mikkola

[Wisp]

I'm really happy to stand corrected - but last time I tried Zeitgeist it looked as if it wasn't in official-release mode - there were some quite serious graphical glitches. (I couldn't get it to untick tickboxes, in particular.)

I can't reproduce untickable tickboxes, but I did run across a glitch with the radio buttons (affecting Windows only; the joys of cross-platform code). If you remember any more or any other issues, please feel free to report it in the WeiDU forum or on github. Edited October 9, 2018 by Wisp

[c4_angel]

Hello.

 

I agree to the concept of removing READLN, but I cannot figure out the solution to my mod (published only on a forum with Chinese players by now):

It requires the player input 3 different hotkeys (from A to Z) during installation, also checks if any typo or confliction when input the 2nd and the 3rd hotkey.

 

I think neither solution 1 or 2 can handle this easily.

[Ardanis]

I suppose you could make the installer automatically increment a wrong letter by one until it hits a free slot. But yes, it's not not exactly user friendly.

[DavidW]

Or else just define some defaults, and revert to the defaults unless the player choices pass validation.