projectinfinity ACTION_READLN - replacement examples

[AL|EN]

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 October 14, 2018 by ALIENQuake

[cmorgan]

So to summarize, just so I understand - 

ACTION_READLN (which I use a good bit to give a huge amount of user choice on install in Aran) is not on the current chopping block.

BUT it is frustrating to mega-install tool development and maintenance. 

AND the current status of the technology is

1. run out all of the various choices as individual subcomponents leveraging GROUP 

2. Investigate and copy Tweaks use of a custom configuration file (anything else out there to crib from/compare/contrast)

or

3. Ignore this as very few folks are likely to use Aran on release

Did I miss an alternative?

And finally, going forward the consensus seems to be that A_R manual input is a less favorable and less versatile construct for installation and eventually the player base will either manually set a configuration file or have an install tool other than Weidu do it (fuzzy on this last one). 

 

Do I have this correct (before I go spend hours figuring out how to reconstruct multiple user inputs into defined files)?

 

(I am not afraid of a little work - this is nothing compared to the initial work necessary for crossplatform stuff. I just don’t want to go down any unnecessary rabbit holes - I make enough of those on my own...)

[AL|EN]

Hi cmorgan

For me, dealing with A_R it's not only frustrating to mega-installs and tools. If you support three games:  BG2, BGT, and BGII:EE and you only testing 3 main components, it's still a hustle to make clean installation when you have to manually send input instead of just use weidu.exe aran/aran.tp2 --force-install-list 1 2 3. Just think about the amount of unnecessary actions in order to test mod installation.

As for choosing right way to get rid of A_R from Aran mod:

