ToBEx

[Salk]

Demi,

 

I was wondering if the time for the .exe hacks is now finished.

 

I was taking a look at the latest Beta (0014) of Ascension64's ToBEx modification and I was really impressed. All those .exe hacks that SR (but also SCS) uses seem to me obsolete when ToBEx can accomplish the same and more in a more elegant manner. Even though its still technically a Beta (but only because few of its components are, I would say...) it has been widely tested and confirmed working.

 

I am hoping that ToBEx becomes a standard install and a modders' base to work from in the future and I think it's worth taking a close look at it now.

[yarpen]

Well, maybe it's not very rational but I still prefer to use Taimon's hacks. SR is fine as it is - one solid package with .exe patches included. And IMHO it should stay as it is - it's better than "TobEx Required".

[Salk]

Well, maybe it's not very rational but I still prefer to use Taimon's hacks. SR is fine as it is - one solid package with .exe patches included. And IMHO it should stay as it is - it's better than "TobEx Required".

 

The point is that TobEX is still being worked on actively by its creator, who has also kindly opened a Wish list topic at SHS.

 

I am probably Taimon's number one fan (and I am honoured to count him as friend) but I think he can hardly find the time to expand on his original project. Already now ToBEx includes Taimon's .exe modifications and counts numerous fixes/tweaks more that are nowhere else available.

 

It's not just a solution to SR but also to all other .exe patching mods out there.

 

About being a requirement, I don't find it strange or disturbing as it is supposed to be installed just after the official ToB patch and is going to great lengths to keep compatibility as high as possible. I'd go as far as to wish to see ToBEx become (in a near future) part of the Fixpack as it does corrects many engine bugs which affect any BG2 player (vanilla or not).

[Ardanis]

New users probably will find it alot easier if everything is located within one package. I'd keep Taimon's code just in case twenty years later somebody will discover a dead forum with IE mods and nobody to guide among them.

 

That said, why not just split hack component into actual EXE patch, skipped if ToBEx is installed, and the resource patching?

[DavidW]

Salk: can you say what the actual advantage is of using ToBEx rather than the existing SCS/SR code?

[Salk]

Salk: can you say what the actual advantage is of using ToBEx rather than the existing SCS/SR code?

 

Standardization and streamlining, I would think.

[Mike1072]

Considering we do more than just apply .exe patches, the components will need to stay regardless. We discussed adding a check to skip the .exe patches in case ToBEx was installed, but we needed a little more assurance that someone who had ToBEx installed was actually going to be using the relevant modifications. Ascension64 has been updating his mod recently so that we can do something like this.

[DavidW]

Salk: can you say what the actual advantage is of using ToBEx rather than the existing SCS/SR code?

 

Standardization and streamlining, I would think.

 

Those don't seem very concrete advantages. What are the actual ways in which this would make the mods better? i.e. what actual part of a player's experience would be improved?

[Ardanis]

I've checked on ToBEx file. If I understand it correctly, both SR and SCS can keep their own EXE patches safely.

-----Configurable Damage Effect Bypasses Mirror Images [C, M]

(Identical to tob_hacks, SCS, SCSII, Spell Revisions)

Adds new bit 24 to effect feature block save type 'Bypass Mirror Images'

Only for the damage effect opcode, if this bit is set, the mirror image check is skipped when checking saving throw

 

Options:

-0: disabled

-1: enabled

 

-----Configurable Magical Item Dispel Behaviour [C, M]

(Different implementation to, and overrides tob_hacks, Spell Revisions)

 

This hack perform two functions:

1. Modification to dispel effect opcode

Alows configuration of the dispelling of items in the magical weapon slot (SLOT_MISC19) by adding a high WORD (0xA)

 

Description

#58 (0x03A) Cure: Dispellable Effects (Dispel Magic) [58]

Parameter #1: Level

Parameter #2 (low WORD): Type

Parameter #2 (high WORD): Magical weapon dispel behaviour

Description:

Dispels magic from the targeted creature(s). Depending on the value of the 'Type' field, the 'Level' field can be used to set the level of the effect.

 

Known values for 'Type' are:

0 Always dispel

1 Use Caster Level

2 Use 'Level' field

 

Known values for 'Magical weapon dispel behaviour' are:

0 Always dispel

1 Do not dispel

2 Chance of dispel (target level is the higher of the effective mage or cleric level, whichever is higher)

 

With 'Type' of 1 or 2, the base chance of successfully dispelling is 50%. This chance is modified by the relative levels of the dispeller to the target.

Each level below target gives a -10% chance, each level above target gives a +5% chance. There is always a 1% chance of success or failure.

 

2. Adds new bit 24 to the item flags 'Not dispellable in magical weapon slot'

 

Options:

-0: disabled

-1: enabled

 

...

 

-----Disable Stoneskin Grey Colour [C, T]

(Identical to tob_hacks, SCS, SCSII)

Removes grey colour change of character applied the stoneskin opcode

 

Options:

-0: disabled

-1: enabled

 

...

 

-----Dispel Formula Fix [C, F]

(Different implementation to, and overrides tob_hacks, SCS, SCSII, Spell Revisions)

Corrects the formula used for the dispel opcode

 

Options:

-0: disabled

-1: enabled

[the bigg]

