Concordance of new features

[Galactygon]

Therefore, anything equipped in SLOT_HELMET would have a flag to turn off aversion of critical hits. All other items would have a flag to turn on aversion of critical hits. The question is: should they use the same bit because they are mutually exclusive (saves bits if we want to use them later), or separate them to prevent modder confusion?

 

I'd go for using the same bit and calling it "switch critical hit aversion" - this way we would not be wasting bits. Who knows how many of them we might need in the future.

 

-Galactygon

[Mike1072]

The item field is a DWORD, and based on what we know, the high WORD isn't used at all.

Taimon's Dispel Magic fix introduces a flag that prevents an item from being dispelled.

 

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.

[Ascension64]

The item field is a DWORD, and based on what we know, the high WORD isn't used at all.

Taimon's Dispel Magic fix introduces a flag that prevents an item from being dispelled.

 

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.

I am aware of it. Has that flag come into use at this point in time?

I am still working towards factoring in his remaining hacks into TobEx.

[Mike1072]

I am aware of it. Has that flag come into use at this point in time?

SR uses it.

[Ascension64]

Description for TobEx. Placed it at bit 25 next to Taimon's bit 24 for configurable dispel.

 

-----Customisable Critial Hit Aversion

REQUIRES: Component 'Required component for Customisable Critical Hit Aversion'

Adds new item flag bit 25 'Toggle critical hit aversion'

If an item with bit 25 set is equipped, critical hit aversion is enabled if the item is equipped in a non-helmet slot

If an item with bit 25 set is equipped, critical hit aversion is disabled if the item is equipped in a helmet slot

 

Options:

-0: disabled

-1: enabled

[Avenger]

The pulsating bit is used in pst (but that's irrelevant as gemrb has to implement both iwd2 and pst as well).

I guess, i will have to implement Taimon's flag as well, sounds useful.

[Avenger]

Since we cannot have any hardcoded effects (or rather, we try to keep them low), i have added a new feature, which may have other uses.

In effects, the probability fields can be set to:

low prob = 100

high prob = caster's stat number

 

This setting will set the probabilities to 0/stat value on first cast.

 

I needed this feature to de-hardcode the detect illusion effects applied when the thief does 'find traps'.

(the original engine dispelled illusionary creatures/removed illusion school effects based on the detect illusions skill).

 

This feature will probably enable the implementation of spells/abilities where the chance is based on a skill (or other stat).

[Ascension64]

Perhaps something useful to combat stacking issues.

 

I have been able to add configurable flags in feature blocks to control stacking behaviour.

1. One of the bits can turn on behaviour that will skip the effect application if a similar effect is already found. However the timing will still be updated, meaning that it will still expire when expected.

2. The other bits can turn on behaviour that will suspend the effect from being applied until similar effects have expired. This effectively extends the duration of an effect.

 

As examples, if I cast a 30-sec Blindness spell, and then I cast it again 5-sec later...

1. Blindness1 lasts from 0-30 sec, Blindness2 will only start applying from 31 sec and ends at 35 sec.

2. Blindness1 lasts from 0-30 sec, Blindness2 is suspended and applies from 31-60 sec.

 

The question that I have is - what criteria should be used to determine that a previous effect is similar to the new effect?

My current code is

bool CEffect_IsSimilar(CEffect& eff1, CEffect& eff2) {
if (eff1.effect.nOpcode == eff2.effect.nOpcode &&
	eff1.effect.nTarget == eff2.effect.nTarget &&
	eff1.effect.nSplLvl == eff2.effect.nSplLvl &&
	eff1.effect.nParam1 == eff2.effect.nParam1 &&
	eff1.effect.nParam2 == eff2.effect.nParam2 &&
	eff1.effect.wProbHigh == eff2.effect.wProbHigh &&
	eff1.effect.wProbLow == eff2.effect.wProbLow &&
	!(eff1.effect.rResource != eff2.effect.rResource) &&
	eff1.effect.nDice == eff2.effect.nDice &&
	eff1.effect.nDieSides == eff2.effect.nDieSides &&
	eff1.effect.bStoreLocalVariableParam == eff2.effect.bStoreLocalVariableParam &&
	eff1.effect.nType1 == eff2.effect.nType1 &&
	eff1.effect.dwFlags == eff2.effect.dwFlags &&
	eff1.effect.nParam3 == eff2.effect.nParam3 &&
	!(eff1.effect.rResource2 != eff2.effect.rResource2) &&
	!(eff1.effect.rResource3 != eff2.effect.rResource3) &&
	eff1.effect.nType2 == eff2.effect.nType2) {
	return true;
} else {
	return false;
}
}

[Galactygon]

I have been able to add configurable flags in feature blocks to control stacking behaviour.

1. One of the bits can turn on behaviour that will skip the effect application if a similar effect is already found. However the timing will still be updated, meaning that it will still expire when expected.

2. The other bits can turn on behaviour that will suspend the effect from being applied until similar effects have expired. This effectively extends the duration of an effect.

 

I will have to disagree with this for the following reasons:

1.) I doubt any modder would want to have opcodes such as blindness or invisibility to be cumulative with itself - so having some sort of non-cumulative default behavior is fine.

