Does anyone know the current status of the BWS?

[SCO]

Yeah it makes sense that the error is on extraction, it even says there are errors, for example:

 

 

øvørythingàisàOk

Foldørs:à73
Filøs:à599
Sizø:ààààààà342750897
Comprøssød:à277975694

D:\Documønts\Gómøs\PCàGómøs\BóldursàGótøàTrilogy\BigWorldSøtup\BiGàWorldàSøtup>The following command failed to extract an archive:
"D:\Documents\Games\PC Games\Baldurs Gate Trilogy\BigWorldSetup\BiG World Setup\Tools\7z.exe" x "D:\Documents\Games\PC Games\Baldurs Gate Trilogy\BigWorldSetup\BiG World Downloads\EET-master.zip" -aoa -o"D:\Documents\Games\PC Games\Baldurs Gate Trilogy\Baldurs Gate II"
This may be caused by several reasons.

 

However, all the files were extracted, so these 'errors' are entirely spurious (unless the error above is even more misleading than what i think and it's checking for some file it does not find instead).

 

What is getting me annoyed is that even if ask it to 'continue', by manually extracting the zips into the folder, that also doesn't work.

 

 

Also that -aoa switch on the 7z exec invocation above is strange. -o is output dir, '-aoa' is nothing i can tell from running the given archive 7z on wine to check the switches.

edit: never mind. It's not on the output (whyyyy) but google tells me it's "Overwrite All existing files without prompt".

[Jarno Mikkola]

Also, what new gui version of WEIDU?

This. Well, and in line, what ALIEN suggests to do with the topic titles "weidu next generation ... blah plah".

It's not a rich echosystem, it's more of an ease of use ... which will allow better usability in the long run with everything in weidu mods, as it allows better ways to integrate it via other tools, not just BWS.

[SCO]

I looked at the autoit code of BWS and i think i know what's happening.

 

The way BWS looks for 'success' on extraction is to compare the stdout of 7z to 'Everything is Ok'. Quite naturally it's possible that trying to compare 'Everything is Ok' to 'øvørythingàisàOk' is kind of broken.

 

This is some kind of wine charset problem. I think i need to go look in wikis.

[lynx]

maybe try running it with LANG=C or LC_ALL=C.

[SCO]

None of those or LC_ALL=en_US or LANG=en_US appear the work (i nuked the prefix obviously). It's pretty strange, it seems the text gets mangled on the round trip:

 

7z output > visual basic text frame > string > compare if "Everything is Ok" is in string.

 

7z is a process in autoit, then it gets into the frame already wrong (thus the log and the text frame having those weird names). So the error must be on the transition from getting the ouput of the process and autoit, or visual basic 'assuming' something about its encoding before dumping it on the visual basic frame.

 

This is probably complicated from the only way to run BWS on wine being with winetricks installing native visualbasic dlls. Who knows how they react (or not) to LC_ALL and LANG.

 

 

I want to ask, when BWS is run on a native windows, english language windows or not, the names output by 7z during the extraction step are correct for you right?

[subtledoctor]

Using the local, native version of Weidu works just fine with WINE installs as a general matter - I routinely use my macOS Weidu Launcher app to install mods onto BGT on my Mac.

 

Getting BWS to actually use that version of Weidu... I have no idea.

[SCO]

This has nothing to do with WEIDU, it's autoit code or possibly 7z that is failing to interpret correctly text. The failure reported here happens because of a very fragile way of checking for failure + wine pulling the rug underneath some assumptions.

 

Now that i looked at the 07_Extract.au3 file some more it apparently hardcodes some mods to move files to the upper game dir. No wonder that EET-master.zip had a extra folder.

 

Are EET BWS installs even working on windows? Because, besides this charset problem, this would seem to indicate they aren't, because it would download from github with the extra dir, and not get corrected (i searched for 'EET-master' on the 07_Extract.au3 file and it doesn't exist, unlike say, 'SandrahToT-master'). Maybe the code has a working heuristic though, not sure without fixing the 'error' above.

 

Man, BWS really needs a substitute that is maintained and has fileformat standards of 'you must at least be this sane' for accepted mods. Not using a eldritch language and having a codebase of tens of thousands of lines and not hardcoding mods to be treated especially would be good too.

[subtledoctor]

