Skip to content

[(BG1\2) BUG] AreaCheckObject trigger (0x40D4) has been known to cause crashes.

AndreaColomboAndreaColombo Member Posts: 5,533
edited August 2012 in Fixed
Originally posted by devSin in this thread. Since devSin won't beta test BG:EE, I thought I'd report his request here and atomize it for the devs' convenience.

CURRENT BEHAVIOR:

AreaCheckObject trigger (0x40D4) has been known to cause crashes.


EXPECTED BEHAVIOR:

It should return true if the given creature is determined to be in the listed area; otherwise, it should always return false (even when it just can't check the area). (I'm not sure if there were ever any steps for reliably reproducing the crashes here; it's a pretty useless trigger regardless, but it is used in some of Cernd's plot dialogue in SoA.)
Post edited by Bhryaen on

Comments

  • devSindevSin Member Posts: 32
    edited August 2012
    Some longstanding low-hanging fruit in some of the BG2 AI object and trigger code:


    The Nearest object (14) does not function correctly (its results aren't reliable). It should return the Nearest matching (Object). (The nthNearest objects actually do function correctly.)

    The nthNearestEnemyOfType objects (51-59) all return the nearest matching object. They should correctly return the nth-nearest matching enemy of the caller.

    The nthNearestMyGroupOfType objects (61-69) all return the nearest matching object. They should correctly return the nth-nearest matching object whose group is the same as the caller.

    Attempting to nest additional objects with NearestDoor (76-85) causes a crash (e.g., NearestDoor(Myself)). It should correctly return the nearest closed door (either of just the caller or of the nested object, depending on how robust the original implementation is, I guess).


    The CombatCounterGT trigger (0x4085) is unreliable. It should always return true if the combat counter is currently greater than the specified value.

    The AreaCheckObject trigger (0x40D4) has been known to cause crashes. It should return true if the given creature is determined to be in the listed area; otherwise, it should always return false (even when it just can't check the area). (I'm not sure if there were ever any steps for reliably reproducing the crashes here; it's a pretty useless trigger regardless, but it is used in some of Cernd's plot dialogue in SoA.)


    Trying to do this from memory. Let me know if these should be formatted differently or if you need additional information.
    Post edited by Bhryaen on
  • SethDavisSethDavis Member Posts: 1,812
    Well, I've made the code more secure. Can't be sure if this fixes it as devSin didn't leave an example.
  • Avenger_teambgAvenger_teambg Member, Developer Posts: 5,862
    @SethDavis, I can think of global npcs. They have no area but found by scripts.

    Easy test, add this to dplayer3.bcs:


    IF
    AreaCheckObject("ar3200","kivan") // ~Kivan~
    THEN
    RESPONSE #100
    DisplayStringHead(Myself,1) // ~Why hast thou disturbed me here? Have thee no manners? Get out!~ [AJAN10]
    END


    If you fixed the crasher, then
    1. you won't see crash when you enable party AI
    2. you will see the head text when you are in ar3200 (Kivan's starting area)
    3. bonus quest: make the engine always notice kivan's starting area, even when the area isn't loaded.
  • SethDavisSethDavis Member Posts: 1,812
    @Avenger_teambg - Thank you kindly, 1 2 and 3 complete.
  • Avenger_teambgAvenger_teambg Member, Developer Posts: 5,862
    Confirmed fixed! - See i can say that without a BAD comment.
  • BhryaenBhryaen Member Posts: 2,874
    edited August 2012
    Erm... I added @Avenger_teambg's text to DPLAYER3.BCS and started a save... Didn't crash, but I got this repeating Ajantis mantra immediately and anywhere I went:

    [SNIP]

    This continued until I was able to toggle AI off, even after CLUAing to AR3200 to pick up Kivan. Then it went away entirely after CLUAing separately to AR1400 (where Ajantis is).
    Post edited by Bhryaen on
  • cmorgancmorgan Member Posts: 707
    Yep - expected behavior, I think -

    the script is constantly checking for Kivan and seeing if he exists. If it is working, you have a constant tream of the line from Ajantis' soundset playing over and over again. So I think, if I read your report right, you have officially confirmed that

    1. the game detects if Kivan is in his starting area - even if the party is not.
    2. If he is not in his starting area (I am assuming he was in your party when you went to see Ajantis) then the game detects that he is no longer there.

    The recheck would be to CLUA into Ajantis' area while Kivan is still in his starting area and see if that line still runs. If it does, the engine sees Kivan even if Kivan's area is not loaded currently. It should stop repeating when Kivan joins the party or is moved out of the area (like sending him to an inn).
  • BhryaenBhryaen Member Posts: 2,874
    edited August 2012
    Well, I just went directly to AR1400, picked up Ajantis- thought that it would actually have Ajantis himself repeating his own lines, but oh well.

    1. CLUAed in KIVAN into AR1400- stopped repeating.
    2. Recruited Ajantis, CLUAed to AR3200, recruited Kivan- repetition continued.
    3. CLUAed to AR3200 from start, recruited Kivan- repetition continued.
    4. CLUAed to AR3200 from start, CTRL-Y'd Kivan- repetition continued... corpse lingered...
    5. CLUAed to AR3200, recruited Kivan, got him killed in AR3200 (no corpse)- repetition continued even in different areas. Repetition stopped when getting him rezzed elsewhere though.

    Anyway, I think the issue was that it was crashing under these conditions before? So perhaps...

    Confirmed Fixed (?)
  • Avenger_teambgAvenger_teambg Member, Developer Posts: 5,862
    @Bhryaen Yep, this is confirmed fixed. You see the mantra when kivan is in his starting area (regardless of his party status or if the area is actually loaded).
    Previously it would crash when the area was not loaded.
  • cmorgancmorgan Member Posts: 707
    Which is a huge + for modders, developers, and players alike :)
Sign In or Register to comment.