Various ToB hacks

[Taimon]

Probably not, sorry.

To quote devSin: "It's been fun.", but I doubt I'll do much more IE related stuff.

Maybe if some research sparkles new interest in the IE for me, but at the moment I simply miss motivation to dive in again.

(That dispel bug and the way how "hide in shadows" works definitely kept me going, but right now I don't want to look at disassembly.)

[Jarno Mikkola]

Probably not, sorry.

To quote devSin: "It's been fun.", but I doubt I'll do much more IE related stuff.

Maybe if some research sparkles new interest in the IE for me, but at the moment I simply miss motivation to dive in again.

(That dispel bug and the way how "hide in shadows" works definitely kept me going, but right now I don't want to look at disassembly.)

Also known as, ask from Ascension64 .

...as the two mods do almost the same things, but with the TobEx, the user can disable the features he doesn't want without the need to reinstall anything.

[Galactygon]

There isn't any need for a HIDESPL.2da support for priest spells; I found out from Divine Remix that marking both Disable for Clerics/Druids flags does the trick.

 

-Galactygon

[Ascension64]

Some possible internal flag overlap between two hacks. Bit 24 in the item flags is being used for both hacks. Was this intended?

 

For example, if MyMagicalItem (with bit24 set) does damage, it will bypass the enemy's mirror images. Also, the magical item is not dispellable.

 

BEGIN ~Introduce AoE flag to bypass mirror images~

...

// This checks bit 24 of the parent resource flags in the damage effect.

// You can flag both items and spells. (item ability/spell flags)

 

BEGIN ~Introduce configurable item dispel behavior~

...

//

// It also introduces a special item flag (bit 24) that skips the dispel

// effect on that particular item, even if the effect itself is configured

// to dispel items.

[the bigg]

I think one is in the item header and the other in the ability header.

[Ascension64]

I think one is in the item header and the other in the ability header.

I checked and it does not appear to be the case.

Even if it was, the item ability bit 24 will be overriding the IWD2 keen bit.

 

I think the 'bypass mirror images' flag is best set within the Damage feature block, since it only applies to the saving throw function of the Damage opcode, perhaps in the saving throw type field. Also that field is a dword and only 5 bits are being used.

[Taimon]

I think one is in the item header and the other in the ability header.

I checked and it does not appear to be the case.

Well, it definitely should be - that's how it was intended. (Did nobody try it?)

 

/Edit: Come to think of it: My comment says I check parent resource flags (I hope I do ) and that's definitely the item ability flags. (If the effect came from an item.)

 

Even if it was, the item ability bit 24 will be overriding the IWD2 keen bit.

I think Avenger mentioned this somewhere, but somehow we decided it doesn't concern us here.

 

I think the 'bypass mirror images' flag is best set within the Damage feature block, since it only applies to the saving throw function of the Damage opcode, perhaps in the saving throw type field. Also that field is a dword and only 5 bits are being used.

Hm, I don't really like it (it's sort of hacky ), but you can just ignore me.

I'm only back to clean things up, i. e. fix that bug I promised to and maybe package a last version of ToB Hacks.

[Ascension64]

Well, it definitely should be - that's how it was intended. (Did nobody try it?)

SR uses it in a component, I think it works.

 

/Edit: Come to think of it: My comment says I check parent resource flags (I hope I do ) and that's definitely the item ability flags. (If the effect came from an item.)

That is probably what it was. It does load the parent extended header flags (the IESDP description can be misleading as well).

I think the keen and bypass armor bits sit at 16 and 17, so no problems there, my mistake.

 

I think the 'bypass mirror images' flag is best set within the Damage feature block, since it only applies to the saving throw function of the Damage opcode, perhaps in the saving throw type field. Also that field is a dword and only 5 bits are being used.

Hm, I don't really like it (it's sort of hacky ), but you can just ignore me.

Open to comment. SR already uses the hack, and its component would need changing if we do decide to change.

The only glitch is the check for SAVE_NONE, which expects that the entire DWORD == 0, but that is easily hacked to check for BYTE instead.

[Taimon]

The problem with (my) hacks is that they were mostly done to fix one specific issue. I was just happy to find any solution that I could fit in (remember the size restriction). No real design here.

So if you are going to reimplement things, don't feel obligued to follow my hacks.

[Ascension64]

The problem with (my) hacks is that they were mostly done to fix one specific issue. I was just happy to find any solution that I could fit in (remember the size restriction). No real design here.

So if you are going to reimplement things, don't feel obligued to follow my hacks.

Fair, enough. This is probably another 'design' thing:

 

BEGIN ~Introduce configurable item dispel behavior~

DESIGNATED 41

 

// This modifies the dispel effect to not automatically dispel items

// in the magical weapon slot. You still need to delete the "Remove Item"

// effects in the standard dispel spells.

// The behavior is configurable with the upper word of param2 (0x08):

// 0: Item is not dispelled.

// 1: Item is always dispelled.

// 2: Item is dispelled based on roughly the same probability that gets

// used for dispelling the effects.

// As there is no equivalent of a "caster level" for the item, the

// the highest magic class level of the character that wields the item

// is used.

//

// It also introduces a special item flag (bit 24) that skips the dispel

// effect on that particular item, even if the effect itself is configured

// to dispel items.

This hack currently overrides the vanilla behaviour of magical items always being dispelled, because the default 0 indicates the magical item should never be dispelled. I am thinking of switching 0 and 1 in TobEx. Comments?

[Taimon]

I remember asking about the default behaviour for the dispel effect and there wasn't much of a discussion.

[Ascension64]

I remember asking about the default behaviour for the dispel effect and there wasn't much of a discussion.

Yeah, OK. One vote.

[Wisp]

I think the bits should be switched. Items being dispelled is vanilla behaviour and what most people expect. I also think that's what the default behaviour should be. If you want a particular item to be undispellable you can set that on the item itself.

[Demivrgvs]

Introduce configurable item dispel behavior

This hack currently overrides the vanilla behaviour of magical items always being dispelled, because the default 0 indicates the magical item should never be dispelled. I am thinking of switching 0 and 1 in TobEx. Comments?

I remember asking about the default behaviour for the dispel effect and there wasn't much of a discussion.

Yeah, OK. One vote.

Mmm, I fear this may cause troubles if Spell Revisions is installed after Tobex instead of using SR's version of Taimon's patch. SR currently consider all "magically created items" undispellable, and specifically patch those few which should be disapellable (e.g. Polymorph Other's squirrel pawn).

 

I can't see many players complaining if you don't switch 0 and 1, actually I think they complained vanilla's behaviour in the first place (which is especially bad when you consider shapeshifting abilities). Am I wrong?

 

I'd vote for not changing it for now.

[Ascension64]

I'll keep it as is. I guess the Remove Item effects still take effect in vanilla, so the original behaviour is preserved.

 

Still awaiting comment on the placement of the 'AoE' flag.