AL|EN Posted October 2, 2018 Author Share Posted October 2, 2018 That's a useless argument if such tools don't exist. Make my life worse and claim someone can make it better? That's still a regression. What subtledoctor was probably aiming at is that this (nonexisting?) tool likely doesn't work on non-windows systems (mobile hw, linux, macs, bsds ...). I mentioned verification for the free-form entry use case, of course it's not much of a problem when you only have a discreet list of options. The install will have to be aborted and the tool probably can't know that beforehand, as the code needs to be executed first (Halting problem). It already exist. The codename for the project is "Project Infinity". One of the features is detection of the "config-default.ini" and saving to + config.ini. When it comes to IE modding, only 3 platforms are taken into consideration: Win, Mac, Linux. The iOS/Android devices can receive mods via transferring override+lang trick. Replace 'can' with 'willing to' I don't follow. While the ALPHA version works only on windows, I'm not using "windows only" language like AutoIT. So the cross-platform is definitely possible. Quote Link to comment
lynx Posted October 2, 2018 Share Posted October 2, 2018 You ignored the verification problem. Or are you suggesting user choice should be ignored in case of mistakes? Quote Link to comment
AL|EN Posted October 2, 2018 Author Share Posted October 2, 2018 @lynx I try to not ignore anything. Those my proposition how to deal with verification of the user mistakes: http://gibberlings3.net/forums/index.php?showtopic=29708&p=263539 Basically, weidu code check should be preformed and if it fails, usual ACTION_READLN is executed. If such situation occurs, then the mod code itself make sure that the values will be correct, otherwise it won't install. But if values are correct, then we have fully automated installation, without pausing for user input. Quote Link to comment
Wisp Posted October 2, 2018 Share Posted October 2, 2018 You can verify user input with a schema, either to make the component uninstallable if the user input is incorrect, or by restricting which values the user can input during input time. In either case, you'd be sure installation would not fail or stall due to the input value. @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. Quote Link to comment
Jarno Mikkola Posted October 2, 2018 Share Posted October 2, 2018 (edited) You can verify user input with a schema, either to make the component uninstallable if the user input is incorrect, or by restricting which values the user can input during input time. In either case, you'd be sure installation would not fail or stall due to the input value. 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: ... THEN BEGIN PRINT ~What would you like to set the second level refresh timer at?~ ACTION_READLN timer12 OUTER_WHILE !(IS_AN_INT %timer12%) BEGIN PRINT ~What would you like to set the second level refresh timer at?~ ACTION_READLN timer12 END END Meaning that there is no escape from that... Edited October 2, 2018 by Jarno Mikkola Quote Link to comment
AL|EN Posted October 2, 2018 Author Share Posted October 2, 2018 @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. Agree on alternative and valid use cases. How about display description "It will pause installation for the player, try to use SUBCOMPOPNENT or reading value from ini" ? Quote Link to comment
aqrit Posted October 2, 2018 Share Posted October 2, 2018 The mod install process should NOT be automated unless the exact version of the mod is known. If the exact mod version is known... a "tool" has a couple of options: 1. pipe/send/inject input to automatically fill out READLN prompts with appropriate values. 2. rewrite the mods source code, replace READLN with some helper function that sets the appropriate value. If the 10th mod to install needs absolutely needs input from user -- then -- that input should be asked for upfront, before the tool launches any installation steps for intervening mods. This is how unattended installation should work. Trying to outsource this or related problems to mod creators or weidu is entirely wrongheaded. Quote Link to comment
AL|EN Posted October 3, 2018 Author Share Posted October 3, 2018 (edited) The mod install process should NOT be automated unless the exact version of the mod is known. If the exact mod version is known... a "tool" has a couple of options: 1. pipe/send/inject input to automatically fill out READLN prompts with appropriate values. 2. rewrite the mods source code, replace READLN with some helper function that sets the appropriate value. If the 10th mod to install needs absolutely needs input from user -- then -- that input should be asked for upfront, before the tool launches any installation steps for intervening mods. This is how unattended installation should work. First post contains world "automatic" while in fact is really "doesn't have to wait for user input problem/provide measures to not require it at all", I've edited it to better describe what I mean. 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. It's even impossible to know which component of the mod will require READLN. Custom data is needed or mod needs to switch to SUBCOMPONENTS/config-default.ini where such limitation doesn't apply. 2. It's impossible without 24/7 maintainer. There was a period of time when BWS had 3 maintainers, still it was not enough to follow mod changes. It's a road to nowhere. 3. "If the 10th mod to install needs absolutely needs input from user -- then -- that input should be asked for upfront, before the tool launches any installation steps for intervening mods." - See 1 and 2. I appreciate you feedback but those things are either technically impossible or are the same things which makes BWS dead. I'm not goona repeat BWS mistakes. Trying to outsource this or related problems to mod creators or weidu is entirely wrongheaded. Let's assume that you created a mod with one component, let's say "0:Change Quest X to:" and two READLN "Press 1 to add additional content", "Press 2 to add additional content and more enemies". I want to install you mod using weidu commandline: setup-aqritMinsc.exe --force-install 0 --language 0 Yet, for every new attempt to install you mod, installation is paused after 4h (other mods are installed before you mod) and waits for keyboard input of 1 or 2. I complain about this because it's unnecessary and I cannot save my choices to not repeat them during next installation. Multiple this by the amount of READLN components for you current install. Weidu provide necessary functions in order to deal with such cases: It can be solved by using SUBCOMPONENTS without changing what the mod is actually doing. I'm not using any kind of "install tool" at all. What's you answer to my complains? Edited October 3, 2018 by ALIENQuake Quote Link to comment
lynx Posted October 3, 2018 Share Posted October 3, 2018 1 *is* technically possible, that's what my initial mention of Expect was about. Good point about answer preservation for READLN, but I see that as a missing weidu feature, not something unsurmountable or something the mod author should save manually. Simple choice problems are easily solved, but we're talking about the hard one — arbitrary input. Quote Link to comment
AL|EN Posted October 3, 2018 Author Share Posted October 3, 2018 (edited) 1 *is* technically possible, that's what my initial mention of Expect was about. Yes, I can send input to console host during installation processes. But: player must know which component require input player must know correct input and what it means, for eg: ajantisBG2, component 0, player can send 1,5,2 because he already knows what such input means. player choices are also not included inside weidu installation log so debbug information is lost - yet another reason to not use READLN I don't think that requiring such "blind setup" is a good way to go, especially when subcomponents/config.ini are much better alternatives. Good point about answer preservation for READLN, but I see that as a missing weidu feature, not something unsurmountable or something the mod author should save manually. Simple choice problems are easily solved, but we're talking about the hard one — arbitrary input. Yep, and such "missing feature" is "is way, way outside WeiDU's capabilities" http://forums.pocketplane.net/index.php/topic,29449.msg337320.html#msg337320 That's why there is no hope for READLN and I urge any modder to get rid of it because for 99% user cases, it's unnecessary. Edited October 3, 2018 by ALIENQuake Quote Link to comment
lynx Posted October 3, 2018 Share Posted October 3, 2018 You asked for something completely different in that thread. But let's leave it at that, there is no point in continuing the subthread. Interactivity is a thing of hot contention in package management. Quote Link to comment
Ulb Posted October 3, 2018 Share Posted October 3, 2018 Skipping over this, I guess for my mod the best solution would probably be to just offer subcomponents to either use direct input or use an ini file. That way the full functionality would be preserved while still offering an easy solution for install tools. (The BWS currently already circumvents the issue by just using a default name for the animal companion.) I'm currently not very motivated to work/update the animal companions mod but I guess I'll get around to do it at some point (hopefully before your new tool is released). Quote Link to comment
AL|EN Posted October 3, 2018 Author Share Posted October 3, 2018 (edited) @Ulb Don't allow druids to get animal companions Allow druids to get animal companions too Those options are perfect candidate for SUBCOMPONENT. Or even single component with only one option "Don't allow druids to get animal companions" - because main component will have "Allow druids to get animal companions too" as default. If I don't want to impose limits, I don't have to install any component at all. Enter a name for your animal companion (by default is Buddy) Proceed the installation Goals: - ability to provide name when player install mod via console - ability to save the name so it can be used for next installation Approach: - add AnimalCompanions\config-default.ini with "AnimalCompanionName=Buddy", add a info that player needs to copy/rename this file to config.ini (not included inside mod archive in order to avoid overwrite user defined name)- during mod installation detect if AnimalCompanions\config.ini is present, if yes, read name from config.ini file using this function http://gibberlings3.net/forums/index.php?showtopic=29657&p=262759 - if config.ini is not present, execute normal ACTION_READLN and wait for user input When the time comes, I can help you with that, if it will be necessary. Edited October 3, 2018 by ALIENQuake Quote Link to comment
Jarno Mikkola Posted October 3, 2018 Share Posted October 3, 2018 (edited) Approach: - add AnimalCompanions\config-default.ini with "AnimalCompanionName=Buddy", add a info that player needs to copy/rename this file to config.ini (not included inside mod archive in order to avoid overwrite user defined name) - during mod installation detect if AnimalCompanions\config.ini is present, if yes, read name from config.ini file using this function http://gibberlings3.net/forums/index.php?showtopic=29657&p=262759 - if config.ini is not present, execute normal ACTION_READLN and wait for user input Have you an example ? Cause I can't see this happen.. I can see that A component uses a ,ini -files, and a B component reads ACTION_READLN ... this is because that is a declarative statement... aka it's easier to program the option to include the reading of a clear insert to a component A if it's there, than it's to use it while checking that the .ini file is not there already. Which is where the component B can read the inserts as a separated entries and do whatever the cheese it wants with them. Edited October 3, 2018 by Jarno Mikkola Quote Link to comment
AL|EN Posted October 3, 2018 Author Share Posted October 3, 2018 Have you an example ?Cause I can't see this happen.. I can see that A component uses a ,ini -files, and a B component reads ACTION_READLN ... this is because that is a declarative statement... aka it's easier to program the option to include the reading of a clear insert to a component A if it's there, than it's to use it while checking that the .ini file is not there already. Which is where the component B can read the inserts as a separated entries and do whatever the cheese it wants with them. You don't need separate components only for READLN, it can be done via simple "IF variable exist ELSE ask for input". Let me see if I can update my example. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.