projectinfinity ACTION_READLN - replacement examples

[Jarno Mikkola]

it can be done via simple "IF variable exist ELSE ask for input".

Yeah, but I like to zero the variable before I set it... So it won't get underwritten by another mod component.

And I would assume that as the config-default.ini file is read first, that that SETS the variables to the default values. Which the player then can configurate with the non-config.ini file, via the very same code:

//timer11
OUTER_SET timer11 = 100

//timer12
OUTER_SET timer12 = 200

//timer13
OUTER_SET timer13 = 300

//timer13
OUTER_SET timer14 = 400

//timer13
OUTER_SET timer15 = 500

//timer13
OUTER_SET timer16 = 600

//timer13
OUTER_SET timer17 = 700

//timer13
OUTER_SET timer18 = 800

//timer13
OUTER_SET timer19 = 900

Yes, that too could use work, but I tend to copy paste...

As the .tp2 does this:

INCLUDE ~IMPsurprice/configuration-default.ini~ // default-config file

ACTION_IF FILE_EXISTS ~IMPsurprice/configuration.ini~ THEN BEGIN

INCLUDE ~IMPsurprice/configuration.ini~ // custom user defined config file

END

 

..yes, technically that's .tpa coding, which the include adds into the .tp2 code for the function.

 

But let's see your code and we'll take it from there.

Edited October 3, 2018 by Jarno Mikkola

[Wisp]

Really ? So how would the install behave if the input would be restricted to a number, and it was given a letter ? It would STALL, right there and then, as it would require an additional input that is not provided. Or at least that's how the schema usually works:

Your post makes no sense.

 

In this context, a schema is a separate document (it does not literally have to be a separate document) that describes the structure and bounds of the first document (the config file). Schema validation is the process of ensuring the config file conforms to the specifications laid out in the schema. There is no incorrect or incomplete input, or validation would fail.

[aqrit]

> 1. It's impossible for any kind of "install tool" (and even for weidu itself!) to get READLN "appropriate values" and description of those from the mod itself.

 

But it is possible via manual review by a "install tool" maintainer.

 

> 2. It's impossible without 24/7 maintainer.

 

Yes. Each mod revision requires attention. There is no way around this.

 

What would happen if I decided to changed my subcomponent numbers (or behaviors) between releases?

 

 

> installation is paused after 4h (other mods are installed before you mod) and waits for keyboard input

 

the "unattended install tool" should ask these questions up front.

 

 

> I cannot save my choices to not repeat them during next installation.

 

The "unattended install tool" should save the responses that it has already received.

 

> I'm not using any kind of "install tool" at all.

 

Then how (and why) did you queue four hours of unattended mod installs? This makes no sense.

 

Batch scripts are a form of "install tool". A script can prompt questions, verify input, and save responses.

 

Could a script pipe to weidu? I don't know.

Could a script edit a tp2 file? Yes.

 

Could a custom program pipe input to weidu? Yes.

Edited October 3, 2018 by aqrit

[Jarno Mikkola]

What would happen if I decided to changed my subcomponent numbers between releases?

Which is a good reason to NOT DO THAT. General rules here.

And yes, a .bat file can insert a .txt file to answer all the variable amount of guestions a weidu can ask as a ACTION_READLN ... but that becomes a whole lot of a mess when it's done to mods made by at least 9 different authors. Me & @Tash @wisp @Pecca @argent77 @jastey @berelinde @Ulb @LavaDelVortel ... just to name the ones in this thread. Then there's the fact that the autoinstall tool maker probably wants to not make a unreliable product ... for 488 985 use cases, that's nearly half a million downloads. Now, a few of those mods don't generally ever get to be installed by a mod manager... like in the 3 last mods in argent77's post, but still... there are fair amount of mods that do.

One can get a 4 hours waiting time by installing a mod like SCS ... that all of a sudden asks your phone number while you are asleep. This doesn't happen for now, but it could...

Edited October 3, 2018 by Jarno Mikkola

[aqrit]

One can get a 4 hours waiting time by installing a mod like SCS ... that all of a sudden asks your phone number while you are asleep

 

Which is a good reason to NOT DO THAT.

User input needs to be solicited at the beginning.

 

