141 replies to this topic

[the bigg]

An example of why blanket-removing uncompiled .bafs is a bad idea:

in older builds of Refinements, component 10 was creating from scratch a .baf file (that was written to the override for lack of better options), and later component 20 needed to compile that file. If you remove that file and then reinstall component 20 without reinstalling component 10, component 20 wouldn't find the BAF file it needed and thus install would fail. Now, I don't know if Refinements was the only mod to ever follow that coding pattern, but one mod is reason enough to assume that other mods are doing it, and thus making removing uncompiled .bafs a bad idea.

[Jarno Mikkola]

An example of why blanket-removing uncompiled .bafs is a bad idea:

in older builds of Refinements, component 10 was creating from scratch a .baf file (that was written to the override for lack of better options), and later component 20 needed to compile that file. If you remove that file and then reinstall component 20 without reinstalling component 10, component 20 wouldn't find the BAF file it needed and thus install would fail. Now, I don't know if Refinements was the only mod to ever follow that coding pattern, but one mod is reason enough to assume that other mods are doing it, and thus making removing uncompiled .bafs a bad idea.

In that case you could be a good little coder and not give others bad ideas... and print the 'to be compiled' scripts in a neutral ground(into the mods own folder)... not in the override -folder, as that one should be reserved to files that the game actually reads.

If it ain't broke...

Don't act stupid.

[Lollorian]

The problem with uncompiled .baf/d's in the override (as I remember it ) is indirectly caused by using the combination of the BWPTrimpack and the megamods

Before trimpack:
1) megamod puts all baf/d into some new folder called XXX-BCS or something
2) megamod runs a sweep COMPILE over the folder
3) megamod biffs that folder packing all the useful stuff inside XXX-BCS.bif and leaving the un-useful baf/d's in the folder itself
4) megamod nukes the folder

