morpheus562

18 minutes ago, subtledoctor said:

Neither here nor there but there are actually three invisibility-dispelling opcodes.   47 and 116 are identical, while 136 is slightly weaker. Plus you can dispel the ILLUSIONARYPROTECTION sectype with opcode 221. And for good measure, there is opcode 160 to remove Sanctuary. 

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.

On 3/9/2021 at 9:11 AM, subtledoctor said:

No worries! I didn't realize what you were talking about, I didn't think about what the spells were doing with stats. (I think some of the stat stuff doesn't show up on my installs, because I am on the EEs and some of the spells might be using spellstates instead there. Maybe. Anyway, NBD.
If your scripts are targeting the EEs, you can patch the spells with spellstates, instead of messing with the stats that may be used by Detectable Spells. There is an "add spellstate" macro here at line 55:

  Reveal hidden contents

 

DEFINE_ACTION_FUNCTION resolve_spellstate INT_VAR index=0 delete=0 STR_VAR new_state_id = ~blah~ RET new_state_ind BEGIN
 OUTER_SET min_new=118
 COPY_EXISTING ~splstate.ids~ override
  new_state_ind=0
  found=0
  READ_2DA_ENTRIES_NOW stats 2
  FOR (row=0;row<stats;row+=1) BEGIN
    READ_2DA_ENTRY_FORMER stats row 0 ind
    READ_2DA_ENTRY_FORMER stats row 1 str
    SET $stat("%row%") = ind
    PATCH_IF index BEGIN
      PATCH_IF ind=index BEGIN
        REMOVE_2DA_ROW row 2
        found=1
        PATCH_IF delete=0 BEGIN
          INSERT_2DA_ROW row 2 ~%index% %new_state_id%~
        END
        row=stats
      END
    END ELSE BEGIN
      PATCH_IF ~%str%~ STRING_EQUAL_CASE ~%new_state_id%~ BEGIN
        new_state_ind=ind
        found=1
      END
    END
  END
  PATCH_IF found=0 BEGIN
    new_state_ind=min_new
    PHP_EACH stat AS row => ind BEGIN
      PATCH_IF found=0 && (row+1 < stats) BEGIN // not at the end of file
        next_row = row+1
        next_ind = EVAL $stat("%next_row%")
        PATCH_IF index BEGIN
          PATCH_IF index<next_ind && index>ind BEGIN
            INSERT_2DA_ROW next_row 2 ~%index% %new_state_id%~
            found=1
          END
        END ELSE BEGIN
          PATCH_IF new_state_ind<next_ind BEGIN
            PATCH_IF ind<new_state_ind BEGIN
              INSERT_2DA_ROW next_row 2 ~%new_state_ind% %new_state_id%~
              found=1
            END ELSE BEGIN
              new_state_ind+=1
              PATCH_IF new_state_ind<next_ind BEGIN
                INSERT_2DA_ROW next_row 2 ~%new_state_ind% %new_state_id%~
                found=1
              END
            END
          END
        END
      END ELSE BEGIN // at the end of file
        PATCH_IF found=0 BEGIN
          PATCH_IF index BEGIN
            INSERT_2DA_ROW stats 2 ~%index% %new_state_id%~
          END ELSE BEGIN
            PATCH_IF new_state_ind>ind BEGIN
              INSERT_2DA_ROW stats 2 ~%new_state_ind% %new_state_id%~
            END ELSE BEGIN
              new_state_ind+=1
              INSERT_2DA_ROW stats 2 ~%new_state_ind% %new_state_id%~
            END
          END
        END
      END
    END // PHP_EACH
  END
END

 

 

 

 

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.

7 minutes ago, Bartimaeus said:

It's something that SCS already does for anti-magic spells, except it might be disabled if it detects any kind of SR installation because SR tries to handle it in a different manner? I'm not one hundred percent sure, but I feel like it doesn't take effect if you have SR installed.

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?

On 3/7/2021 at 1:58 PM, Bartimaeus said:

Non-Detection + Improved Invisibility is definitely a little wacky, but while SCS AI doesn't always conform to SR's rules in this regard, my experimentation in testing SCS's handling of it seemed to indicate that it does a "good enough" job that it doesn't act either super unfair towards or get completely broken because of it. Player AI, on the other hand, I know nothing about. This actually reminds me that I planned a long while ago on creating an optional settings.ini tweak to allow anti-magic spells to always be able to always pierce through improved invisibility so that the player can do what SCS can do in being able to force spells through - I wonder if that would help with player AI as well?

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.

9 minutes ago, subtledoctor said:

Ah, it's a mistake of terminology. Detectable Spells has nothing to do with spellstates, the DS library was written before spellstates were invented in the EE engine. Spellstates only cover one byte, with 255 possible values, each assigned to a single spellstate. Each spellstate can thus be set, or not set. They have no numerical values.

Detectable Spells uses various proficiencies, which can be set to different values.

I would NOT mess with SR's Detectable Spells stuff, without the advice of someone knowledgeable like Mike or Ardanis or DavidW.

I just glanced at the scripts thread, and it already has a Weidu installer. So there's no reason it shouldn't patch things there to make its own product work better. Just a question of

ACTION_IF (FILE_EXISTS_IN_GAME ~dvsrv4here.mrk~) BEGIN
  COPY_EXISTING [dispelling screen] ~override~
    LPF ADD_SPELL_EFFECT INT_VAR opcode = [et cetera]
END

 

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

2 minutes ago, subtledoctor said:

Spellstates are binary - they only have a value of 0 or 1. So I'm not sure what he meant by the 9. But as far as setting that spellstate: it could either be perfectly harmless, or it could slightly mess with SCS if SCS AI scripts detect and react to it. (Because, as we've said, the appropriate reaction to SI:Abj is different from the appropriate reaction to DS.)

