Source Code Project Mantis - FSSCP
View Issue Details
0000001FSSCPgameplaypublic2003-11-21 20:212015-05-20 01:09
Assigned Totaylor 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.6.9 
Summary0000001: CTD With "Target In Reticle"
DescriptionGame crashes to desktop under release build when the "Target In Reticle" command is used more than once in rapid succession. Seems to affect debris more than ship objects.
TagsNo tags attached.
related to 0003130closed FSO 4 The insidious beam crash bug 
Attached Files

2003-12-18 11:02   
(Last edited: 2006-05-21 01:38),17649.0.html

this is the forum thread that handles this bug, i thought it was a good idea to link to it, in case someone is going to fix this one.

new link // Goober5000

edited on: 05-21-06 01:38
2004-01-14 17:19   
Only happens with debris, and seems to be dependant on the distance and speed of the debris you're targetting. Distant, fast debris tends to crash the game, whereas near and slower debris is properly targetted most of the time.
2004-01-16 05:24
2004-02-05 01:27   
Marking it as fixed then.
2004-02-05 01:28   
Ugh... this bug got crossed with some other bug.
2004-03-04 15:34   
Does this still happen?
2004-03-04 16:24   
Yup. But I'm in the middle of some restructuring that I hope will fix it. If not, we'll have to either ignore it or rewrite the targeting code.
2004-03-05 04:46   
It just occurred to me that this bug only seems to happen when a ship arrives in the mission. I just finished my header file restructure and played the 03_04_2004 build, and the Y function worked fine except when a ship warped in. Perhaps we should investigate the ship arrival code.
2004-03-06 02:25   
I dunno. What do you consider "just arrived"? Do you mean within 5 seconds of jumping in?

In any case, this still occurs, and still only occurs in the release builds.

Easily replicated too, play "Surrender, Belisarius!" Wait for a herc wing to jump in and get close to the transports. Blow them up and mash "y" repeatedly to target the really fast moving herc debris and it'll crash to desktop.
2004-04-06 21:11   
does this still occur.. i have not expirienced it in a while
2004-04-07 01:31   
Probably because everyone's been trained not to use that key now. :-/

It still occurs. Righteous1 is currently working on fixing it.
2004-04-07 10:25   
Yes, it still happens. Specifically it will crash if there is debris and a ship in the reticle FOV. If the debris gets targeted, it crashes.

I have a work around that prevents the crash but I'm trying to understand and track down the root cause of the crash. According to the logic, the debris should not be in the list of targetable objects if there's a ship in the FOV.

There's no reason to hold 3.6 up for this one though. I can release the workaround and continue looking for the root cause on the side.
2004-04-08 01:25   
Ooh, I just had an interesting instance of this crash. This time, only one ship was in the reticle, with nothing else in the way -- but I had debris targeted. When I pressed Y again, it crashed. (Basically, what happened is that I pressed Y, accidentally targeted debris, flew by the debris, and pressed Y again.) So perhaps the error is caused by culling a piece of debris that is targeted?
2004-04-08 10:00   
that would make a lot of sense
2004-04-08 10:55   
I agree, I believe that is what is happening. My question is, how is the debris getting targeted in the first place...and why does it not occur in the debug builds. I've had the same thing happen but there are definitely ships in the FOV and according to the logic, the debris shouldn't be targetable.

I think the last bit of code is what targets the debris. Maybe the ships are already in the save_list and cur_list so it goes through the logic at the end and picks the debris. Next time you hit Y, you cull the address your targeting. But I'd expect this to be reproducable in debug though.
2004-05-24 14:00   
Same bug here. I'm using a button on my joystick for this. Sometimes it crashes and othertimes not.
It never happend when there was no debris.
2005-06-22 16:21   
* BUMP *

Anyone tried to replicate this with the modified timer code yet?
2005-06-23 01:32   
That would require rolling back the original code while the check was run. It's important to do; I just haven't gotten around to it yet. ;)
2005-10-11 12:39   
* BUMP *

Do you want me to just roll this back in CVS and see if it crops up in redmenace's builds? I can add a temporary cmdline option or something so that it's easy to switch between the code for testing purposes.

I think it's well past time to clear this thing out.
2005-10-11 13:04   
That would be much appreciated. :)

Hopefully the modified timer code will have this nipped in the bug. Er, bud. ;)

edited on: 10-11-05 13:04
2005-10-11 14:22   
Ok, I'll get that done as soon as I can. I reworked the timer code again (alot cleaner now) to hopefully get rid of the dual core problems. After someone reports that the new code works I'll make all of the changes.

It will use the original target selection code by default and have a -y_bug_fix cmdline option to use the new code. This way if it messes up we can just tell people to use the cmdline option (or not) while we work out the problem.
2005-10-21 09:08   
Well it has been in the past 8 or 9 builds and not a single complaint. Considering this fixed until a new report shows up. I'll leave the -y_bug_fix option there for a while just in case.

2006-02-23 18:16   
From 0000828, reported by bfobar...

taylor: "Also try the -y_bug_fix cmdline option and see if it still does the same thing. There is an old bug on this but we thought it was linked to the bad timer code which has since been replaced. After that change no one has been able to recreate the CTD. The previous hack to deal with the targetting CTD is still there if you use the -y_bug_fix option but otherwise just uses the retail code.

