[(BG1\2) BUG] AreaCheckObject trigger (0x40D4) has been known to cause crashes.
AndreaColombo
Member Posts: 5,533
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.)
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
0
Comments
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.
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.
[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).
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).
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 (?)
Previously it would crash when the area was not loaded.