Bartimaeus

1. I don't believe it's specific to SCS. The AI can see invisible creatures when it has opcode 193 applied to it (exactly how it behaves as a result of being able to do so...may not always be consistent, but it can). This creates an awkward situation where the player expects Non-Detection to protect them from, well, divination spells used to detect invisible creatures as per the current description of the spell, and are not actually afforded that protection; meanwhile, if the AI casts the combination of Invisibility + Non-Detection, they are protected from the player's divination spells. So not only is the AI's behavior/reaction erratic at best, but the AI gets an advantage out of it that the player can't. I find this rather untenable and certainly very undesirable on both grounds, especially after having just tested BG2EE and being instantly smashed to bits by cheating AI. 2. In my opinion, Non-Detection should provide protection from detection. That is, after all, the name of the spell, and presumably what Demivrgvs intended when he left it called "Non-Detection" (as opposed to something like "Protect Your Other Non-Invisibility Illusionary Protections"...well, hopefully something much more concise and fitting than that) while specifically having it immunize the recipient against the effects of invisibility dispellers such as True Seeing and Detect Invisibility (not to mention having the description of Non-Detection explicitly say "[Non-Detection] makes the creature touched undetectable by divination spells such as Detect Invisibility, Oracle, and True Seeing, or by a thief's Detect Illusion abilities"). I do not personally know how much Demivrgvs tested opcode 193 or whether he was aware of it behaving unequally between player and AI (or if he believed it to be acceptable or not), but given that he is not presently here to argue for its case anyways, it truthfully matters very little to me at this exact moment. Though if someone wants to dig up his argument for it, if it survives to the present day somewhere publicly readable, then I would be very interested to read it. 3. However, SCS assumes installations with SR (and SRR) will require either Detect Invisibility or True Seeing to cast through improved invisibility (and does not use its normal "anti-magic spells can always pierce improved invisibility" setup), and thus I feel that my hands are tied, given the obvious importance of SCS in the BG modding ecosystem. Furthermore, in order to fix at least the AI being able to "cheat" seeing through your invisibility when the player cannot do the same to them, I would have to let Detect Invisibility and True Seeing actually dispel invisibility (but only invisibility, not improved invisibility or anything else!), which is not only a bit annoying to implement, but is also a change of how these spells function. The current situation is that only AI spellcasters who cast Detect Invisibility or True Seeing can see through invisibility, but if I were to attempt to make it 'fair' for both player and AI, Detect Invisibility and True Seeing (and maybe Invisibility Purge?) would actually reveal those invisible characters to everyone else. That's quite a bit of a change to mull over. And good lord, how the hell am I supposed to explain these mechanics in the descriptions of these spells so that players can have a possibility of actually understanding how any of this works? They're already pretty convoluted as it is, and apparently I need to add even more! 4. In effect, I think using opcode 193 is just kind of a bad idea and would prefer the SCS/EE approach at this point, but I cannot really do much about it unless the official version of SR decides to make a change as well, which I do not believe is going to happen. 5. ...Maybe it's possible to do a mass-scan/patch of all .bcs files looking for that particular condition and replacing it with the non-SR equivalent, but that's certainly not an ideal place to be. A lot of people use automated installs these days, and requiring people to add another random mini-mod way after SR/R is installed to fix broken behavior is really just not fantastic, even if it's not my fault. And that's assuming it's always going to be easy to replace, which I am not sure of either. I did try that, and anyone who's played SR/R should have run into this exact situation at some point and seen what happens. Even so, there is a very crucial difference between asking about how something works (i.e. asking me to test it, or explain it if I already had)...versus leaping to wrong conclusions about something which wasn't being discussed (no big deal, we all make mistakes in communication, both when we ourselves write and when interpreting others!), then suggesting that I was the one at fault for misspeaking and leading them to those wrong conclusions (I was not), and then shifting the goalposts as if the first option, that they were just 'asking' that it be tested, was what had actually happened in the first place...all the while making snide comments about how I was the one having some kind of attitude issue here. No, sorry, the conversation started out perfectly harmless, and I tried to be as inoffensive as possible given the circumstances, but I've had quite enough at this point. This is the absolute last I'll say of the matter.

