morpheus562

@Bartimaeus @subtledoctor No luck updating SCS Non-Detection (DWSW310.SPL) either. I ran multiple tests and removed opcode 69 (no positive results), then removed scripting state opcode 282 (still no positive results).

Tome and Blood was my very last install, is that not correct? I'll get to testing here shortly and post what I find out.

You actually read my mind and those were going to be my first steps next morning. SCS does have a number of them, I think three. I am going to go into the character file tomorrow, go into the script, and grab the exact one being used by SCS. Will post more results tomorrow when I have them.

@Bartimaeus @subtledoctor Okay, so I ran a test against Kahrk in the Firewine Bridge, and scripts were not able to target him with spells. Per SCS and SRR, he casts the following spells: Mirror Images, Haste, Minor Globe of Invulnerability, Shield, Stoneskin, Non-Detection, and PfMW. Mods installed are: EET, IRR, SRR, SCS, and Tome and Blood w/ Invisibility & True Sight improvements. I expected, that with the spells present that my characters would cast Breach, then begin attacking. Instead my characters sat around because the spell targeting wasn't working and they were not able to damage Kahrk with physical weapons yet (as I scripted). I had to manually cast Breach to take down PfMW, and then they began attacking automatically via the scripts. Spells available to my characters to cast were: Spell Thrust, Secret Word, Breach, Pierce Magic, KWW, RRR, and Pierce Shield. I suspect with high certainty now that Non-Detection is causing some issues with script targeting of spells. Please note, no invisibility spells were cast, so there should be no reason why my characters did not target Kahrk with spells. I also manually deleted opcode 69 for testing and that also didn't remediate the issue. UPDATE 1: Uninstalled Tome and Blood, and attempts to target Kahrk with SRR non-detection were unsuccessful. Attempts were made both with and without opcode 69 with no success. UPDATE 2: Removed Modify Script State (282) and that had no effect either.

I should be able to run tests tonight to see how scripts react to SRs invisibility with Tome & Blood revised invisibility and True Sight installed. Fingers crossed it provides useful information.

The macro seems to be broken. It starts at index 118, increments to 119, then appends the new spellstate to 119 replacing DETECT_INVISIBILITY. It should increment to spellstate 184 on my splstate.ids file and append. UPDATE 1: The issue is my splstate.ids file is not in order and I need a macro to reorganize it. SCS has one, but its causing a hangup...hmm...more work to do. UPDATE 2: Learning occurred and it is now running as intended.

It's coming along. Testing right now that I'm getting the weidu component working right since I'm new to it. So far, beyond the pedantics of weidu, it's coming along well. I've seen, and learned on far more annoying things than weidu. I'm hoping I can get an install up of EET, SCS, IRR, SRR, and Tome & Blood tonight so I can get cracking at figuring out the invisibility thing. @subtledoctorI may reach out if I have any questions and if I'm able to determine a culprit. I'm really hoping your Revised Invisibility component does the trick. On another note, if/when I get this up and running, can g3 host my improved ai scripts and components?

That helps. Digging through DavidW's posts, it appears he uses the DEFENSE_MODIFIER stat set to 3 to track SR's WIZARD_ARMOR. I would only need to create a new spellstate for Dispel Screen and then adjust antimagic to be able to target through Improved Invisibility, then I should be good to go.

Hmm... Thank you. I'll have to dig into SCS to see if that was interacting at all. If not, then it might be an easy fix.

Is that something SCS already does for the spell or is that changed since SRR finishes installation for the secondary components after the SCS install?

If instead of making this an .ini option, I could add it with my weidu script install for SRR specific scripts? That way, my scripts can be installed after SRR is completed and make the change if the player wants.

You are most correct, and I am going to eat crow for going off of memory there. It is the STATS.ids file and not the SPLSTATE.ids file that I am referencing. My apologies for the confusion. I might have to give this a go on my end then to see what I can pull of in creating new stats, etc.

Here are the spell states created by detectable spells, which I believe SCS brings with it's install and references: https://gibberlings3.github.io/Documentation/readmes/readme-detectable_spells.html

Spell States are not binary, and Spell_Immunity goes from 0 (not active) up to 8 to represent each of the spell schools it blocks against. SCS checks these already, but 9 is not used. If memory serves, Mestil's Acid Sheath uses the same spell state as fire shield blue which is good. True Strike, Spell Shield, and Spell Deflection scripts also worked well. Mind Blank has its own spell state, so that works. I can't remember if Moment of Prescience had an issue, but would just need to verify the spell. Otherwise, the only other spell state needed would be for Mage Armor (and I can provide the line of weidu code to get that added if you wish).

I would do that if I still had SRR installed. I ended up just getting frustrated and rewrote everything for SCS and vanilla spells, but would love the opportunity to write updated ones for SRR if some of the items I mentioned are addressed. Spell states should be relatively easy to create/update. The non-detection and improved invisibility is going to take much more time and testing to really see what is going on and ascertaining the true culprit.

You're making me think back to my testing last summer . SCS always has II go up with ND with SRR installed, so technically wasn't able to compare. My scripts never cast Invisibility Purge or Detect Invisibility with ND up because even vanilla blocks that. If ND is not up, I would cast either of those to take down II, and I have 100% success rate in vanilla with that.

