SR vs megamod installations

[Graion Dilach]

I've looked at it from a megamod install POV and it could play better than how it currently is:

- deletes and overwrites all changes in hidespl.2da (this affects SoD and the EE Fixpack, EET moves the SoD additional spells trio outside of the exposed spell slots range, so it's safe until one doesn't combine it wiith the fixpack)

- wastes the spellslot of Stone to Flesh and the level 5 cure wounds (maybe even more than those)

- breaks immersion with the summons being statted (but this one is only cosmetics).

I've also had a few test installations with IWDification. Note that because of the hidespl messup, all my installs were tested with SR installed first. I also would consider SR as a pure overwrite-mod, being installed early. So the following aren't directly issues within SR.

 - IWDification detects the level 6 SR elemental summons, which leads to it only installing the level 5 Conjure Water Elemental spell (there's a separate elemental_summoning function in the post-install, which generates the L6 variants). However, this leads to an install without a level 6 Water Elemental spell, which then throw SCS off, because it expects both the level 5 and level 6 Conjure Water Elemental spells in it's wizard spellbook using the IWD lists (if you had a Not_found error during Smarter Mages, this is the cause - thanks again @Bozerg for pointing out this issue on Discord last weekend).

- IWDification will partially overwrites monster/animal summonings, so yeah, that's also bad. It's not as bad as the first two though.

The first two are legitimate issues. I've started slowly writing tweaks to iron out the compat issues, but I'd like to see them acknowledged.

Edited May 31, 2023 by Graion Dilach

[subtledoctor]

On 5/31/2023 at 12:14 PM, Graion Dilach said:

I also would consider SR as a pure overwrite-mod, being installed early.

SR was specifically and intentionally a pure overwrite mod, for a very long time. We’ve work to make it less so, but I guess Rome wasn’t built in a day. 

The Hidespl thing should be fairly easy to fix. (Not that I have time these days.)

[grodrigues]

On 5/31/2023 at 5:14 PM, Graion Dilach said:

deletes and overwrites all changes in hidespl.2da (this affects SoD and the EE Fixpack, EET moves the SoD additional spells trio outside of the exposed spell slots range, so it's safe until one doesn't combine it wiith the fixpack)

Yeah, SR just straight overrides hidespl to hide the spells it deprecates and/or moves to some other level. Bad boy.

On 5/31/2023 at 5:14 PM, Graion Dilach said:

The first two are legitimate issues. I've started slowly writing tweaks to iron out the compat issues, but I'd like to see them acknowledged.

What do you mean by "waste? Do you mean a slot in the spell namespace (say "spwi") that was before used and is now not used? If so, why exactly is that a problem?

On 5/31/2023 at 5:14 PM, Graion Dilach said:

breaks immersion with the summons being statted (but this one is only cosmetics).

This one, we will have to disagree on.

On 5/31/2023 at 5:14 PM, Graion Dilach said:

Note that because of the hidespl messup, all my installs were tested with SR installed first. I also would consider SR as a pure overwrite-mod, being installed early.

Yes, that is also my explicit recommendation in the SR frontpage readme (which reminds me: fix the markdown footnotes).

On 5/31/2023 at 5:14 PM, Graion Dilach said:

I've started slowly writing tweaks to iron out the compat issues, but I'd like to see them acknowledged.

Patches are always welcomed.

[Graion Dilach]

1 hour ago, grodrigues said:

What do you mean by "waste? Do you mean a slot in the spell namespace (say "spwi") that was before used and is now not used? If so, why exactly is that a problem?

Other mods can still introduce newer spells to the system after SR. Although, on a review, IWDification also wastes a few slots, so that's probably ain't as big of a deal. (Especially if newer mods try to rely on ClassSpellTool where possible.)

Although ClassSpellTool isn't a solution since it's unavailable to classic and on platforms where UI modification isn't available. It also isn't prepared against duplicate checks. But yeah, this can be ignored.

1 hour ago, grodrigues said:

This one, we will have to disagree on.

Actually, even if we put my personal low opinion on the format away, we still can't. But description inconsistency within a megamod installation is just part of a bigger problem.

The only aspect SR documents right for mod compatibility is it's description format. (This is actually cool.) This allows other mods to prepare against it if they are installed after and willing to support it via a detection code to adhere their own spells to this format. If - as you say it - SR is an override mod, then it should even come before quest mods, if those quest mods introduce spells within their main component (A7-ToTLM, CtB, SoS, DSotSC-BGEE - the Trilogy version separates it's spells to components, which will leave SR spells as-is, so it's only compat issue against SR I'm aware of is that it doesn't follow the description format for it's unique ones -, Test Your Mettle, SoA, list goes on). But the other systematic changes it does (like, for example, petrification) are undocumented. If a quest mod introduces new creature effects or spells which would interact with a system SR changed, would SR explain the modder what to do? Or whose job is to ensure compatibility for a case like this?