Ascension64 said that TobEx might misbehave if one of its tweaks is altering the same code region as an exe patch. As such, leaving the exe patch it and not running it if TobEx is installed (as suggested by Mike) is the best solution.

[Salk]

Salk: can you say what the actual advantage is of using ToBEx rather than the existing SCS/SR code?

 

Standardization and streamlining, I would think.

 

Those don't seem very concrete advantages. What are the actual ways in which this would make the mods better? i.e. what actual part of a player's experience would be improved?

 

Since ToBEx produces the same results that you, Demi and others obtain by applying instead an .exe hack there are no concrete advantages at the moment over your implemented solution.

 

The difference is that ToBEx is actively mantained by its creator and does already everything that those hacks do plus much more (it fixes many things that Demi has been dreaming of, example the ApR broken opcode). And it does it by modifying the virtual image of the game's executable on the fly.

 

Considering that Taimon can hardly be considered active on the modding scene, that you are already using a third party solution for your own modifications, that SCS and SR have duplicated components that do the same thing, that ToBEx replicates and expands over Taimon's ToB hacks, and that there are no real drawbacks in supporting ToBEx then I am just wondering what the reason to hold it back is.

[Igneous]

The most concrete advantage to using TobEx as a base, I would think, would be the benefit of Ascension64's various engine and opcode fixes (e.g., the fixes to regeneration, repeating effects, and others). In the case of SR/IR, this brings a lot to the table in terms of functionality.

 

That said, TobEx is still pretty rough around the edges—it's still labelled as a beta, after all. At this point, it might be better to include TobEx-facilitated content as an optional component, as opposed to committing to a hard-set requirement.

 

I don't see why Taimon's EXE patches need to go, though. Self-sufficiency is good, and it's simple enough to skip them at install if the relevant TobEx counterparts are detected.

[DavidW]

Considering that Taimon can hardly be considered active on the modding scene, that you are already using a third party solution for your own modifications, that SCS and SR have duplicated components that do the same thing, that ToBEx replicates and expands over Taimon's ToB hacks, and that there are no real drawbacks in supporting ToBEx then I am just wondering what the reason to hold it back is.

 

That's easy: it violates the principle that if it ain't broke, don't fix it.

 

(Edit: I also agree with Igneous's comment about self-sufficiency.)

[Salk]

Considering that Taimon can hardly be considered active on the modding scene, that you are already using a third party solution for your own modifications, that SCS and SR have duplicated components that do the same thing, that ToBEx replicates and expands over Taimon's ToB hacks, and that there are no real drawbacks in supporting ToBEx then I am just wondering what the reason to hold it back is.

 

That's easy: it violates the principle that if it ain't broke, don't fix it.

 

(Edit: I also agree with Igneous's comment about self-sufficiency.)

 

I am not sure I have such great respect for that principle above. There are many things that are not broken, but people wish to change them anyway because they believe the change brings an overall improvement. The first practical example (albeit futile) that comes to mind is TVs: most people buying LCD/Plasma TVs had a perfectly working CRT TV at home.

 

What Igneous said makes sense to me as well. Even because he begins saying:

 

The most concrete advantage to using TobEx as a base, I would think, would be the benefit of Ascension64's various engine and opcode fixes (e.g., the fixes to regeneration, repeating effects, and others). In the case of SR/IR, this brings a lot to the table in terms of functionality.

 

and I wouldn't even limit it to just SR/IR but to rather every .exe hacking mod out there.

 

It's true that ToBEx is still at a Beta stage and I was not advocating an immediate action. I was just trying to give notice to what I believe is a breakthrough moment for the IE modding community. Something that should be acknowledged, rather than ignored.

 

ToBEx, just as some .exe hacks, fixes engine bugs that affect both vanilla and modded game. Why shouldn't it be part of the Fixpack in the future? I can't see a single reason to leave it out.

[DavidW]

Considering that Taimon can hardly be considered active on the modding scene, that you are already using a third party solution for your own modifications, that SCS and SR have duplicated components that do the same thing, that ToBEx replicates and expands over Taimon's ToB hacks, and that there are no real drawbacks in supporting ToBEx then I am just wondering what the reason to hold it back is.

 

That's easy: it violates the principle that if it ain't broke, don't fix it.

 

(Edit: I also agree with Igneous's comment about self-sufficiency.)

 

I am not sure I have such great respect for that principle above. There are many things that are not broken, but people wish to change them anyway because they believe the change brings an overall improvement. The first practical example (albeit futile) that comes to mind is TVs: most people buying LCD/Plasma TVs had a perfectly working CRT TV at home.

 

What I mean by "if it ain't broke, don't fix it", is that if your code is already doing exactly what you want it to do, don't bother rewriting it to work in a different way. Now if (for instance) the existing SR/SCS dispel magic patch didn't fix Dispel Magic 100%, and it could be fixed more accurately by ToBEx, that would be a reason to change it. But as far as I can tell, that's not the case. To modify your analogy to fit better: if you've spent all afternoon wiring up your plasma TV and it now works perfectly, you'd be a fool to rewire it just because someone comes up with a way to wire it that they think is more streamlined and standardised, unless that rewiring actually affects your viewing experience.

 

Let me put it another way. You are suggesting that I use some of my finite time to rework a section of SCS which, as far as I know, already works fine, in a way which will not improve user experience at all. Why would I want to use my time that way, rather than to code something else, or read a novel, or (shock) do some academic research?