Yeah, that's what I'm finding out now. Well, this really seems to be a "you made your bed, now lie in it" kind of situation. From that OR, it looks like the issue applies to both Detect Invisibility and True Seeing? Which would mean I can't implement my secondary idea either. Well...if I want it to be fully fair and functional, I guess the only thing to do is have Non-Detection...you know, protect everything except for the invisibility/stealth state. Which is like, the complete opposite of what one would envision the spell as doing. Sigh.

Yup, your version has the wrong line endings (CRLF instead of LF). But if it's the fault of your Git client, then that's a relief, as I was about to turn into the Joker. Can you easily work around it? Not sure what I could do on my end anyways. Non-Detection would continue to shield Invisibility, Improved Invisibility, Mirror Image et al. from being dispelled until Non-Detection has been stripped, but True Seeing and Detect Invisibility would lose the "you can target a semi-invisible character with any spell" ability; instead, yeah, anti-magic spells would just always be able to target through the semi-invisible state. A few people have complained about enemy spellcasters already doing this when SCS is installed over the years, so it's quite possible that this is how SCS AI already operates (in that it assumes anti-magic spells should always penetrate the semi-invisible state and forces them to do so even if it shouldn't be possible), and if that's the case, then it really only just makes sense that the same ability should be given to the player. This would also make Non-Detection being a spell protection make way more sense than it currently does, as anti-magic spells which strip spell protections are the only spells given the unique "can target through the semi-invisible state", which makes them a natural counter to Non-Detection when it's a spell protection. I'm making an install right now to see if that's exactly what happens when opcode 193 isn't given by True Seeing/Detect Invisibility, though, just to be sure. If it's not, then a different idea will have to be used for sure. Even if it is how it works, it's not impossible that the function of Non-Detection could change to something better nonetheless, but I'm viewing the current way as too big of an issue to just let it be as-is. One quick-and-easy alternative would be to let True Seeing retain opcode 193, remove it from Detect Invisibility, and then just always have True Seeing strip the normal invisibility state regardless of Non-Detection (but letting Non-Detection protect everything else): that would at least make the system fully functional and fair.

Fixed, thanks! Did this actually full lock it out of scripted spellcasting, or just out of player-initiated spellcasting? Can't confirm, I just downloaded the live repository version, checked several .bcs files, and they all had the right line endings. I dropped the hobgoblin shaman script (spell_rev\spwi2##\dvhobsha.bcs) straight into my override, cast Monster Summoning II, and the shaman cast Resist Fear upon being summoned (which is what it's scripted to immediately do upon being summoned). Moved around, and all the hobgoblins automatically followed me. If none of that happens for you, could I have your dvhobsha.bcs so I can check it out? After re-reading my post, I just don't believe that I did. I'd be curious to see exactly what of was the key passage of issue in my recounting of events. My post specifically says my character cast Non-Detection and Invisibility (not Improved Invisibility, not Shadow Door) upon themselves, and that I had them stand next to Brother Pol with no mention of any hostile actions. Even if I had made any unmentioned hostile actions, again, only Non-Detection and Invisibility. I believe that would be because I wasn't speaking to you and it wasn't relevant to whom I was nor the issue at hand. The post to which I was responding to: The issue at hand being, "[...] the mage will cast Detect Invisibility or True Seeing, they'll gain the ability to see through invisibility, and they'll be able to target the invisible creature. Even if it's still fully invisible to everyone else. Whether it has Non-Detection active or not. Nothing protects against opcode 193, because it doesn't act on the creature being observed at all. For as long as that effect is active, that mage is equivalent to a creature that can naturally see through invisibility." The whole conversation gives some helpful context on what exactly was being tested here. But all of this is kind of irrelevant for SRR, which will be ejecting opcode 193 wholesale after I do some testing of SCS+SR behavior to ensure that the AI can dispel Non-Detection with anti-magic spells even when improved invisibility is active. If it can't, then some other measure will have to be taken.

