Good news for auras?

[Ascension64]

I have fixed the Repeating EFF opcode to allow multiple instances of this opcode with different param2 to work correctly. The problem was that whenever the creature was refreshed, the effects were re-applied as if fresh, and the effects that have not yet triggered did not have their timings kept.

 

Maybe the auras you were having trouble with can be re-instated.

Unfortunately, it will require TobEx to function. It will be in TobEx beta 0012: I'm just getting around some difficulty trying to get some consistency into the timing.

[Demivrgvs]

I have fixed the Repeating EFF opcode to allow multiple instances of this opcode with different param2 to work correctly. The problem was that whenever the creature was refreshed, the effects were re-applied as if fresh, and the effects that have not yet triggered did not have their timings kept.

Has your function anything to do with Taimon's recent work? Because as I recently happily announced here, I tested a code he gave me few days ago and it indeed seemed to fix opcode 272.

 

I've still to check if Cast Spell on Condition opcode (232) and the fixed one (272) can work together. The former seems to be considered by the engine just like a Repeating EFF (272), with a frequency set to once per round (when triggered), and thus causes similar timing issues. Regeneration opcode (98) has similar issues too.

 

In case opcode 232 still gives issues I may just as well change IR's items to use 272 in its place, as more often than not the trigger condition is simply a "while in combat" (parameter 2 set to 1 - SeeNearestEnemyOfMyself).

 

Maybe the auras you were having trouble with can be re-instated.

Unfortunately, it will require TobEx to function.

