Jump to content

SR Revised V1.3.900 (2022 August 8th)


Recommended Posts

16 minutes ago, Bartimaeus said:

@subtledoctor You'd know better than I - do you know if there'd be an issue in setting the Spell Immunity spellstate to the purportedly unused 9 state for @morpheus562's purposes?

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.

Link to comment
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).

Link to comment

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

 

Link to comment
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.

Link to comment
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.

Link to comment
5 hours 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.

Thank you for the advice. Totally agree, don't like messing around with that which I do not fully understand the consequences of - hence why I had to ask you, :p.

@morpheus562 You may certainly do that. I don't remember the flag off-hand that allows a spell to pierce improved invisibility, I'll have to look at SCS code real quick...

                       DEFINE_PATCH_FUNCTION SPL_bypass_II STR_VAR arguments="" RET value BEGIN
                                     LPF fail_unless_boolean STR_VAR value="%arguments%" expression="" END
                                     PATCH_IF arguments=0 BEGIN
                                        WRITE_BYTE 0x1b (BYTE_AT 0x1b BAND 254)
                                     END ELSE BEGIN
                                        WRITE_BYTE 0x1b (BYTE_AT 0x1b BOR 1)
                                     END
                                     SET value=1
                       END
                       DEFINE_PATCH_FUNCTION SPL_read_bypass_II STR_VAR arguments="" RET value BEGIN
                                     PATCH_IF (BYTE_AT 0x1b BAND 1)  = 0 BEGIN
                                        SET value=0
                                     END ELSE BEGIN
                                        SET value=1
                                     END
                       END

In other words, byte 0x1b must be set to 01 (shows up as a value of 256 for the "Not in combat" field in DLTCEP). Although that value can probably be combined with the others (i.e. if you wanted to combine it with "cast through silenced" and "not in combat", I think 0x1a and 0x1b would become values 01 03 instead).

Edited by Bartimaeus
Link to comment

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.

Link to comment
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.

Link to comment
On 3/3/2021 at 10:17 PM, Jarno Mikkola said:

You might want to spare the upload space you have, and to do that, you could upload every image you have by uploading them all to imgur, and then going into the image location, it's not the one you linked to, but a right click on the image and then use the copy location, and post that in your post. Like so:

Thanks, much better.

Link to comment
17 hours ago, morpheus562 said:

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

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:

Spoiler

 



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

 

 

 

Add that somewhere early in your .tp2, then you can do this:

LAF resolve_spellstate STR_VAR new_state_id = ~dispel_screen_state~ RET new_state_ind END

COPY_EXISTING ~spwi510.spl~ ~override~
  LPF ADD_SPELL_EFFECT INT_VAR opcode = 328 target = 1 special = 1 parameter2 = %dispel_screen_state% timing = 0 duration - 120 END

...repeated for each relevant spell. Then add checks for the spellstate in your scripts to avoid casting the spell when it is still in effect.  (There is room for about 100 mod-added spellstates, and various mods add about 20-30 in total, so of course don't do this a hundred times. But if doing it 10 times or helps to improve your scripts, then there's no reason not to.)

EDIT - you can also do this with old-fashioned stats, using higher values in some of the Detectable Spells stats, but 1) that means using opcode 233, which is a bit more finicky, and 2) some Detectable Spells scripts treat the stats as binary and use dumb checks like "IF stat > 0" (which is immensely wasteful because those stats can have several billion numerical values or 128 bit-equality values, but that's a different conversation), so if a Detectable Spells spell sets the stat to 1 and your mod sets it to 9, they may get confused. Spellstates are limited in number, but cleaner and more reliable in application.

Edited by subtledoctor
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...