Installing SCS on BG2EE Linux

[vtazt]

Wait why are you using 'cp' instead of 'mv'? I had initially thought there was a reason for it -- something to do with ciopfs -- but I don't think there is one. This works fine:

mv bgee bgee_tmp
mkdir -p .ciopfs/bgee bgee
ciopfs .ciopfs/bgee bgee
cd bgee_tmp && mv * .mojosetup ../bgee

Edit: Clean up warnings.

 

Edit: Well the warnings are still there, but they're superficial. 'mv' is telling us about discrepancies in symlinks, but that's only because 'mv' doesn't understand that e.g. libx11.so.6 and libX11.so.6 are the same.

 

Edit: Oh, 'cp -a' produces the same warnings; I thought it was a 'mv' issue.

[vtazt]

OK here is the improved installer for BGEE Linux:

## config

SCS=~/Downloads/lin-stratagems-v30.zip
BIG_WORLD=~/Downloads/BiG-World-Fixpack-master.zip
BG_DIR=~/usr/bgee
CIOPFS_DIR=~/.ciopfs/bgee
WEIDU_DIR=~/usr/weidu
PLATFORM=amd64 # or i386

## vars

BIG_WORLD_DIR=`basename "$BIG_WORLD" .zip`
GAME_DIR="$BG_DIR/game"
BG_DIR_TMP="$BG_DIR-tmp"
WEIDU="$WEIDU_DIR/bin/$PLATFORM/weidu"

## check tools

set -ex
"$WEIDU" --version
dos2unix --version
ciopfs --version
unzip -v

## run

echo "Mounting case-insensitive filesystem (the warnings are OK)..."
mv "$BG_DIR" "$BG_DIR_TMP"
mkdir -p "$BG_DIR" "$CIOPFS_DIR"
ciopfs "$CIOPFS_DIR" "$BG_DIR"
cd "$BG_DIR_TMP"
mv * .mojosetup "$BG_DIR"
cd ..
rmdir "$BG_DIR_TMP"

echo "Unpacking BiG fixpack..."
# unzip has no --strip-components; rm containing dir manually
cd "$GAME_DIR"
unzip "$BIG_WORLD"
cd "$BIG_WORLD_DIR"
mv * ..
cd ..
rmdir "$BIG_WORLD_DIR"

echo "Unpacking SCS..."
cd "$GAME_DIR"
unzip "$SCS"

echo "Running dos2unix..."
cd "$GAME_DIR/stratagems"
dos2unix ./tactical_bg1/c2end.tpa
dos2unix ./tactical_bg1/demoncult.tpa
dos2unix ./genai/genai.tpa
dos2unix ./lib/install.tph
dos2unix ./lib/stratagems_shared.tph
dos2unix ./lib/always.tph
dos2unix ./caster_shared/caster_shared.tph
dos2unix ./gameplay/npc_proficiencies.tpa
dos2unix ./gameplay/npc_separate.tpa
dos2unix ./gameplay/wk_early.tpa
dos2unix ./setup-stratagems_autoinstall.tp2
dos2unix ./initial/initial.tpa
dos2unix ./tactical_bg2/spawn.tpa
dos2unix ./sfo/install_sfo.tpa
dos2unix ./sfo/general/lib_macro.tpa
dos2unix ./sfo/general/lib_iterate.tpa
dos2unix ./spell/ironskins.tpa
dos2unix ./sarevok/sarevok.tpa
dos2unix ./setup-stratagems.tp2
dos2unix ./werewolf/werewolf.tpa
dos2unix ./item/elemental_arrows.tpa
dos2unix ./item/dispelling_arrows.tpa
dos2unix ./help/baf/shout.baf
cd ..

echo "Running weidu..."
"$WEIDU" --log big.log _applypatches.tp2
"$WEIDU" --log scs.log stratagems/setup-stratagems.tp2

echo "Success! If you reboot you will need to run \"ciopfs '$CIOPFS_DIR' '$BG_DIR'\", or you may set up fstab to do it for you."

[khelban12]

