SR Revised V1.3.900 (2022 August 8th)

[subtledoctor]

Yeah, it's actually enabled in the AoE Spell Deflection component UNLESS you have Spell Revisions' base component installed, where it is then disabled. This is how it was already set in SR, and the reason for this is because it's similar to some of the other spells that can't currently be enabled to be deflected (like Gust of Wind) - it has some effects that self-target. In this case, trying to enable AoE Spell Deflection would make it so that you would blow yourself up when you cast the spell, too. What I might try doing is for special cases, just introduce a specially prefixed subspell with the AoE effects so that it can be handled by this subcomponent, unless Subtledoctor has come up with a solution already.

When I have some time I'll look into this. I kind of think it's worth simply using a different subspell name, at least for the small universe of vanilla and SR-added spells that need this treatment. Just change from "spwi000b" to "dvwi000." We're only talking about a small handful of spells. Of course, changing subspell names could possibly involve a lot of interconnected changes, where other spells refer to that subspell... have to tread carefully...

 

@Subtledoctor: Ah, I see that your method of "avoiding tooling around in NI for hours" is made possible by me tooling around in a text file for hours to actually make your method work. Nicely done, .

My hope is that comparing a simple text list to the descriptions is quicker and easier than examining files in NI/DLTCEP.

 

My code also handles setting opposition schools... I don't recall, does SR change opposition schools? Or can I rely on the vanilla setup?

 

And in IWDEE each school has two opposition schools. If SR is installed, should it defer to the IWD system or impose its own SR-defined opposition schools? (Personally I favor the latter.)

[Bartimaeus]

They're the same as vanilla, so probably (definitely) stick with that unless you want a lot of angry people complaining that you just fundamentally changed how the magic system works in SR, . Conjuration-Divination, Abjuration-Alteration, Necromancy-Illusion, and Invocation-Enchantment.

 

Yeah, for the subspell AoE issue, I think using a dvwi/dvpr prefix instead for the handful of spells whose AoE effects need to be separated from the rest of the spell would probably be best. Then you can just leave the non-AoE effects in the original spell, have it cast the AoE subspell at the end, then have the AoE SD component target that subspell.

Edited October 18, 2018 by Bartimaeus

[DavidW]

I’m not sure renaming subspells is such a good idea (though it’s a judgement call). SR uses a lot of them, and while yes, Demi should have used his modder prefix, in practice that corner of namespace is not otherwise going to get much use, so you’re balancing a probably-not-too-large risk of namespace conflict against the quite high chance of introducing bugs - to say nothing of other mods that react to SR spells using the current names. (I think SCS does some of this.)

[subtledoctor]

Maybe I can set the AoE deflection code to check

1) does the spell to be affected have 8 characters?

2) does it begin with 'sp'?

...and if so, then use the 'dv' prefix on the new sub-subspell cast for AoE deflection. So e.g. Chain Lightning at spwi605 would cast spwi605e as normal; but we will patch spwi605e with a 146 effect which will cast dvwi605e which will be blocked by Spell Deflection.

 

It won't cover mod-added spells, but it will handle spells that really ought to be included and that SR already knows about - Fireburst, Chain Lightning, Earthquake, etc.

Edited October 18, 2018 by subtledoctor

[subtledoctor]

Here it is if you wanted to look at it: https://dl.dropboxusercontent.com/s/48748442srres0a/fix_spellbooks_arcane.tpa

 

Relevant lines for your coding:

READ_SHORT 0x20 priest_type

ELSE PATCH_IF (priest_type == 0xe07f) BEGIN // disabled

 

So if a spell (e.g. the supposed-to-be disabled level 4 version of Mestil's) is supposed to be disabled, your coding should WRITE_SHORT at 0x20 to 0xe07f. That'll mark it for removal.

Which bit(s) of byte 0x20 does that set? (I can't make heads or tails of hex stuff like "0xe07f.") How was that chosen? Is it an SRR thing? (I don't see it in SR proper.)

 

I'm pretty sure those bits are actually useful, at least in the EEs - though you'd never know it from looking at the IESDP, of course ) I forget if it's 0x20 or 0x21 or both, but those can actually set usability flags for bard kits and possibly cleric/druid kits. I used some of them in my bard mod until I radically changed it to adopt 3E conventions.

 

Worth pinning this down before committing SR to it... given how much more limited the options are to mod spell usability vs. item usability, these bits could be hidden gold. I wouldn't want to take that away from other modders if we can find another way to mark spells for spellbook removal...

Edited October 18, 2018 by subtledoctor

[Bartimaeus]

It's what was already being used by SR to mark divine spells for being disabled (see e.g. SPPR510 in non-Revised SR), so it's what I just kept using for arcane spells. But if those priest type values can actually be used in EE games for other things, then it's probably best to just set one of the unused bits (0x24, 0x28, 0x2C) to 1 and detect for that instead...UNLESS setting those causes the spell to malfunction and/or crash the game, so probably test that.