2.) It's not possible to fine tune stat changing (STR, DEX, fire resistance, spell failure, etc) opcodes with two bits which is what we really need. I'll explain this through an example: character A who is affected by Righteous Magic and Holy Power is hit by a Ray of Enfeeblement and a (mod-added) Ray of Fatigue that imposes a STR penalty. Ideally, Righteous Magic and Holy Power would be in one non-cumulative group while Ray of Enfeeblement would override the previous two effects, but would not be cumulative with itself or Ray of Fatigue.

 

These two bits would be unable to tell the engine - which is where I think giving overlapping feature blocks an "ID" would work best. Depending on whether we are increasing or decreasing some stat, of all the feature blocks with the same "ID" only the highest or lowest stat change would be evaluated.

 

This is where your recent finding of dword at 0x2c would prove useful.

 

-Galactygon

[Ascension64]

I have been able to add configurable flags in feature blocks to control stacking behaviour.

1. One of the bits can turn on behaviour that will skip the effect application if a similar effect is already found. However the timing will still be updated, meaning that it will still expire when expected.

2. The other bits can turn on behaviour that will suspend the effect from being applied until similar effects have expired. This effectively extends the duration of an effect.

 

I will have to disagree with this for the following reasons:

1.) I doubt any modder would want to have opcodes such as blindness or invisibility to be cumulative with itself - so having some sort of non-cumulative default behavior is fine.

2.) It's not possible to fine tune stat changing (STR, DEX, fire resistance, spell failure, etc) opcodes with two bits which is what we really need. I'll explain this through an example: character A who is affected by Righteous Magic and Holy Power is hit by a Ray of Enfeeblement and a (mod-added) Ray of Fatigue that imposes a STR penalty. Ideally, Righteous Magic and Holy Power would be in one non-cumulative group while Ray of Enfeeblement would override the previous two effects, but would not be cumulative with itself or Ray of Fatigue.

 

These two bits would be unable to tell the engine - which is where I think giving overlapping feature blocks an "ID" would work best. Depending on whether we are increasing or decreasing some stat, of all the feature blocks with the same "ID" only the highest or lowest stat change would be evaluated.

 

This is where your recent finding of dword at 0x2c would prove useful.

 

-Galactygon

 

I was hoping to introduce disabling stacking as a 'bug-fix' more than anything (because, for example, unfixed Blindness THAC0 penalties stack in vanilla). The advantage of the effect comparison is that Righteous Magic and Holy Power can still stack. But if you applied two Righteous Magic on yourself, then the strength bonus will stack. I am unsure as to whether it should be applied across the board, because the behaviour you want is opcode-specific. For example, you might not want the THAC0 penalty of blindness to stack, but you do want two incremental strength bonuses from different effects to stack.

 

As for unique ID, this is tricky for a number of reasons.

1. The IDs become universal, so there is high potential for mod conflict.

2. The evaluation becomes highly opcode-specific. Each opcode would need some way of comparing who is greater/lesser than the other.

3. Effects are applied sequentially. This makes it extreme hackery (and lots of overhead) to compare any matching ID effects and then turn off effects before applying all the effects. This will still need to use a bit to tell the effect that it should be suspended because another effect is overriding it.

 

So, in summary, what you propose is quite a challenge.

[Galactygon]

The advantage of the effect comparison is that Righteous Magic and Holy Power can still stack. But if you applied two Righteous Magic on yourself, then the strength bonus will stack. I am unsure as to whether it should be applied across the board, because the behaviour you want is opcode-specific. For example, you might not want the THAC0 penalty of blindness to stack, but you do want two incremental strength bonuses from different effects to stack.

