Does anyone know the current status of the BWS?

[lynx]

This time probably not science, but engineering.

[Jarno Mikkola]

This time probably not science, but engineering.

Sorry, but magic and crystals wasn't really the answer I was looking for.

[lynx]

I don't know history that well, but the earliest thing I can think of is dpkg, which is around since '94. Likely didn't have subdependency support at the time, but that's not a hard thing to enact.

https://en.wikipedia.org/wiki/Dpkg

[SCO]

Got BWS running on linux wine. Then it actually breaks quite far into the process, when it tries to unzip the archives. It seems to get majorly confused with quite some of them:

 

..
The extraction of the following mod(s) failed:
BiG World Textpack: Translations and sounds (BiG World Textpack ENGLISH-v16.7z) ¹
BG1 Mini Quests and Encounters: The Mod itself (bgqe-15.zip)
BG1 Unfinished Business: The Mod itself (AstroBryGuy-bg1ub-v14.1-0-gd731814.zip)
Ajantis BG1 Expansion: The Mod itself (Ajantis_BG1-v10.zip)
BG1 NPC Project: The Mod itself (Gibberlings3-BG1NPC-v22.8a-0-g7359140.zip)
BG1 NPC Project Music Pack: The Mod itself (bg1npcmusic-v6.exe)
Coran's BG Extended Friendship Talks: The Mod itself (Gibberlings3-CoranBGFriend-v4-0-g7ec8d6f.zip)
Neera Expansion for BG:EE: The Mod itself (neera_v1.1.rar)
The following mods cannot be installed because of missing dependence:

The Picture Standard for BG2:EE:
3000: BG1NPC -> Vanilla

Cannot proceed installation without this essential mod.

 

This is pretty bunk because the files exist extracted on the BGEE folder. What may be happening is that the WEIDU execs are on the top folder, but the .tp2 and .tp2.dlt are inside the folder in some cases. The "BiG World Textpack" seems like a strange case where the tp2 is on the BGEE dir but i don't know where it comes from (it's not on the archive) and the weidu exe doesn't exist. I believe that the exec not existing is not a showstopper because they're all supposed to be the same and you use the latest version, but it breaks somehow.

 

What i don't understand is how windows people are even managing to run this if these errors happen there too. Why don't you modders organize yourselves to have one and only one archive folder structure for mods?

 

It's maybe some funky code on the virtual basic files which is failing silently even after installing 'winetricks -q wsh57 vcrun6' on wine. Who knows, maybe the windows shell vb version is different.

[SCO]

For reference, this is the script i used to run BWS (renamed folder to BigWorldSetup; created file on the parent of the folder):

#!/bin/bash

PREFIXES="$HOME/.local/share/wineprefixes"
mkdir -p "$PREFIXES"
export WINEARCH=win32
export WINEPREFIX="$PREFIXES/BWS"

GAME_PATH=$(dirname "$(readlink -f "$0")")
cd "$GAME_PATH/BigWorldSetup"

winetricks -q wsh57 vcrun6

#wine wscript "Start BiG World Setup - Without Update.vbs"
wine wscript "Start BiG World Setup - Update If Needed.vbs"

[SCO]

Turns out that "BiG World Textpack" readme says the bat file is supposed to 'be run after unzipping all the mods but before installing'. I'm pretty sure that these bat files are failing in wine because they use windows stuff that is not 'core'.

 

It's pretty clear that megamods maintainers love bat files when they need 'more power' than WEIDU, because multiple fundamental transformations are 'hidden' in them. Well, either BWS evolves and removes this requirement to have pieces of code not tracked on the system itself, or if these bat files could be converted to actual tp2 scripts, most of these incompatibilities would disappear.

 

But to be clear, i still think that in order to 'tame' this into true portability, all of the relevant code to turn a install into a modded game should be on the same system and visible at the same level. Mod order, is not enough, but mod order + attached scripts on a powerful script language attached would be and more importantly, would discourage modders from creating incompatible or non-portable hacks by having a working solution out of the box.

 

I suppose WEIDU would be even better since it's reversible, but there must be a reason this isn't done already and the reason is probably 'it's already done' or 'it's too difficult'.

 

Resuming, i'm going to just wait another 3 years because there is no way that BWS big mods install will run on wine when wine won't run the multiple bat files necessary. Sad to say, but for now, linux IE and IE_EE megamod modding is pretty much windows only, or a extremely tedious affair of generating a mod list yourself and butchering the given bat files until they work.

[lynx]

Doesn't wine have dosbox integration? Batch files shouldn't really be a problem.

[Roxanne]

Doesn't wine have dosbox integration? Batch files shouldn't really be a problem.

The issue is, that the above rant mixes everything in one big hotchpotch, as it misunderstands the roles of BWS vs Weidu vs how modmakers create their mods. And totally misses the fact that BWS deals with the sources its given to, with no influence on how those are designed and working.

[SCO]

Doesn't wine have dosbox integration? Batch files shouldn't really be a problem.

Not exactly. Wine doesn't have nearly the compatibility the original windows cmd line has (it's better than dosbox, that doesn't even have attrib though).

 

 

 

