Enough material for new version?

[Salk]

Hello!

 

Considering the vast work done on the GTU Light and possibly some recently fixed bugs since the latest release I was wondering if we could hope for a new version of the Fixpack soon?

 

Speaking of the Fixpack, I wonder also if one day in the future we might see the Fixpack include those engine fixes (former hardcoded bugs) that ToBEx is addressing with success at SHS?

 

Thanks!

[devSin]

Maybe not. I'm not sure if Cam is up to jumping back in, and I don't know if there's anybody else around to do it.

 

As to the second question, no, there will never be executable patching in Fixpack. You're free to use ToBEx or Taimon's patches if you so choose.

[CamDawg]

As to the second question, no, there will never be executable patching in Fixpack. You're free to use ToBEx or Taimon's patches if you so choose.

I understand the reluctance but I think, at the least, it's worth discussing. I wouldn't mind taking the patches under the condition that they're 1) strictly legitimate bug fixes, 2) have been in the wild and tested extensively, and 3) are a separate component with the requisite warnings in flashing red text.

 

prowler sent me an updated Russian translation, so it's as good a time as any to put together FP X (Banana Slug).

[the bigg]

Including exe-hacking fixes a la ToB_Hacks risks compatibility with ToBEx (ToBEx's readme contains detailed description of which bits are duplicated and how the duplication affects compatibility), and I doubt that it'd be possible to include portions of ToBEx without making updates to ToBEx harder than it should be.

 

By the way, TB#Tweaks contains a fix for 'Weapon Specialization Does Not Provide Extra Attacks for Non-Fighters ' (the version that just fixes the bug is in git), but it must patch all CLAB*.2da files to work properly (hence must go AFTER kit-adding mods).

[devSin]

I'm completely against it. Our goal was to fix the game that BioWare released (wasn't it?), not change the engine to behave closer to what we consider to be correct. Not to mention that these hacks are for Windows ToB 26498 only, so now we'll have users with possibly different engine behaviors depending on what version, with or without the expansion, and what platform on which they install their chosen combination of mod components.

 

The GTU light updates seem good, so hopefully Wisp can pop in to bless it. I want to get the druid grove and black dragon night lums in, although the druid grove at least needs to be tested just to make sure it works everywhere, and there are a few bug reports and compatibility issues in the forums that would be good to fix up.

 

I also want to switch over the Mac release to a plain zip (I'll volunteer to package it). The way it's built now, it rarely works for anyone, it seems, and even release v9 has ranged the gamut from having incorrect permissions to not even having the WeiDU executable included.

[the bigg]

The Fixpack contains one Mac-specific fix, so it can contain Windows-specific fixes (as long as you correctly predicate against installing them on incompatible systems). That said, possible incompatibilities with ToBEx should be reason enough to avoid adding EXE fixes to the Fixpack.

[Wisp]

You aren't scheduling Fixpack 10 for like, next week or anything, are you?

I need time to mobilise my lobbying campaign (there still are a few fixes of worth that haven't been included), plus I'd like to have another whack at the GTUL before the latest version goes live. And there's some of Nythrun's stuff that should be incorporated, etc.

[CamDawg]

Nah, just given the scope of the documentation there has never been, nor will there ever be, a quick Fixpack release. I think a reasonable, achievable time frame would be something approaching the end of February, though I reserve the right to ignore that deadline indefinitely for no reason.

 

There's probably quite a bit of new stuff to be incorporated, and some beta fixes need to be moved in to the core component as they've been 'beta' for a couple of years now.

[Salk]

Well, thanks for the discussion.

 

I can see the reasons behind devsin's refusal to even think of having the Fixpack join efforts with ToBEx. On the other hand, I do agree with CamDawg when he says that a safe-for-player approach (extensive testing, warnings and import of bug fixes only) would be desirable. There would be nothing wrong to have the Fixpack check if the game's .exe is the required one and just skip everything in case it is not.

[DavidW]

I'm completely against it. Our goal was to fix the game that BioWare released (wasn't it?), not change the engine to behave closer to what we consider to be correct.

 

As I've understood the Fixpack rationale, "developer intent" doesn't obviously preclude fixing bugs in the engine as well as in the files. Something like the Dispel Magic fix seems a relatively straightforward case where the game isn't working the way the developers intended it to work.

[the bigg]

Let me re-state that including ToBEx fixes is impossible, while including ToB_Hacks fixes introduces compatibility problems with ToBEx.

[cmorgan]

I think the bigg has just summed up why there are almost always two very different sets of "fixes" for games - ones that deal with game resources, and ones that deal with the game engine itself.

 

 

In other words, I agree with the bigg.

 

Plus, it would be more efficient in terms of testing and release if Ascension64 didn't have to keep rechecking to see what got messed with where; there are mods out now that specifically look at .exe to determine code changes/install/etc.; taking on .exe changes seems way outside of the mission, which sees always to have been some version of "make it easier for players and modders to have a clean, fixed, easy to add mods to game".

[DavidW]

Let me re-state that including ToBEx fixes is impossible, while including ToB_Hacks fixes introduces compatibility problems with ToBEx.

 

That sounds pretty persuasive to me. (Philosopher's bad habit of commenting on particular points in the argument for X, never mind whether X is an overall good idea, sorry.)

[devSin]

As I've understood the Fixpack rationale, "developer intent" doesn't obviously preclude fixing bugs in the engine as well as in the files. Something like the Dispel Magic fix seems a relatively straightforward case where the game isn't working the way the developers intended it to work.

I agree that it's quite possibly arbitrary, but I firmly believe there has to be some limit to how far we'll go in pursuit of smoothing out the game's bugs, and executable and keyfile modification seems to me as good a limit as any. There have been enough errant issues caused by resource modification to have us start taking on support for ever more drastic changes (I also ascribe much higher value to the fundamental operation of the dispel magic effect than I do to it being called in a spell with the proper target and power; it's above a level I'd want to be responsible for changing).

[Ascension64]

I'll chip in by mentioning that TobEx is not TobFixer. The program is explicitly called ToB Extender for one reason, to extend the functionality of the engine. This is very much TobEx as to OBSE as BG2 Fixpack as to Unofficial Oblivion Patch, they are two completely separate things.

 

While TobEx does include bugfixes to the engine where typos have obviously been made, it will obviously include other changes that will extend the functionality of the engine. Currently (in a model that I do not like), it also includes tweaks to game behaviour, which if we decide for a 'standard', will no longer feature in TobEx.

 

I support BG2Fixpack in continuing to make changes to game resources without touching the engine for a reason similarly to the bigg's explanation - it makes my life hell to account for compatibility issues. I have enough trouble thinking about how TobEx may clash with Infinity Animations and Widescreen Mod, for example, let alone SCS and SR and whatnot.