After trimpack:
1) trimpack applies patches lololol (including a baf/d/mp3/tiz/ogg deletion loop at the end of all the megamod .bat's)
2) megamod puts all baf/d into the OVERRIDE
3) megamod does a sweep compile of the OVERRIDE (oh noes )
4) megamod doesn't biff
5) megamod runs the deletion loop fubaring all the baf/d/etc (to prevent the next megamod from reCOMPILing all the baf/d's again )

Also, methinks there's been a problem with SCS(I/II) doing a COMPILE of the override (maybe fixed in the newer versions ) The only places where these baf/d get removed from the override is during megamod installation (via trimpack) and at the end.

My vote (if it counts ) goes to separating the cleanup process from the install process and making it optional - like it used to be in the form of the Cleanup.bat, don't run the cleanup loop by default

[Arkenor]

As I said in the thread where I opened this can of angry worms, I respectfully submit that a batch file that goes around deleting anything it does not understand is an incredibly bad idea.

I've removed the call for empty_override.bat from my BiG World Install.bat, and thus far it does not seem to have done me any harm.

Edited by Arkenor, 09 September 2010 - 10:52 PM.

[the bigg]

In that case you could be a good little coder and not give others bad ideas... and print the 'to be compiled' scripts in a neutral ground(into the mods own folder)... not in the override -folder, as that one should be reserved to files that the game actually reads.

Which it now does. Back when I used to do it, there was no way to APPEND to a file unless it's in the override. Point is, mods have always been putting marker files in the override, and removing them provides no benefit but is going to break something when you try to alter your install.

[Lollorian]

Imho, the BWP never favored altering installs, always thought of it like a fire-n-forget thing (dunno if it does now though )

[the bigg]

It never really supported that; however, it's pretty stupid to waste your effort on the trimpack and my effort on generalized_biffing to save maybe 20MB.

[Lollorian]

On the subject of the trimpack, I noticed some stuff

The beta v9.1.7 fixpack had folders called "_depends" that checked for the presence of the trimpack before applying the non-trimpack fixes to the megamods. These folders seem to be missing in the v9.3 fixpack cause HUNKs to fail in all the megamod .tp2's if the trimpack is applied before the fixpack

Also noticed that the fixes for SCS, SCSII and Item Upgrade are redundant now cause of nu verzionz!!!

And another also ... the creature offset checker seems to be borking again

All this is based on Arkenor's BiG World Debug.txt uploaded here

[DavidWallace]

Also, methinks there's been a problem with SCS(I/II) doing a COMPILE of the override (maybe fixed in the newer versions )

I'm pretty sure I never compiled the Override.

In fact, I can't imagine why anyone would want to compile the override. The situations where I've seen it happen are when someone types something like

COMPILE ~my_badly_coded_mod/dialog.d~ ~override~


I continue to be really confused why this issue of non-functional files in the override is an issue for people. Functional ones, yes, since theoretically they slow the game down (though testing of IWD-in-BG2 suggests to me this isn't an issue with BCS or DLG files, only things like BAMs and WAVs). But as far as I know the engine just ignores random cruft in the directory.

As for why I do put markers and things in the override: largely it's the same reason as TheBigg gives, i.e. it's a legacy of earlier versions of WEIDU. But there is also an argument for minimizing the extent to which a mod modifies itself: that can lead to accidentally distributing a tangled-up version. (I have this enough as it is with SSL files; in hindsight I should have compiled them somewhere other than inside scs itself.)

Edited by DavidWallace, 10 September 2010 - 03:13 AM.

[Lollorian]

I'm pretty sure I never compiled the Override.

My mistake SCS used to put uncompiled files into the override so mashed up

I continue to be really confused why this issue of non-functional files in the override is an issue for people.

Spring cleaning I guess

I should prolly make some changes to the trimpack so that the megamods don't compile the override ... tonight ... most prolly

[Jarno Mikkola]

Back when I used to do it, there was no way to APPEND to a file unless it's in the override. Point is, mods have always been putting marker files in the override, and removing them provides no benefit but is going to break something when you try to alter your install.

Erhm, those two sentences are two different things; The marker file can be anything anywhere, or a stain on the carper... were you a dog, you aren't. While the compilable file is the (original file + the appended file) or the overwrite -file. The former can be done even in WeiDU.exe v185 with this:

BACKUP ~Test/backup~
AUTHOR ~Jarno Mikkola & copied code snips provided by http://weidu.org/WeiDU/README-WeiDU.html ~

BEGIN ~Testing the WeiDU.exe v185~
COPY_EXISTING ~sw1h01.itm~ ~Test/testmark.itm~

And then we just have to use the file alike ...

...
ACTION_IF FILE_EXISTS ~Test/testmark.itm~ THEN BEGIN
COPY ~Test/testmark.itm~ ~IJ#item2.itm~
END

->

Spoiler

WeiDU v 185 Log

C:\185test\BGII - SoA\setup-Test.exe
[./CHITIN.KEY] loaded, 590551 bytes
[./CHITIN.KEY] 182 BIFFs, 41793 resources
[dialog.tlk] loaded, 8692747 bytes
[dialog.tlk] 74107 string entries
[./Autorun.ini] loaded, 1452 bytes
[./baldur.ini] loaded, 3539 bytes
Possible HD/CD Path: [C:\185test\BGII - SoA\]
Possible HD/CD Path: [C:\185test\BGII - SoA\CD1\]
Possible HD/CD Path: [C:\185test\BGII - SoA\CD2\]
Possible HD/CD Path: [C:\185test\BGII - SoA\CD2\]
Possible HD/CD Path: [C:\185test\BGII - SoA\CD3\]
Possible HD/CD Path: [C:\185test\BGII - SoA\CD4\]
Possible HD/CD Path: [C:\185test\BGII - SoA\CD5\]
[./Keymap.ini] loaded, 5615 bytes
[./Mplaynow.ini] loaded, 230 bytes
[dialog.tlk] claims to be writeable.
[dialog.tlk] claims to be a regular file.
[WeiDU.log] parsed
[SETUP-TEST.TP2] parsed

Install Component [Testing the WeiDU.exe v185]
[Y]es or [N]o or [Q]uit?
Installing [Testing the WeiDU.exe v185]
Copying 1 file ...
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\CD5\/data/Items.bif]
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\CD4\/data/Items.bif]
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\CD3\/data/Items.bif]
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\CD2\/data/Items.bif]
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\CD2\/data/Items.bif]
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\CD1\/data/Items.bif]
BIFF may be in hard-drive CD-path [C:\185test\BGII - SoA\/data/Items.bif]
[C:\185test\BGII - SoA\/data/Items.bif] 659688 bytes, 1990 files, 0 tilesets
Copied [sw1h01.itm] to [Test/testmark.itm]
Copying 1 file ...
[Test/testmark.itm] loaded, 314 bytes
Copied [Test/testmark.itm] to [IJ#item2.itm]


Saving This Log:
SETUP-TEST.TP2 0 0 Installed ~Testing the WeiDU.exe v185~
[SETUP-TEST.TP2] parsed

SUCCESSFULLY INSTALLED [Testing the WeiDU.exe v185]

WeiDU Timings
unmarshal BIFF 0.000
parsing .tp2 files 0.000
load TLK 0.000
parsing .log files 0.000
PATCH_IF 0.000
BUT_ONLY 0.000
eval_pe 0.000
saving files 0.003
COPY 0.006
loading files 0.021
unmarshal KEY 0.034
unmarshal TLK 0.090
TOTAL 0.154

Edited by Jarno Mikkola, 10 September 2010 - 04:28 AM.

[DavidWallace]

@Jarno: I'm still waiting to hear why it actually matters.

[Jarno Mikkola]

@Jarno: I'm still waiting to hear why it actually matters.

So "we" don't have to take extra efforts to accommodate your... laziness... or anyone else's, just like you seem to do, with the BG2 Fixpack needing to be installed for your mod. And I am not talking about myself in this case... or would it be better to say that it's a good policy not to brake down things that aren't broken, as the override folder is not in it's original content.

Edited by Jarno Mikkola, 10 September 2010 - 05:19 AM.

[the bigg]

@Jarno: I'm still waiting to hear why it actually matters.

I was going to flame BiG Modders (and specifically Jarno) for a page or two, but decided that it isn't the best idea. Good luck dealing with bug reports you aren't responsible for.

Edited by the bigg, 10 September 2010 - 05:24 AM.

[Anduin Shadow Mantle]

A short and sweet suggestion, going back to Dabus's ideas for Leomar.

Can Dark Horizons be downgraded from expert to tactic? Yes the assasins do carry nice, lets be honest, very nice equipment... but you do have to kill them first to get it. I usually use a thief for the first couple of assassins I meet and backstabbing and if that fails, running away to try again! I love meeting the occasional enemy where you have to run away or just simply die. Perhaps BP-Balancer could remove some of the overly powered stuff they carry? Can't be as bad as that house in Beregost where you meet "Daddy" and "Mommy" and they drop over the top swords, staff and shoes (and they are easy to defeat!).

Sorry I am not a modder just a simple enjoyer of mods (some people say very simple). When people talk about biffing and overides my brain starts to hurt, but I will try and keep up!

[DavidWallace]

@Jarno:

I don't entirely understand that, but I'll have a go:

@Jarno: I'm still waiting to hear why it actually matters.

So "we" don't have to take extra efforts to accommodate your... laziness...

I haven't yet had an explanation of what those "extra efforts" are.

Unless you mean that you have to make the effort to not compile the override directory. In that case: sure, I don't accommodate that, but I don't accommodate other ways in which people might make elementary mistakes in WEIDU.

or anyone else's, just like you seem to do, with the BG2 Fixpack needing to be installed for your mod.

I think that means that you're objecting to my requiring the Fixpack. I'm not sure on what grounds, though. (Unless it's some general principle that mods shouldn't require other mods, in which case I'd need to hear a theory as to why. Plenty of mods require Ascension, after all.)

It might also be worth noting that I don't explicitly require the Fixpack; I just use it as a coding base. If not having the Fixpack breaks something, I imagine it's because I assume something's fixed and it isn't (e.g. the corrupt IPLOTxyz objects). If there's a different reason, I'd be moderately interested to know what it is.

And I am not talking about myself in this case... or would it be better to say that it's a good policy not to brake down things that aren't broken, as the override folder is not in it's original content.

I don't understand that at all (and I mean: I almost literally can't understand what you are saying here).

But: obviously any mod leaves some part of the game not in its original content. What's sacred about the override directory?

Edited by DavidWallace, 10 September 2010 - 06:59 AM.

[the bigg]

I haven't yet had an explanation of what those "extra efforts" are.

The effort of removing uncompiled BAF files and marker files from the override. Remember, in BiG World, the override must be cleaned because the override must be cleaned!

It might also be worth noting that I don't explicitly require the Fixpack; I just use it as a coding base. If not having the Fixpack breaks something, I imagine it's because I assume something's fixed and it isn't (e.g. the corrupt IPLOTxyz objects). If there's a different reason, I'd be moderately interested to know what it is.

Knowing Jarno, it's safe to assume that he's pulling stuff out of his ass (or, at best, five years old threads where people were having IPLOT-related problems).

I don't understand that at all (and I mean: I almost literally can't understand what you are saying here).

