Skip to content

Spell immunity fails to trigger the school selection when paused *half-resolved*

TippisTippis Member Posts: 2
edited November 2013 in BGII:EE Bugs (v1.2.2030)
I'm running BG2:EE on OSX, and now that I'm getting into the more Lich-heavy territory of the story, I've come to notice that Spell Immunity literally does nothing in my game.

When the spell is cast, I get no dialogue asking me to pick a school to protect against, and no effects are being applied to the character casting the spell. This effectively makes some fights near impossible since the first or second strike of some magic-using enemies is to cast Imprisonment on the main character.

No save + instakill + no protection = insta-game over, and that's just no fun. The only other option is to go for a Benny Hill-style chase and hope to be able to stay out of touch range, but since these enemies also have a nasty tendency to appear in tight spaces, that's not really a practical solution either.
Post edited by Tippis on

Comments

  • Are you talking about Spell Immunity, or Spell Turning? The title of your post says one, the body says another.

    If it's Spell Immunity, then there isn't a dialogue to choose the school. Instead, the quickbar will be replaced with icons representing the schools, and you click on one of them (there are tooltips so you can tell them apart). You won't see any effect applied until you've clicked on a spell school.

    If it's Spell Turning, then you should definitely see a spell effect (it's a small glowing circle under your feet, which may be obscured if you have a bunch of other effects already - Mirror Image especially makes it hard to see). You should also get a 'Spell Turning' icon on your portrait and it should show up in the list of effects on the character record. If none of that is happening, there may be some buggage.

    Also, I don't think any of the mobs are scripted to hit the main character with Imprisonment...if I recall correctly, they all cast it on the nearest person that they're aware of. So if you have a paladin beating on them, but that paladin has a Protection from Undead scroll used on him, they'll look for the next 'visible' target.
    sarevok57Tippis
  • TippisTippis Member Posts: 2
    edited November 2013
    Yes, I meant immunity, so I'll edit that, and d'oh! I simply hadn't noticed the UI change.

    Still, on further experimentation, I've noticed why I didn't see it in the first place.
    If I cast the spell while paused, and then switch characters to make them cast or prepare something, when I unpause and the spell is set off (which should trigger the selection bar), the selection process doesn't actually happen.

    The bar pops up, but is empty and the icons for selecting the school isn't there. I also can't see any way to make them appear if at first I miss them. So mass-preparing this spell still seems not to be working as intended.

    So the chain of events is:
    Pause; cast Spell Immunity; select other character […]; unpause… at which point no school selection takes place.

    It should either be
    Pause; cast Spell Immunity; select school; select other character […]; unpause

    or
    Pause; cast Spell Immunity; select other character […]; unpause; select school.
    Post edited by Tippis on
  • Yeah, it's a weird two-stage cast for some reason (or is treated as such by the auto-pause). While it's somewhat inconvenient, it still works if you pay attention to one person casting it at a time.
  • acdhaacdha Member Posts: 15
    This is particularly buggy in multi-player – if the other player does anything at all, it will also trigger the UI bug
  • GalactygonGalactygon Member, Developer Posts: 412
    Bump.

    Existing behavior 1: This issue still persists. This can be fixed by setting the targettype of SPWI510.spl to "7 - Self ignore pause" from the current "5 - Self". This applies to SPWI417.spl (enchanted weapon) as well.

    Desired behavior 1: SPWI124 (Nahal's Dweomer) works just fine when the game is paused so the other two should receive this same treatment as well.

    Existing behavior 2: Also, a slightly unrelated bug is that CONTINGX.2da still includes SPWI510 even though the engine properly handles spell immunity menu type spells when creating a contingency.

    Desired behavior 2: SPWI510 (Spell Immunity) 's subspells should be selectable in contingency/trigger spells.
    CrevsDaakAvenger_teambg
  • Gate70Gate70 Member, Developer Posts: 3,870
    Thanks @Galactygon‌ raised as 9058.

    Don't suppose you know if any other spells may be affected. I'm thinking Wondrous Recall might.
    GalactygonCrevsDaak
  • argent77argent77 Member Posts: 3,431
    The following spells are affected:
    SPWI510 (Spell Immunity)
    SPWI417 (Enchanted Weapon)
    SPCL621 (Summon Spirit Animal)

    I wouldn't apply it to Wondrous Recall, as target type "7 - Self ignore pause" ignores casting times.
    Gate70CrevsDaak
  • Gate70Gate70 Member, Developer Posts: 3,870
    Many thanks @argent77‌ have updated the ticket with this information
    Galactygon
  • GalactygonGalactygon Member, Developer Posts: 412
    @Gate70

    I've tried placing three farsights (SPPR415, SPW424) in spell trigger and it doesn't work. So I suggest appending CONTINGX.2da with those two entries unless you want to bother making them work. Other than that, I see no other possible bugs regarding CONTINGX.2da, and @argent77 yes SPCL621 also needs to have a targettype of 7 (self ignore pause). Furthermore, scrolls SCRL6M and SCRL6S need to use a targettype of 7. At the moment targettype of 7 is hardcoded to not work for items (I've tested this for SCRL6S) when it should.

    I've tried what happens when you remove SPWI124 (Nahal's Reckless Dweomer) from CONTINGX.2da. At the moment, the game doesn't handle if the caster's known spells are called up instead of a list (by .2da) in the contingency selection. You could try and "fix" that as well and enable the entire list of known spells appear in level 1 but then you have new issues to worry about:
    1. Nahal's Dweomer works by forcing the parent spell onto the caster a split second before the child spell (the ones in the menu) are cast. Furthermore, the parent spell causes the next .spl cast by the caster to have wild surge, which is usually the child spell (unless the caster esc the spell menu and starts another spell). This is crucial, and the contingency/trigger must somehow be able to store this extra information *(the parent spell to cast a split second before the child spell) when carried by the .cre. This might be possible by using the local variable field at 0x00a8 of .eff v2 file format. It has a size of 32 bytes so it should be able to store the three parent spell resrefs of the child spells (which already take up 24 bytes or 3 resource fields).
    2. Also make sure spells cast from a trigger in the correct order (ie parentspell1, childspell1, parentspell2, childspell2, and so on) so that the parentspellx occurs right before the correct childspell to be modified by the wild surge. This functionality would only occur when we are dealing with spell menus.

    Also I might as well report some more related spell bugs. Get ready for a long list.

    1. existing behavior: opcode 146 (cast spell at creature) is affected by wild surge when parameter2 is set to 0 (casting type = cast normally).

    1. expected behavior: opcode 146 should not be affected by wild surge by default even when param2 is set to 0.

    2. existing behavior: When opcode 146 (cast spell at creature) is used, the casting time not correctly modified by stat77 (MENTALSPEED) despite that the casting graphics duration is correctly calculated. To test this, equip the robe of vecna and try casting any scroll that does not have a target type "cast at point".

    2. expected behavior: the casting time should be modified by stat MENTALSPEED from items such as robe of vecna OR do not modify casting time but then casting graphics duration should be correctly calculated.

    3. existing behavior: The casting time of opcode 148 (cast spell at point) is also not modified by stat MENTALSPEED despite that the casting graphics duration is correctly calculated. You can test this by casting any area effect spell from a scroll while having the robe of vecna equipped.

    3. expected behavior: As #2, the casting time should be modified by stat MENTALSPEED from items such as robe of vecna OR do not modify casting time but then casting graphics duration should be correctly calculated.

    4. existing behavior: spellcasting graphics duration (incl. when cast via opcodes 146 and 148) are not correctly calculated when the character is STATE_SLOWed.

    4. expected behavior: When the character is slowed (and spells take 2x longer), the duration of the casting graphics should also be extended by 2x.

    5. Existing behavior: When using the select spell for contingency GuI the scrolling arrows on both sides at any given spell level do not work properly if the caster has too many different types of spells memorized on a particular level. If the caster selects and then unselects a spell to place in a contingency the arrows work erratically, turning on and off. Also, if there are too many spells at a given level then the spell icons erratically appear and disappear when toggled. To test this have a lot of different spells on a particular spell level memorized and cast any contingency/trigger spell.

    5. Expected behavior: Arrows appear and work consistently when there are too many types of spells. Spell icons from the menu do not appear and disappear when there are too many types of spells.
    hook71CrevsDaak
  • Gate70Gate70 Member, Developer Posts: 3,870
    Might be worth @Dee being aware of these.
    GalactygonCrevsDaak
  • GalactygonGalactygon Member, Developer Posts: 412
    edited August 2014
    Here is another one:

    Existing behavior: Unconscious creatures (STATE_SLEEPING) are not revealed by farsight whereas creatures under STATE_NONDETECTION are revealed. Also, wizard eye (.cre with stat 148 EXPLORE set to 1) reveals creatures under STATE_NONDETECTION

    Expected behavior: STATE_NONDETECTION should hide creatures from farsight and wizard eye. Meanwhile, creatures under STATE_SLEEPING should be visible to farsight.

    Suggested implementation of stat 148 EXPLORE:
    - when stat 148=1, then it is blockable by STATE_NONDETECTION
    - when stat 148=2, then it is not blockable by STATE_NONDETECTION

    EDIT: I might suggest the same thing for stat 81 SEEINVISIBLE but this is bordering on a request rather than a bugfix:
    - When stat 81 SEEINVISIBLE is set to 1, it is not blockable by STATE_NONDETECTION (default behavior)
    - When stat 81 SEEINVISIBLE is set to 2, it is blockable by STATE_NONDETECTION
    - In both cases, when the PC is selected/deselected invisible creatures toggle on/off just like in infravision
    - In all cases Detect() would detect invisibility regardless of STATE_NONDETECTION but See() does not. I might suggest this behavior to opcode100 (protection from creature type) to ease. OR introduce a new scripting action DetectNoFailure() or something like that.
    Post edited by Galactygon on
  • GalactygonGalactygon Member, Developer Posts: 412
    @Gate70 Just saw your post, thanks for raising these.
  • Avenger_teambgAvenger_teambg Member, Developer Posts: 5,862
    I don't think that nahal's will be ever in castable spells by contingency. Adding the selectable spells was a big enough change for such a small feature. There is really no point in jumping through so many loops just to support this spell. On the other hand, enchanted weapon subspells will need a casting time now.

    GalactygonCrevsDaak
  • kjeronkjeron Member Posts: 2,367

    2. existing behavior: When opcode 146 (cast spell at creature) is used, the casting time not correctly modified by stat77 (MENTALSPEED) despite that the casting graphics duration is correctly calculated. To test this, equip the robe of vecna and try casting any scroll that does not have a target type "cast at point".
    3. existing behavior: The casting time of opcode 148 (cast spell at point) is also not modified by stat MENTALSPEED despite that the casting graphics duration is correctly calculated. You can test this by casting any area effect spell from a scroll while having the robe of vecna equipped.

    This behavior is present for all forms of this spell-casting type:
    Opcode:146(Cast Spell), Type:0
    Opcode:148(Cast Spell at Point), Type:0
    Opcode:215(Select Spell), Type:4
    Action:ForceSpell
    Action:ForceSpellRES
    Action:ForceSpellPoint
    Action:ForceSpellPointRES
    CrevsDaak
Sign In or Register to comment.