It's a spell protection in both SR and SRR. 1. It cannot be remedied for the EEs, that opcode is hardcoded behavior for both games. 2. He could not or at least did not. After Brother Pol cast True Seeing, my sorcerer stood right next to him with nothing but Non-Detection and Invisibility active and he did not directly act against my character in any way. 3. Improved Invisibility (the spell) gives both invisibility and improved invisibility. "Invisibility" is the invisible state that breaks when you do hostile actions (and some non-hostile actions, like talking), "improved invisibility" is the semi-invisible state that makes it so you can't be targeted by spellcasting. Wizard Eye is a 4th level spell, and that's effectively what you turn your character into if you cast Invisibility and Non-Detection on yourself and then proceed to perform zero hostile actions. I guess if the recipient is a cleric, they can cast healing spells with zero fear of reprisal, but honestly, not really seeing what's so terribly powerful about it. Oh no, they can do that thing they could already do with a 1st level Sanctuary, except for longer if you decide to use a 3rd and 2nd level spell on it! I think Non-Detection would just need to not explicitly give immunity (opcode 206) against the pulsing sub-spell of True Seeing like it currently does.

No, sorry, I don't mess around with sectypes as such willy-nilly. It's less of an issue of "can it be done?" (it would be very easy), and more of an issue "should it be done?". To which if the answer is "if the AI can't figure out how to adjust accordingly, then no". I could swear I had tested this rather extensively in oBG2 against a few different casters at least a couple of times now. I would get them hostile and get them to cast True Seeing while my invisible + Non-Detection character was standing right next to them, and they would largely ignore my character. I say "largely", because I think they would sometimes do weird stuff like suddenly try to melee my character, but then freeze up like they wanted to cast a spell against me but couldn't. If there was another character of mine on screen that they could target, they would go straight for them instead. What SR wanted to accomplish with its systems seemed to effectively work out, even if it looked a little erratic. So I just tested this again against the Vigil Knights at the foot of Watcher's Keep...except this time, I did it with both oBG2 and BG2EE. Same mod install: ~SPELL_REV/SETUP-SPELL_REV.TP2~ #0 #0 // Spell Revisions: v4 (Revised v1.3.927) ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ #0 #5900 // Initialise AI components (required for all tactical and AI components): 34.3 ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ #0 #6000 // Smarter general AI: 34.3 ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ #0 #6030 // Smarter Mages: 34.3 The spellbooks for each install, of course, will be different, because SCS creates the spellbooks for spellcasters at install time. However, for both installs, Brother Pol got True Seeing in his spellbook, so it happens to work out here. In both games, I had my sorcerer cast Non-Detection and Invisibility upon themselves, then had Jan Jansen go attack the Vigil Knights, then quickly cast invisibility upon himself. In both games, Brother Pol casts True Seeing and Jan Jansen is summarily murdered by the Vigil Knights in mere moments. However, this is where the similarities stop: in BG2EE, Brother Pol then kills my sorcerer with an immediate casting of Finger of Death; in oBG2, he casts a Timestop, then a Mantle, and then just...stands there. He doesn't do anything else, and his True Seeing wears off with not a single hostile action made against my character who's standing right next to him. In my experience, SCS AI doesn't cast spells like Timestop and Mantle unless they see hostiles, so...it's like he knows I'm there, but for some reason can't do anything about it until I actually reveal myself. I think the implementation of opcode 193, or the way the AI reacts to it, must be somewhat different between oBG2 and BG2EE, because each time I've tested it in oBG2 (and I think this is the third time in the history of this thread), it seems to work O.K., but him immediately dusting my character in BG2EE would sure seem to be a problem. In any case, it would seem wise for SR to get rid of this whole silly system where opcode 193 is used if A. SCS doesn't really want to gel with it in the first place and prefers "you and the AI can just cast anti-magic spells through improved invisibility whenever", and B. the AI can fully abuse it (at least in the EEs) but the player can't. Maybe what SR wants to do works fine in the original engine, but it seems most albeit not all current players prefer the EEs, so that's kind of important. Also, on a personal level, C. I was never very attached to this whole system in the first place, and in fact, close to the beginning of this thread when I was starting SRR, I implemented and strongly argued for the SCS/EE system of anti-magic spells always penetrating improved invisibility. subtledoctor talked me out of it and into more thoroughly testing how SR wanted to do it, where my tests seemed to conclude that yes, it did seem to more or less work how it was intended...at least on my preferred game engine, which is oBG2. True Seeing: It already lasts 1 turn, and also, isn't True Seeing the main anti-illusory spell that the player uses once they have access to it? If you have multiple sources of True Seeing (e.g. an Inquisitor and a mage), maybe you have the mage memorize Detect Invisibility instead, but otherwise I thought True Seeing was pretty much always the player go-to. Like, who's casting Detect Illusion? Maybe Oracle in certain situations, but True Seeing getting rid of invisibility, improved invisibility, Mirror Image, Blur, and Reflected Image every 3 seconds for an entire turn is hard to beat. Non-Detection: I tend to go mage-heavy for my party builds, so it being difficult to do away with Non-Detection can be annoying: if I'm trying to overwhelm a mage that has ND+II, it often means having to have Detect Invisibility or True Seeing running on each spellcaster, which...that's a round of spellcasting each for them, especially what with Detect Invisibility only lasting 5 rounds and True Seeing 1 turn, combined with possibly getting dispelled...it can be a real pain in the butt to get everyone on the same page.