Honestly, I don't think it's worth changing things or setting spellstates in this mod for the sake of the tiny fraction of people who might use those player scripts. No offense intended! It's just a question of who should bear the burden of compatibility, and adding code to SR that will be largely useless to most players and when we're not 100% sure of the consequences, seems a mistake to me. I mean it should be simple enough to wrap those player scripts in a simple Weidu installer, and then little tweaks can be added for the sake of compatibility, like patching Dispelling Screen and Mage Armor to set a spellstate. Nothing is standing in the way of that happening.

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).

2 minutes ago, subtledoctor said:

You could just remove all of the effects from ND, then load up a save and see what happens... that might suss out the issue.

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.

2 minutes ago, subtledoctor said:

And they are targetable with II but no ND?

My gut says it's something to do with opcode 69, if that's the case. (Though I've been wrong before. This game engine is wacky.) Which would mean this problem is already solved by my mod. (Though, it could create other issues, like Nondetection becoming too strong... at least against priests. Their only counter would seem to be Faerie Fire. )

What happens in SRR with someone has Nondetection and you cast Invisibility Purge?

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. 

18 minutes ago, subtledoctor said:

With vanilla spells, you simply cannot target an enemy who has II + ND. (Heck, you can;t target an enemy who only has II - ND doesn't even factor into it.) So I'm not clear on what you are comparing here.

I have definitely had occasions when I turned on player AI by mistake, and one of my characters started attacking an invisible enemy. So invisible enemies can definitely be targeted with SR installed. (In fact that is partly what caused me to go out and make my own invisibility tweak mod.)  I don't know whether that enemy had Nondetection cast... probably not. So maybe adding Nondetection into the mix can screw with player scripts? But if so, it sounds like it is something, as you say, "at the opcode level." I can't see how SR could be causing it; SR doesn't really change Nondetection. The only thing SR does to Nondetection is add an opcode 282 effect, setting the value to 3. I have no idea what that is for - I assume it is something to do with Detectable Spells?

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.

13 minutes ago, subtledoctor said:

Mage Armor has a sectype, which SCS knows how to handle. As a combat protection, it can be breached or dispelled. SCS is quite adept at doing such thing, in my experience.

Dispelling Screen has a custom sectype, which I think SCS knows about... but even if not, it doesn't really matter. Dispelling Screen blocks one instance of Breach or Dispel Magic; to remove that protection you must cast... Breach or Dispel Magic. Thing thing it protects from is the thing that dispels it; so even if the AI is dumb as a rock and casts Dispel Magic at your Dispelling Screen, it is actually doing precisely what a smart AI would do in the same circumstance.

 

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. 

1 hour ago, Bartimaeus said:

I don't know how that would interface with SCS, but you can certainly do it on your own end.

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.

20 minutes ago, Bartimaeus said:

It does not appear to have one, unfortunately. I do not know enough about spell states (and what slots are already taken up and such) to be able to just assign it one by myself, either.

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. 

I am trying to write a script so my characters will cast Dispelling Screen when certain conditions are met. Is there a Spell State or State I can check to determine if the spell is currently active on my character? I'm having trouble locating it, if it exists, and my character is continuously casting the spell over and over again. Thank you!

Is there a comprehensive list somewhere for IRR items that offer strength increase or apr increase? 

For STR increase, I am tracking the various belts, gauntlets of ogre, and maybe a mace? For weapons with apr, is it only now just belm and kundane offering 1/2 apr increase?