Yeah but at that point you're talking about starting over with a new codebase.

 

And st that point, like I say, there's already a cross-platform GUI version of Weidu being developed... why not work on adding the good things about BWS (install order determination and conflict detection) to that project? Get away from being just a massive script that runs things in the command line (things which themselves are just massive scripts).

 

In fact AL|EN has been very vocal over on the Weidu forum, to the benefit of that new program.

[SCO]

The installer doesn't need to be the same tool as the mod order checker. The mod order checker literally just has to have a database of 'orderings', or if you're willing to have a single order (the situation today in BG modding, unlike for example morrowind) and remove confliicts until you get a sequence of components the user wants. Downloading and extracting is useful too.

 

Then pass that list to the installer (It could be cmd line weidu for all i care after this, as long as it works). The problem with BG mods are all the hacks that people invented over the years and the lack of standards, which created a mod ecosystem with zips, rars, 7z or those horrible NSIS-Setups with random folders inside, and the possibility of requiring more unzipping and even executing bat files or other executables. This all prevents automation.

 

That is what must be discouraged and forcefully solved, or at least the metadata must categorize the mods more deeply so these problems can be 'worked around'. So for example, if you couldn't convince wisp to only accept mods with the tp2 and the directory on the toplevel nothing else (the sane preference, though maybe a toplevel dir is better because of github); then your metadata would have:

 

mod.archivepath=stupid_extra_folder/actual_folder

or something for the app to not need a hack for the 'single' mod.

 

That UUID idea is interesting. I have to read more about the use case.

 

There is something to be said for BG modding depending on a single mod order for megamods (BWS), namely that it makes the metadata much less (compare mlox metadata file with the size of BWS data file). That is no reason for a flexible mod order tool not to be able to use other, possibly better orderings though.

 

A suggestion for whoever does a mod order tool (if not Zeitgeist), even if it doesn't download mods, it would be helpful to export and import a ordered list of mods, so people who share the same interests could share lists. Even though it's dangerous (less tested), i assume it would be helpful for 'opinionated' people or to introduce unpopular mods (because, say they break all the romances).

[lynx]

if you think switching to a different system would require less hacks, I have bad news for you (just from linux packaging experience). Sure, some could be converted to data, but it's more code either way. Worrying about file extensions and subfolders seems really contrived (again, a solved problem).

 

A map of orderings is impossible, as some mods are too intertwined. See earlier discussions: http://gibberlings3.net/forums/index.php?showtopic=26245 http://gibberlings3.net/forums/index.php?showtopic=28503

 

Weidu has become a standard long ago. Luckily, more and more mods are now under public version control, which automatically improves predictability and reliability. I think batch files are only used for audio and tileset and maybe other graphic conversions. Many come with shell alternatives or launch this stuff from within weidu. Things are only going up.

[subtledoctor]

Well, to be honest, the automatic downloading of mods is the last priority as far as I'm concerned. I can go out and find mods that I like, and unzip/extract/unrar them into a folder. The far more important parts IMHO is the install order and conflict-detection stuff.

 

I can't use BWS but I do have opinions about it... It seems to me that combining all these functions into a single package is one of its biggest problems. Like, it should be easier for mods themselves to report their own incompatibilities, in a machine-readable way that BWS or whatever future tool can handle. And for installation order, instead of some massive list with a proprietary syntax, why not just do a massive megamod install that's been tested to be pretty bug-free, and then rename the weidu.log to weidu.order, or something like that. And the installation tool could simply read that log file. And if it works well people can pass it around. And pass around newer, better ones if the situation changes. Etc.

 

Implement that with, as you say, a "non-eldritch" language that works across different platforms, and Bob's your uncle.

 

Now, as to who has the time and expertise to actually do that...

[Jarno Mikkola]

Luckily, more and more mods are now under public version control, which automatically improves predictability and reliability. I think batch files are only used for audio and tileset and maybe other graphic conversions. Many come with shell alternatives or launch this stuff from within weidu. Things are only going up.

Well, the BWS actually has had kinda large impact on that on PC, as the old biffing was done via .bat files and todays, the BWS had to remove everyone of them to fix the issues the biffing raised, in everyone of the old mods.. as it was able to be done better, later.

 

Implement that with, as you say, a "non-eldritch" language that works across different platforms, and Bob's your uncle.

