Author Topic: Roadmap  (Read 5195 times)

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Roadmap
« on: February 24, 2017, 08:52:42 AM »
On and off for a while now, I've been working on a graphical frontend for WeiDU, and since it's approaching an initial release it might be a good time to present it and some of the things I have in mind. Whether all, some, or none actually get done is, of course, a separate matter (and you'll notice a conspicuous lack of time estimates). Feedback's welcome.


Graphical Frontend
For those unfamiliar with the term, a graphical frontend is a GUI-based program for interacting with a non-GUI program. Let's call it Zeitgeist. Today it looks vaguely like this: Picture 1. Picture 2. (This is the GNOME look; on Windows and MacOS it will look correspondingly native for the respective platform.)

The intention is for Zeitgeist to replace setup-mymod.exe as the normal way of installing mods. There is of course a lot left to do before that happens (vide infra), but that's the ambition.

For those interested in such things, Zeitgeist is written in Qt and C++ and the source code will be made available along with the initial release. No doubt there will be a bunch of issues of robustness and user experience that will have to be sorted out.


Work on WeiDU and related (of a larger/wider nature)
As things are today, neither WeiDU nor mods in general are entirely well-adapted to being used in other ways than interactively installing one component at a time. Once Zeitgeist offers a decent experience (which will be after WeiDU has been fixed to enable one such) I will be rewriting WeiDU's installer code to be completely non-interactive (which will drastically simplify it). I'll admit this is less something that is necessary to do and more something I want to do because the shell menus are awful and limiting.

A remaining issue, however, will be that component requirements cannot be fully known ahead of time. Component requirements frequently include game state (such as requiring some particular file) that depend on what previous components were installed. We'll have to see how things develop, but it's something to be aware of.


Replacement for READLN
Once people take to queuing up mod after mod and going off to have a sandwich while it all installs, they are going to be right annoyed when some component half-way through stops and asks for input. I posted one suggestion for a replacement for READLN here. I did perhaps jump the gun a bit on that one, as both Kulyok and Miloch pointed out it would not fly without the GUI. But now I don't have to be cagey about the GUI, so yes, there will be a GUI for users to check off options and whatnot before they install the mod.


Cross-platform mod-distribution format
At the risk of having that XKCD comic cited at me, mod distribution today is a mess. Particularly noteworthy are the Windows-only self-extracting archives.

Not having to package mods in various arcane ways for each platform would be terrific. To that end, I propose a standard compressed format (say, 7z) with a manifest and a specific file extension. The archive can be created equally well regardless of which platform the packager is on and the user experience is consistent on all platforms. Since it'd be a standard file format, there is no impediment to treating it as a normal archive with the normal tools (see omod files, over in Bethesda-land).

The tie-in with Zeitgeist is obvious. Through the specific file extension, double-clicking the file opens Zeitgeist, which guides the user through the steps of getting the mod into the right directory. The aforementioned manifest would also tie into the GUI. You could include such meta-information as the full and properly written name of your mod, for example, to be displayed instead of the name of the TP2 file.


I think that's all the soapboxing from me today.
« Last Edit: March 18, 2017, 12:34:00 PM by Wisp »

Offline Almateria

  • Planewalker
  • *****
  • Posts: 76
Re: Roadmap
« Reply #1 on: February 25, 2017, 03:22:58 AM »
Bro that's real sweet!

Offline DavidW

  • Planewalker
  • *****
  • Posts: 316
Re: Roadmap
« Reply #2 on: February 25, 2017, 01:13:14 PM »
A remaining issue, however, will be that component requirements cannot be fully known ahead of time. Component requirements frequently include game state (such as requiring some particular file) that depend on what previous components were installed. We'll have to see how things develop, but it's something to be aware of.

Some thoughts on this. There are three issues:
1) checks within a mod, where one component requires another. None of those *need* to be done via checks of game state; they can be done via REQUIRE_COMPONENT, either directly keyed to component number or using IDS_OF_LABEL. (I keep meaning to shift SCS over to that format.)
2) checks *by* one mod, *for* a component of another mod. (e.g., SCS checks for various bits of Spell Revisions). I at least have tended to do that by checking for a marker file because I don't trust people not to change their component numbers. IDS_OF_LABEL ought to obviate that, so changing to using that check process would be straightforward enough. It's a problem if the mod being detected isn't being actively maintained... but I guess in that case the component numbers *are* stable.
3) checks *by* one mod, *for* some possibly-installed feature that some other mod might have put in place (e.g., SCS checks for whether any other mod has made HLAs innate-only, and doesn't install its version if so). In practice checks like that are too complicated to build into a REQUIRE_PREDICATE, so again there shouldn't be a problem, but I guess it might be sensible for components to fail more gracefully in that case if they're being installed non-interactively. (At the moment I just declare a FAIL and say why, which is fine for interactive install but a bit drastic for non-interactive.)

Bottom line: mods that use marker files had better shift over to using component numbers/labels?

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 131
Re: Roadmap
« Reply #3 on: February 25, 2017, 04:19:03 PM »
Regarding the READLN/interactivity issue: how about promoting the use of .ini files? As an example, my little 'spiritual successor to FPPS' mod has an .ini file that lets the player define almost every statistic of different armor types: base AC, effect of enchantment on AC, Dex penalties, damage resistance, casting speed penalties, and thieving penalties. Unfortunately, BWS users cannot get the benefit of this because very few users know how to modify the .ini without prompting a re-die load of the mod.

There's no reason a modder like me couldn't code a .tp_ file prompting the user to fill out the values in the .ini file; this .tp_ file would be ignored in a command-line install but could be recognized and processed by Zeitgeist prior to the beginning of the non-interactive installation. So any mods that need user input would get it out if the way early on, and then the full non-interactive installation would proceed apace, reading the (now-)static .ini files.

In addition to making .ini files more useful and user-friendly, this would obviate READLN.

EDIT - sry, just went and read the linked proposal, and basically yeah, exactly. Mods can have .ini files in some arbitrary-but-uniform format. (Ideally something easy to read and edit by laypeople, if they do want to open it in a text editor.) And another file or function or whatever, with the dual purpose of 1) triggering Zeitgeist to ask the .ini questions before initiating the full non-interactive install; and 2) letting Zeitgeist know exactly what questions to ask the user during that initial phase, i.e. what information needs to be defined in the .ini.

