Arco Vauhan Buggy in RC7

These are old bug reports that have been closed.
Locked
User avatar
PKodon
Militia Lieutenant
Militia Lieutenant
Posts: 127
Joined: Sat Apr 18, 2009 6:03 pm
Location: "Minocs. I've got a baaad feeling about this.... This is no cave!"

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
"Don't ask ..., I don't wanna know, and I don't wanna care!" - PK
Meet us on IRC --> Image
"... the hornet battlepod is the closest we have ingame to flying into battle in a wheelbarrow
with a bathtub nailed upside down to the top of it to provide armor."
- The Shrike
User avatar
Blitz
Militia Commander
Militia Commander
Posts: 342
Joined: Wed Mar 07, 2007 7:29 am

I can't seem to repro this. I tried with the Targetting ROM and without it. hmm...
george moromisato
Developer
Developer
Posts: 2997
Joined: Thu Jul 24, 2003 9:53 pm
Contact:

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.]
User avatar
Xephyr
Militia Captain
Militia Captain
Posts: 857
Joined: Fri Dec 14, 2007 1:52 am
Location: Orion Arm, Milky Way
Contact:

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.
Project Renegade (Beta) : "The Poor Man's Corporate Command!"
Real programmers count from 0. And sometimes I do, too.
User avatar
Aury
Fleet Admiral
Fleet Admiral
Posts: 5421
Joined: Tue Feb 05, 2008 1:10 am
Location: Somewhere in the Frontier on a Hycrotan station, working on new ships.

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...
(shpOrder gPlayership 'barrelRoll)
(plySetGenome gPlayer (list 'Varalyn 'nonBinary))
Homelab Servers: Xeon Silver 4110, 16GB | Via Quadcore C4650, 16GB | Athlon 200GE, 8GB | i7 7800X, 32GB | Threadripper 1950X, 32GB | Atom x5 8350, 4GB | Opteron 8174, 16GB | Xeon E5 2620 v3, 8GB | 2x Xeon Silver 4116, 96GB, 2x 1080ti | i7 8700, 32GB, 6500XT
Workstations & Render machines: Threadripper 3990X, 128GB, 6900XT | Threadripper 2990WX, 32GB, 1080ti | Xeon Platinum 8173M, 48GB, 1070ti | R9 3900X, 16GB, Vega64 | 2x E5 2430L v2, 24GB, 970 | R7 3700X, 32GB, A6000
Gaming Systems: R9 5950X, 32GB, 6700XT
Office Systems: Xeon 5318Y, 256GB, A4000
Misc Systems: R5 3500U, 20GB | R5 2400G, 16GB | i5 7640X, 16GB, Vega56 | E5 2620, 8GB, R5 260 | P4 1.8ghz, 0.75GB, Voodoo 5 5500 | Athlon 64 x2 4400+, 1.5GB, FX 5800 Ultra | Pentium D 3.2ghz, 4GB, 7600gt | Celeron g460, 8GB, 730gt | 2x Athlon FX 74, 8GB, 8800gts 512 | FX 9590, 16GB, R9 295x2 | E350, 8GB | Phenom X4 2.6ghz, 16GB, 8800gt | random core2 duo/atom/i5/i7 laptops
User avatar
Aury
Fleet Admiral
Fleet Admiral
Posts: 5421
Joined: Tue Feb 05, 2008 1:10 am
Location: Somewhere in the Frontier on a Hycrotan station, working on new ships.

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.
(shpOrder gPlayership 'barrelRoll)
(plySetGenome gPlayer (list 'Varalyn 'nonBinary))
Homelab Servers: Xeon Silver 4110, 16GB | Via Quadcore C4650, 16GB | Athlon 200GE, 8GB | i7 7800X, 32GB | Threadripper 1950X, 32GB | Atom x5 8350, 4GB | Opteron 8174, 16GB | Xeon E5 2620 v3, 8GB | 2x Xeon Silver 4116, 96GB, 2x 1080ti | i7 8700, 32GB, 6500XT
Workstations & Render machines: Threadripper 3990X, 128GB, 6900XT | Threadripper 2990WX, 32GB, 1080ti | Xeon Platinum 8173M, 48GB, 1070ti | R9 3900X, 16GB, Vega64 | 2x E5 2430L v2, 24GB, 970 | R7 3700X, 32GB, A6000
Gaming Systems: R9 5950X, 32GB, 6700XT
Office Systems: Xeon 5318Y, 256GB, A4000
Misc Systems: R5 3500U, 20GB | R5 2400G, 16GB | i5 7640X, 16GB, Vega56 | E5 2620, 8GB, R5 260 | P4 1.8ghz, 0.75GB, Voodoo 5 5500 | Athlon 64 x2 4400+, 1.5GB, FX 5800 Ultra | Pentium D 3.2ghz, 4GB, 7600gt | Celeron g460, 8GB, 730gt | 2x Athlon FX 74, 8GB, 8800gts 512 | FX 9590, 16GB, R9 295x2 | E350, 8GB | Phenom X4 2.6ghz, 16GB, 8800gt | random core2 duo/atom/i5/i7 laptops
User avatar
PKodon
Militia Lieutenant
Militia Lieutenant
Posts: 127
Joined: Sat Apr 18, 2009 6:03 pm
Location: "Minocs. I've got a baaad feeling about this.... This is no cave!"

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
"Don't ask ..., I don't wanna know, and I don't wanna care!" - PK
Meet us on IRC --> Image
"... the hornet battlepod is the closest we have ingame to flying into battle in a wheelbarrow
with a bathtub nailed upside down to the top of it to provide armor."
- The Shrike
george moromisato
Developer
Developer
Posts: 2997
Joined: Thu Jul 24, 2003 9:53 pm
Contact:

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:

Code: Select all

(eq aObjDestroyed (objGetObjRefData gSource "target"))
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.
Locked