Transcendence

Okay, here's the scoop:

Started new vanilla game with Sapphire.
No Targeting ROM in system (at least, not up to where I discover the bug).
Fought Centauri Warlords, bought NAMI missile launcher.
Got mission from Raisu Station.
Mission pointer points at Arco Vaughan's Container Habitat
Go kill Arco with missiles I get from Raisu, loot Arco's ship.
Mission pointer still points at Arco's station
Kill Arco's container habitat, loot it, leave.
Mission pointer still red, still points at Arco's Container habitat.

Also, without a Targeting ROM, I don't know if anything should show up in the lower-left HUD display, but nothing does.

EDIT: Also, when you get back to Raisu, everyone is in hiding, so the whole mission is broken.

PK

I can't seem to repro this. I tried with the Targetting ROM and without it. hmm...

PKodon, can you remember if you saved at any point? For example, did you save just before you attacked Arco?

[I'm pretty clueless, so I'm searching for anything unusual.]

When I triggered the bug, I'm pretty sure I saved just before killing him. It's just reflex for me to save before attacking something.

Not sure about the rest of it, but I think that this may have created the illusion of everyone still being in hiding...

This switch:
(sysFindObject gSource "s +centauriWarlords; N:100;")
Causes the 'hiding' dockscreen...

I may be wrong and it is still sending them to the 'inprogress' pane; the problem is that the two panes display IDENTICAL text, so there is no way to tell them apart...

I looked through it again, and nowhere in the code is the pane 'MissionInProgress' ever used as far as I can see.... which is odd.

Okay, here's the saved game, just before killing Arco:

http://dl.dropbox.com/u/3919962/Transce ... hinara.sav

And I've learned to always save before a (possible) major battle.

PK

Thank you! That helped and I was able to fix the bug.

This is definitely important enough that I will do a quick RC8 tomorrow. Thanks to everyone who helped debug it!

For those who are interested, the full gory details are below. Feel free to skip if you're not interested:

1. There was code on Raisu station that gets called when Arco is killed. The code checks the object killed against its internal variable:
2. In a previous optimization, I had changed objGetObjRefData so that it stores a global ID, not a pointer. When someone asks for the pointer (with objGetObjRefData) it looks up the global ID and returns the pointer.

3. In another optimization, I changed the code that looks up a global ID to NOT return a pointer (it returns Nil instead) if the object has been marked as destroyed (this avoids problems with code holding around references to objects that are about to get deleted).

4. Finally, in RC7, to fix a crash, I moved a piece of code that marks an object as destroyed to an earlier point--in fact it got moved to a point BEFORE the call to <OnObjDestroyed>. [That's necessary because sometimes the code in <OnObjDestroyed> ends up destroying the object again (for various reasons). Knowing that it is already destroyed helps to prevent a bad recursion.]

5. So when the Raisu station got called on <OnObjDestroyed> it checked to see if the object that was destroyed (aObjDestroyed) was equal to its stored value for Arco. But the call to (objGetObjRefData gSource "target") noticed that the object that it was supposed to return (Arco) was already marked as destroyed, and so it returns Nil instead. So Raisu never gets notified that Arco was killed.

6. The bug was hard to reproduce because objGetObjRefData caches its pointer. Right after a save/load, the cache is empty, so objGetObjRefData does a full lookup, which triggers the bug.