In SR, invisibility (opcode 20 type 0) is protected by Non-Detection (note: when referring to "Non-Detection" in the context of SR, I mean the spell, not the nigh useless opcode). A creature which is invisible and affected by Non-Detection should be completely undetectable by divination spells such as Detect Invisibility - SCS AI may "hear" your character walking around and cast Detect Invisibility or True Seeing to try to detect you, but it should fail to reveal your character, and you should remain invisible and thus perfectly safe. The exceptions to this are creatures which naturally see through all invisibility, such as mindflayers and liches, where no amount of invisibility, improved invisibility, or Non-Detection will ever help you even an iota against them. Improved invisibility (opcode 20 type 1), on the other hand, is only protected from being dispelled by e.g. True Seeing, but if you are no longer invisible (opcode 20 type 0), then anyone currently running Detect Invisibility/True Seeing is allowed to target you through your improved invisibility, as you have already been revealed/detected. Non-Detection should perfectly protect the invisibility state, but it does not perfectly protect the improved invisibility state - it just prevents it from being actually dispelled which would allow all spellcasters to directly target you with spellcasting. Having Non-Detection protect improved invisibility from being dispelled makes it so that only spellcasters which have Detect Invisibility/True Seeing currently running are able to directly target you with spellcasting. SR (and SRR) do not have any spells which can always pierce improved invisibility - if the EEs made anti-magic spells able to do so, then SR goes right ahead and reverses it when it does its overwrites. Well, SRR gives the option of allowing anti-magic spells to do so for players that got used to playing with that and preferred it, but it's defaulted to off for a reason. It is expected that you use Detect Invisibility and True Seeing to counter enemies who are protected by Non-Detection and some source of improved invisibility. So in SR, whether Non-Detection is a specific protection or a spell protection, the process would be much the same: you wait for the enemy who has ND+II to reveal themselves*, you have your mage cast either Detect Invisibility or True Seeing, and then using the same mage cast an anti-magic spell that strips them of their Non-Detection, thus allowing their improved invisibility to be stripped by True Seeing/Oracle/Detect Illusion/Invisibility Purge. Whether that anti-magic spell is Breach or Secret Word doesn't really make any material difference for breaking the ND+II combo, except that if Non-Detection were a specific protection and not a spell protection, Breach would also dispel the rest of their protections in the same step. Though if it's Breach, there's also the possibility of it being protected by e.g. Spell Deflection (and Dispelling Screen); if it's instead Secret Word (or similar) that you have to use, it may dispel some other spell protection entirely and leave their ND+II combo protected until you can get another one off. It doesn't help here that anti-magic spells always target the highest level spell protections, which allows Non-Detection to be "protected" under virtually every other spell protection, as only Minor Spell Deflection is of lower or equal level, which can leave you up crap creek if you're desperately trying to dispel Non-Detection so that your other spellcasters can dogpile them but you keep dispelling other spell protections like globes and spell deflections instead. Overall, I think Non-Detection being a specific protection would work better for reducing how annoying the combo can be, but I think I have to stay in lockstep with the official version of SR here. *Or if you know where they're standing because of special visual effects (or you saw them before their ND+II combo went up?), I guess you could try either a Remove Magic or Spell Thrust to pre-empt them, but that's kind of cheating. Whatever, though - pretend that you "heard" them walking or casting spells just like SCS gives the AI a chance of doing, I guess.

