View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000001 | FSSCP | gameplay | public | 2003-11-22 01:21 | 2015-05-20 05:09 |
| Reporter | Sticks | Assigned To | taylor | ||
| Priority | high | Severity | crash | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.9 | ||||
| Summary | 0000001: CTD With "Target In Reticle" | ||||
| Description | Game 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. | ||||
| Tags | No tags attached. | ||||
|
|
http://www.hard-light.net/forums/index.php/topic,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 |
|
|
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. |
|
|
http://fs2source.warpcore.org/bugzilla/show_bug.cgi?id=65 |
|
|
Marking it as fixed then. |
|
|
Ugh... this bug got crossed with some other bug. |
|
|
Does this still happen? |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
does this still occur.. i have not expirienced it in a while |
|
|
Probably because everyone's been trained not to use that key now. :-/ It still occurs. Righteous1 is currently working on fixing it. |
|
|
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. |
|
|
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? |
|
|
that would make a lot of sense |
|
|
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. |
|
|
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. |
|
|
* BUMP * Anyone tried to replicate this with the modified timer code yet? |
|
|
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. ;) |
|
|
* 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. |
|
|
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 |
|
|
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. |
|
|
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. Fixered. |
|
|
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." |
|
|
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. |
|
|
* BUMP * Anymore progress on recreating this? The -y_bug_fix thing is a strange hack so it would be preferable to not use it. |
|
|
Assuming that the crash can't be recreated. Just reopen again if you get it to crash. |
|
|
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... http://lore.maxgaming.net/~scp/mantis/bug_view_advanced_page.php?bug_id=0000897 ...but I'd prefer to keep everything consolidated in the original bug. |
|
|
*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? :) |
|
|
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. :) |
|
|
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 |
|
|
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!) |
|
|
Original code is back in. Hopefully we'll never see this blasted thing again. :D Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-11-22 01:21 | Sticks | New Issue | |
| 2003-11-23 10:37 | Goober5000 | Category | => gameplay |
| 2003-12-18 16:02 | kasperl | Note Added: 0000006 | |
| 2004-01-14 18:24 | Sticks | Status | new => assigned |
| 2004-01-14 18:24 | Sticks | Assigned To | => Goober5000 |
| 2004-01-14 22:19 | Lightspeed | Note Added: 0000034 | |
| 2004-01-16 10:24 | kasperl | Note Added: 0000037 | |
| 2004-02-05 06:27 | Goober5000 | Status | assigned => resolved |
| 2004-02-05 06:27 | Goober5000 | Resolution | open => fixed |
| 2004-02-05 06:27 | Goober5000 | Note Added: 0000158 | |
| 2004-02-05 06:28 | Goober5000 | Status | resolved => feedback |
| 2004-02-05 06:28 | Goober5000 | Resolution | fixed => reopened |
| 2004-02-05 06:28 | Goober5000 | Note Added: 0000159 | |
| 2004-02-05 06:28 | Goober5000 | Status | feedback => assigned |
| 2004-03-04 20:34 | RandomTiger | Note Added: 0000274 | |
| 2004-03-04 21:24 | Goober5000 | Note Added: 0000277 | |
| 2004-03-05 09:46 | Goober5000 | Note Added: 0000297 | |
| 2004-03-06 07:25 | ChronoReverse | Note Added: 0000336 | |
| 2004-04-07 01:11 | Kazan | Note Added: 0000701 | |
| 2004-04-07 05:31 | Goober5000 | Note Added: 0000717 | |
| 2004-04-07 14:25 | Righteous1 | Note Added: 0000728 | |
| 2004-04-08 05:25 | Goober5000 | Note Added: 0000734 | |
| 2004-04-08 14:00 | Kazan | Note Added: 0000736 | |
| 2004-04-08 14:55 | Righteous1 | Note Added: 0000738 | |
| 2004-04-30 04:10 | Goober5000 | Priority | high => immediate |
| 2004-05-24 18:00 |
|
Note Added: 0000953 | |
| 2005-06-22 20:21 | taylor | Note Added: 0002680 | |
| 2005-06-23 05:32 | Goober5000 | Note Added: 0002681 | |
| 2005-10-11 16:39 | taylor | Note Added: 0003527 | |
| 2005-10-11 17:04 | Goober5000 | Note Added: 0003528 | |
| 2005-10-11 17:04 | Goober5000 | Note Edited: 0003528 | |
| 2005-10-11 18:22 | taylor | Note Added: 0003530 | |
| 2005-10-11 18:22 | taylor | Assigned To | Goober5000 => taylor |
| 2005-10-21 13:08 | taylor | Status | assigned => resolved |
| 2005-10-21 13:08 | taylor | Resolution | reopened => fixed |
| 2005-10-21 13:08 | taylor | Note Added: 0003609 | |
| 2006-02-23 23:16 | Goober5000 | Status | resolved => feedback |
| 2006-02-23 23:16 | Goober5000 | Resolution | fixed => reopened |
| 2006-02-23 23:16 | Goober5000 | Note Added: 0004912 | |
| 2006-02-24 21:44 | bfobar | Note Added: 0004926 | |
| 2006-03-07 17:50 | taylor | Note Added: 0005079 | |
| 2006-03-20 12:04 | taylor | Note Added: 0005201 | |
| 2006-03-20 12:04 | taylor | Status | feedback => resolved |
| 2006-05-21 05:31 | Goober5000 | Status | resolved => feedback |
| 2006-05-21 05:31 | Goober5000 | Note Added: 0005547 | |
| 2006-05-21 05:31 | Goober5000 | Priority | immediate => high |
| 2006-05-21 05:38 | Goober5000 | Note Edited: 0000006 | |
| 2006-06-14 20:15 | Goober5000 | Note Added: 0005838 | |
| 2006-06-14 20:34 | taylor | Note Added: 0005839 | |
| 2006-06-14 20:37 | Kazan | Note Added: 0005840 | |
| 2006-06-14 22:03 | Goober5000 | Note Added: 0005841 | |
| 2006-06-14 23:38 | taylor | Status | feedback => resolved |
| 2006-06-14 23:38 | taylor | Resolution | reopened => fixed |
| 2006-06-14 23:38 | taylor | Note Added: 0005844 | |
| 2006-10-27 03:16 | Goober5000 | Status | resolved => closed |
| 2006-10-27 03:16 | Goober5000 | Fixed in Version | => 3.6.9 |
| 2007-03-23 02:16 | taylor | Status | closed => resolved |
| 2007-03-23 08:14 | taylor | Status | resolved => closed |
| 2013-10-07 23:52 | Goober5000 | Status | closed => resolved |
| 2015-05-20 05:09 | Goober5000 | Relationship added | related to 0003130 |
