Post reply

Warning - while you were reading a new reply has been posted. You may wish to review your 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:
Subject:
Message icon:

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)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Wisp
« on: July 14, 2017, 12:53:13 PM »

The subject of Zeitgeist eventually replicating functionality presently offered by BWS has come up and I thought maybe I should comment. There are at this time no firm plans beyond those already described in this thread. After that, who knows? But, personally, I have little interest in BWS-like functionality. I have some highly tentative plans for quality of life features suitable for maintaining more curated mod sets, but it should be emphasised that these are highly tentative and will come after the already planned features have been implemented.

But Zeitgeist is free software using mainstream technology and if someone wants to contribute good code towards their cause, I'm not opposed to merging it.

Edit: also, on the subject of plugins: if there is demand for such, we can certainly talk about it, but there are some technical hurdles involved. The plugin would need to be compiled against the same versions of the same (relevant) libraries as the main program. Then there are whatever limitations are imposed by the plugin API. I'm thinking if someone wishes to write features for Zeitgeist, it might be easier to just upstream them.
Posted by: AL|EN
« on: June 21, 2017, 09:22:13 AM »

In my opinion, the day of releasing Zeitgeist is a perfect day for abandon auto-overwrite design and threat every weidu SDK instance as standalone.
Posted by: Wisp
« on: June 18, 2017, 10:01:27 AM »

I was really brainstorming for a way to get non-Zeitgeist WeiDU--WeiDU Classic? OS (Old School) WeiDU? WeiDU's Not Zeitgiest (WNZ)?--an easy way to pop up the file prior to the installation process. In the end, whether it's an explicitly defined filename in a tag or implicitly via convention it works out the same.
Let's say, completely hypothetically, that the next version of WeiDU would coincide with roughly shell-menu-equivalent GUI functionality and that WeiDU 243 would have axed the shell menus themselves. Just out of the possibility events were to unfold in this manner, I'm rather hesitant to do non-trivial work on the shell menus or add any new interactive features.
Posted by: CamDawg
« on: June 14, 2017, 08:44:46 PM »

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.
I was leaning towards convention over configuration, myself. If mymod/mymod.conf exists, it would be used, otherwise not. The translated comments is a fair point, but surely having one configuration file for each language would be fairly suboptimal (every time you wanted to add/change/remove something). There must be a better way to do it (but for the moment all I can think of is a TRA-like scheme).
Sure, a translatable config file is an edge case at best. I was really brainstorming for a way to get non-Zeitgeist WeiDU--WeiDU Classic? OS (Old School) WeiDU? WeiDU's Not Zeitgiest (WNZ)?--an easy way to pop up the file prior to the installation process. In the end, whether it's an explicitly defined filename in a tag or implicitly via convention it works out the same.
Posted by: Wisp
« on: June 14, 2017, 02:30:53 PM »

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.
It's a nice idea. I'll have to tinker a bit to evalute whether its feasible. It is possible you could define the process environment in which Zeitgeist runs WeiDU to include references to other executables. Worth noting, however, is that this would complicate matters for users of BWS or other ways of running WeiDU, as these other things would need to set up comparable environments.

Quote
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.
I was leaning towards convention over configuration, myself. If mymod/mymod.conf exists, it would be used, otherwise not. The translated comments is a fair point, but surely having one configuration file for each language would be fairly suboptimal (every time you wanted to add/change/remove something). There must be a better way to do it (but for the moment all I can think of is a TRA-like scheme).

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.
Any changes here are going to introduce backward-incompatibilities (of the kind 'mod/der expects some specific kind of newline, but file was written with another kind'). What I can do, and which is the OCaml stance on the subject and the lack of which is the source of at least one otherwise unsolvable bug/shortcoming (regexp-$ does not match CRLF), is convert all newlines into LF when reading files and convert them into platform-native form when writing files. This would mean mods and WeiDU always and only see LF when running, but files use the native kind of newlines when at rest. Edit: it may be possible to avoid backward-incompatibilities by stealth-converting all CRLF sequences in TP2 strings into LF, because what could possibly go wrong?
Posted by: CamDawg
« 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.
Posted by: AL|EN
« 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.
Posted by: CamDawg
« 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.
Posted by: AstroBryGuy
« 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?
Posted by: CamDawg
« 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.
Posted by: AL|EN
« 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?
Posted by: CamDawg
« 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
Posted by: AL|EN
« 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.
Posted by: CamDawg
« 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.
Posted by: AL|EN
« 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)