OK here is the improved installer for BGEE Linux:

echo "Running dos2unix..."
cd "$GAME_DIR/stratagems"
dos2unix ./tactical_bg1/c2end.tpa
etc
cd ..

 

Do you convert cr-lf to lf only for specific files because it is needed only for those patches or you convert every SCS file that has cr-lf terminators ? If you convert every file, wouldn't something like the following be more appropriate ?

# Catch other mods too
cd "$GAME_DIR/"

# all the mods i have seen have weidu files named tp2, tpa, tph so with .tp? you can catch all of them and nothing else
find . -type f -name "*.tp?" -exec dos2unix {} \;

{} gets replaced with each match and \; signifies the end of the exec command line.

[vtazt]

You missed *.baf. That causes more patch failures. Well if we only do the baf individually then it seems OK. Only a handful of the 1836 patches fail. Running dos2unix isn't an expected step; there shouldn't be any patch failures. The goal is to not use dos2unix in the first place. Having the explicit list will help identify the problem, which is not as simple as line endings on patch files. Every patch file in the fixpack has dos endings except

./BiG World Fixpack/TS/TSAreasSounds.bat.patch -- 58.33% unix, 41.67% dos
./BiG World Fixpack/karatur/setup-karatur.tp2.patch

and all 220 .tp? files in stratagems have dos endings except

./ssl/ssl.tph
./lib/crossplatform.tph
./initial/taimonhacks.tph
./initial/beregost.tph

so the underlying problem is not clear, at least to me.

 

[Edit: Well most of those fixpack files are for things other than stratagems; I didn't really know what the fixpack addressed until now. So there's no mystery: the files that fail are exactly those with dos line endings. And dos2unix isn't needed, just --binary flag for patch.]

[vtazt]

@agb1, I missed your comment here http://gibberlings3.net/forums/index.php?showtopic=28443&p=249754

 

Running dos2unix on the patch files doesn't help. I had said in one of the earlier posts that the key to understanding patch is that it will gladly strip CRs from patch files but it won't touch target files. So you may convert the patch files if you like, but patch won't care (though it'll avoid the message "Stripping trailing CRs from patch").

 

Edit: The solution is to use 'patch --binary', but it's complicated:

 

dos target, dos patchfile --> use patch --binary

unix target, dos patchfile --> use normal patch

dos target, unix patchfile --> not possible

unix target, unix patchfile --> use normal patch

 

So it would seem that you need to run unix2dos on all patchfiles, and when applying the patch check to see what endings the target has (or notice a failed patch and try again with/without --binary). The underlying problem is inconsistent line endings in the stuff being patched, which is not your fault.

[Incantatar]

Wait why are you using 'cp' instead of 'mv'? I had initially thought there was a reason for it -- something to do with ciopfs -- but I don't think there is one. This works fine:

mv bgee bgee_tmp
mkdir -p .ciopfs/bgee bgee
ciopfs .ciopfs/bgee bgee
cd bgee_tmp && mv * .mojosetup ../bgee

Edit: Clean up warnings.

 

Edit: Well the warnings are still there, but they're superficial. 'mv' is telling us about discrepancies in symlinks, but that's only because 'mv' doesn't understand that e.g. libx11.so.6 and libX11.so.6 are the same.

 

Edit: Oh, 'cp -a' produces the same warnings; I thought it was a 'mv' issue.

 

 