Doesn't wine have dosbox integration? Batch files shouldn't really be a problem.

The issue is, that the above rant mixes everything in one big hotchpotch, as it misunderstands the roles of BWS vs Weidu vs how modmakers create their mods. And totally misses the fact that BWS deals with the sources its given to, with no influence on how those are designed and working.

 

I checked out the sources of BiG World FixPack on here https://github.com/BiGWorldProject/BiG-World-Fixpack, and while it seems a *part*of the original bat file was converted to WEIDU, and it says " This script is legacy code and has been replaced by the newer _ApplyPatches script" which is a tp2.

 

However, to actually *run* that new file there is a new bat file: https://github.com/BiGWorldProject/BiG-World-Fixpack/blob/master/_CreatePatches.bat

 

I'm 80% sure this is what failing (80% because BWS doesn't actually report the right errors, just says 'this failed to extract' when it actually *did* extract).

 

I could try to delete the @echo off on that file and see if something happens. Guess i'll try it on a minimal EET after restoring my rage-quit delete.

 

If someone else wants to track down the error, the script above will run BWS on linux, so a minimal EET mod install should easily replicate it.

[lynx]

it just runs weidu, which you can do manually. It's simply a user bonus, since windowers don't have terminals close at hand and weidu isn't shipped with this particular mod.

[SCO]

Ok then. The extraction logs are kind of big and 'weird' even for a minimal EET so i'm uploading them as a gist.

 

extraction log

 

download log

 

In spite of 7z outputting those cyrillic(?) letters, it actually names them correct. One thing though, the EET folder is like this:

 

Baldurs Gate II/

EET-master/

README.md

setup-EET.exe

EET/

EET.tp2

<rest of the files>

 

 

ie: it has a 'extra' 'EET-master' folder around it all that may be confusing the autoit script. It's not the only 'extract' error (in fact all of them say there is a error extracting but have the tp2 on the main BG 2 folder, except 'EET-master')

[Roxanne]

Which should be

 

Baldurs Gate II/

EET-master/

README.md

setup-EET.exe

EET/

EET.tp2

<rest of the files>

EET master is just an envelop created by github around the files you need. Which is true for most other mods downloaded directly from the github masters, not just EET.

Just move the real stuff up one level and see that it works.

[subtledoctor]

@SCO BWS has never been, and will never be, interested in cross-platform portability. You see what kind of tespons s you get when you discuss it. If you know your way around programming stuff (I don't ) then I submit it might be more productive to help out with the new GUI version of Weidu, which is cross-platform. Hopefully, with support and contributions, it will eventually fold in stuff like automated install orders and incompatibility avoidance.

[SCO]

@Roxanne, i tried that after posting, but it didn't really work. I tried:

 

1. 'No download - only report missing mods' on 'Download-logic', deselected 'install mods in batches'

2. moved the EET-master.zip out of the download folder, repacked a new version of the zip without that upper folder.

3. continued, [p]rovided and elected the new file, [f]orced BWS to ignore the mismatched sizes.

 

 

Aaaand, the same errors occurred.

 

edit: hmm, i didn't delete the Readme.md, no sure if it matters.

 

The requirement for the savegames on the BGEE and EET installs seems wrong to me too. Is this still really needed or a bit of AutoIt code no one knows how to edit anymore to disable the check in these cases?

 

@subledoctor Well, that may be right, but wine is not 'portability' but a emulation layer.

 

Using the native version of WEIDU is certainly possible (if super tedious and probably broken as my previous experience butchering the Leonardo BGT bat file back in 2015 taught me), but i expect a compatibility layer of 'rename all files to lower case' and 'use dos2unix on every file to remove \r' pre-processing step would be needed to use native WEIDU and native BGEE execs (depending on how the game runs on mixed \r\n and \n).

 

Also, what new gui version of WEIDU? The critical thing about a replacement for BWS is the conflict rules and to make sure that the (no standards) mod archives actually get placed right. Just a GUI to install multiple weidu mods is not enough if you want a rich ecosystem.

 

Honestly, a great deal of mods should just get updated by people other than the maintainers to get their archive directory structure right. It's incredible that there are 'installers' for every other mod that have to be extracted by 3 or 4 different formats and that the folder structure inside is apparently at will and needs heuristics for a install to be automated. Some people place zips inside of zips and apparently BWS has to deal with this!

 

Another 'solution' to this 'mod extract directory structure' bull is if WEIDU introduces its own 'mod archive format' that is well specified. If that happens, and it can be used directly i expect that a trickle of new versions of mods gets converted to the 'new, no 'unzip' format' and the problem would solve itself mostly. This is probably hard to do because of the way WEIDU writes files though.

 

Just make sure it has some 'sanity checks' like 'no executables inside the archive', 'no bat files inside the archive' and 'no zips inside the archive' and 'put in a actual version number on the version number to create the archive'.

[lynx]

weidu runs fine on osx and linux, besides not caring about whitespace. It has nothing to do with batch files. Unfortunately, the gui thing in development is not something that will replace bws, but that discussion was already held.

 

just a wild guess - the download errors are from higher up, so something went wrong while un/re-packing, giving you not-so-helpful errors.