Let me clarify, in vanilla my scripts will identify a character has non-detection and improved invisibility up and immediately take it down using True Sight. From there, the characters will get to work stripping spell protections to take down pfmw if it's up. Otherwise, they will autoattack. 100% success rate, no fuss, spells are appropriately identified by the scripts and dealt with. With SRR, it gets wonky. Even with a character who cast true sight, something at the opcode level is preventing the scripts from targeting the enemy and taking down the appropriate spell protections even though the spells can be cast manually. The enemy is still not targetable by spells, from the scripts point if view, even though spells can be manually cast. Autoattack still works, but you can still attack an enemy with improved invisibility up so long as they revealed themselves. I want to be clear, there are no checks preventing spells being cast, they should 100% work; however, some other check in one of the opcodes is preventing it.

You could have Dispelling Screen set the SPELL_IMMUNITY spell state to 9, which is not currently being used. That would not require adding a new spell state and allows for proper tracking of the spell.

Generic AC buff is how Mage Armor has to be checked, but it's a bad way to check since the ac adjustment changes based on mage level. Scripts can easily be written to cast Mage Armor out of combat, but the issue is there is no way yet to check if the player has it active. Same goes with Dispelling Screen. I've done hours of testing SRR non-detection and improved invisibility, and it doesn't matter what conditions I have set within the scripts, enemies with those spells up will not be targeted by the scripts even if spells can be cast manually. Zero issues with targeting using vanilla spells. SRR, non-detection, and improved invisibility are the only outliers.

But from a player ai scripts perspective, there is no way to track either Mage Armor or Dispelling Screen. Both will continue to be cast by any scripts until all instances in the players spell books are used up. SCS gets around this on buffing the enemies through contingencies, and as you state, it doesn't matter as far as casting on enemies. The difficulty with targeting comes from non-detection and improved invisibility. The changes Bart mentioned should improve targeting in theory.

I think allowing anti-magic spells to target improved invisible creatures with non-detection active would go a long way to resolving the wonkiness surrounding it. I would make that standard instead of an ini tweak. Would you be able to create your own spell states and add it to the appropriate ids file? That way scripts can be written to effectively use SRR.

There would be many issues when trying to get complete compatability with SCS. For starters, many of the new spells (i.e. Dispelling Screen, Mage Armor, etc.) do not update any spell states, so it's impossible to detect if an enemy or player has the spell active. I think this would be a great first step for laying the groundwork for complete SCS compatability. Let's look closer at Dispelling Screen and why appropriate spell tracking is necessary. SCS currently checks if the SPELL_IMMUNITY spell state is set at 1 to see if SI: Abjuration is active to appropriately determine what spells to cast at the player. Dispelling Screen updates NOTHING! So SCS will cast spells assuming the player is not protected when in fact the player is. Additionally, there is no way to write player scripts to cast Dispelling Screen because the player will keep casting the spell until every instance of it in their spellbook is used up because there is no way for the script to detect if it's active. Simple solution would have Dispelling Screen update SPELL_IMMUNITY to 1 to mimic SI: Abjuration. This is just one example of many on why tracking spell states matters. The way detecting enemies with non-detection and improved invisibility is a complete mess. Something is going on at the opcode level preventing scripts from appropriately targeting enemies with this combo active, even when true sight is up by the player attempting to target the enemy. If players are having this issue with scripting, then SCS would equally have this issue when trying to target players with this combo. SCS can partly get around this by using the forcespell scripting command, but that is non-interruptible and a poor work around for an issue with SRR. Players can get around it by manually casting, but scripts won't work.

I really love these mods, but am encountering a number of errors when it comes to scripting and having desired reactions. Specifically: Dispelling Screen does not update a state/spellstate on the character, so standard checks like WIZARD_SPELL_IMMUNITY are not working as originally designed. This impacts not knowing if the spell is already cast on the player, so it will keep casting, or determining if the enemy has it up so a script can react appropriately. My recommendation is updating the Spell State of WIZARD_SPELL_IMMUNITY to 1 on any character with Dispelling Screen. This is the same value that SI: Abjuration uses, so there should be no negative impact with SCS. Scripts are not accurately targeting invisible enemies with Non-Detection with spells after True Sight is cast (specifically the character who cast True Sight is not able to target them). To be clear, the enemy is targetable manually; however, there appears to be a script state working in the background that prevents automated detection by scripts and allowing the character to cast a spell. I think this involves how Non-Detection works in SRR and how True Sight no longer changes the spell state on the enemy like it has in the past since only the character who cast True Sight is able to cast a spell on an invisible creature with Non-Detection. I imagine SCS has some difficulties around this; however, they use a mix of both regular spell casting and forced spellcasting that will work whether the creature is targetable or not. This is a tougher one for me to wrap my head around on figuring out the appropriate way to make it work correctly.

I'd be interested to hear from the creator of SCS on this. Looking at some SCS scripts, they do appear to reference the WIZARD_SPELL_IMMUNITY and make decisions off of it. With the change from Spell Immunity to Dispelling Screen, WIZARD_SPELL_IMMUNITY is no longer updating like SCS expects it to.

Looking into Spell States, it appears that Spell Immunity before SRR would update the SpellState value of WIZARD_SPELL_IMMUNITY to a value of 1-8 depending on the specific sub-spell (Abjuration would assign 1, Conjuration would assign 2, etc.). Since Dispelling Screen is replacing Spell Immunity, I am wondering as part of the casting if it can be set to update the value of WIZARD_SPELL_IMMUNITY.