Edited October 18, 2018 by Bartimaeus

[HuoYuhao]

Thank you for fixing Prismatic Mantle. I also mentioned earlier how Chain Lightning is only doing 10d6 damage on a failed save instead of 20d6. I tested this by EEKeeper-ing a sorcerer to max level in Chateau Irenicus using SRR v1.0.1 and casting the spell on myself.

[Bartimaeus]

Sorry, I didn't see that: will look into it.

 

@Subtledoctor: Regarding the AoE SD thing: I'm not skilled enough with weidu to figure out how to take the name of a spell and replace the first two letters of it, so if you can figure that out, sounds good to me.

[Bartimaeus]

HuoYuhao: No, Chain Lightning seems to work correctly, but I can see why you didn't think it did. If you cast it only on yourself or on allied/neutral creatures, the second part of the spell (the AoE-spreading part) does not kick in, since it targets only enemies. So only the extra damage that applies to the main target is effective. There's possibly a more effective way of doing this via spell immunities, to make sure that the initial target still receives full damage even if they're neutral at the time of the spell hitting them, though...

[subtledoctor]

 

READ_SHORT 0x20 priest_type

ELSE PATCH_IF (priest_type == 0xe07f) BEGIN // disabled

 

So if a spell (e.g. the supposed-to-be disabled level 4 version of Mestil's) is supposed to be disabled, your coding should WRITE_SHORT at 0x20 to 0xe07f. That'll mark it for removal.

Which bit(s) of byte 0x20 does that set? How was that chosen? I'm pretty sure those bits are actually useful, at least in the EEs - though you'd never know it from looking at the IESDP, of course )

It's what was already being used by SR to mark divine spells for being disabled (see e.g. SPPR510 in non-Revised SR), so it's what I just kept using for arcane spells. But if those priest type values can actually be used in EE games for other things, then it's probably best to just set one of the unused bits (0x24, 0x28, 0x2C) to 1 and detect for that instead...UNLESS setting those causes the spell to malfunction and/or crash the game, so probably test that.

Okay, I've confirmed that this is not a great idea. To be fair to Demi, those bits were not in use when SR did this. It's a relatively new EE thing, added in either the 1.3 or 2.0 patch I think. For example: if you look at a spell in Near Infinity, bit 0x10000000 of the byte at offset 0x20 says it excludes "elf." The bits in byte 0x21 purport to exclude a bunch of other races, and cleric and druid. That representation was taken from the item format, but spells do not actually exclude races. Those bits actually (now at least, in the EEs) represent various classes and kits (not all of which are functional, unfortunately). For instance the "elf" usability flag in 0x20 actually excludes spells from Skalds. One of my mods used to use it to give bards custom spell lists.

 

Maybe we can set a incongruous set of flags to mark the spells. These are going to be removed from general use and not usable by players, correct? What if we set all the alignment bits in 0x1e? So nobody of any alignment can use these spells... that shouldn't matter because nobody will be using them. That wouldn't stop the AI using them... would it?

 

Or, what about setting the "exclude cleric/paladin" and "exclude druid/ranger" flags? That shouldn't matter since we're talking about arcane spells. But no other arcane spells have those flags (no need for them) so it could be an effective marker. For divine spells could do the opposite: set the "exclude generalists" flag, which should be useless and redundant, but a recognizable marker.

[Bartimaeus]

It really doesn't matter to me, as long as it's a clear, consistent marker that doesn't infringe upon other functions, and the spells still actually function (so that AI can still use them as necessary), and the spells (divine or arcane) never show up in spellbooks after being removed. The thing I'm wondering, though, is that for disabled spells, what does it matter? Like, the priest type matters for cleric spells, obviously, but it doesn't matter if we set it to an invalid priest type because those spells aren't going to be used by players anyways. Isn't the same true of disabled arcane spells? We're not going to be setting any spells that actually use those values to what's essentially an invalid (yet harmless) combination, right? Not that that's any reason not to make a more foolproof method, but I imagine that there's little to no risk of anything going wrong with the current method...right?

 

Either way, you're more knowledgeable about the EE-only values, and I'll most likely follow your lead based on what you decide makes most sense. Though I think the restrict via all alignments option (which would be, what, a value of 0x14 at location 0x1e?) sounded like the best (and most natural) method.

Edited October 19, 2018 by Bartimaeus

[subtledoctor]

It really doesn't matter to me, as long as it's a clear, consistent marker that doesn't infringe upon other functions, and the spells still actually function (so that AI can still use them as necessary),

Yeah, I only care about whether it functions well. My question was along the lines of, "will this break things?" Like, if a spell is coded with the cleric exclusion flag, maybe SCS AI will see that and enemy clerics won't use it... that is not a desired outcome because we want the AI to be using these spells. I'm pretty sure using the divine exclusion flags on arcane spells and using an arcane exclusion flag(s) on divine spells should be fine.

 