I'm not sure whether this addresses the concerns of L1NPCs, where sometimes you want to reinstall without answering a million questions but other times you do want to change the answers to some of those questions. But, baby steps.
« Last Edit: February 25, 2017, 06:54:02 PM by subtledoctor »

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: Roadmap
« Reply #4 on: February 26, 2017, 08:01:54 AM »
3) checks *by* one mod, *for* some possibly-installed feature that some other mod might have put in place (e.g., SCS checks for whether any other mod has made HLAs innate-only, and doesn't install its version if so). In practice checks like that are too complicated to build into a REQUIRE_PREDICATE, so again there shouldn't be a problem, but I guess it might be sensible for components to fail more gracefully in that case if they're being installed non-interactively. (At the moment I just declare a FAIL and say why, which is fine for interactive install but a bit drastic for non-interactive.)
The way I see it, bailing out of the installation (of the component) is a good way to handle it, but I agree FAIL is perhaps not the best conceivable way, since it reports the component as NOT INSTALLED DUE TO ERRORS, when, in fact, there were no errors.

Bottom line: mods that use marker files had better shift over to using component numbers/labels?
Pretty much. Requirements on component numbers/labels can unambiguously be derived from the already installed mods and the preceding components in the install queue.

EDIT - sry, just went and read the linked proposal, and basically yeah, exactly. Mods can have .ini files in some arbitrary-but-uniform format. (Ideally something easy to read and edit by laypeople, if they do want to open it in a text editor.) And another file or function or whatever, with the dual purpose of 1) triggering Zeitgeist to ask the .ini questions before initiating the full non-interactive install; and 2) letting Zeitgeist know exactly what questions to ask the user during that initial phase, i.e. what information needs to be defined in the .ini.