I remember it being a specific protection in SR, but I think that was back in the days of anti-magic spells always piercing through improved invisibility. But I don't quite understand what you mean with regards to Non-Detection preventing Breach. Whether it's a specific protection or a spell protection, one still has to use Detect Invisibility / True Seeing before you can cast either Secret Word or Breach (depending on which sectype you set it as) against an Improved Invisibility + Non-Detection character to be able to strip them of their improved invisiblity, so I don't see how it really changes anything in that regard. But Breach dispelling it instead means one less layer of spell protections, which can make a bit of a difference against enemy spellcasters who can have 3 or 4 layers of spell protections.

Yeah, Mind Blank is not a spell protection but a specific protection - removed by Breach and a general dispel, but nothing else. Fixed both that and the Pierce Shield issues, thank you! And yes, Non-Detection is supposed to be a spell protection...though it wasn't always this way, but I didn't personally hear the specific reasoning for it at the time that it happened.

If it were power level 6, it would bypass Minor Spell Deflection completely. From a mechanical standpoint, I'm not a big fan of 3rd level AoE dispel which isn't supposed to be guaranteed to work counting as level 6 (Dispel Magic) while a 5th level single target dispel which is guaranteed to work only counts as level 5 (Breach). It seems...hacky and disproportionate to me. I knew hyperbole would be my downfall one day.

I decided to test it. Had Jan cast Spell Deflection, used up its charges until it only had 1 left, then cast Dispelling Screen. Had my character cast Dispel Magic at him, it used up the Spell Deflection first, but the Dispelling Screen stayed put and it took an additional Dispel Magic to dissipate it. Seems to work the same way if you instead cast Dispelling Screen first: it isn't dissipated until the Spell Deflection is all used up.

I completely forgot about Dispelling Screen with regards to this theoretical tweak. Well, Dispelling Screen applies to everybody and Spell Deflection to just one character, I suppose, so I guess the conflict wouldn't be too terrible...

Well, what am I doing designing this for, then? Go use that! ...I'm assuming it's because you specifically want this one change and not everything else that his component does. The biggest problem I have with this idea is that SCS will have no possibility of knowing that Dispel/Remove Magic will be deflected and thus it will try to use Remove Magic against the player to not much avail (though at least each cast will drain charges!), otherwise I think I'd probably use this tweak myself (...and also, I'd be much more motivated to get it working). But if SD has already designed and implemented this exact idea already (and to be sure, he is an infinitely better coder than I am), I am a little loathe to spend the hours necessary to implement and troubleshoot the danged thing with my meager and pained skills.