Either way, you're more knowledgeable about the EE-only values, and I'll most likely follow your lead based on what you decide makes most sense. Though I think the restrict via all alignments option (which would be, what, a value of 0x14 at location 0x1e?) sounded like the best (and most natural) method.

I'm reasonably sure SCS doesn't care about alignment when deciding whether and how to use this or that spell... but not 100%. Insofar as there are two different functions being run here - one for divine spells which is in vanilla SR, and one for arcane spells which I think you added? - the most harmless approach is probably the one I described above.

 

Actually since we're only currently talking about arcane spells, I'm just going to use the cleric+druid flags. Whatever SR already does for divine spellbooks, I'll leave that alone unless and until I have a better sense of how and where to change it.

[subtledoctor]

Btw it seems like there might be a problem in your spellbook code. You have:

READ_SHORT 0x1e exclusion_flags
...
SET $spell(~%SOURCE_RES%~ ~excl~) = (specialist_flag BAND 0b111111) // store the exclusionary school

You read 2 bytes, 0x1e and 0x1f with the READ_SHORT, and then later treat it like its one byte with "variable BAND 0b111111" - in fact, only 6 bits of that byte. I think that's a mismatch. I'm not sure how to fix it yet because I don't actually know what it's doing there... adding the exclusion flag value to an array?

 

Maybe you took that straight from the SR divine spellbook code? (I think Ardanis wrote that... I forget.) This would work for divine spells since it only need a READ_BYTE at 0x21. But the arcane specialist flags are spread across 2 different bytes, 0x1e and 0x1f, so they would need slightly different treatment.

 

EDIT - looking at the divine spellbook code, it looks like that "0b111111" actually represents alignment exclusions, which is relevant for priests but not for mages. So it's not necessarily a mismatch, but it's also not necessarily useful. I wonder if it can be safely excised on the arcane side...

Edited October 19, 2018 by subtledoctor

[subtledoctor]

Okay I've got this all working. I also updated the method for detecting joinable NPCs, which is now 1) more reliable, and 2) quicker to install.

 

The only fix left on my 'to-do' list before I upload "4b15sd7" is:

 

"Go over all protection spells that are not supposed to be cumulative with themselves and corrected a number of spells that had them not in quite the correct order: various Protections Against Evils, Mage Armor, Ghost Armor, Barkskin, Resist Elements, Storm Shield, Magic Resistance, and Regeneration. Most of these, with the exception of I think Storm Shield, were only very slightly out of order, mostly because of other versions of the spell across the arcane-divine spectrum or vs. IR copies of the spells (i.e. the divine version of Resist Elements was specifying protection against the divine version of the spell before the arcane version, which prevented the protection against the arcane version from ever happening...so you could cast the arcane version right after and stack them, but not the other way around). Storm Shield had its protection against itself inserted right in the middle of spell, and so was lacking its protections against gas spells like Cloudkill as a result."

 

I don't suppose you have any advice for getting this done in an expeditious way...?

EDIT - just so I'm clear: this involves shifting the opcode 206 effects in those spells in order to prevent stacking in non-EE games, correct? And kreso's EE code should strip out those 206 effects and add in 321 effects for the EEs... correct? So I only need to worry about the spells in their base state in the SPxx__ folders, and only need to worry about the 206 effects. Right?

Edited October 19, 2018 by subtledoctor

[Bartimaeus]

Yeah, I for sure left junk code in there that didn't apply just because it already seemed to work fine and I didn't feel like bothering with it anymore.

 

@Cumulative immunities: I don't think this is something SR has to worry about, per se. Not really, anyways - you'd just want to look at a few duplicates of spells (e.g. the divine and arcane versions of Resist Elements) and make sure that they're in the right order. The text that you quoted there was more to do with IRR's duplicated resources than SR proper. I don't want IR's Arbane's Hastening ability stacking with SR's Haste, or Mazzy's Haste with standard Haste, or Improved Haste with standard Haste, or standard Haste with Oil of Speed, or...so it really just depends on how far you want to go with that. My suggestion, since I don't think you really want to work too much with IRR and IR itself is currently in a state of...uncalm, to say the least, is to probably to just have SR's spell stacking concern itself with only SR for the time being, which is much simpler. I think the one you'd especially want to look at are the two copies of Storm Shield - that one could've been my fault (perhaps I accidentally hit the "order" button in DLTCEP by accident at some point), but it's worth checking to make sure anyways. When I looked at it, the self-protection came in the middle of the spell, when it definitely should've been at the end.

 

As for the opcodes themselves, yeah, that sounds about right. Although, um...now I wonder: how does SR, for EE games, determine what is supposed to be a nonstacking opcode (e.g. Haste protecting against, say, IR's dvhaste) vs. a genuine protect against another spell opcode (e.g. Improved Haste protecting against Slow...when it's also protecting against other forms of Haste in the same effect stack) if they aren't the same spells?

Edited October 19, 2018 by Bartimaeus