7eyes.2da works similar to opcode 324, but with a limited range of conditions(spellstates only) and an extended range of targets (opcode/parameter2 or resource). It can only detect and grant immunity based on them already being set. Adding new lines won't affect the Seven Eyes spell, but if the file doesn't already exist, I always copy the default file from IWDEE, so those first 7 lines are already set and won't cause issues with the spell - the string references would need to be updated if the spell was actually added, but that's another issue.
The 7eyes opcode (335) gives abilities, but that's (mostly) unrelated to 7eyes.2da. Wizard/Priest spells that it grants just adds them to known spells, it doesn't grant memorizations, but it will remove known and memorizations when the effect ends. Innate abilities grant a memorization. It actually only grants the ability if the spellstate is NOT already set, as the opcode also sets the spellstate as part of its effect.
If I understand correctly you want a dynamic list, but to not rely on "known wizard spells", or innates that move around on the bar every time they are used. It's possible to keep the psionic powers in the same order among themselves, but not in relation to any other innate abilities.
I'd like to add known wizard spells dynamically, and temporarily, every time the "cast" ability is used. And then do a quick 214 effect and then blank out the known spells again. That actually sounds perfect, actually. Maybe apply all of the relevant any spellstates at level 1, and then use 321 to remove them one at a time, when you "learn" each ability. Then have the "cast" spell work on all of them, and it will give you the spells for which you don't have the spellstate. Unless I'm misunderstanding.
Heck, if that works it should scale up for the Sorcerer application too. And be slightly better than using 233/326, for guaranteeing not to interfere with any stat checks.
Your not misunderstanding, it should do as you want. Upon gaining access to psionics, set all spellstates that correspond to a psionic power, through separate subspells. Upon gaining a psionic power, remove its spellstate through opcode 321.
Activating the ability to use Psionics would look like this: Seven Eyes (335), parameter1 = (spellstate X), parameter2 = "-1", special = "-1", resource = (psionic power X, wizard spell) Seven Eyes (335), parameter1 = (spellstate Y), parameter2 = "-1", special = "-1", resource = (psionic power Y, wizard spell) Seven Eyes (335), parameter1 = (spellstate Z), parameter2 = "-1", special = "-1", resource = (psionic power Z, wizard spell) etc... Select Spell (214), parameter2 = known spells (1) All timing/duration 0. parameter2 = "-1" so they do not trigger immunities (invalid row of 7eyes.2da). special = "-1" so they do not interfer with the seven eyes spell.
The 0 duration will trigger "knowing" the spell long enough for opcode 214 to catch it, before removing it.
You would be able to use this method for the higher spellstates that correspond to proficiency bits as well, provided that you set the proficiency stats with opcode 233, rather than the spellstates directly with 328. It appears that the Seven Eyes (335) opcode detects those higher spellstates already being set in the same manner as splprot (nothing above 255 if set by opcode 328).
Would be a problem with the caster level of a single-class thief casting wizard spells through 214 this way? Would it always have a casting level of 1, making level-based headers useless? Will I need to apply a 191 effect at each level-up? Would that even have any effect?
The easy way around this is to have those wizard spells just use opcode 146/148, parameter2=1, targeting the real, innate, psionic power. Those without a proper mage/priest spellbook are not affected by opcode 191.
1) Anyone know the difference between stat 76 "AURACLEANSING" and stat 165 "SCRIPTINGSTATE10 / WIZARD IMPROVED ALACRITY" ? Is the former set by opcode 188, and the latter set by the Improved Alacrity HLA? In which case, maybe I could use stat 165 for a psionic thief kit (which for obvious reasons will never be able to multiclass with mage)...?
Stat 76 "AURACLEANSING" is the actual functional stat, set by opcode 188. Stat 165 "SCRIPTINGSTATE10 / WIZARD IMPROVED ALACRITY" is just a label from detectable spells, it has no function.
2) Will opcode 233 basically work with anything in stats.ids? (I.e. will setting a 233 effect to increment proficiency 165 by [4 << 8] set bit 3 of byte 2 of stat 165? And then the new line in 7eyes.2da would check against state 5067?)</p>
Opcode 233 can only modify stats 89 - 134, the "proficiency" stats. These are all the ones that work in "WEAPPROF.2DA" and will display in the record screen as proficiencies.
Hmm... so if the stats can't be set by opcode 233, and the states can't be set effectively by opcode 328 for filtering by 318/324/326/335, then it seems a lot of the bits identified in the chart above are not very useful... no? I guess some of them are already associated with opcodes, which may or may not be able to use more than one byte of the stat...
Opcode 282 can set (but not increment) stats 165 - 201, though only the first 10 are meaningless, the rest have functions. Most other stats are set directly by other opcodes, most utilize the entire 2-4 bytes (even if they don't appear to in-game), but there are some that only utilize the first bit, like Hold. They are useless for splprot filtering if set by opcode 328, but still usable in script checks.
Any idea whether opcodes that increment stats can generally byte-shift? Like, can you use opcode 85 "Magic Cold Resistance" to set your "resistance" to (32 << 8)?</p>
For most opcodes other than proficiency, no. Many have in-game caps to their effective value. The resistance stats, for example, cannot hold a detectable value greater than 127 or less than -128. You can set these values, and they will be considered when using "Increment" modifiers, but the final value will still be between -128 and 127, negating those higher bits for detection purposes.
Most stats either cannot be manually set, cap their values, or don't offer an "increment" option (while "set" overwrites any previous value), The only other stats I know this could work with are not practical for doing it: Max Hit Points and Experience.
- 26-29: various thief skills, 2 bytes each, set by opcodes 59, 90, 91, 92. * ^ - 135-137: various thief skills, 4 bytes each, set by opcodes 275, 276, 277. * ^
Opcode modifier and base stat are capped 0 to 255. Modifiers from Dexterity/Race apply after this cap, and can exceed it up to full 2-byte range (-32768 to 32767).
Capped 0 to 255, all other values (the 2nd byte) cannot be detected. The first byte is fully usable though. I thought Aquadrizzt was already using it for something else though.
- 56: Backstab Multiplier, 2 bytes, set by opcode 263. ^
Capped 0 to 32767, negative values (the last bit) cannot be detected. 15 fully usable bits, provided you suppress its natural effect. I think using 3e Sneak Attacks ignores this stat, so that is one method of suppressing it.
Sadly, while this seems to work just fine when triggered by an item with header target 5 in the 2.3 engine, it does not work when triggered by an item with header target 7 in the 2.5 engine.
Which I was kind of banking on.
EDIT - Actually header target 5 doesn't work on the 2.5 beta either
I have it working for equipped item abilities in both BG beta v2.5 and IWD release v2.5, both target 5 and 7, though target 7 does not work if the game is paused when you activate it. Quick-item slots still don't function with target 7 for anything (BG beta v2.5 or IWD release v2.5).
Well, good timing for my other post about 318/177:
Replace setting spellstates through proficiency with opcode 318 to prevent usage of that spell. Replace opcode 335 with 177[->171]. Add opcode 172 for each spell after the opcode 214. Even works while paused with target 7.
Is it me or could this just be done with 206 instead of 318? Theoretically this doesn't even need stats assigned to powers.
Opcode 206 cannot block EFF files by the parent resource within the EFF file, only opcodes 318/324 can. Similar to how 318/324 can block item effects, while opcode 206 cannot.
Your right, I forgot that you just need to set the parent resource type in the EFF to "Spell". It cannot block it if the type is set to "None(0)" or "Item(2)".
Actually I would suspect that this is why Opcode 232 can only be stacked when you specify (parent_resource_type = "None/Item"), as it likely uses the same internal mechanism as opcode 206 to block proceeding effects, which can only block the "Spell" type.
You would have to use opcode 318 if the EFF opcode was 232.
There are at least a few other opcodes that utilize this anti-stacking mechanism, so if you do ever find it not working, try switching to (parent_resource_type ="None/Item") and Opcode 318.
Next thing to check, instead of applying dozens or hundreds of spells with the 206 protection in the clab table, apply each as an .EFF with its own parent resource. Question then being, will the 321 effects used to "learn" new spells work on those .EFFs by targeting those parent resources.
Opcode 321 falls short in that respect. It cannot remove opcode 177 based on the parent resource in the EFF file.
Using unsafe memory reads can break the engine on some platforms. Leaving that thing in could have caused mysterious crashes on Android, at least. We've seen how simply recompiling the code caused Android-specific crashes.
If there is a good reason to access an internal state to read, we might work out something, contact @Avenger_teambg
If there is a good reason to access an internal state to read, we might work out something, contact @Avenger_teambg
I can understand needing to disable everything about Spellstates #6240 and up, there's no surprise or real argument to make against those.
What what was lost and could be reproduced (IMO): - Script trigger(s) to check stats bit-wise. - Some option (other than Gore-OFF) to disable the chunking associated with frozen/stoned creatures, to leave the creature as a stature no matter how much you wail on it. Or alter Frozen Death from causing an automatic Frozen Explosion - make it require being struck before it explodes, as Stoned Death does.
Comments
The 7eyes opcode (335) gives abilities, but that's (mostly) unrelated to 7eyes.2da.
Wizard/Priest spells that it grants just adds them to known spells, it doesn't grant memorizations, but it will remove known and memorizations when the effect ends. Innate abilities grant a memorization. It actually only grants the ability if the spellstate is NOT already set, as the opcode also sets the spellstate as part of its effect.
If I understand correctly you want a dynamic list, but to not rely on "known wizard spells", or innates that move around on the bar every time they are used. It's possible to keep the psionic powers in the same order among themselves, but not in relation to any other innate abilities.
Upon gaining access to psionics, set all spellstates that correspond to a psionic power, through separate subspells.
Upon gaining a psionic power, remove its spellstate through opcode 321.
Activating the ability to use Psionics would look like this:
Seven Eyes (335), parameter1 = (spellstate X), parameter2 = "-1", special = "-1", resource = (psionic power X, wizard spell)
Seven Eyes (335), parameter1 = (spellstate Y), parameter2 = "-1", special = "-1", resource = (psionic power Y, wizard spell)
Seven Eyes (335), parameter1 = (spellstate Z), parameter2 = "-1", special = "-1", resource = (psionic power Z, wizard spell)
etc...
Select Spell (214), parameter2 = known spells (1)
All timing/duration 0.
parameter2 = "-1" so they do not trigger immunities (invalid row of 7eyes.2da).
special = "-1" so they do not interfer with the seven eyes spell.
The 0 duration will trigger "knowing" the spell long enough for opcode 214 to catch it, before removing it.
You would be able to use this method for the higher spellstates that correspond to proficiency bits as well, provided that you set the proficiency stats with opcode 233, rather than the spellstates directly with 328.
It appears that the Seven Eyes (335) opcode detects those higher spellstates already being set in the same manner as splprot (nothing above 255 if set by opcode 328).
Those without a proper mage/priest spellbook are not affected by opcode 191. Stat 76 "AURACLEANSING" is the actual functional stat, set by opcode 188.
Stat 165 "SCRIPTINGSTATE10 / WIZARD IMPROVED ALACRITY" is just a label from detectable spells, it has no function. Opcode 233 can only modify stats 89 - 134, the "proficiency" stats. These are all the ones that work in "WEAPPROF.2DA" and will display in the record screen as proficiencies.
They are useless for splprot filtering if set by opcode 328, but still usable in script checks.
Most stats either cannot be manually set, cap their values, or don't offer an "increment" option (while "set" overwrites any previous value),
The only other stats I know this could work with are not practical for doing it: Max Hit Points and Experience.
Quick-item slots still don't function with target 7 for anything (BG beta v2.5 or IWD release v2.5).
Replace setting spellstates through proficiency with opcode 318 to prevent usage of that spell.
Replace opcode 335 with 177[->171].
Add opcode 172 for each spell after the opcode 214.
Even works while paused with target 7.
Upon gaining psionics "(PSIPOWER)X.spl":
Opcode 318, target=2, timing=9, resource="(PSIPOWER)X"Item Ability: To learn:
Opcode 321, target=2, resource="(PSIPOWER)X".Similar to how 318/324 can block item effects, while opcode 206 cannot.
It cannot block it if the type is set to "None(0)" or "Item(2)".
You would have to use opcode 318 if the EFF opcode was 232.
There are at least a few other opcodes that utilize this anti-stacking mechanism, so if you do ever find it not working, try switching to (parent_resource_type ="None/Item") and Opcode 318.
Using unsafe memory reads can break the engine on some platforms. Leaving that thing in could have caused mysterious crashes on Android, at least. We've seen how simply recompiling the code caused Android-specific crashes.
If there is a good reason to access an internal state to read, we might work out something, contact @Avenger_teambg
What what was lost and could be reproduced (IMO):
- Script trigger(s) to check stats bit-wise.
- Some option (other than Gore-OFF) to disable the chunking associated with frozen/stoned creatures, to leave the creature as a stature no matter how much you wail on it. Or alter Frozen Death from causing an automatic Frozen Explosion - make it require being struck before it explodes, as Stoned Death does.