Anyway, having a fully functional Repeating EFF opcode is indeed a bless for IR, not only for aura-like effects. Even within V2 I still kept few aura-like effects despite their issues (e.g. I loved too much PnP-like Belt of Inertial Barrier to remove it), but this indeed allows me to use it more often if necessary, and to also add few features here and there if we wish so (for example I'd be able to make True Seeing work against Cloak of Displacement).

 

Considering how important this fix is I was actually going to include Taimon's code within IR just like we did with many of his codes for both IR (V3 will also needs the one which fixes stacking apr bonuses) and SR (e.g. the recently discussed Dispel fix), thus I don't think it will need TobEx unless your work isn't just like Taimon's one, but a more functional/updated one.

[Ascension64]

Talk about two completely independent discoveries at the same time. I had no knowledge of Taimon's work.

 

With just the repeating effect opcode fixed, any stacks will have this opcode work, but no others. The others will need to be fixed in turn. It is simple to port the same change over to all other opcodes, using the same principle of preserving timings.

 

Edit: Fixed the regeneration opcode now.

[Demivrgvs]

Talk about two completely independent discoveries at the same time. I had no knowledge of Taimon's work.

I didn't even knew he was working on it myself before he sent me the holy code.

 

With just the repeating effect opcode fixed, any stacks will have this opcode work, but no others. The others will need to be fixed in turn. It is simple to port the same change over to all other opcodes, using the same principle of preserving timings.

I guessed the same, but I'm not a ninja coder like you and Taimon, thus I just mentioned them hoping have you or him fix them too!

[Ascension64]

Cast Spell On Condition has a delay timer of 100 ticks to evaluate their triggers. This may produce the delayed effects that you see when switching weapons. I imagine this delay is to limit the frequency with which contingencies are checked. Perhaps they were never meant to be used in other ways. It is possible to remove this delay (set the delay to 1 tick instead), but the effects 'may' be undesirable.

 

If you would like to test this, either hex edit or WeiDU you patch the LONG value at 0x6BED8 (this should be 100 by default).

[Demivrgvs]

Cast Spell On Condition has a delay timer of 100 ticks to evaluate their triggers. This may produce the delayed effects that you see when switching weapons. I imagine this delay is to limit the frequency with which contingencies are checked. Perhaps they were never meant to be used in other ways. It is possible to remove this delay (set the delay to 1 tick instead), but the effects 'may' be undesirable.

Well, if the only problem left is the "delayed refresh" issue I think not using opcode 232 on weapons should be enough (I generally use it only on armors, that cannot be removed or equipped during combat). Weapons can still have aura-like effects with a fixed opcode 272.

 

But, does Cast Spell on Condition (when parameter 2 is set to 1) still break Regeneration opcode even after your fix on opcode 98?

 

Anyway, even leaving 232 untouched with a fixed 272 and 98 I'm sure I can handle pretty much everything.

[Ascension64]

Cast Spell On Condition has a delay timer of 100 ticks to evaluate their triggers. This may produce the delayed effects that you see when switching weapons. I imagine this delay is to limit the frequency with which contingencies are checked. Perhaps they were never meant to be used in other ways. It is possible to remove this delay (set the delay to 1 tick instead), but the effects 'may' be undesirable.

Well, if the only problem left is the "delayed refresh" issue I think not using opcode 232 on weapons should be enough (I generally use it only on armors, that cannot be removed or equipped during combat). Weapons can still have aura-like effects with a fixed opcode 272.

 

But, does Cast Spell on Condition (when parameter 2 is set to 1) still break Regeneration opcode even after your fix on opcode 98?

 

Anyway, even leaving 232 untouched with a fixed 272 and 98 I'm sure I can handle pretty much everything.

I toyed around with the delay interval, the only side-effect appears to be extra overhead, which shouldn't be a problem on a modern computer unless lots and lots of script-active objects have contingencies on them. Muck around with WRITE_LONG 0x6BED8 1 just to check if that actually fixes your mixed Cast Spell on Condition results.

 

Good you are using the See() trigger. The HitBy() trigger is checked every script round. In terms of testing the Regeneration opcode with Cast Spell on Condition, can you lean me towards a specific item that I can test with? I can't install IR at this point in time, but can download and find an appropriate file if it is still in the mod. Even easier, you could just attach a test item.

[Demivrgvs]

I toyed around with the delay interval, the only side-effect appears to be extra overhead, which shouldn't be a problem on a modern computer unless lots and lots of script-active objects have contingencies on them. Muck around with WRITE_LONG 0x6BED8 1 just to check if that actually fixes your mixed Cast Spell on Condition results.

Well I prefer to not be a cause of extre overhead, as I prefer to leave the CPU free for more important scripts like SCS ones. As I said, I'll simply limit such effects, as most of them are doable even via Reapeating EFF.

 

Good you are using the See() trigger. The HitBy() trigger is checked every script round.

Well, I do have a couple of HitBy() too, but they are very few (4 within my current V3 install: ), and I never noticed any issue on my games, not even on old SCS installs (previous version had much longer and CPU consuming scripts).

 

In terms of testing the Regeneration opcode with Cast Spell on Condition, can you lean me towards a specific item that I can test with? I can't install IR at this point in time, but can download and find an appropriate file if it is still in the mod. Even easier, you could just attach a test item.

Belt of Inertial Barrier for example (belt10.itm), though this is indeed one of the items I can re-do with opcode 272 instead of 232.

[Ascension64]

Reporting that the IR Belt of Inertial Barrier works instantaneously when you set the contingency delay to 1.

Practiced on lightning mephits in Chateau Irenicus.

 

I had to bugfix the item in v2 because it had improper targeting.

However, the limitation is that because the targeting is nearest enemy, you have to physically run your character around all the enemies to affect them all.

[Demivrgvs]

Reporting that the IR Belt of Inertial Barrier works instantaneously when you set the contingency delay to 1.

Practiced on lightning mephits in Chateau Irenicus.

Great, though in theory you shouldn't notice the delay anyway, because SeeNearestEnemy (more or less 30-40 feet away) should trigger be well before the target is within range of the the effect (10 feet).

 

I had to bugfix the item in v2 because it had improper targeting.

However, the limitation is that because the targeting is nearest enemy, you have to physically run your character around all the enemies to affect them all.

I remember V2 without hotifx having wrong projectile assignement, but I can't see anything else wrong. The targeting is self cenetered when nearest enemy is on sight, and the projectile AoE should affect any opponent, not just one. Are you sure about your issues?

 

P.S I tested it just to be sure and it indeed seems to work fine on my install.