Well, have you yourself downloaded these "weidu mods" and installed them ?

// Log of Currently Installed WeiDU Mods (May 2017)
// The top of the file is the 'oldest' mod
// ~TP2_File~ #language_number #component_number // [Subcomponent Name -> ] Component Name [ : Version]
~SETUP-WEIDU.TP2~ #0 #0 // 24000
~SETUP-BWS.TP2~ #0 #0 // Expert Mod In Selection: NeJ2v694
~SETUP-BWS.TP2~ #0 #1 // Expert Mod In Selection: NeJ2v691
~SETUP-BWS.TP2~ #0 #2 // Expert Component In Selection: 1pp_hq_music_BGT(+)
~SETUP-BWS.TP2~ #0 #3 // Expert Component In Selection: 1pp_hq_music_BGT(0)
~SETUP-BWS.TP2~ #0 #4 // Expert Component In Selection: 1pp_hq_music_II(0)
~SETUP-BWS.TP2~ #0 #5 // Expert Component In Selection: 1pp_hq_music_ToSC(0)
~SETUP-BWS.TP2~ #0 #6 // 20161130 - Updated by agb1 (installation started 17-05-20)
~SETUP-BWINSTALLPACK.TP2~ #0 #0 // BiG World Installpack v16.7z
~TOBEX/TOBEX.TP2~ #0 #100 // TobEx - Core: Beta 0025
~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #0 // BG2 Fixpack - Core Fixes: v10 (BWP Fixed to v11 Alpha 1)
... 

That's what stands in a weidu.log and there's not really great ways to go around that. But if it were that easy, weidu could itself be used to have that utilized, as it has some old replica of that, that can retroactively start the files and install them in that order. .. from what I understand of it, as it can also uninstall and reinstall stuff on a ready-made chain, if you go an uninstall a component from the middle, if you haven't old_style_biffed the content which cannot be chain-uninstalledn.. as it required the .bat uninstall.

[SCO]

I can't use BWS but I do have opinions about it... It seems to me that combining all these functions into a single package is one of its biggest problems. Like, it should be easier for mods themselves to report their own incompatibilities, in a machine-readable way that BWS or whatever future tool can handle.

I believe this is sort of misguided. You really can't expect a modder to install every mod under the sun to check if it breaks theirs... but you can expect that to insane mod users.

 

Dependencies, fine, although 'someone' has to be ready and willing to commit updates; for example i'm 99% sure that i can install BWS - if i could - with the EET Tweaks xp cap remover and aTweaks multiclass HLA (that requires 'aTweaks' level cap remover). Only i probably can't, because the tp2 doesn't have that idea (until it gets patched by a 'BiG mods' fixpack anyway).

 

I find it funny that we're in a situation where dead mods are being patched with diff files, because no one dares to just take the code. Mods really should have been GPL'ed or something from the start... doesn't apply to aTweaks, but some others. If i ever do a game i'll decree all mods are gpl, so this pearl clutching can cease, if it's super successful. Eh, diff files are easy to get applied upstream at least, so maybe its for the best than 5+ different versions. 'Fixpacks' are just so... inelegant to a programmer.

[lynx]

And then you remember debian ships diffs of diffs in their package specs. :>

[SCO]

I do remember, i've done some of them (dosbox and exult ppa). And i've complained voraciously about dosbox upstream not adopting some of those patches, which is the reason i bothered (voodoo and mt32).

 

Mods though, mods that have been dead for years?

I'd say just fold copy the relevant functions into a actual 'related' group maintained mod. So for example, ideally, aTweaks xp cap remover would disappear, and EET/BG1/BG 2/PST Tweak would be the only ones.

 

Duplication of functionality diverts developer effort and costs users valuable brain hertz to resolve conflicts basically.

 

I think Zeitgeist - from what i've read - is going for a less metadata, more actual reading tp2 for finding the actual components and conflicts defined there because wisp has the idea that that is sufficient and more democratic that metadata controlling installs orders or availability, but i simply disagree that everything can be 'distributed' like that. Metadata is the only solution i can think that is 'accessible' for joe mod order maintainer, over for example diff files or learning WEIDU, even if stable sorting doesn't come into play with precedences and only conflicts, dependencies and warnings are supported. Responsiveness to conflict findings is key.