Feature Request: -C , --directory

[MagusWizardo]

Essentially, I want to be able to run WeiDU like so:

Code: [Select]

weidu foo.tp2 -C /bar/baz
This would parse foo.tp2 as normal, but it would change the working directory to /bar/baz. In other words, it would run 'weidu foo.tp2' as if weidu were located at and running from /bar/baz, ala gnu tar.
This would allow mods to be installed by a shell script/batch file set up with that line, which would in turn allow one machine to have exactly one copy of WeiDU (instead of one for every mod that has been downloaded as it is currently). WIth front ends to WeiDU, this could be simplified further.
The net benifits I can see coming from this are, in no particular order:

• Slightly smaller mod packages (one small batch file / shell script, rather than a copy of weidu.exe).
• Probably easier to write front-ends for WeiDU.
• We'd be alot closer to automatically cross-platform modding - this would let us simply change a few scripts (the one to actually install it, and any we happen to use to call external apps), and the archive format.
• Easier version control (none of this "now re-run setup-foo.exe").

[the bigg]

In windows, you can put in a dir inside the path WeiDU.exe and a properly designed install.bat:

Code: [Select]

mkdir debugs
weidu.exe --tlkout dialog.tlk [--ftlkout dialogf.tlk] --log debugs\setup-%1.debug %1.tp2 setup-%1.tp2 %1\setup-%1.tp2 %1\%1.tp2
so that you can CD to BG2's dir and then
install somemod

to install all mods with exactly 1 copy of WeiDU. You can also add check.bat to try to work out bugs:

Code: [Select]

mkdir debugs
weidu.exe --debug-assign --debug-value --tlkout dialog.tlk [--ftlkout dilalogf.tlk] --log debugs\setup-%1.debug %1.tp2 setup-%1.tp2 %1\setup-%1.tp2 %1\%1.tp2
then to get full debug info you give
check somemod

BTW: you'll notice I moved the debugs inside the debugs dir. This removes a lot of files from the main dir.



So, an appeal to modders: please move your tp2, bat, old tp2, readmes, kit 2da... inside your mod directory. This leaves only the directory inside BG2 dir, without any additional files.
Thanks for helping clearing my BG2 directory!

[CamDawg]

So, an appeal to modders: please move your tp2, bat, old tp2, readmes, kit 2da... inside your mod directory. This leaves only the directory inside BG2 dir, without any additional files.
Thanks for helping clearing my BG2 directory!

Moving tp2s from existing mods into their mod folder makes upgrades substantially more difficult for players. Otherwise, yes, please.

[the bigg]

Moving tp2s from existing mods into their mod folder makes upgrades substantially more difficult for players. Otherwise, yes, please.

This doesn't apply to specifically suited bat installers for your mod (in case this is ever needed, please warn the user that running the bat on first time around is needed, or specify manual actions):

Code: [Select]

setup-somemod.exe somedir\[setup-]somedir.tp2
del oldtp2.tp2and the new tp2 explicitly uninstalls the old one. [note: better change your backup directory's name at least].
Note II: of course, the tp2 file will be the same as the directory (something that you should already know, but maybe it's not universally known)

Of course, when I think of all the mods which package readme.txt directly inside the BG2 dir (TS, I'm looking at you), their own copy of weidu.exe v150 (TS, I'm looking at you again), leaves old tp2 (Ease of Use, hello), or leave in maindir the 2da for the kits (waves at Warrior Kit Pack) all I can do is 

[CamDawg]

Moving tp2s from existing mods into their mod folder makes upgrades substantially more difficult for players. Otherwise, yes, please.

This doesn't apply to specifically suited bat installers for your mod (in case this is ever needed, please warn the user that running the bat on first time around is needed, or specify manual actions):

Unless you actually care about making things easier for your players. We use SFX-RARs explicitly because we don't want users to be forced into installing something unless it's the way that they want to install the mod. If they wish to extract and execute it themselves (or, extract it multiple locations without going through the self-extraction dance on every pass) this fails. This also doesn't account for anyone to whom you distribute and support your mod that doesn't come with executing installers (heya, OS X folks).

Good interface design is about providing the maximum number of failsafes to your users and minimizing the number of steps they need to perform. Adding an additional level of complexity (and its inherent failure points) to remove a legacy tp2 for cosmetic reasons qualifies as neither.

[devSin]

How can this not be accomplished with the existing functionality? You can use 'cd' or whatever in your script (which can't be entirely universal, since you need to know where to cd to), and the --game flag to tell WeiDU where the game is (WeiDU itself can be anywhere, and you can probably install mods from anywhere, as long as you tell WeiDU which game to target).

[the bigg]

I have weidu.exe and install.bat inside the e:\bgii - soa directory; the PATH variable contains e:\bgii - soa, and the register links BG2 to e:\bgii - soa.
However, if I go to RTW directory (e:\bgii - rtw) and launch install rtw, it will install in RTW directory. So, you can put weidu.exe inside the PATH variable, call it from the command-line from the installation of an IE game you are going to work on, and Windows will sort out everything on his own.

As for distributing, I assume 50% of the people don't know how to "get weidu and run the installer from the command-line", so I'll continue to add setup-foo.exe.

[MagusWizardo]

and Windows will sort out everything on his own.

Notice I said platform independance. Hint: I'm a Linux guy.   Basically what I want is a situation where every mod is platform independant without extra work from the author - which makes assumptions about what the OS will and won't do not good.

How can this not be accomplished with the existing functionality? You can use 'cd' or whatever in your script (which can't be entirely universal, since you need to know where to cd to), and the --game flag to tell WeiDU where the game is (WeiDU itself can be anywhere, and you can probably install mods from anywhere, as long as you tell WeiDU which game to target).

That sounds like it could just do exactly what I want.. thanks.

[the bigg]

Notice I said platform independance. Hint: I'm a Linux guy. Basically what I want is a situation where every mod is platform independant without extra work from the author - which makes assumptions about what the OS will and won't do not good.

On all platforms, commands from the $PATH are executed from the $PWD without need to specifying it. Hint: under Linux, "rm" is an executable inside the path (as is cp, mv, rename and a slew of other common commands). If you do rm somefile, it removes somefile from the $PWD, rather than from the path containing "which rm". With WeiDU, it's the same thing: it installs in $PWD rather than in /bin or wherever you put weidu (or whatever you called it).

If you take the install.bat I posted above, rename it to install.sh, make it executable, add it into the $PATH (preferabily, but not needed, in the same dir as weidu), replace weidu.exe with weidu, and replace %1 with $1, it will work: 1 copy of weidu and 1 simple script, and this will allow to install mods in any dir.

Note: I am a Windows guy, with some use of Cygwin and Linux, mostly command-line bound, so I know what I'm talking about.

[MagusWizardo]

*reads thread again*
*realises the shell script method might actually work*
*decides to start testing stuff instead  of spurting crap again*