A guy wrote on a German forum, that you absolutely should use cp and never mv (https://baldurs-gate.eu/showthread.php?t=44201). I don't know why but I would play it safe.

[vtazt]

Well you're doing two copies. The first one,

$ cp -a /home/username/games/BGEE/. /home/username/games/BGEE_copy
$ rm -r /home/username/games/BGEE/*

is completely unnecessary. There's just no reason not to use 'mv'.

 

Now the second copy is from one filesystem to another. The German guy may have been concerned about 'mv' across filesystems. In this case 'mv' is equivalent to copying then deleting the source. There shouldn't be any cause for concern, though, about 'mv' here.

 

So if you like, keep the second 'cp' because 'mv' is doing that anyway. But in any case the first 'cp' needs to be 'mv' instead, else you risk generating suspicion and prejudice in the minds of readers. (The same goes for the trailing '/.' which doesn't serve a purpose.)

[Incantatar]

Well you're doing two copies. The first one,

$ cp -a /home/username/games/BGEE/. /home/username/games/BGEE_copy
$ rm -r /home/username/games/BGEE/*

is completely unnecessary. There's just no reason not to use 'mv'.

 

Now the second copy is from one filesystem to another. The German guy may have been concerned about 'mv' across filesystems. In this case 'mv' is equivalent to copying then deleting the source. There shouldn't be any cause for concern, though, about 'mv' here.

 

So if you like, keep the second 'cp' because 'mv' is doing that anyway. But in any case the first 'cp' needs to be 'mv' instead, else you risk generating suspicion and prejudice in the minds of readers. (The same goes for the trailing '/.' which doesn't serve a purpose.)

 

 

Right on the first point. The second point, of course '/.' serves a purpose. It's a difference if you copy a folder or just the insides of a folder.

[vtazt]

I was referring to the code I quoted,

$ cp -a /home/username/games/BGEE/. /home/username/games/BGEE_copy

The '/.' doesn't serve a purpose there.

 

I think 'mv' should be used instead of 'cp' in the second case as well, because using 'cp' means that an additional delete step is needed. Like in the first case, people will wonder why you're not using 'mv'. I've tested the script I posted, and it works fine with 'mv'. If you don't believe that 'mv' accomplishes the same thing (but in one step instead of two) then google about it.

[khelban12]

I was referring to the code I quoted,

$ cp -a /home/username/games/BGEE/. /home/username/games/BGEE_copy

The '/.' doesn't serve a purpose there.

 

It is as Incantatar said about copying contents or not. Try the following:

 

% mkdir bgee_copy

% mkdir bgee1
% touch bgee1/{file1,file2} 
% ls bgee1 
file1  file2
% cp -dRp bgee1 bgee2

% cp -a bgee1 bgee_copy 
% cp -a bgee2/. bgee_copy 
% ls bgee_copy 
bgee1/  file1  file2

The /. will result in copying the contents of BGEE directory to BGEE_copy. Without it, you will have a bgee directory inside the bgee_copy one.

 

With regards to cp/mv, i am with vtazt. Since we are copying to a different mount point, mv will essentially behave as copy + remove so you don't lose anything. If we were copying to the same filesystem, then mv is essentially rename so it would be super fast and again no reason to use cp+rm. The only difference in behavior i can think of is that mv does not mess with permissions (again in favor of mv). Let's see the following stupid example:

 

 

 

% mkdir test
% cd test 
% ls -al
total 0
drwxr-xr-x  2 khelben users  40 Dec 19 15:44 ./
drwxrwxrwt 11 root    root  320 Dec 19 15:44 ../
% sudo touch rootfile
% ls -al
total 0
drwxr-xr-x  2 khelben users  60 Dec 19 15:44 ./
drwxrwxrwt 11 root    root  320 Dec 19 15:44 ../
-rw-r--r--  1 root    root    0 Dec 19 15:44 rootfile

% cp rootfile cpfile
% mv rootfile mvfile
% ls -al
total 0
drwxr-xr-x  2 khelben users  80 Dec 19 15:45 ./
drwxrwxrwt 11 root    root  320 Dec 19 15:44 ../
-rw-r--r--  1 khelben users   0 Dec 19 15:45 cpfile
-rw-r--r--  1 root    root    0 Dec 19 15:44 mvfile

I have a file that belongs to another user but the directory belongs to me so i can modify everything in it. cp + rm messes with the ownership because it can only create the new files as my own user while mv keeps the ownership intact.

 

In this case of course we won't benefit from this, i just mentioned as the only difference between them.

 

 

[vtazt]

Again, I was referring to the first copy. There is no 'mkdir bgee_copy'. Since bgee_copy doesn't exist, the '/.' doesn't serve a purpose.