Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

New Premium Module: Tyrants of the Moonsea! Read More
Attention, new and old users! Please read the new rules of conduct for the forums, and we hope you enjoy your stay!

SPLSTATE.ids and OpCode 326 help?

2

Comments

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited January 2018
    So, how about some advice. I'd like to use ~40 spellstates to represent the various abilities in my psionics mod, and then use an opcode 214-based spontaneous casting method using "known wizard spells." (The alternative is using opcode 214 to reference several hundred variant static .2da lists, and I might shoot myself if I have to write them up by hand.)

    1) I could add 40 spellstates to splstate.ids. But there are not a ton of free spellstates (~100?) so I'm not sure it's wise to use up 40 of them with a single mod.

    2) There are 7 psionic abilities in each of 4 disciplines, plus ~14 HLAs. So I could use opcode 233 and a stat. Each discipline would require one byte of one stat (to do bit checks for each ability) and the HLAs could be covered by 2 bytes.

    Question here is, which stat? I was all set to use Tracking but it looks like it doesn't encompass 4 bytes? What about stat 108, is that used by anything? I could use it for the 4 disciplines and use a couple bytes of stat 134 for the HLAs.

    3) Alternatively I could set the spellstate associated with the bytes of a stat or two, without touching the stat itself. It would maximize compatibility because I could pretty safely use the upper bytes of any of the ExtraProficiency stats.

    But splprot.2da can't check for those bits, only 7eyes.2da can, and I'm not totally clear on the use of 7eyes.2da. Would I:
    - append a line to 7eyes.2da with no "immunity" entries (not needed, because I only need to check for the presence of the pseudo-spellstate)
    - set the pseudo-spellstate with... opcode 328? Can it set the states associated with those values?
    - check for the state with... opcode 335? That doesn't sound right, based on its description in the IESDP. How do I actually trigger a conditional spell based on the content of 7eyes.2da?

    The ultimate aim is this:
    - Cast spellA
    - SpellA checks those 40 stat values, and applies a 171 effect for each one that returns true

    So how do I trigger those 171 effects?

    Oh yeah, also: does adding lines to 7eyes.2da screw up the actual "Seven Eyes" spell, if you have it in your game?

    EDIT -

    Actually, poop, the Seven Eyes opcode/spell actually gives you an ability, doesn't it? Maybe I could take advantage of that. As long as 1) granting the ability can be conditioned on the spellstate being true, and 2) it can give you .SPLs coded as wizard spells instead of innate abilities.

  • kjeronkjeron Member Posts: 2,135
    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.

  • subtledoctorsubtledoctor Member Posts: 11,466
    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.

    So you would use the "Telekinesis" ability; it would temporarily put in your wizard spellbook all spells that are 1) of the Telekinesis school and 2) already known by you. Then on the next round you use the "Telepathy" ability; it would temporarily put in your wizard spellbook all spells that are 1) of the Telepathy school and 2) already known by you. Etc.

    We already have a proof-of-concept working with opcodes 233 (set the stat permanently when you "learn" the ability) and 326 (add "known" abilities to the spellbook); I'm trying to figure out if there's a better way to skin this cat.
    kjeron said:


    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.

    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.

  • kjeronkjeron Member Posts: 2,135
    edited January 2018

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

    Post edited by kjeron on
  • subtledoctorsubtledoctor Member Posts: 11,466
    kjeron said:

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

    Ah, that's disappointing. So we'll actually have to set a stat - and patch any CheckStat triggers relating to it. Unfortunate. I hoped we could avoid using 233.

    Eh, this is still cool though. Just need to figure out which stats to use.

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited January 2018
    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?

    More on-topic questions: given that this is for a non-wizard, maybe the best bet is to use a caster-focused stat(s), to avoid any bad interactions. So,

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

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

  • kjeronkjeron Member Posts: 2,135

    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.

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited January 2018
    kjeron said:

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

  • kjeronkjeron Member Posts: 2,135

    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.

  • subtledoctorsubtledoctor Member Posts: 11,466
    A few more questions since I want to get the best use out of this and I'm getting frustrated.

    If the chart is split into two columns, does that mean each stat comprises two bytes?

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

    There is a lot of use to be had from this kind of stuff, and it appears that resources are very contrained; off the top of my head I know there are about 100 unused spellstates, and what looks like about 2 dozen stats that could be partially usable. Plus msectype.2da, although that has a different and more limited application.

    It's probably worth cataloguing exactly what is available to be used by modders. My little psionics project needs ~40 bits or states, and our spontaneous casting idea needs an order of magnitude more. It might be worth staking out some claims on this territory...

  • subtledoctorsubtledoctor Member Posts: 11,466
    Here are some of what I'm looking at:

    - 19: Resist Magic Fire, 2 bytes, set by opcode 84 * ~
    - 20: Resist Magic Cold, 2 bytes, set by opcode 85 * ~
    - 25. Lore, 2 bytes, set by opcode 21 * +
    - 26-29: various thief skills, 2 bytes each, set by opcodes 59, 90, 91, 92. * ^
    - 33: Tracking, 2 bytes, set by opcode 95.
    - 46: Morale Break, 4 bytes, set by opcode 106 +
    - 51-52: Spell Failure, 2 bytes each, set by opcode 60 (?). ^
    - 53-54: Spell Duration Modifier, 2 bytes each, set by opcode 99. ^
    - 56: Backstab Multiplier, 2 bytes, set by opcode 263. ^
    - 77: Casting Speed Modifier, 4 bytes, set by opcode 189. ^
    - 135-137: various thief skills, 4 bytes each, set by opcodes 275, 276, 277. * ^
    - 89-107, 109-133: various proficiencies, 3 of 4 bytes available for each, set by opcode 233.
    - 108, 134: ProficiencyBlackJack and ExtraProficiency20, 4 bytes each, set by opcode 233. #

    Legend:
    ~ Magic Fire and Magic Cold damage types are unused in the unmodded game. They may be used by some mods (though it is unlikely)
    * These stats display values on the Record screen. It is unknown whether setting values above byte 1 will cause any problems.
    ^ These stats are class-specific... they could be utilized by classes without access to those skills.
    + Utilizing these stats would involve fairly major changes to core game mechanisms
    # I'm currently using the 4th byte of stat 134 for various dofferent mods

    Those are all the possibilities I'm seeing. I know these stats could be better used as actual stat values than for state-equivalent bit checks, but with only ~120 available spellstates, there might be more demand for the latter. By my count that makes about 1100 bit checks that could possibly be used, with varying degrees of ease or success.

  • kjeronkjeron Member Posts: 2,135
    edited February 2018

    If the chart is split into two columns, does that mean each stat comprises two bytes?

    Yes. Usually it also means that only the first 2 bytes of Parameter1 are used by the opcode that sets the stat.

    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.

  • kjeronkjeron Member Posts: 2,135
    edited February 2018

    - 19: Resist Magic Fire, 2 bytes, set by opcode 84 * ~
    - 20: Resist Magic Cold, 2 bytes, set by opcode 85 * ~

    Capped -128 to 127, all other values cannot be detected. So 1 byte each of usable values if you cannibalize their function.

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

    - 33: Tracking, 2 bytes, set by opcode 95.

    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.

    - 46: Morale Break, 4 bytes, set by opcode 106 +

    Capped 0 to 20, all other values (most of the first and all of the 2nd byte) cannot be detected.

    - 25. Lore, 2 bytes, set by opcode 21 * +
    - 51-52: Spell Failure, 2 bytes each, set by opcode 60 (?). ^

    Capped 0 to 100, all other values (many of the first and all of the 2nd byte) cannot be detected.

    - 53-54: Spell Duration Modifier, 2 bytes each, set by opcode 99. ^
    - 77: Casting Speed Modifier, 4 bytes, set by opcode 189. ^

    Fully usable, provided you suppress its natural effect, as they use all of those bytes for their effect.

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

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited February 2018
    kjeron said:

    - 19: Resist Magic Fire, 2 bytes, set by opcode 84 * ~
    - 20: Resist Magic Cold, 2 bytes, set by opcode 85 * ~

    Capped -128 to 127, all other values cannot be detected. So 1 byte each of usable values if you cannibalize their function.
    Maybe worth it... although I once advocated implementing these damage types, as radiant and negative energy damage, respectively. That may be a better use...
    kjeron said:

    - 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).
    Hmm, sounds dangerous - the race/Dex modifiers sound like they will throw off bit checks.
    kjeron said:

    - 33: Tracking, 2 bytes, set by opcode 95.

    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.
    He's using it for psionics, which is why I figured I would use it for my (incompatible, alternative) psionics mod. But if it can only correspond with 8 of my 40 abilities, instead of 31 of them, that is substantially less useful. I suppose I could use this for the HLAs...
    kjeron said:

    - 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.
    Ah, but I guess anyone attacking from invisibility would be affected by this, so that's not so good.

    That 1100 stats is starting to look like a lot less :( . But then, ~900+ of them are from the proficiency stats 89-134, and those work great as long as there are no CheckStat conflicts. So I guess proficiencies really are the way to go here. Everything else is just a few crumbs.

    Post edited by subtledoctor on
  • subtledoctorsubtledoctor Member Posts: 11,466
    edited May 2018
    kjeron said:

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

  • kjeronkjeron Member Posts: 2,135


    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 :worried:

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

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited May 2018
    kjeron said:


    I have it working for equipped item abilities in both BG beta v2.5 and IWD release v2.5, both target 5 and 7,
    Quick-item slots still don't function with target 7 for anything (BG beta v2.5 or IWD release v2.5).

    This is an equipped ability, but the item is in a quiver slot. (Ammo3, to be precise.) Maybe some slots don't work for equipped abilities? I'll try it in a necklace or helmet slot.

    Here is an alpha version of the mod, using target 5, if you want to try it out.
    kjeron said:


    though target 7 does not work if the game is paused when you activate it.

    Damn... that's half the point of using target 7.

  • kjeronkjeron Member Posts: 2,135
    edited May 2018
    @subtledoctor I see what they changed now - Opcode 335 no longer accepts spellstates above 255, that's a dead end.

  • kjeronkjeron Member Posts: 2,135
    edited May 2018
    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.

    Upon gaining psionics "(PSIPOWER)X.spl":
    Opcode 318, target=2, timing=9, resource="(PSIPOWER)X"
    Item Ability:
     Opcode 177, target=1,parameter2=2,timing=0,duration=0, resource -> EFF Opcode 171, resource="(PSIPOWER)", parent_resource="(PSIPOWER)X"
     Opcode 214, target=1, parameter2=1
     Opcode 172, target=1, resource="(PSIPOWER)"
    To learn:
    Opcode 321, target=2, resource="(PSIPOWER)X".

  • subtledoctorsubtledoctor Member Posts: 11,466
    kjeron said:

    @subtledoctor I see what they changed now - Opcode 335 no longer accepts spellstates above 255, that's a dead end.

    Goddamit! Why would they reduce the functionality of something?? I put a lot of effort into that.

    Now I have to reengineer the whole thing to use 326... :rage:

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited May 2018
    kjeron said:

    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.

    The other way to do it is to use 326.
    To learn powers: a spell uses 233 to set a bit in a proficiency.
    To use powers:
    - opcode 326 checking for the bit representing Mind Ward, if true cast subspell A
    -- subspell A has opcode 171 adding Mind Ward
    - opcode 326 checking for the bit representing Id Insinuation, if true cast subspell B
    -- subspell B has opcode 171 adding Id Insinuation
    - etc., more 326 effects
    - opcode 214, choose from known spells

    Supposedly the subspells will all process and the 214 effect will pick up the added wizard spells and present them to you. I haven't seen it in action but apparently Aquadrizzt has a working version of this. I decided to use opcode 335 since I think it's a bit more elegant, no need for subspells or EFFs or clearing the spellbook afterward.

    Sigh. I like the 177 idea - for some reason I don't love the idea of a bunch of subspells. And to do this without stats is safer. (Aquadrizzt's version is for spontaneous casting of any wizard spell, which means it uses several hundred stats. Though, the 206/318 method would need several hundred effects applied at level 1... that would be a looong CLAB table...) But either way I'll need to rip out and rewrite a substantial part of my mod... this is going to set me back a few weeks.

  • kjeronkjeron Member Posts: 2,135

    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.

  • subtledoctorsubtledoctor Member Posts: 11,466
    Huh. I could've sworn I've implemented 206 vs. EFFs... wait, in my armored casting mod. Here:
    https://github.com/subtledoctor/TomeAndBlood

    Install the "bardic armored casting" component. Unless I'm mistaken, it works to block the 145 effects in EFFs....

  • kjeronkjeron Member Posts: 2,135
    edited May 2018
    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)".

  • kjeronkjeron Member Posts: 2,135
    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.

  • subtledoctorsubtledoctor Member Posts: 11,466
    Okay, I've got a draft version working with two spells cast spontaneously via 177/171/214.

    Worth noting, I don't think the 172 effect afterward is necessary: you can set the 177 effect and the 171 EFF to zero-duration, and they resulting added spells will be picked up by the 214 effect. (Unless the added spells get stuck in your spellbook... I'll check for that. )

    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.

  • kjeronkjeron Member Posts: 2,135

    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.

  • JuliusBorisovJuliusBorisov Member, Administrator, Moderator, Developer Posts: 19,747
    About https://support.baldursgate.com/issues/36998:

    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

  • subtledoctorsubtledoctor Member Posts: 11,466
    edited May 2018
  • kjeronkjeron Member Posts: 2,135

    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.

    JuliusBorisov
Sign In or Register to comment.