Why I can bring up petrification as an example because this already had a scenario: when @subtledoctor brought up that klatu's "Drop Inventory on Petrification" component isn't needed on SR, I read the documentations and I couldn't found out if the basilisk gazes are handled within the mod to confirm it.

With this in mind, I am even baffled at how often SR comes up within megamod installations, when I see no reason why I shouldn't treat it as a ticking bomb waiting to cause problems down the line. (It also doesn't help that SR often comes up with the implication of IR being also installed, but this relationship is also informal. Also note that the shipped HTML documentation within the mod still refers to Spell Immunity.)

SR isn't clear enough and I don't know how to proceed on this. If SR intends to remain an override mod, then it only needs better documentation to explain questmods what to do to play nicely with SR's system. If SR intends to come after questmods, then it should mention which questmods are handled or what it assumes from these questmods. I'm williing to participate in updating other mods if SR chooses the former, but first this should be clarified. (DSotSC-Trilogy plays semi-nicely because I wrote the code to ensure it.)

EDIT: Actually, SR's documentation format ignores one of the stylistic choice of the EEs: dropping the fullcaps. SR listing summon stats with fullcaps should be changed to adhere here.

Edited June 3, 2023 by Graion Dilach

[grodrigues]

2 hours ago, Graion Dilach said:

But the other systematic changes it does (like, for example, petrification) are undocumented. If a quest mod introduces new creature effects or spells which would interact with a system SR changed, would SR explain the modder what to do? Or whose job is to ensure compatibility for a case like this?

Agreed. The problem here is that SR does not give mods that come after it the tools to patch and adapt. The same general problem applies to IR. From the top of my head, the more important cases are:

- Insects

- Petrification

- Dispel

- Imprisonment

- Invis and True Sight interactions

- The finer points of spell protections

As the current maintainer, and someone that has tried to wade into say, the dispel code, all I can say is that this is not an easy task, at least not for me.

I opened up a branch to patch hidespl.2da instead of overriding -- see Patching hidespl.2da instead of overriding. Still in draft and not finished.

Edited June 3, 2023 by grodrigues
Add imprisonment

[grodrigues]

Missed this:

2 hours ago, Graion Dilach said:

Actually, even if we put my personal low opinion on the format away, we still can't. But description inconsistency within a megamod installation is just part of a bigger problem.

My "agree to disagree" reply was just for the "immersion" part. Compatibility is of course a problem.

[subtledoctor]

Lobbing a lot of very vague broadsides here (as usual?), and it honestly doesn’t seem helpful. What good is throwing shade?? Better to make specific, iterative improvements. @grodrigues has been doing just that, and I and Bart and Mike and Grammarsalad have tried to help, along with others I am surely forgetting. Why not actually help, you certainly have the skills. 

2 hours ago, Graion Dilach said:

If a quest mod introduces new creature effects or spells which would interact with a system SR changed, would SR explain the modder what to do? Or whose job is to ensure compatibility for a case like this?

I honestly don’t see a big problem here? Allowing for the fact that I don’t expect perfection, which may be the difference. If other mods want to apply petrification or dispel etc. like the normal spells, they can cast or clone the normal spells; if they want to apply petrification according to their own specific vision, they can do that and SR won’t interfere. As an example, the Imoen Is Stone mod had a bit of interference with SR, but I modified that mod to make better assumptions and now they play nicely. 

SR can be improved in this regard, yes, but we are in fact making these iterative improvements. That doesn’t absolve other mods of the responsibility to use best practices.

Honestly this sounds like my kids in the car asking why we haven’t arrived yet. We’re on the road; we’re moving in the right direction. What more do you want?