I'm not sure whether this addresses the concerns of L1NPCs, where sometimes you want to reinstall without answering a million questions but other times you do want to change the answers to some of those questions. But, baby steps.
One day, there will be a button in the enqueue-mod window labelled something like "Configure". The configuration file will be editable from there. It should also be possible to declare input constraints, like Anomen's eyes must be a dreamy [blue, green, brown] or ability scores must fall between 3 and 25, things like that.
« Last Edit: February 26, 2017, 08:15:23 AM by Wisp »

Offline DavidW

  • Planewalker
  • *****
  • Posts: 316
Re: Roadmap
« Reply #5 on: February 26, 2017, 10:33:43 AM »
Actually, I have one scenario that I think will cause problems. The current (unreleased) version of SCS suppresses some components by default (their content is installed in the setup component instead) but you can unsuppress them via a stratagems.ini entry. (This is part of a general project to streamline SCS's install process for general users without removing customisation for power users.)

I think I'd probably better just learn to live without that. As a reasonable alternative I can just let the user select/unselect those components directly in the ini file (in the medium term that will be more userfriendly because of the Configure button in any case).

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: Roadmap
« Reply #6 on: February 26, 2017, 12:57:52 PM »
From the sounds of it, wouldn't it just be better to scrap these components entirely and have the setup component install the content if the corresponding option is set in the ini file? Or was that what you meant? But If so, I don't see the problem.

Offline DavidW

  • Planewalker
  • *****
  • Posts: 316
Re: Roadmap
« Reply #7 on: February 26, 2017, 07:13:47 PM »
Yes, and that's what I meant. And no, no problem - on a moment's reflection the alternative is better anyway, quite apart from compatibility.

Offline Mike1072

  • Planewalker
  • *****
  • Posts: 298
  • Gender: Male
Re: Roadmap
« Reply #8 on: March 03, 2017, 10:33:07 PM »
I'm not around very much at the moment, but I wanted to mention I've been following this and these changes sound great.

I have some very limited experience with Qt & C++ from some introductory graphics courses I took, so I might look into contributing to Zeitgeist in the future if I have more time.

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: Roadmap
« Reply #9 on: March 04, 2017, 03:57:26 PM »
I have some very limited experience with Qt & C++ from some introductory graphics courses I took, so I might look into contributing to Zeitgeist in the future if I have more time.
You're welcome any time.

Offline Magus_BGforge

  • Planewalker
  • *****
  • Posts: 75
Re: Roadmap
« Reply #10 on: March 26, 2017, 01:22:15 PM »
That is great, I've been thinking similarly for a long time, tried to start, but Qt takes time to learn.
However, I don't think that simply adding GUI is going to change much at this point. There's BWS already, and for large installations it's simply integral. For small ones, it's not too hard to run setup-mymod a few times.
But, a native replacement for BWS, with proper UI and more functions, would be the holy grail.

Offline DavidW

  • Planewalker
  • *****
  • Posts: 316
Re: Roadmap
« Reply #11 on: April 09, 2017, 01:19:01 PM »
I don't agree. SCS, in particular, will become way easier to use with Zeitgeist.

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 131
Re: Roadmap
« Reply #12 on: May 15, 2017, 10:52:52 AM »
That is great, I've been thinking similarly for a long time, tried to start, but Qt takes time to learn.
However, I don't think that simply adding GUI is going to change much at this point. There's BWS already, and for large installations it's simply integral. For small ones, it's not too hard to run setup-mymod a few times.
But, a native replacement for BWS, with proper UI and more functions, would be the holy grail.

Speaking as someone who can't use BWS, and therefore "run setup-mymod a few times" means "a hundred or more times," if a GUI is on offer, I'll gladly take it. :)  If I could figure out how to compile Zeitgeist on a Mac I would.

