EFF application (op177) vs Spell application (op146/op326)

[marchitek]

I'm struggling with one topic and I'm wondering if someone could help me with some piece of advice.

Case is I want to apply local variable (with opcode 309) on exactly same conditions as some other opcodes and I want spells that grant immunity to those other opcodes to protect also agains setting this local variable.

E.g. I want to set local variable every time when creature is petrified. And I want stuff that protects against petrification to protect also against setting this local variable.

My current approach is to create own SPL that applies both petrification opcode and local variable and replace all applications of petrification opcode with application of this SPL (with opcode 326). Then I replace all petrification immunity opcodes to protection against resource (opcode 318), that would protect against my SPL.

So far so good until I realized, that I need the same trick for more complicated opcodes, that use parameters, duration etc. In such cases I would need to clone entire effect inside my SPL and I will end up probably with number of SPLs equal to number of usages of opcode (or I will need some not trivial logic to reuse SPL if all parameters are the same).

Then I thought that maybe better approach in general would be to just clone effect that applies opcode and change cloned one to apply local variable. Then original effect will remain untouched and effect that apply variable would have always exactly same conditions as original. The problem is that I cannot grant immunity to opcode 309 every time that something gives immunity to original opcode. So I anyway need some wrapper for my set local variable effect.

And here comes problem form the title. I see three options:

1. create EFF file and apply it with opcode 177
2. create SPL file and apply it with opcode 146
3. create SPL file and apply it with opcode 326

At the beginning EFF file seemed to me as the best solution, but apparently it can be blocked with opcode 318 only by using parent resource not EFF resource itself. So it seems it is designed more to be one to one relation with ITM/SPL/CRE which is not my case.

Both SPL solutions also looks also nice and I could even apply more additional effects if needed. The problem is that there is two of them and they are quite similar. I'm keen into opcode 146 since it has reasonable reflect behavior and I don't need all of this advance condition matching that 326 offers.

I guess that's it. I would be grateful for any insights that could help make a right decision. Or maybe I'm completely missing something and there is better way to achieve all of this.

 

[subtledoctor]

I don't really follow everything. Can you maybe say what the ultimate purpose is here? Like, why replace petrification effects with op326? 326 is used when application of the spell is meant to be conditioned on something. Is there a condition here for petrification being applied?

Ditto using op318 for immunity to petrification. What is the condition for the immunity? Why not just use op206 against a spell, or op101 against an effect?

I feel like you could simply:

• copy all spells and CLONE_EFFECT instances of petrification to add an op177 effect
• create an EFF with op309 setting the local variable, and set parent resource type to 'spell' at 0x90 and give the parent resource a name at 0x94
• copy all spells and CLONE_EFFECT instances of 101 immunity to petrification to add an op206 effect against the parent resource you named

Opcode 206 can protect against EFF files if they have a parent resource name at 0x94 and set to 'spell' at 0x90. I usually set the parent resource to be the same as the EFF filename, for simplicity.

22 minutes ago, marchitek said:

until I realized, that I need the same trick for more complicated opcodes, that use parameters, duration etc. In such cases I would need to clone entire effect inside my SPL and I will end up probably with number of SPLs equal to number of usages of opcode

This doesn't sound necessary, but OTOH it's not the worst thing in the world if it is needed. I do this in several mods, e.g. custom invisibility detection.

[marchitek]

28 minutes ago, subtledoctor said:

I don't really follow everything. Can you maybe say what the ultimate purpose is here? Like, why replace petrification effects with op326? 326 is used when application of the spell is meant to be conditioned on something. Is there a condition here for petrification being applied?

Ditto using op318 for immunity to petrification. What is the condition for the immunity? Why not just use op206 against a spell, or op101 against an effect?

Probably answer to most questions is my lack of modding experience.  I used op326 just to apply my own SPL as part of other SPL. I guess op177 is better in such cases (when no need for condition)?

I haven't used op101 because I would protect again all usages of op309. So I needed something that would protect agains my own SPL, and I picked op318. Again, I guess op206 is just simpler equivalent here?

 

28 minutes ago, subtledoctor said:

I feel like you could simply:

• copy all spells and CLONE_EFFECT instances of petrification to add an op177 effect
• create an EFF with op309 setting the local variable, and set parent resource type to 'spell' at 0x90 and give the parent resource a name at 0x94
• copy all spells and CLONE_EFFECT instances of 101 immunity to petrification to add an op206 effect against the parent resource you named

Opcode 206 can protect against EFF files if they have a parent resource name at 0x94 and set to 'spell' at 0x90. I usually set the parent resource to be the same as the EFF filename, for simplicity.

Ah, I can set parent resource to the same as this resource name. Then EFF option is back in the game.  And I can use simpler op206 instead of op318. Thank you!

 

It's easy to get lost in all of those opcodes, but I think I start to see the pattern here. 

• For spell application: use op146/op177 unless you need special conditions, then op326
• For protection agains spell: use op206, unless you need special conditions, then op318, unless you want also auto message, then op324

Roughly.  

[subtledoctor]

Exactly right!