As currently designed, yes. With my theoretical re-design I was just brainstorming that I've explained below that I'm putting here just in case I fail to get around to it or if I think of some kind of problem with doing this, no: Dispel Magic et al.: 1. Base spell with projectile that has no power level, casts two subspells (opcode 146) 2. 1st subspell is the actual dispel, has no projectile or power level 3. 2nd subspell has some kind of placebo effect (THAC0 or AC bonus of 0 for duration 0?), no projectile, power level of 3 4. AoE spell deflection component targets the first subspell but not the base spell or 2nd subspell Unnecessary, as splitting Dispel Magic et al. in this fashion has incidentally already made it subject to the AoE spell deflection component whether the player likes it or not - perhaps this optional tweak should actually be in that component and not the main component? Spell Deflection et al.: 1. Clone opcode from opcode 201 (spell deflection) and opcode 200 (spell turning) with a parameter 1 of 3 (level 3) for all existing .spls 2. New opcodes will be 206 (protection from spell) specifying 1st subspell of Dispel Magic et al.; clone for as many Dispel/Remove Magics used (currently 5 in SRR) Actual Effect: Spell Deflection et al. will give blanket protect against 1st subspell (i.e. the actual dispel) of Dispel Magic et al., but not against the base spell or 2nd subspell, thus allowing the 2nd subspell to drain charges as per normal; M/GoI's behavior with regards to dispelling will then be determined by the setting used for dispel_globes (whose effects are set either to dispellable, not dispellable, or not dispellable + blanket protection against Dispel Magic et al.); creatures immune to spells of 3rd level or higher will be immune to the useless 2nd subspell, but not the base spell or 1st subspell (i.e. the actual dispel), thus making them vulnerable to dispelling...though such creatures will likely display "spell ineffective" even when the dispel actually works as a result of the 2nd subspell also hitting them (acceptable minor cosmetic issue...somewhat avoidable with creature-targeted immunity .effs, but probably not worth the trouble?).

As mentioned earlier, that optional tweak changes only Dispel Magic and Remove Magic. The tweak simply sets their power levels set to 3, which makes them subject to the various forms of spell deflections...and necessarily the globes as well, as they use the same power level mechanic to determine what they protect against. There's nothing to restore, as whether you use that tweak or not, all the spell deflection and globe .spl files come out exactly the same. If you can give me a few days, I'll try to figure and test out a workaround.

Oh, right! Well, that was incidentally fixed now as well, and I don't see any other spells where "School:" is listed.

Meaning, it says a -10 penalty instead of a -4 penalty? I just simplified its installation, which should hopefully fix the issue. The last time I tested, which was not v34 of SCS but maybe v33, SCS seemed to mostly work with SR's Improved Invisibility / Non-Detection / Detect Invisibility setup...but it could act goofy and do things in not quite the right order. I don't think SCS would have any way to determine whether or not that tweak, which is disabled by default for a reason, is enabled. However, that particular tweak is actually intended to just be a mild cheat for players who just want the whole problem simplified and be able to cast anti-magic spells without restriction like they could in the past - it was basically an option I added by 'popular demand' as a result of the number of players very frustrated with the improved invisibility mechanics over the years, so I am okay if SCS does not adjust its behavior any for it. Alrighty, thank you! I think there are a few other spells in SR/R that could use some correction...

My gosh, I'm so sorry, and thank you so much. What's the best way to be doing these look-ups for portrait icon strings so somebody doesn't have to pester you or someone else to figure these out?

This is more or less how SR does it: STRING_SET ~13070~ @565 // Change portrait icon from Fire Shield (Blue) to Acid Sheath Just a straight override of the currently existing string in dialog.tlk. At least, this is how SR usually does it, but this particular one is disabled in the base SR package...probably because somebody noticed it didn't work right for the EE games and didn't want 13070, whatever it happens to be in the EE games, to be overwritten with "Mestil's Acid Sheath". But you see, I am lord king of the bozos, so I re-enabled it...though I was wise enough to at least put a check around it. ACTION_IF (GAME_IS ~bg2 tob bgt bg2ee eet~ AND NOT GAME_IS ~tutu tutu_totsc bgee~) BEGIN STRING_SET ~13070~ @565 // Change portrait icon from Fire Shield (Blue) to Acid Sheath END BG2 and BG2EE strings typically match up, so I suppose I didn't think to actually check BG2EE before I re-enabled it, and I never bothered to go figure out what BG1EE's string was. Lord king of the bozos indeed. Thank you!