Speaking more generally, "we already have BWS" is no answer. BWS has been shepherded well lately but it's original bones are creaky and can never be extended cross-platform, and AFAIK it is not being maintained at the moment. Plus, BWS took 15 years to get into the shape it's in now. Rome wasn't built in a day. What BWS has that Zeitgeist lacks, like auto-sorting of mods, can presumably be added in time. And in other ways Zeitgeist is already superior, e.g. It (presumably) can dynamically detect and present mod components for the user, whereas every time a mod adds or moves a component it requires that BWS itself be manually updated to reflect it. That's far from ideal.

tl;dr: I see no reason not to encourage this.

Offline The Imp

  • Planewalker
  • *****
  • Posts: 288
  • Gender: Male
Re: Roadmap
« Reply #13 on: May 15, 2017, 03:15:35 PM »
It (presumably) can dynamically detect and present mod components for the user, whereas every time a mod adds or moves a component it requires that BWS itself be manually updated to reflect it. That's far from ideal.
There's a clear reason for this, the BWS user is not typical tester, but wants to use tested features that are known to work together quite well. Rather than subject every user to test their compilation as if it were their own coded mods. There's a slight difference between say 5 mods, and 1500 mod components.

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Roadmap
« Reply #14 on: June 04, 2017, 07:35:33 PM »
Cross-platform mod-distribution format
At the risk of having that XKCD comic cited at me, mod distribution today is a mess. Particularly noteworthy are the Windows-only self-extracting archives.

Not having to package mods in various arcane ways for each platform would be terrific. To that end, I propose a standard compressed format (say, 7z) with a manifest and a specific file extension. The archive can be created equally well regardless of which platform the packager is on and the user experience is consistent on all platforms. Since it'd be a standard file format, there is no impediment to treating it as a normal archive with the normal tools (see omod files, over in Bethesda-land).

The tie-in with Zeitgeist is obvious. Through the specific file extension, double-clicking the file opens Zeitgeist, which guides the user through the steps of getting the mod into the right directory. The aforementioned manifest would also tie into the GUI. You could include such meta-information as the full and properly written name of your mod, for example, to be displayed instead of the name of the TP2 file.
The one item I'd add here is the handful of platform-specific 'helper programs' would need to be made available centrally, e.g. sox/oggdec and tisunpack. We already have the action functions for them, it would just be a matter of moving them into Zeitgeist so they could be excluded from the mod packages themselves.

As for the READLN problem, I like the ini idea. As a stopgap before Zeitgeist is ready, it would also be nice for WeiDU itself to have a mod header-level prompt (like README, perhaps CONFIG ~path/to/file.ini~ or simply INI ~path/to/file.ini~) where we could prompt a user to review, edit, and save an ini file before the install process really kicks off. This would also have the benefit of informing Zeitgeist that a mod has an associated ini file and prompt the same user intervention before an unattended install queue.
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: Roadmap
« Reply #15 on: June 05, 2017, 02:43:36 AM »
Quote
CONFIG ~path/to/file.ini~ /  INI ~path/to/file.ini~
Because external tools need to create/modify such ini file, the path to it should be defined by weidu and the filename of the ini also should be handled by weidu and be always the same (MyModName.tp2 => MyModName.ini)  to avoid yet another custom mess (BACKUP)
« Last Edit: June 05, 2017, 02:50:34 AM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Roadmap
« Reply #16 on: June 08, 2017, 12:16:17 AM »
Quote
CONFIG ~path/to/file.ini~ /  INI ~path/to/file.ini~
Because external tools need to create/modify such ini file, the path to it should be defined by weidu and the filename of the ini also should be handled by weidu and be always the same (MyModName.tp2 => MyModName.ini)  to avoid yet another custom mess (BACKUP)
This is arbitrarily restrictive and would nix the ability to do language-specific files (like we can with readmes), but I just don't care enough to argue about it.