"If -y_bug_fix makes it stop crashing then let us know as it would likely be the same problem and the previous bug hunt yielded a false cause."
2006-02-24 16:44   
I tried a mission with and without the command line -y_bug_fix. I haven't gotten a crash yet either way this session, but so far I can say that with the -y_bug_fix turned on, reticle targeting is better in that it will not target debris 10k away when you're pointing straight at an enemy ship. I will run a while with this on and see if the crash reoccurs.
2006-03-07 12:50   
* BUMP *

Anymore progress on recreating this? The -y_bug_fix thing is a strange hack so it would be preferable to not use it.
2006-03-20 07:04   
Assuming that the crash can't be recreated. Just reopen again if you get it to crash.
2006-05-21 01:31   
Reopening. Looks like this was never actually fixed... I just haven't gotten around to testing it since October... :nervous:

Latest bug discussion is here...
...but I'd prefer to keep everything consolidated in the original bug.
2006-06-14 16:15   
*bump* for great justice. :)

So, now that we know the cause of this, can we rip out all the testing code and put the original retail code back in? :)
2006-06-14 16:34   
Yeah, I have the commit ready to restore it to the retail code. I'll try and get that in later tonight.

It would be a really good idea if someone else fixed the project file to get rid of the optimization setting issue though. My files aren't in a sane state right now, plus I always seem to get something bad in there when I change those. :)
2006-06-14 16:37   
issues that only manifest under compiler optimization are often extremely subtle bugs - such as in wxWidgets if you make one of your event handlers on your class

void eventFoo() instead of void eventFoo(wxEvent &bar) it will be fine under debug builds but release will crash on triggering eventFoo
2006-06-14 18:03   
Okay, I committed the project file fixes. You can mark this fixed once the original code is back in. :)

(This might be the longest unresolved SCP bug in Mantis!)
2006-06-14 19:38   
Original code is back in. Hopefully we'll never see this blasted thing again. :D


Issue History
2003-11-21 20:21SticksNew Issue
2003-11-23 05:37Goober5000Category => gameplay
2003-12-18 11:02kasperlNote Added: 0000006
2004-01-14 13:24SticksStatusnew => assigned
2004-01-14 13:24SticksAssigned To => Goober5000
2004-01-14 17:19LightspeedNote Added: 0000034
2004-01-16 05:24kasperlNote Added: 0000037
2004-02-05 01:27Goober5000Statusassigned => resolved
2004-02-05 01:27Goober5000Resolutionopen => fixed
2004-02-05 01:27Goober5000Note Added: 0000158
2004-02-05 01:28Goober5000Statusresolved => feedback
2004-02-05 01:28Goober5000Resolutionfixed => reopened
2004-02-05 01:28Goober5000Note Added: 0000159
2004-02-05 01:28Goober5000Statusfeedback => assigned
2004-03-04 15:34RandomTigerNote Added: 0000274
2004-03-04 16:24Goober5000Note Added: 0000277
2004-03-05 04:46Goober5000Note Added: 0000297
2004-03-06 02:25ChronoReverseNote Added: 0000336
2004-04-06 21:11KazanNote Added: 0000701
2004-04-07 01:31Goober5000Note Added: 0000717
2004-04-07 10:25Righteous1Note Added: 0000728
2004-04-08 01:25Goober5000Note Added: 0000734
2004-04-08 10:00KazanNote Added: 0000736
2004-04-08 10:55Righteous1Note Added: 0000738
2004-04-30 00:10Goober5000Priorityhigh => immediate
2004-05-24 14:00user116Note Added: 0000953
2005-06-22 16:21taylorNote Added: 0002680
2005-06-23 01:32Goober5000Note Added: 0002681
2005-10-11 12:39taylorNote Added: 0003527
2005-10-11 13:04Goober5000Note Added: 0003528
2005-10-11 13:04Goober5000Note Edited: 0003528
2005-10-11 14:22taylorNote Added: 0003530
2005-10-11 14:22taylorAssigned ToGoober5000 => taylor
2005-10-21 09:08taylorStatusassigned => resolved
2005-10-21 09:08taylorResolutionreopened => fixed
2005-10-21 09:08taylorNote Added: 0003609
2006-02-23 18:16Goober5000Statusresolved => feedback
2006-02-23 18:16Goober5000Resolutionfixed => reopened
2006-02-23 18:16Goober5000Note Added: 0004912
2006-02-24 16:44bfobarNote Added: 0004926
2006-03-07 12:50taylorNote Added: 0005079
2006-03-20 07:04taylorNote Added: 0005201
2006-03-20 07:04taylorStatusfeedback => resolved
2006-05-21 01:31Goober5000Statusresolved => feedback
2006-05-21 01:31Goober5000Note Added: 0005547
2006-05-21 01:31Goober5000Priorityimmediate => high
2006-05-21 01:38Goober5000Note Edited: 0000006
2006-06-14 16:15Goober5000Note Added: 0005838
2006-06-14 16:34taylorNote Added: 0005839
2006-06-14 16:37KazanNote Added: 0005840
2006-06-14 18:03Goober5000Note Added: 0005841
2006-06-14 19:38taylorStatusfeedback => resolved
2006-06-14 19:38taylorResolutionreopened => fixed
2006-06-14 19:38taylorNote Added: 0005844
2006-10-26 23:16Goober5000Statusresolved => closed
2006-10-26 23:16Goober5000Fixed in Version => 3.6.9
2007-03-22 22:16taylorStatusclosed => resolved
2007-03-23 04:14taylorStatusresolved => closed
2013-10-07 19:52Goober5000Statusclosed => resolved
2015-05-20 01:09Goober5000Relationship addedrelated to 0003130