Edited June 3, 2023 by subtledoctor

[Graion Dilach]

I've mentioned my problem on this: If SR should be installed before quest mods, then the compat code goes to the quest mods. If SR should come after quest mods, then SR is where the compat code goes to. There's no clear guidelines on the order.

It''s not like the SCS/IWDification IWD spells, where this is straightforward, because their changes to the system aren't disruptive and those components only need to be mixed into among the questmods, because they are better maintained than the IWD spells within the individual questmods.

I opened this topic exactly to see how could this be resolved and I intended to help. But when i get a response like that - even though you did answer my main question if I interpret your backhanded response as "yes, SR should come before questmods" -, I'm not even sure I want to deal with you in this.

I'm more willing to work with people who don't take offense at me initating a conversation.

[grodrigues]

1 hour ago, Graion Dilach said:

I've mentioned my problem on this: If SR should be installed before quest mods, then the compat code goes to the quest mods. If SR should come after quest mods, then SR is where the compat code goes to. There's no clear guidelines on the order.

I do not if you are addressing me or subtledoctor, but if it is me, per the readme as of 4.19rc3: "SR's main component does wholesale spell replacement, so it should be installed relatively early in the install order, certainly before Tweaks Anthology and SCS. On the other hand the "Update NPC spellbooks" component should be installed after all NPC mods."

Should it be more clear? Feel free to make any suggestions, I will patch them in myself.

Any changes to the readme notwithstanding, everything I said earlier stands.

Edited June 3, 2023 by grodrigues
Added clarification

[Graion Dilach]

14 minutes ago, grodrigues said:

Should it be more clear? Feel free to make any suggestions, I will patch them in myself.

... It should, but I don't know the mod enough to suggest how.

Mods which add spells tend to come after quest/area addition mods, which allows the spell mod to add it's own scrolls to the new area shops, based on tying their scrolls to the availability of a vanilla spell scroll. (This is what IWDification and MiH does, I should propose that for DSotSC-Trilogy's spell-adding components as well.)

If SR is an override mod, then it should be before the quest mods, so it cannot afford this for it's new spells. In which case quest mods need to be updated to add SR scrolls where they should.

You are the maintainers, you should know better what is the intention here, should other mods attempt to follow SR, or SR would adhere to them and how far are you willing to go on this front. I don't understand why it's so hard to see where I'm coming from. I value consistency.

23 minutes ago, grodrigues said:

Any changes to the readme notwithstanding, everything I said earlier stands.

I can accept that reverting to the original description style is out of scope, but changing the creature stats within the EE descriptions to CamelCase over FULLCASE should be still treated as an issue, because the EEs did away from the FULLCASE everywhere (like with their usage of op319, or lowercasing the dice abbreviation in damages).

[subtledoctor]

4 hours ago, Graion Dilach said:

opened this topic exactly to see how could this be resolved and I intended to help

Don’t look for excuses to be unhelpful  What is the point of that? Help or don’t, it’s your choice and cannot be blamed on anyone else.

I still don’t see what the specific issue is. I’ve always always installed SR after most quest mods, even when it operated completely by overwriting. Now SR does much less overwriting so this is even more appropriate. That’s the recommendation, so whatever issues you find can comfortably assume that.

Coming early in the order doesn’t absolve mods from considering compatibility. Every quest mod can’t assume spell mods will jump to adapting to whatever the quest mods add. So quest mods should consider, how am I using this spell? What might tweak mods do to this spell and how can I shield my mod from being unintentionally altered? 

Again, I’m not clear on what needs addressing. Rereading the OP:

— Hidespl handling needs to be imoroved; is being addressed. 

— “wastes a slot” - no, this is handled this way specifically to preserve compatibility with other mods. If you have suggestions for how to handle this better, by all means give them, nobody is married to the current implementation

— summoning spell descriptions - eh, is a matter of taste IMHO. 

— Recommended install order - now you have it. 

Edited June 3, 2023 by subtledoctor

[grodrigues]

Patch to patch hidespl.2da is in. It ended up being a rather substantial patch; tested only install and in-game in bg2ee, not in eet, so do complain if something is not working. No tesing in iwdee, as I do not have the opportunity to test it right now and there is the question of exactly what spells to hide as well -- for now the answer is "same as in bg2ee".