One thing did occur to me is that I think the config files should be straight txt files instead of ini. I'm not sure that all versions of Windows have default programs set for handling ini files, forcing that annoying 'what should Windows do with this file' prompt. A straight txt file ensures Windows will, at worst, use Notepad and avoid a possible complication for users.
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: Roadmap
« Reply #17 on: June 08, 2017, 03:20:08 AM »
Quote
This is arbitrarily restrictive and would nix the ability to do language-specific files (like we can with readmes), but I just don't care enough to argue about it.
Those files should not contain language-specific values in the first place, unless they are comments. Only variable = value and possible all acceptable values which you can use(regex,array of the pre-defined values).Language-specific values should be inside .tra.

Quote
One thing did occur to me is that I think the config files should be straight txt files instead of ini. I'm not sure that all versions of Windows have default programs set for handling ini files, forcing that annoying 'what should Windows do with this file' prompt. A straight txt file ensures Windows will, at worst, use Notepad and avoid a possible complication for users.
It's exactly opposite: using .txt extension will cause Notepad to open those files as default but if the file will have unix.osx line endings, people will endup with unreadable mess:
http://i.imgur.com/yLZBzus.png
It's better to have .ini/.conf/.iemodconf extension to force players to use any sane file editor which will handle line endings correctly.
« Last Edit: June 08, 2017, 03:20:42 AM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Roadmap
« Reply #18 on: June 08, 2017, 08:12:28 AM »
Quote
This is arbitrarily restrictive and would nix the ability to do language-specific files (like we can with readmes), but I just don't care enough to argue about it.
Those files should not contain language-specific values in the first place, unless they are comments. Only variable = value and possible all acceptable values which you can use(regex,array of the pre-defined values).Language-specific values should be inside .tra.
Of course I'm talking about translated comments in the file. A text file that's a series of variable_name = x without an explanation for the user is the most difficult way we could do this.

Quote
One thing did occur to me is that I think the config files should be straight txt files instead of ini. I'm not sure that all versions of Windows have default programs set for handling ini files, forcing that annoying 'what should Windows do with this file' prompt. A straight txt file ensures Windows will, at worst, use Notepad and avoid a possible complication for users.
It's exactly opposite: using .txt extension will cause Notepad to open those files as default but if the file will have unix.osx line endings, people will endup with unreadable mess:
http://i.imgur.com/yLZBzus.png
It's better to have .ini/.conf/.iemodconf extension to force players to use any sane file editor which will handle line endings correctly.
The whole point of Zeitgeist is to make it easier for the user, not more difficult. Forcing a user to install a text editor instead of simply paying attention to your line endings runs against that.

As an example, here's the config file that Tweaks will roll in the next version. It's the easiest possible way I can conceive for the user and modder--the player gets explanations for everything, and I get to just INCLUDE it as needed:

Code: [Select]
/*
The settings in this file allow for this mod to be installed in an unattended mode, e.g.
if you install Tweaks Anthology with the Big World Setup. A handful of components will
otherwise pause WeiDU and wait for input; defining these values ahead of time in this
file will instead use the values defined here instead of waiting on user input in the
middle of installation.
*/

// The following values are used for the Romance Cheats component.
// Set this value to 1 if you want to use the values defined here:
OUTER_SET romance_use_config_values = 0

// This variable will remove the racial requirement if set to 1
// e.g. a value of 1 will allow Viconia to romance gnomes, or Aerie half-orcs
OUTER_SET romance_racial_requirements = 0

// This variable will remove the gender-based requirements for romances if set to 1
// e.g. a value of 1 will allow Anomen to romance males or Jaheira to romance females
OUTER_SET romance_gender_requirements = 0