More importantly, what I wish to know is whether SCS is aware that Fire Shield/Acid Sheath are not breachable when SR is installed. If it is not, I would just set them back to breachable...but if it is, then no, because I'm not a fan of optional tweaks like this that introduce broken/sub-optimal behavior in ways that the player cannot reasonably expect when they enable an optional tweak like this. This reminds me that I never figured out if SCS AI can use targetable Chant or not...sigh. That's another thing that if I knew the answer, I might remove entirely if it doesn't work how I'd like.

Apparently, it does...both ways, too. I didn't think it would, but I dispelled Jan Jansen successfully six times in a row...and then I put on him a ring of +20 caster level, and suddenly the next six didn't work. That actually probably makes your idea of having Dispelling Screen increase your effective level against dispelling possible albeit not easy to implement. Some sort of conditional duration 0 caster level increase applied by Dispel Magic when it hits you that dissipates right after. The former gets updated in oBG2, but the string location must be different for EE games since it doesn't get updated there. For the latter, I don't think anybody thought to bother. Interestingly, without SR, the Fire Shields are actually "Specific Protections", so they do get dispelled by Breach. Although I can see the argument that they don't directly protect the caster, I think I would've left them as breachable myself.

I don't think that idea is possible, but I don't know for sure. The only remotely close thing I can think of in implementation is @subtledoctor's Protection from Petrification evasion tweak, which grants two saving throws against petrification which could theoretically be used for Dispel/Remove Magic here as well...but I think you'd have to use a saving throw version of Dispel/Remove Magic for that to even work. I don't know how you would work such an idea with the default level mechanic of Dispel Magic.

What you're saying makes sense and I always thought the overlap between these options was rather awkward myself, but the path to do it would be weird. The way the "spell_protections" tweak works is that it actually sets a power level for the different Dispel/Remove Magics, so that when they hit e.g. a Spell Deflection, Spell Deflection absorbs it as if it were any other 3rd level spell (such as a Fireball), depleting charges. By necessity, this also makes M/GoI absorb it as well, since those two also work on the basis of power levels. Maybe...if Dispel/Remove Magic was broken into two subspells, one that doesn't do anything but has a power level set so that it can drain charges of e.g. Spell Deflection, and then another that has the actual effects of Dispel/Remove but which Spell Deflection et al. specifically grant immunity against, thereby protecting you from the dispel until your Spell Deflection (or whatever) has been used up. Globes would thus protect against the (useless) charge-depleting subspell, but against the actual dispel. I suppose that would work, and I don't...think anything horrible would result elsewhere. Oh, except it wouldn't work correctly for non-EE games, since the immunity to Dispel/Remove Magic would have no way of dissipating itself, thus continuing to grant you immunity to them even after your Spell Deflection (or other similar spell) has been used up. At least, I think that's how Spell Deflection works in the EEs. Maybe this would be best as a fourth option. I reinstalled SRR approximately 30 times, and that's not really an exaggeration, trying to figure out what was going on. It's definitely not very fun.

@NdranC I reinstalled with your settings.ini, and everything was still fine. Hmm, well, I suppose this is one of those times I have to actually download the live repository version instead of using my own files, just on the off-chance something weird with GitHub has transpired...My program that manages my GitHub repositories, SmartGit, says that my directories are the same, but it wouldn't be the first time that it hasn't been entirely truthful with me. And...would you look at that? Hmph. Fixed it, and redownloading master and reinstalling...confirms that it now works again. Sorry about that.

I just installed the latest version of SRR with the "blindness" switch set to 1, and it was Blindness both in appearance... ...and effects, as I was able to blind my own (ToB-leveled) character after casting it a handful of times. Setting the switch back to 0 and reinstalling, it is fully Obscuring Mist: So...what mods have made changes to your SPWI106.spl?