This could be solved by giving feature blocks in Righteous Magic and Holy Power two different "ID"s so they stack with each other but not with themselves.

 

1. The IDs become universal, so there is high potential for mod conflict.

Yes, it would be up to the modders to maintain a community-wide list.

 

2. The evaluation becomes highly opcode-specific. Each opcode would need some way of comparing who is greater/lesser than the other.

The "ID"s would apply for similar opcodes. The same "ID" could be recycled for two seperate opcodes (say DEX bonus and STR bonus), without any consequences.

 

3. Effects are applied sequentially. This makes it extreme hackery (and lots of overhead) to compare any matching ID effects and then turn off effects before applying all the effects. This will still need to use a bit to tell the effect that it should be suspended because another effect is overriding it.

 

I was thinking this "ID" is automatically turned off if dword at 0x2c is zero (default behavior) - in other words, effects with an "ID" of 0 stack.

 

So, in summary, what you propose is quite a challenge.

I can't speak for you on how much hackery it could produce, this stuff already works with the hardcoded DUHM opcode.

 

An alternative is do what IWD has done - create a bunch of hardcoded effects that interact with each other on a hardcoded level and implement a new opcode each time some modder comes up with a new spell or item.

 

-Galactygon

[Avenger]

Adding something this 'grand' is probably not economical with the original engine.

I mean, the gain is obviously less than the effort.

Small few bit changes are fine and doable, but this ID idea would require rewriting much of the original code, probably in many places.

 

If there is a real demand for this, i would recommend coding this stuff for GemRB and submitting it as a patch

 

Btw, the ID group idea remind me about the journal entry groups. (journal entry may have a group id, if you 'solved' a quest, and added an entry with a group id, GemRB removes the previous entries of the same group).

[Galactygon]

This is something that already exists in game (opcode 132), we'd simply extend this to all the other stat-changing opcodes. The difference between the two is one of them would be comparing feature blocks with similar opcodes while the other would be comparing feature blocks with similar opcodes and similar values at 0x2c.

 

I can think of many applications of this, this would be a large step in BGII spell/item editing. For example, we could then mimick IWD's hardcoded opcodes without creating a whole bunch of hardcoded effects.

 

I have been able to add configurable flags in feature blocks to control stacking behaviour.

1. One of the bits can turn on behaviour that will skip the effect application if a similar effect is already found. However the timing will still be updated, meaning that it will still expire when expected.

2. The other bits can turn on behaviour that will suspend the effect from being applied until similar effects have expired. This effectively extends the duration of an effect.

 

I will have to disagree with this for the following reasons:

I take back part of what I said earlier. An application of this could be used in opcodes 177, 272, and 283 for great effect without spending any "ID"s.

 

-Galactygon

[Ascension64]

I take back part of what I said earlier. An application of this could be used in opcodes 177, 272, and 283 for great effect without spending any "ID"s.

I had it implemented, but will have to go back and re-jig it. Is it going to be worth more than just three opcodes though?

 

 

232 Cast Spell On Condition

In order to allow auras to work more consistently if using effect opcode 232 in Item Revisions, I toyed around with the contingency delay timing, which is triggered on a per creature basis every 100 AI updates. (http://forums.gibberlings3.net/index.php?showtopic=21061)

 

One side effect of changing the global value of 100 was that certain spells using this opcode triggered every AI update instead of every script round (http://www.shsforums.net/topic/43639-bg2tob-experimental-tobex/page__view__findpost__p__501601).

 

I believe I can change this so that the condition check for spells can be determined at the effect level as opposed to the global level.

 

Two questions:

1. Would this be useful? E.g. you could make a version of some damage aura trigger once every half-round as opposed to twice per round.

2. Implementation would likely require local storage of the delay timer and a temporary storage of the current time of the effect. I propose you could use the high WORDs of param1 and param2. Any other ideas?

[Avenger]

I don't like bit masking for temporary variables, it is bad enough for read-only parameters.

More precisely, i don't like writing values back into a masked field.

 

There are lots of unused fields that could be used for temporary variables.

And there are some extra fields to use as parameters too.

Even in v1 effects, the 0x2c value (isVariable) is inherited by the v2 effect, and i suspect it could be used as parameter.

(Though i so far avoided its use).

Anyway, for temporary variables, I prefer to use param3 or param4.