1. There is one more alternative: "3. Custom ini file" (this one need feedback from modders who don't want to change weidu tp2 code) look at the first post of this thread. It requires additional file to be included inside mod and it needs to be updated every time when you will change tp2 component numbers/choices. It is only supported by my new install tool and it's really the last thing which you should consider (unless there is no way to change tp2 code).

2. If you really want to use solution which will read values from ini file, you should investigate this function instead, it has already a nice setup and prevent "new mod version overwrite user settings" bug. The way how you name ini files matters for my new install tool. If you follow the Gwendolyne example, you mod could provide support for "Mod Configuration" button.

3. But from what I see, you can use SUBCOMPONENT feature, if you make you do a slight adjustment of the mod components structure. This way is the best way because even weidu console/interactive installation will benefit from it. The goals are: don't ask about changing something if the user doesn't want to change it (via "Do you want to see components from x group"), offer additional things as simple components:

- instead of choosing "Default Talk and Flirt Timers" or "Customize Talk and Flirt Timers" include defaults into main component and offer changing of Talk and Flirt Timers if the player really want it
- instead of asking to "Do not install any audio" offer a choice to install only those audio parts which player really wants
- instead of asking about portrait, class, starting equipment, armor and weapon, mod should have default ones and offer a choice to change it but only if player choose to change them

This would greatly simplify install of the mod components and allows players to skip the ones which they don't even want to touch. You definitely can include various logic conditions via FORBID_COMPONENT/REQUIRE_COMPONENT in order to exclude choices based on previous components.

I'm sure that you can go thought it with the help from my side and others. In case of futer question/explanation, feel free to ask.

Example, numbers are DESIGNATED numbers:

 

100=Install Aran Whitehand for SoA and ToB

GROUP "Customize Talk and Flirt Timers"
( SUBCOMPONENT 200 )
210=Set 15 minutes real time between friendship dialogues
220=Set 30 minutes real time between friendship dialogues
230=Set 45 minutes real time between friendship dialogues
240=Set 1 hour 30 minutes real time between friendship dialogues
250=Set 2 hours real time between friendship dialogues

GROUP "Install Audio Files"
( SUBCOMPONENT 300 )
310=Install Soundset
320=Voiced lines -> JSayles unaccompanied guitar, Early Music
330=Voiced lines -> Renaissance brass
340=Voiced lines -> Vox Vulgaris (midaevil wih a twist)
350=Music -> JSayles unaccompanied guitar, Early Music
360=Music -> Renaissance brass
370=Music -> Vox Vulgaris (midaevil wih a twist)

GROUP "Change Aran NPC Class"
( SUBCOMPONENT 400 )
410=Aran Configuration -> Mage Dual-Class (Tinker)
420=Aran Configuration -> Cleric Dual-Class (Tailor)
430=Aran Configuration -> Fighter (Soldier)
440=Aran Configuration -> Thief Dual-Class (Spy)

GROUP "Change Aran NPC starting equipment"
( SUBCOMPONENT 500 )
510=Aran is down-and-out poor and has sold off most of his equipment
520=Aran has kept most of his good gear
530=Aran has kept the best gear available to a successful mercenary

GROUP "Change Aran NPC starting armor"
( SUBCOMPONENT 600 )
610=Starting armor: Leather
620=Starting armor: Studded Leather
630=Starting armor: Chain
640=Starting armor: Splint
650=Starting armor: Plate

GROUP "Change Aran NPC starting weapon"
( SUBCOMPONENT 700 )
701=Starting weapon: Long Sword, Shield, Dagger
702=Starting weapon: Long Sword, Shield, Quarterstaff
703=Starting weapon: Long Sword, Shield, Mace
704=Starting weapon: Long Sword, Shield, Hammer
705=Starting weapon: Long Sword, Shield, Flail
706=Starting weapon: Long Sword, Shield, Long Bow
707=Starting weapon: Long Sword, Shield, Crossbow
708=Starting weapon: Long Sword, Shield, Potions of healing
709=Starting weapon: Bastard Sword, Shield, Dagger
710=Starting weapon: Bastard Sword, Shield, Long Bow
711=Starting weapon: Short Sword, Shield, Dagger
712=Starting weapon: Short Sword, Shield, Crossbow

GROUP "Change Aran's portrait"
( SUBCOMPONENT 800 )
801=Peachplum's "Latest" (dark brown hair, fair complexion)
802=berelinde's "Boromir" (dark brown hair, fair complexion)
803=berelinde's "Dragon Age" (dark hairr, dark complexion)
804=berelinde's "Scruffy" (light brown hair, fair complexion)
805=McMazey's "Don Pedro" (dark hair, dark complexion)
806=McMazey's "Fantasy Photo" (long brown hair, light complexion)
807=McMazey's "Bearded" (dark hair, light complexion)
808=McMazey's "No Beard" (dark hair, light complexion)
809=McMazey's "Horatio Photo" (dark hair, light complexion)
810=Peachplums' "Young Fighter" (red hair, fair complexion)
811=piperb's "Stalwort Bearded Young" (light brown hair, fair complexion)
812=piperb's "Mature Bearded" (dark brown hair, medium complexion)
813=piperb's "Stalwort Young" (light brown hair, fair complexion)

Edited December 28, 2018 by ALIENQuake

[Jarno Mikkola]

2 hours ago, ALIENQuake said:

-instead of choosing "Default Talk and Flirt Timers" or "Customize Talk and Flirt Timers" include defaults into main component and offer changing of Talk and Flirt Timers if the player really want it

- instead of asking to "Do not install any audio" offer a choice to install only those audio parts which player really wants
- instead of asking about portrait, class, starting equipment, armor and weapon, mod should have default ones and offer a choice to change it but only if player choose to change them

6

Aka, offer the additional things as separate components, not as choices on a multiple ACTION_READLN's. For example, the armor and other equipment could be the one set up in ALIEN's post... or just default (that doesn't need to be offered) or enhanced(aka, a component that updated the armor to a +1, weapon to a +2 and give an equipped Circlet of Genderbend... ), as a single additional component, the readme here can help people to decide their component choices, just like it does to the Tweaks rule changes part... while they keep the clutter away.

And I have to ask, is there even a chance that choosing between Leather, Studded Leather, Chain, Splint, Plate make any difference ? I ask, cause it's just a single slot that needs to be padded at a point before encountering said NPC.. padded, aka retained for carrying the best armor of a kind until the NPC is meat and thus relinquished for that purpose. This is in a game that has bags of holding and thousands of enemies of which a few can carry copies of the said armor ...

[cmorgan]

Heh - and back when I actually knew a little, https://www.gibberlings3.net/forums/topic/19689-adding-aran-into-the-game/?tab=comments#comment-165995 -  where I explain use of SUBCOMPONENT as it leaves a weidu.log record of what is actually installed...

So for straightforward mods, simply using SUBCOMPONENT and FORCED_SUBCOMPONENT  will be the cleanest way of coding up choices; any future install tools can use this information to build whatever they want to regarding unattended user input by choosing which S/F_S to install.

Thank you for the rundown, ALIENQuake. Recoding this way is relatively trivial and I will do so.

Jarno, yep - the number of choices in this particular mod (and the number of ways of coding stuff) are all relatively meaningless . The idea at the time was to explore all of the choices and decisions modders make, and show examples of how to code stuff in various ways. Anyone could simply use a game editor to set what they want up. I'm still going to include that level of detail, even though I know it is silly - after all, this is a mod that adds dialogue responses modified by a large number of DVs from mod added NPCs, on the off chance that the particular player has Aran and Tyris are in the party when that single one talk fires - which will probably be once in a gazillion installs.

 

[Jarno Mikkola]

2 hours ago, cmorgan said:

So for straightforward mods, simply using SUBCOMPONENT and FORCED_SUBCOMPONENT  will be the cleanest way of coding up choices...

 

Forced-subcomponents... probably not the best practice, as you could just assume a choice and then replace it within the other components ... as then the default choice is made, if none of the overwriting choices were installed afterwards.  So none Leather Component, as that's the default, and it's then replaced with the  Studded Leather, Backstabbed Leather or Boiled Leather, Chain, Splint or Plate when one of those components is installed. Well, there's, of course, the option to go naked, but that's also not a FORCED_SUBCOMPONENT.

Why... because the install tools won't be bound to your .exe running forced_ -containments.

Edited December 28, 2018 by Jarno Mikkola

[cmorgan]

Tl/dr:

From what I can see, use of F_S and a required component 0 would work efficiently and is simplest to run out - please provide a counter argument for S and conditional FORBID/REQUIRE _COMPONENT.

 

Long version, thinking out loud...

I get the SUBCOMPONENT usage, and studied Tweaks and 1pp - but still checking on FORCED. Manual installs don’t need extra work on uninstallation if the modder uses REQUIRE on subcomponents - I assume noninteractive uninstall would work the same way.

Is there anything that messes with an automated install tool if say

800 810 820 830 //800 is no change

are designated components that are F_S ?

I already install a “default condition” and then if the user inputs a changed condition action is taken on those files. It seems simplest in both Weidu.log and a custom debug file to log those specific choices using F_C rather than set up a range of conditions to filter out the “you already did this so skipping this component”. Folks may (will probably on a mega install) be using an install for a year or more (BG1NPC on the “change NPC starting area” component we logged where Alora et al was even if she didn’t get changed, so someone who wasn’t sure  what they installed in January could look it up in May). Using this drops the need for a custom debug file with data on user choice - the Weidu.log itself is used as the log of choices (4 lines - mod, class, equipment, portrait).

 

 

 

[Gwendolyne]

The 1PP next version will get rid of all A_R and transfer them into a ini file.

[AL|EN]

2 hours ago, cmorgan said:

Is there anything that messes with an automated install tool if say

800 810 820 830 //800 is no change

are designated components that are F_S ?

AFAIK, no. I will probably hide forced components from TreeView since there is no point of selecting them or not.

[Jarno Mikkola]

3 hours ago, cmorgan said:

Is there anything that messes with an automated install tool if say

800 810 820 830 //800 is no change

are designated components that are F_S ? 

1

I don't see a reason to even provide the 800 component, if it's no change, then the component does nothing, so it requires no install. "You have a mace, do you wish to have a mace ?" In a Yes/No answer -Either way, you end up with a mace, in your face. While the 810, is likely "Do you wish to switch your mace to a hammer?" Which could as well be 800, and you would end up with far fewer components.

And in automated installs... it's never good to REQUIRE anything DURING install, it's better to require them to install something after they have been installed already.

Aka if you wish to provide a component that allows switching an NPC class, then that component should require the NPC mod to be installed, but not REVERSED, say with an infinite class/kit selection that half corrupted and break the game when implemented on an NPC.

Edited December 29, 2018 by Jarno Mikkola

[cmorgan]

Well, Jarno, from a logic standpoint, that makes sense - but I work with kids. I know that when facing a text panel, it is not necessarily that intuitive.

logic says

"You installed the default mod - only change what you want to."

Reality says

"Hey - I just got given a set of choices - I wonder what they are... *poke*"

"Hmmm... what if I don't want any of these... there is no option to leave them alone" (ignores the big prompt thing that says "[N]ot install" because modern brains are wired to "only stuff in GUI box")

or

"Hey! There is one of these that says 'default'! I'll choose that one!" (Modder gets line in tp2 that says default is installed, laughs at silly user for installing a component that does nothing but log itself in the Tp2, drinks more scotch and mutters about young people and the eventual heat-death of the universe)

So the reason I am interested in abandoning behaviors built for interactive installs is that folks are pretty sure automated is the way of the future.

On the breakdown into SUBCOMPONENTS...

I... am stuck. Not on the theory; if it can be done with a full default install and then manipulate the files only if the user wishes to, using SUBCOMPONENT and GROUP, do it.

In my case, I get two choices -

recode the behaviors of SWING_CASE and the myriad of A_R to match (building the subcomponent behavior was a morning's cut paste and adjust work, so no big deal, but unfortunately the main component uses the information up front to build the cre and timers through variables in one go after all those A_Rs. Can't just OUTER_SET in components, because it is built to be interactive - blah. Have to rewrite whole patching setup, except for the easy one - Portraits).

or

join Gwendolyne and do an .ini and explain the new behavior to folks expecting more options on install.

I don't know which is going to be quicker. I guess I will have to play about more with it.

[AL|EN]

42 minutes ago, cmorgan said:

...

On the breakdown into SUBCOMPONENTS...

I... am stuck. Not on the theory; if it can be done with a full default install and then manipulate the files only if the user wishes to, using SUBCOMPONENT and GROUP, do it.

In my case, I get two choices -

recode the behaviors of SWING_CASE and the myriad of A_R to match (building the subcomponent behavior was a morning's cut paste and adjust work, so no big deal, but unfortunately the main component uses the information up front to build the cre and timers through variables in one go after all those A_Rs. Can't just OUTER_SET in components, because it is built to be interactive - blah. Have to rewrite whole patching setup, except for the easy one - Portraits).

or

join Gwendolyne and do an .ini and explain the new behavior to folks expecting more options on install.

I don't know which is going to be quicker. I guess I will have to play about more with it.

I don't know which way would be quicker (Do you have a deadline for finishing 'playing with weidu mods'?) but SUBCOMPONENTS-way will open more possibility for the future:

- using LABELS for internal mod dependence/internal conflicts
right now, you can select ANY single component alone like this and fire installation which will produce error (assuming you are using GUI install tool, doesn't matter which one). Using SUBCOMPONENTS+LABELS with allow you to prevent such situation if you care enough.

- i think that you mod needs to limit/change the components according to the previously selected components/combination of the components. It might be difficult to achieve using ini-way.

Edited January 3, 2019 by AL|EN

[Jarno Mikkola]

1 hour ago, cmorgan said:

"Hey - I just got given a set of choices - I wonder what they are... *poke*"

 

And every one of the choices made should lead the install to a completion... but nobody says they need to be made nor that they can't be uninstalled. That's why every choice made should lead to a Q exit(+ if you have multiple components a S to Skip the component) also rather than ~One more choice you have to make that you have no idea what's going to happen if you choose yes or no, ouh by the way do you wish to make Minsc a mage ?~ If you notice there's a mod that can make Minsc a mage as a valid character... but nobody intends that the choice is seriously reconsidered, unless someone wants to go poking at it.

And seriously, how many personalities should an NPC have ? I have three and that's enough for my entire family ... but if you go and change the NPCs personal responses according to things, their class should at least be one of those things... and you could well make the NPC to be a Cleric and set up subcomponents that allow other classes... but the default should be there in the main component, and not in a subcomponent.

 

Quote

but unfortunately the main component uses the information up front to build the cre and timers through variables in one go after all those A_Rs. Can't just OUTER_SET in components, because it is built to be interactive - blah. Have to rewrite whole patching setup, except for the easy one - Portraits). 

2

The .cre like said, can be divided into subcomponents. The timers... do you mean the dialog setting ? If so, you can speed up the given script just like the other mods do, by targeting that one script. And using a default speed IN THE MAIN COMPONENT THAT FIRST COMPILES the launch script file... which can then be modified easily with OPTIONAL subcomponents.

Edited January 3, 2019 by Jarno Mikkola

[AL|EN]

On 10/2/2018 at 7:20 PM, Wisp said:

Quote

@wisp, can you mark READLN as "DEPRECATED" and display warring?

No, because there is no established alternative, and even if there were, it would not deprecate READLN because there would still be valid use cases.

@Wisp To what extent you are fine with updating description of ACTION_READLN? How about:

ACTION_READLN variable

Do not use this action without a real reason. There are no valid cases for it which cannot be replaced by SUBCOMPONET or user  configuration file. Waits for the user to provided an enter-terminated string and store it in variable. Said string will be stored and re-used during non-interactive reinstalls.

and additionally, replacing READLN tutorial section with SUBCOMPOENT/user config tutorial for the examples covered?

Edited March 12, 2019 by AL|EN

[jastey]

On 12/29/2018 at 6:20 PM, Jarno Mikkola said:

I don't see a reason to even provide the 800 component, if it's no change, then the component does nothing, so it requires no install.

I know I'm late, but I just noticed it does make sense to offer the default value (that is installed with the main component) in the optional component: If, for example, the player want to revert to it by deinstalling another timer they installed (without having to reinstall the whole thing).

Another thing remotedly related: If we are dealing with replacing the ACTION_READLN for a mod that is already around for a while and might be checked for crossmod or conflicts, offering choices for the main component via SUBCOMPONENT has the disadvantage that checking for "mod.tp2" "0" will not be true for all cases if the player choses one of the other options.