DS and SR

[DavidW]

Just in the process of stealing borrowing Demi's very nice changes to Insect Plague and Creeping Doom, and I notice that SR is going to have to make a few changes to DS to allow for shell spells.

 

Demi, is this something you do other than for the two insect spells? If it's just those two, I'll do it in the central DS; if not, we should probably talk about how to handle it. (It's not a problem to handle it - DS is very customisable).

[Demivrgvs]

Well, I can't rememebr all the spells right now (I think SR has more or 300 spells ) but surely I've used it at least for a few other spells. I currently don't include DS within SR because I gladly left that to be handled by mods such as SCS, but if you think it's better to do something about it let me know.

 

Edit: actually V3 was going to make most AoE spells work via shell system to make them not bypass mr when self casted.

[DavidW]

Well, here's how it works (this is mostly based on Cam's old code). DS is based on a table that basically looks like this:

 

SPELL			   NEW_OP  VALUE STAT  CLONE_OP PATCH_WHAT 
SPPR517.SPL	233		  2		120   60			  A
SPPR603.SPL	233		  2		121   142			A
SPPR613.SPL	233		  1		122   197			A

 

Column 1 is the spell being patched, obviously. NEW_OP and STAT, between them, specify the particular stat being used - NEW_OP records if it's a proficiency or a scripting state, STAT records which one is to be used. VALUE is the value that the stat is to be set to. PATCH_WHAT is functionality we never got around to using: it's always equal to A. CLONE_OP specifies another opcode which is applied by the spell and lasts its whole duration (so not something like the initial or final sound effects).

 

What DS does is look through every ability header till it finds an effect which matches CLONE_OP. Then it copies details like duration, saving throws, and the like from that effect, clones them, and sets up a ModifyProficiency or ModifyScriptState block of the right kind.

 

It's probably fairly obvious why this is going to choke on shell spells. Take Insect Plague (SPPR517): in your new version, that spell has no opcode-60 effect. In any case it's not the place where we want the detectable stat to be applied. In this case, we want it on SPPR517B. And we don't want it attached to effect 60 (spell failure) any more, because that has a saving throw. 54 (THAC0 bonus) is a better choice. So to make DS compatible with SR, it needs to lose the SPPR517 entry above, and replace it with

 

SPPR517B.SPL	233		  2		120   54			  A

 

 

So if you want DS to be compatible with SR, you need to work up (i) a list of spells that should be left out of DS if SR is installed (like SPPR517), and (ii) a new table, made up of new rows that need to be included in DS (like the one above). Then you could either install the new table in SR itself (if you want to maintain control of it) or you can give it to me and I'll distribute it with the version of DS that I maintain. Either way, the main version of DS will have to look out for SR and avoid marking certain spells if SR is installed.

 

I'm happy to do all the coding for this (it's not much work; DS is pretty modular) but obviously I'm not in a position (and don't have time) to generate the actual data.

[Ardanis]

In this case, we want it on SPPR517B. And we don't want it attached to effect 60 (spell failure) any more, because that has a saving throw. 54 (THAC0 bonus) is a better choice.

Is your reasoning that spell failure or not, but non-saveable damage will interrupt nonetheless? Because if once-per-3-seconds damage is no big issue (not as big as it was in vanilla) then the DS check should stick with 60 - if we save against miscast, we automatically save against DS.

[DavidW]

In this case, we want it on SPPR517B. And we don't want it attached to effect 60 (spell failure) any more, because that has a saving throw. 54 (THAC0 bonus) is a better choice.

Is your reasoning that spell failure or not, but non-saveable damage will interrupt nonetheless? Because if once-per-3-seconds damage is no big issue (not as big as it was in vanilla) then the DS check should stick with 60 - if we save against miscast, we automatically save against DS.

My reasoning is a bit more basic than that, to be honest: you can already detect spell failure directly.

[Demivrgvs]

Now, if spell failure can be checked SR's insect spells may not even need to be detected by DS, though it's obviously better if they are.

 

 

I'm happy to do all the coding for this (it's not much work; DS is pretty modular) but obviously I'm not in a position (and don't have time) to generate the actual data.

What do you need from me? A list of spells which work with a shell system?

[DavidW]

What do you need from me? A list of spells which work with a shell system?

 

Ideally, a table like the one above, for all the shell spells that need DS flags added. For the spells that are identical to their old versions except for being renamed, just a list of the new names will do.

[the bigg]

PATCH_WHAT is functionality we never got around to using: it's always equal to A.

It's used for the Detectable Items extension that I implemented but Xyx never got around to write a list of items to use. Other valid values are G for adding DS to the main header and a number for a specific extended header.

More info should be in some old thread named 'detectable affects'.