(Well, actually op177 can have some limited conditions too, and has other uses because it can, for example, use ‘while-equipped’ timing. Can be very flexible to combine conditions with equipped timing and a parent resource name. And op318 can block it and op318 can have even more conditions. Can do a lot of interesting stuff with this, though it can get pretty complicated to apply.)

Edited March 20, 2023 by subtledoctor

[marchitek]

Ok. Then, if I get it right, to have those splprot.2da conditions I need to use op318 that protects against it with reversed condition?

***

When looking on op326 it seems a bit useless due to it's reflection behavior. Let's say I want to create spell  that do dmg, but one some condition from  splprot it kill instantly. Then it seems I cannot use this opcode anyway, because in case of reflection, this instant kill would still apply if condition is met.

***

One drawback of cloning approach: it impossible to clone effect in EFF file, since it holds only one effect. But I guess I can clone entire resource and then clone application of original EFF and apply also my new EFF. I'm wondering if EFF file can apply other EFF file. Because then I will need to do all of these recursive. 

[subtledoctor]

Yes, an .EFF can use op177. It can be useful if you need to nest .EFF conditions. 

But in this case you would need to check the long way: use GET_OFFSET_ARRAY to find all spells using op177, then INNER_ACTION to examine the attached .EFF files for the petrification opcode at 0x10. If so, add the originating .SPL and the associated .EFF to an array. 

Then run through that array and CLONE_EFFECT those op177 effects to add your new one. 

(Incidentally this two-step process - GET_OFFSET_ARRAY to build a list of actually relevant spells, then CLONE_EFFECT spells in that list - is about 10 times faster to install than just running CLONE_EFFECT on every spell. So it might be worth it even in the simpler instances as well.)

[marchitek]

1 hour ago, subtledoctor said:

But in this case you would need to check the long way: use GET_OFFSET_ARRAY to find all spells using op177, then INNER_ACTION to examine the attached .EFF files for the petrification opcode at 0x10. If so, add the originating .SPL and the associated .EFF to an array. 

Then run through that array and CLONE_EFFECT those op177 effects to add your new one. 

Nice idea. So you think it would be better to check EFF on every usage (unless already in array) then just go through all EFFs upfront? I think one advantage to resolve it upfront is that I can later just check SPL resource field and if it match EFF in array, then clone it. This way I don't need to worry about opcode and would just catch all regardless if this is op177, one of :protection from resource" opcodes or anything else. On the other hand with your approach I can also have it, so read resource, then check if such eff exists (if not this is some other resource and ignore) and so on. But still searching upfront need to be at least as fast as checking usages (the most optimistic scenario for usage checking is when each eff is used only once), assuming that every EFF is used at least once. Eh, pity that one cannot make PhD on this topic.  

1 hour ago, subtledoctor said:

(Incidentally this two-step process - GET_OFFSET_ARRAY to build a list of actually relevant spells, then CLONE_EFFECT spells in that list - is about 10 times faster to install than just running CLONE_EFFECT on every spell. So it might be worth it even in the simpler instances as well.)

Yeah I noticed that. CLONE_EFFECT always reads whole thing so it is definitely designed to be used when there is something to clone (it even prints warning if nothing was done). I missed existence of GET_OFFSET_ARRAY, I prepared my own functions for reading.  Not big difference though.

[marchitek]

On 3/21/2023 at 12:04 PM, subtledoctor said:

Yes, an .EFF can use op177. It can be useful if you need to nest .EFF conditions. 

Just from curiosity. How many nested conditions like that can I expect? I mean, ofc in theory it can be any number, but just from your experience. It is something up to 10? Or do you saw/implemented longer chains?

[subtledoctor]

2 hours ago, marchitek said:

Just from curiosity. How many nested conditions like that can I expect? I mean, ofc in theory it can be any number, but just from your experience. It is something up to 10? Or do you saw/implemented longer chains?

It’s theoretically unlimited, but I’ve never seen any reason to nest more than two .EFF files. The useful conditions for op177 are pretty limited. 

[marchitek]

20 hours ago, subtledoctor said:

It’s theoretically unlimited, but I’ve never seen any reason to nest more than two .EFF files. The useful conditions for op177 are pretty limited. 

Good news for me.  

Another problem: opcodes that have condition built-in, like op209 (Death: Kill 60HP).  I guess I would somehow need to apply my EFF with special condition "145_CURRENTHP<n". But it seems there is no opcode to apply EFF with special conditions. I could maybe apply protection agains my EFF right before applying it. But it turns out there is no  condition like "CURRENTHP>n". I must say, this engine is crazy.  

***

I missed '>' in "144_CURRENTHP>=n". My bad.  

Edited March 24, 2023 by marchitek

[jmerry]

If none of the presets fit, you can always add new conditions by extending SPLPROT.2DA.

[marchitek]

17 hours ago, jmerry said:

If none of the presets fit, you can always add new conditions by extending SPLPROT.2DA.

Ah, I see. This time maybe not need it, but definitely good to know. And there is even option to join them with OR or NOR. I guess I owe our dear Infinity Engine a bit of apology.