// This variable will allow multiple romances if set to 1
// e.g. a value of 1 will allow you to romance both Jaheira and Aerie
OUTER_SET romance_multiple = 0

// This variable will prevent anything from ending a romance prematurely if set to 1
// e.g. with a value of 1 you can be as mean in dialogues as you like and the romance will proceed
// This also requires the romance_multiple, above, to be set to 1
OUTER_SET romance_nothing_kills = 0

// This variable controls whether romances start for new ToB games if set to 1
// e.g. if set to 1, summoning Anomen via the Fate Spirit in a new game will behave as if you romanced him in SoA
OUTER_SET romance_starts_in_ToB = 0



// This next batch of variables will be used for the  Minimum Stats Cheat component.
// Set this value to 1 if you wish to use the values defined here:
OUTER_SET minimum_stats_use_config_values = 0

// The following six stats will be used as the minimums by the component itself.
// All values must be between 6 and 15, or 0 if you don't want to change them.
OUTER_SET minimum_stats_strength     = 0
OUTER_SET minimum_stats_constitution = 0
OUTER_SET minimum_stats_dexterity    = 0
OUTER_SET minimum_stats_intelligence = 0
OUTER_SET minimum_stats_wisdom       = 0
OUTER_SET minimum_stats_charisma     = 0
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: Roadmap
« Reply #19 on: June 08, 2017, 10:26:38 AM »


Quote
Forcing a user to install a text editor instead of simply paying attention to your line endings runs against that.
I strongly agree to this as I'm always pay attention to details. But you forget about one thing: if there is a possibility to do something using two ways, people will always choose the one solution which doesn't require additional care/work. I doubt tat Linux/Mac modders will care about 'windows thing' when the first bug report with 'config file display mess' will hit them. They will tell people to use proper editor. If they are willing to switch line endings to make windows user life easier, then there is no point for having linux/mac line endings in the first place.


So regardless to the extension, maybe weidu should convert such file to windows file endings at the windows side?
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Roadmap
« Reply #20 on: June 08, 2017, 11:11:04 AM »


Quote
Forcing a user to install a text editor instead of simply paying attention to your line endings runs against that.
I strongly agree to this as I'm always pay attention to details. But you forget about one thing: if there is a possibility to do something using two ways, people will always choose the one solution which doesn't require additional care/work. I doubt tat Linux/Mac modders will care about 'windows thing' when the first bug report with 'config file display mess' will hit them. They will tell people to use proper editor. If they are willing to switch line endings to make windows user life easier, then there is no point for having linux/mac line endings in the first place.


So regardless to the extension, maybe weidu should convert such file to windows file endings at the windows side?
Honestly I don't think it's been much of a problem to date, but running a quick macro for line endings should be well within WeiDU/Zeitgeist's abilities and would be another layer of fool-proofing. And if there's one thing my decades of development has taught me it's that there is no such thing as too much fool-proofing.
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

Offline AstroBryGuy

  • Planewalker
  • *****
  • Posts: 154
  • Gender: Male
Re: Roadmap
« Reply #21 on: June 08, 2017, 12:54:02 PM »
Is there a consensus for how best to replace READLN input? Would it be .ini/.conf files or SUBCOMPONENTs in the .tp2? I want to refresh BG1NPC's code (which is currently one giant bowl of spaghetti). Part of that will be eliminating the READLN commands for romance timers and the banter timer tweak component.

I was planning on using SUBCOMPONENTs that would set the timer variable and then call the component code in a .tpa file. But, after reading this thread, I'm now considering a bg1npc.conf file, like CamDawg's example above.