If a tool stacks multiple mod installs then that tool should also assume *full* responsibility for moving the "beginnings".

Edited October 3, 2018 by aqrit

[Jarno Mikkola]

If a tool stacks multiple mod installs then that tool should also assume *full* responsibility for moving the "beginnings".

If this is your stand, then you should understand why the Original Poster made his request to do it as few times as possible ?!? As he among others have been instrumental on supporting the BWS on doing this exact fact ! Correct ?

[Wisp]

As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.

[AL|EN]

"But it is possible via manual review by a "install tool" maintainer."

"Yes. Each mod revision requires attention. There is no way around this."

"the "unattended install tool" should ask these questions up front."

The "unattended install tool" should save the responses that it has already received."

A script can prompt questions, verify input, and save responses.

Could a script pipe to weidu? I don't know. Could a script edit a tp2 file? Yes. Could a custom program pipe input to weidu? Yes.

I'm not gonna bring back and write down the 3 years of examples of what works and what doesn't. Everything is theoretically possible, but when you actually do it, things start to fall apart, BWS problems prove it very well. Anything which require maintainer, like you proposition of "manual review", "ask these questions up front", "prompt questions" etc are out of scope because otherwise, the tool will be dead in less than a month. The READLN require 24/7 maintainer, subcomponents don't. And subcomponents open another possibilities for mod authors. Lets stop here, so I can focus on updating ini example.

 

What would happen if I decided to changed my subcomponent numbers (or behaviors) between releases?

If you do it, or even add/remove comnponents/subcomponents, Project infinity is still able to dynamically generate list of ALL components for mod, including exclusivity of those components. This is the main(but not only one) advantage of subcomponent functionality over READLN. It's worth every effort.

Edited October 3, 2018 by ALIENQuake

[DavidW]

As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.

This.

[aqrit]

done.

Edited October 4, 2018 by aqrit

[subtledoctor]

As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.

Was going to post something like "forget it man, your app won't support READLN, mods will get with the program or be left behind."

 

But then I realized, that's going to happen no matter what. The point here isn't to force anyone to do anything. There's no call for people to defend the use of READLN, because AL|EN's app won't support it regardless. This is literally just an invitation to discuss how that inevitable fact might affect people's mods, and brainstorm what, if anything, they might want to do about it. (Check the thread title.)

 

Seems like a fine idea to me.

Edited October 4, 2018 by subtledoctor

[AL|EN]

As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.

 

 

As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.

This.

 

I wrote this thread to make players and modders to be aware about of the problem and propose how to get rid of it. To post guide and examples how to do it properly. I should write this years ago, better late then never.

 

 

As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.

Was going to post something like "forget it man, your app won't support READLN, mods will get with the program or be left behind."

 

But then I realized, that's going to happen no matter what. The point here isn't to force anyone to do anything. There's no call for people to defend the use of READLN, because AL|EN's app won't support it regardless. This is literally just an invitation to discuss how that inevitable fact might affect people's mods, and brainstorm what, if anything, they might want to do about it. (Check the thread title.)

 

Seems like a fine idea to me.

 

This.

[jastey]

You could shape the discussions's conclusions up and post it in the tutorials section.

 

It is useful advice for new mods, and not all (new) modders are aware of it. Also for existing ones, too.

[Ardanis]

I may have mentioned it sometime ago, but - shouldn't BWS just make a guide about what tp2 input it can process, and then modders who wish to be part of BWS framework will take steps to ensure their code is compliant with its guidelines? I.e. why not just blacklist by default the mods that use of READLN? If their authors are actively interested in participation in BWS project, they can e.g. use some IS_BWS flag to toggle READLN on/off.

[AL|EN]

I may have mentioned it sometime ago, but - shouldn't BWS just make a guide about what tp2 input it can process, and then modders who wish to be part of BWS framework will take steps to ensure their code is compliant with its guidelines? I.e. why not just blacklist by default the mods that use of READLN? If their authors are actively interested in participation in BWS project, they can e.g. use some IS_BWS flag to toggle READLN on/off.

Nothing is related to BWS/new install tool except "missing treeview nodes". The ACTION_READLN is simply bad for mods, period. 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 ...