But: obviously any mod leaves some part of the game not in its original content. What's sacred about the override directory?

Remember, in BiG World, the override must be cleaned because the override must be cleaned!

[Lollorian]

Omg! The kungfu in this thread is strong

Let's all just ask the good people at the BWP to just separate the cleanup procedure from the default installer

That way, the people who need their spring cleaning can have their fun (with a warning that their install automatically becomes uncustomizable after running that ) while the markers and stuff get saved for the peeps that don't run the cleanup.bat ... simple?? I hope

[the bigg]

Omg! The kungfu in this thread is strong

Let's all just ask the good people at the BWP to just separate the cleanup procedure from the default installer

This is a good idea; however, I have 5$ that say that the choice will never be offered (I mean, in this very thread dabus has declared that 'Further Customization of mod-Setting' shouldn't be checked by default because it offers players too many choices).


Late reply to Miloch:

Someone should really rewrite those tp2s so they use stuff like ACTION_IF NOT MOD_IS_INSTALLED ~setup-mod.tp2~ 666 instead of ACTION_IF NOT FILE_EXISTS ~override\marker.txt~. I suppose the BWFixpack could do that.

Some TP2s use file markers to keep track of version number or something like that (that's what AoE uses that file marker for, by instance). Also, some pieces of code are installed by about 748930215671203497 different mods, and it's beneficial to have them use file markers so you can FILE_EXISTS ~banter_accelerator~ rather than writing dozens of (MOD_IS_INSTALLED a.tp2 0) OR (MOD_IS_INSTALLED b.tp2 1) OR ...

[DavidWallace]

Late reply to Miloch:

Someone should really rewrite those tp2s so they use stuff like ACTION_IF NOT MOD_IS_INSTALLED ~setup-mod.tp2~ 666 instead of ACTION_IF NOT FILE_EXISTS ~override\marker.txt~. I suppose the BWFixpack could do that.

Some TP2s use file markers to keep track of version number or something like that (that's what AoE uses that file marker for, by instance). Also, some pieces of code are installed by about 748930215671203497 different mods, and it's beneficial to have them use file markers so you can FILE_EXISTS ~banter_accelerator~ rather than writing dozens of (MOD_IS_INSTALLED a.tp2 0) OR (MOD_IS_INSTALLED b.tp2 1) OR ...

I use them so that I can reorder or renumber the components in my mods without having to manually rewrite the dependencies, and so I've got something a little more human-readable.