SPLSTATE.ids and OpCode 326 help?
FailGeek
Member Posts: 50
Hey, I'm trying to make a kit that causes an additional effect if the target is under a unique status, but I can't seem to get it to work. What I've currently done using NearInfinity is:
1) Added a new line to SPLSTATE.ids (currently #1000)
2) Created a spell to use OpCode 328 to apply the State #1000 on the target for a 60 second duration.
3) Created another spell that uses OpCode 326 using Paramater 2 - 76 (SPLSTATE = specified value) and Paramater 1 - #1000 to cast yet another spell on the target if they have the custom state.
For some reason Step 3 isn't triggering if I use the added state. It works if I use any of the existing states, but stops working if I use the one I added to SPLSTATE.ids. Am I just not understanding how these OpCodes are supposed to interact, or is there an issue with OpCode 326 and additions to the ids file?
1) Added a new line to SPLSTATE.ids (currently #1000)
2) Created a spell to use OpCode 328 to apply the State #1000 on the target for a 60 second duration.
3) Created another spell that uses OpCode 326 using Paramater 2 - 76 (SPLSTATE = specified value) and Paramater 1 - #1000 to cast yet another spell on the target if they have the custom state.
For some reason Step 3 isn't triggering if I use the added state. It works if I use any of the existing states, but stops working if I use the one I added to SPLSTATE.ids. Am I just not understanding how these OpCodes are supposed to interact, or is there an issue with OpCode 326 and additions to the ids file?
0
Comments
Oh, I seem to recall it being necessary to add certain text for every line up to the line that you are using. So, if you used line 1000, you would need to fill in all lines before that...It was a post on gibberlings regarding the new opcodes.. Anyway, to test, first try just using the very first available line
Okay, it works if the unique splstate is < 255, which is annoying because I thought the upper bound of the ids file would be higher and makes future proofing the mod against patches and newer mods less possible but oh well. Thanks for the help!
Some numbers work, some numbers don't, but its not capped at 256.
1000 does not work with the opcodes but does work with a script check.
100000 works with both the opcode and script checks.
1024 always returns true for both opcode and script checks, without setting it.
1024 is... familiar.
I wonder about 512, 256, 128, 64, 32, 16, 8, 4, 2, 1
One can have more than one state at a time, yes?
The only limitation to stacking them involves its interaction with opcode 335(Seven Eyes):
Along with doing several other things, 335(Seven Eyes) sets the same States as opcode 328, however, Opcode 335 will not apply at all if the spell state is already set. Not an issue so long as you do not use the same State with both Opcodes 328 and 335.
Extra:
The 7EYES.2DA does not require using the Seven Eyes opcode. Any State defined in 7EYES.2DA will provide constant immunity(with feedback) to its list of opcode/resrefs while the state is set, regardless of whether it was set with opcode 328 or 335.
@Avenger_teambg I remember you mentioning there are reserved ids values for hardcoded states that cannot be set. Do you know what those are? It might explain why setting some ids values might not work.
1. make sure you have existing splprot entries for your 2 simple states (undead already has this).
2. build a new entry with the line combination code (0x103)
So, your splprot.2da line will look like this
DUMB [your dumb spell state check]
NOTDUMB [your dumb spell state check negated]
DUMBORUNDEAD 0x103 1 [your code for dumb]
DUMBANDUNDEAD 0x104 2 [your code for not dumb]
Alternatively, if this doesn't work out, you can put an opcode 326 into the spell applied by opcode 326, that will further narrow the target specification.
For example, if I have spell state "Armored Caster", could I add a check to a piece of armor that would only cast a spell (which disabled arcane casting) on creatures who equip the armor without the Armored Caster state?
Spellstates 256-287 are set by STATE.IDS values.
Spellstates 288-6239 are set by STATS.IDS values, with some exceptions:
* Current Bardsong duration modifier is stored in Spellstates 1808 - 1823, (Default Value = 100).
* Current Bardsong is stored in Spellstates 3968-4031, Default = "BARDSONG"
* Current Backstab is stored in Spellstates 4032-4095, Default = (emtpy) / 0
* Opcode 332 Stores its various damage type modifiers in Spellstates 4272 - 4447.
* Opcode 346 Stores its various Save vs School modifiers in Spellstates 4448 - 4639.
Spellstates 6240+ are dependent on the game campaign/version, read directly from specific offsets of the EXE. Pattern is 32(set) - 160(emtpy) - 32(set), and repeats semi-consistently up to at least 32767.
These are all a one-way influence, they will set the spellstates, but the spellstates have no effect on the value used by them if you were to set them manually through opcode 328/335. Two partial exceptions are 262(STATE_FROZEN_DEATH) and 263(STATE_STONE_DEATH), which will generate the character-color overlay associated wit their death type, ice/blue and stone/beige.
I still have not found any matches for these 3 STATS:
- 61 IDENTIFYMODE
- 146 CRITICALHITBONUS
- 188 SUMMON_DISABLE_ACTION
Or for these 64 Splstates:1664 - 1695 (These appear to be the old location of STATS LEVEL2 and LEVEL3.
4224 - 4255 (I don't know why this gap exists)
Some uses I've thought of so far:
A Bitwise STAT check method for scripts, for example:
CheckSpellState(Myself,3680) // This will check just the first bit of ExtraProficiency20 stat, useful if you are setting the latter bytes for other purposes.By adding an entry for spellstates 262 and 263 to 7eyes.2da, you can prevent Frozen and Stoned creatures from shattering.
- An easy way to do this is to just block the 2 exploding deaths that they trigger, while letting anything else through:
- %strref% is the feedback string that will be displayed whenever they would have exploded, so it should be something informing "Ineffective".
- This still allows any other direct "Death" effect to kill them as it normally would, including dropping their inventory. This also includes using debugs "Ctrl+Y".
- Cold damage is tricky though, because when it overkills it applies both the frozen and exploding_frozen deaths together, the exploding slips through before the spellstate is registered, but there is still a way to prevent it. Manually applying the spellstate for an instant after any cold damage is dealt:
- It's not necessary to add these spellstates to SPLSTATE.IDS, and they work in all 2.x games and v1.4 IWDEE. However, I think 7EYES.2da does not by default exist in the BG series, so it will need to be imported from IWDEE.
- None of this has any effect on preventing party members from getting kicked from the group when they are stoned/frozen.
A far simpler way to prevent poison from getting past Mirror Image than I previously posted elsewhere: No more poison(effect) getting past Mirror Image.A way to fake a STATE without setting it, such as for a Sightless creature, which should be immune to Blindness, but also immune to spells that require sight (such as IWDEE Color Spray, which only checks against STATE_BLIND).
opcode 324(Doesn't work for SPLPROT, only through 7eyes or scripts.) with a SPLSTATE=274 check in Color Spray, it could catch both naturally sightless and the unnaturally Blind.Hello kjeron, about the used SpellState by system beyond 6240, I make a test in my BG2EE v2.3.67.3.
I cannot follow the pattern you mentioned in G3 forum or here, and I'm not familier with the EXE, so I'm not sure my idea is correct.
The idea is:
Repeatly EXTEND the following script block to DPLAYER3.bcs, then start a new game and save, get the saved variables from BALDUR.gam in a txt file.
CheckSpellState(Myself,%x%)
!Global("%x%","Global",1)
THEN
RESPONSE #100
SetGlobal("%x%","Global",1)
Continue()
END
Where x is 6240 to 32767.
The resault is in the attached file. But I cannot conclude any pattern from it, maybe you would like to help me. Thanks.
The second (32) represents the hex value 0x0000000a (and has always shown this value within consistent sets as far as I've seen).
Each of those (32)'s corresponds to a 4-byte section of the EXE, a different value in the EXE will alter which of those 32 spellstates get set. Each different version(2.0, 2.1, 2.2, 2.3, etc..) of each game that I could test has had different values, though BGEE(without SoD) and BG2EE did share some within the same version, SoD and IWDEE did not.
the next set: and the next: But the pattern is not always consistent, such as the next section: These irregular sections were usually present in the EXE as well - the pattern would break in both places.
Then it resumes again:
The extraprof's would require either unique sources for each stat, or one bit per source, since adding the same bit from two sources would equal the next bit, not the intended bit. Obviously this isn't always a loss, as this behavior has been quite useful for determining how many weapons are equipped, but that is more an exception than the norm. The other extraprof's would be better spent on stats that need actual values, rather than just true/false.
It does enable being able to better detect the default proficiency stats, either because their upper bits are being used through "Increment" effects, or because they are dual-classed and have "original class" proficiency values, each of which screw up the CheckStat trigger.
Just always negate the check for bits you don't need, don't omit them.
Checking '1' would need: 1= 1, 0, 0
2 = 0, 1, 0
3 = 1, 1, 0
4 = 0, 0, 1
5 = 1, 0, 1
6 = 0, 1, 1
7 = 1, 1, 1
Still better than the 6-8 CheckStat()s needed for dualclasses.
The issue is with SPLPROT, it can only detect the first 255 spellstates when they are set by opcode 328.
It can detect higher spellstates only when they are set indirectly through by other Stats(such as opcode 233 in this case).
This limitation is exclusive to SPLPROT (edit - and Opcode 335*). The CheckSpellState() script trigger and the 7EYES.2da spellstate checks can check higher spellstates set either by opcode 328 or indirectly through Stats.
*(Opcode 335 has no effect if it detects that it's specified spellstate is already set).