Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Black Wolf on June 13, 2006, 01:44:51 am
-
The Y targetting bug is ****ing annoying. I use Y targetting constantly, and I know not to target debris with it because there's a good chance that it'll crash my game. But occasionally I go to Y target a fighter, miss, and get some debris, thereby causing the aforementioned crash. I know you guys have tried to fix it and can't find the cause, so, I propose a different solution.
Turn off Y targetting for debris. Make it impossible to trigger the single circumstance (AFAIK) that triggers this stupid, frustrating, annoying, unfixable bug. Just go around it.
*NB - I know I sound pissed off in this post, and I am, but at the game, not at you coder people. :)
[EDIT]Oh, already a topic on this. Erm, didn't know, my bad. Sorry.
-
I agree with Black Wolf, I think it is a good idea to disable the feature to "Y" any debris, just until you come up with a solution. I encounter this bug many times, it is really frustrating when you made 2 objectives out of 3 in a difficult mission on Insane, then accidentally press "Y" and get this error. Then everything is from scratch. Anyway, who wants to target debris with "Y" ?
-
Already done this actually, it's just not in CVS yet. I keep hoping to find the actual problem and doing this wouldn't help in that endeaver. I'm going to wait until the last possible second before adding this code, and if I can't figure it out then debris targetting with "Y" will be disabled in 3.6.9.
-
I use 3.67 and i got no probs with Y.Is it just in the later builds?
-
Taylor, I don't know if you saw my post in the RC2 thread, but I've found the crash replicatable on all the machines I've tried in FEP-'Battlefield', where you start off pointing at the Arcadia that was destroyed before the mission started. I'm going to see if it's consistent across other missions with the FREDded 'pre explode' thing. I hope this helps.
-
I suppose it's also to do with where in the code the bug is, after all, in order to know to ignore it, it still has to read what's under the hud when Y is pressed, but fingers crossed, nonetheless :)
-
There are several problems preventing a fix:
1) It only appears to happen in Windows builds only, Linux and OS X builds don't have this problem. That makes it much harder for me to debug since I use Linux. If it would just happen under Linux that I could hunt it down with a vengence.
2) Nothing in that code has changed between 3.6.7 and now. We also have no real idea what the problem was in the first place. The thought is that it was the asm timer code, which has since been replaced. The other idea is that it is linked to filtering debris out of the reticle list but that doesn't appear to be it either (see next item...).
3) The -y_bug_fix cmdline option is there to switch between the original code and the previous fix for the Y-bug which changed how debris gets filtered out of the targetting list. Numerous bug reports have indicated that the -y_bug_fix option no longer has any affect on the problem however. That means that both the new fix, and the original fix, no longer work.
I'm working on a couple of ideas right now and will get test builds out to a couple of people later today via PM. If we're lucky then these changes will sort it out. If not then I still don't even know if not targetting debris at all will even work (since I can't recreate it either way).
-
It's like a virus, developing resistance to new fixes over time, then reappearing with a vengeance. We should be scared, it may eventually multiply and take over our whole code base :nervous:
-
Who'd have though skynet would be born from a tageting bug in a public release of a 3d space combat games source code.
wow! :lol:
-
Woot!?!? What do my eyes see! Disable targetting for debris? It was my favourite past time to roll around after a battle and target pieces of debris floating around. It was somehow so hilarious to find a floating fighter cockpit flying towards the emptyness of space. :drevil:
Oh well, I havent done that in ages. I guess I've grown out of it...
-
Don't have time to PM anyone individually, so here: http://icculus.org/~taylor/fso/testing/20060613-win32.rar
It's basically RC2 with a few more bug fixes, and changed targetting code regarding the Y-thing. Don't know whether it actually fixes the crash or not though. I did try to build it with speech and voice recognition support though so if you use those be sure to report if that acutally works or not.
-
voice recognition appears to be broken. same problem as detailed in the thread in Recent Builds
-
This build does not fix the "Y" crash. Just encountered it couple of minutes ago.
-
voice recognition appears to be broken. same problem as detailed in the thread in Recent Builds
Yeah, figured. Unless RandomTiger comes back to fix the voice recognition feature you can pretty much consider it dead. No one else knows how to fix it so if he doesn't do it then we might remove the code from CVS.
This build does not fix the "Y" crash. Just encountered it couple of minutes ago.
I updated the build at the same link with the second variation of the same fix I was working towards. This one is specificially setup to figure out if the last remaining theory for the cause of the crash is correct. If this doesn't work then we'll have pretty much nothing to go on to find a fix.
-
Well ... just downloaded again and tested... it's still there :(
-
Maybe we should just rewrite that whole section of code, from scratch, to emulate the original :v: behavior. :)
-
Glort, Why isn't possible to just copy the original Y targeting code?
-
Maybe we should just rewrite that whole section of code, from scratch, to emulate the original :v: behavior. :)
I changed it up pretty good in those two builds actually. But, it's only a problem under Windows. That would seem to indicate that it's not just a generic code problem so even if we totally scrap that code and rewrite it, whatever is actually causing the problem could still be there. We know it can't the asm timer code because that's been replaced. It's probably not an issue with filtering out the targets for the reticle list, since I just rewrote how that works.
Also, this code is still 100% retail, just as :v: wrote it. That the problem seems to come and go, and only in FS2_Open builds, makes it highly unlikely that their original targetting code is actually at fault here. It could be, but I'm leaning towards an SCP introduced issue.
-
Has anyone ever gotten this crash using a debug build?
If not then I might have just hit on something while testing on a Windows box.
EDIT: See if this does anything different: http://icculus.org/~taylor/fso/testing/20060614-win32r.rar
-
Man u did it !
Unless anyone says otherwise, everything regarding "Y" works just fine now.
Nice job :yes: :D
-
Wow. If that really fixed it for good, that almost warrants a version jump on its own... that thing has been a staple of FS2 (though I've never seen it myself) for as long as I've known about the project ;)
-
Has anyone ever gotten this crash using a debug build?
Nope; that was a major complaint when the bug first reared its ugly head:
Now I know what it feels like to be a quantum physicist. :rolleyes:
It seems that the "Y" targeting bug doesn't want to be found out. I have determined that the crash occurs in hud_reticle_pick_target in hudtarget.cpp, but I can't figure out anything more than that, for the following reasons.
1) The crash doesn't occur using the debug build.
2) Any attempt to trace through hud_reticle_pick_target causes the bug to not occur. :confused:
I just compiled and ran two versions of fs2_open_r... one with no modifications to hudtarget.cpp, and one with just three commands spaced at beginning, middle, and end of the function that printed a number to a file. The no-mod build crashed, while the trace build worked just fine. :wtf:
Okay. Following Phreak's suggestion, I systematically rolled back each file committed on 2/16 to pinpoint the error. The results are disturbing.
The 'Y' targeting bug was introduced in weapons.h, when version 2.6 was updated to version 2.7.
This doesn't make any sense! Look at the CVS diff (http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_open/code/weapon/weapon.h.diff?r1=2.6&r2=2.7&f=h) between those two versions. The changes were trivial - one #define and two float declarations. Why on earth would this introduce a bug?!? Could the size change of the BWI struct have anything to do with it?
EDIT: See if this does anything different: http://icculus.org/~taylor/fso/testing/20060614-win32r.rar
I'll try it tonight. Does this use the original code?
-
I think this one did the trick. I selected many debris from asteroid to ship debris and no crash so :yes: way to go!!
-
This actually should have been figured out earlier, it's almost too easy not to have been. Lets look at what we know:
1) only happens on Windows. Both Linux and OS X don't have this problem
2) the code has hardly been touched since the original source release
3) possible cause 1, the timer asm, wasn't the problem
4) possible cause 2, the debris filtering, rewriten yesterday so thay shouldn't be it
5) only happens in release builds
6) doesn't happen in release builds when you are trying to trace it
At this point only one thing should be making your ears perk up... compiler optimizations. Yep, the only thing different between the build that works and the one that doesn't is the compiler optimizations. Specifically it's "Global Optimizations" (/Og) in MSVC. I tested 9 different builds with various optimization settings and having that one option enabled made it crash every single time. The 20060614 build is the same code as the 13 one but with the optimizations set at "Maximum Speed" instead of "Custom".
So, after we test it against a build without any of the code changes from me, we can know for sure that the one option is the problem. We can either disable it with a #pragma in hudtarget.cpp (I think that will work anyway) and leave the optimizations as they are, or just use the "Maximum Speed" option for release builds.
Of course the biggest problem for me was just tracking down a Windows box to test with. :)
-
Yay! :)
-
Taylor, you've done it. It even passes the FEP:Battlefield test, with the reticle avoiding debris for actual targets. I knew something funny was going on when the last kara build had the crash, but when I tried to get a spew with a debug build it never happened. Again, fantastic work.
-
At this point only one thing should be making your ears perk up... compiler optimizations. Yep, the only thing different between the build that works and the one that doesn't is the compiler optimizations.
I would double check if it's really broken optimization and not some bugs in code that are triggred by these optimizations. Simply starting game and exiting results in several conditional jumps/uses of uninitialized values being detected by valgrind.
-
I would double check if it's really broken optimization and not some bugs in code that are triggred by these optimizations. Simply starting game and exiting results in several conditional jumps/uses of uninitialized values being detected by valgrind.
I've run it through Valgrind many, many times and it hasn't hit on this code (that I ever remember at least). You are going to find quite a few Valgrind messages about conditional jumps and uninitialized values, I've already fixed more than half of them, but I don't think I've never had it hit on the targetting code. This has only ever been an issue for Windows release builds. I've never been able to recreate this issue with GCC, even with most every optimization enabled and maxed out. There is nothing all that strange with that code anyway (other than it being outdated and needing to be replaced). The same basic methods are used in many places in :v:'s original code.
It is going to get double checked though. I had quite a few code changes there in these test builds which could have attributed to it working. It won't be considered 100% fixed until it's verified to work in a build without those changes (which, so far, it has).
-
Many thanks for resolving this, and a tip of the hat to the persistence required to do so.
Incidentally... the nature of the problem being compiler-related, it reminds me of a young coder in college who couldn't get a homework program to function at all. The teacher examined the source and found every line commented out; she asked "why on earth did you do that??", to which the young coder replied:
"Well, that's the only way i could get it to compile."
-
I'm a very neophyte coder, so I didn't even know that something like changing an optimization setting could do something like this. (Come to think of it, I've never even used an optimization setting. :p) Do you have any specific idea why that setting would have borked this specific targeting function, or is that question just best left unanswered? Regardless, this is great news; it was only recently that I started encountering this bug (or at least, that I realized that I was encountering this bug), but even in that short time, I learned to be very careful with the Y key. It'll be great to go back to targeting whatever and wherever I please. :)
-
Somehow, while this bug has greatly annoyed me, I can't help at being slightly amused. I with goober, definetly Quantum physics vibe here as you can't find it when you're looking for it. Can't you track exactly what the global Optimisation option is doing and see which exact optimisation is causing the crash? I'm a code newb so I'm not sure if its even possible.
-
Well, there is more to it than just /Og, but it's the easy fix and doesn't hurt much. If you notice, I said that it works with /O2 ("Maximum Speed"), which the test build was compiled with. /O2 basically implies /Og, though it doesn't crash. But we need something to work for 3.6.9 and simply removing /Og fits the bill. After 3.6.9 is out we can afford to spend the time to figure out in greater detail exactly what series of compiler optimizations is doing this. Also at issue is that /Og is obsolete, even in MSVC6, and Microsoft recommends not using it. So though /O2 may do basically the same thing, it may not have the same optimization issue.
This is just the nature of compiler optimizations, though I'm not good enough to go much futher in figuring this out than I already have. The optimization aggressiveness/bugs can vary from compiler to compiler, even different versions, so it's just something to be aware of. The Linux version had issues with certain optimization settings in GCC3, but it's largely ok in GCC4, for instance. So using the same basic settings in VC++ 2005 that you use in VC++ 6 may give slightly different results. Giving a detailed account of exactly what is going on here is over my head though.
As far as broken code goes, well we know the problem function and at least 4 coders have been through it in great detail over the past 3 years. Exactly what in there is the issue will take someone smarter (or luckier) than the rest of us to identify. I even replaced most of the code which we thought was at issue for the first test build, and it still crashed.
-
'Y' targeting? Y-axis or 'target ship in reticle'?
-
'Y' targeting? Y-axis or 'target ship in reticle'?
'Y' as in 'target ship in reticle' (the default key for that action).
-
Taylor, could you please check my error reports in the RC2 thread, the issue is still in some .dll file. Earlier builds work fine.
-
Taylor, could you please check my error reports in the RC2 thread, the issue is still in some .dll file. Earlier builds work fine.
I think it's something with your OpenAL setup. Make sure you are using the newest version of OpenAL (http://www.openal.org/downloads.html), and don't have ct_oal.dll or nvopenal.dll in your system32 directory.
-
I have nvopenAL, however it being listed as an Nvidia file makes me wary to just delete it.
-
I have nvopenAL, however it being listed as an Nvidia file makes me wary to just delete it.
Just move it to a different directory then. The nvidia drivers are older than the current version required (ie, I don't think it's proper 1.1). Basically it's falling back on that hardware specfic version and that dll is incompatible. It can cause the builds and launcher to hang and/or crash.
-
Hows the Y target bug solution going,? I had my first error after reading this, I cidn't believe it could happen to me until now
-
Hows the Y target bug solution going,? I had my first error after reading this, I cidn't believe it could happen to me until now
Just test it again in RC3, which is going up in the next few minutes (or however long it takes to finish building/uploading the Windows binaries).
-
Spanktastic, Cheers.
-
YES, it works. Thanks Taylor.