For Zeitgeist, is a .conf file going to be preferred for something like setting a customizable timer, or giving a range of options via SUBCOMPONENTs?

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Roadmap
« Reply #22 on: June 08, 2017, 02:07:10 PM »
I think SUBCOMPONENTs are, in general, much preferred, but there are going to be times when they would result in an unmanageable number of components and you're more or less forced to use READLN/config file. I don't think there can be a hard-and-fast rule.
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: Roadmap
« Reply #23 on: June 11, 2017, 04:24:10 AM »
CamDawg, It is very nice solution for the mod but after second look at you proposition, is not a solution for "READLN" problem.
Similar solution existed before (Subtle SoB mod ini) but there was no way to present it to the player without creating extra solution between GUI and configuration file.
The whole point of GUI is to have all mod components, subcomponents and list of all "READLN" options + acceptable values for each of them.
Quote
/ The following six stats will be used as the minimums by the component itself.
// All values must be between 6 and 15, or 0 if you don't want to change them.
OUTER_SET minimum_stats_strength     = 0
OUTER_SET minimum_stats_constitution = 0
OUTER_SET minimum_stats_dexterity    = 0
OUTER_SET minimum_stats_intelligence = 0
OUTER_SET minimum_stats_wisdom       = 0
OUTER_SET minimum_stats_charisma     = 0


In terms of "GUI mod installer" or for command-line tool:
- it shouldn't require to set yet another variable only to read values from configuration file, it should always do it if the configuration file is present and value isn't null / default
- it doesn't provide a information for what component are these variables and values intended ( no way to generate menu for specific component )
- it doesn't have list of acceptable values which players could put there as data which can be used by external tool
- weidu should apply some checks for configuration file to not allow variables which hasn't have representation inside component code

proposition using pseudo code:
<MainComponentDesignatedNumber> "Name of the component"
<MainComponentDesignatedNumber> "descriptionForComponentOption1" <valueRangeForComponentOption1> <variableNameForComponentOption1> = <defaultValue>
<MainComponentDesignatedNumber> "descriptionForComponentOption2" <valueRangeForComponentOption2> <variableNameForComponentOption2> = <defaultValue>


example:
3210 "Minimum Stats Cheat"
3210 "Provide minimum stats for strength"      regexpOnlyDecimalNumbersRange(6..15)orArrayListOfStrings   minimum_stats_strength = 6
3210 "Provide minimum stats for constitution" regexpOnlyDecimalNumbersRange(6..15)orArrayListOfStrings   minimum_stats_constitution = 6
3210 "Provide minimum stats for dexterity"     regexpOnlyDecimalNumbersRange(6..15)orArrayListOfStrings   minimum_stats_dexterity = 6
3210 "Provide minimum stats for intelligence"  regexpOnlyDecimalNumbersRange(6..15)orArrayListOfStrings   minimum_stats_intelligence = 6
3210 "Provide minimum stats for wisdom"       regexpOnlyDecimalNumbersRange(6..15)orArrayListOfStrings   minimum_stats_wisdom = 6
3210 "Provide minimum stats for charisma"     regexpOnlyDecimalNumbersRange(6..15)orArrayListOfStrings   minimum_stats_charisma   =  6


this way weidu can add such information to --list-components-json and then Zeitgeist/other tool can:
- dynamically build gui with component list
- and dynamically build gui with treeview of ComponentOption for each component
- and set acceptable values as regexp or if there is a array of strings, dynamically build dropdown menu
- and set initial value to the <defaultValue> from configuration file


Having all above functionality is what I think a proper solution for READLN problem. I hope you see that having a GUI only to open weidu mod confoguration file is not really something which we should looking for.
« Last Edit: June 11, 2017, 04:41:02 AM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline CamDawg

  • Infidel
  • Planewalker
  • *****
  • Posts: 859
  • Dreaming of a red Xmas
    • The Gibberlings Three
Re: Roadmap
« Reply #24 on: June 11, 2017, 11:15:12 AM »
Right, but Tweaks is being released today. When WeiDU supports what you propose, Tweaks will roll a new config file. But this works now.
The Gibberlings Three - Home of IE Mods

The BG2 Fixpack - All the fixes of Baldurdash, plus a few hundred more. Now available, with more fixes being added in every release.

 

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Name: Email:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?: