Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Beowulf on December 21, 2003, 01:57:27 am
-
Any work on that particular bug? You know, the one where the afterburners fail to function?
http://www.hard-light.net/forums/index.php/topic,18871.0.html
-
[color=cc9900]You are holding the button down, right? Is it bound to a button on your joystick that might have some funky settings attached to it so it 'clicks' instead of holding? Try rebinding it, say, to a button on the keyboard (or a different button on the keyboard if you're already using one).[/color]
-
This a new bug that affects FS2 retail and Open Odyssy. I've seen a few cases of people reporting it (Always on XP and W2K systems).
I'm sure the SCP would love to fix it but at the moment no one has been able to come up with a common factor between the cases of people who suffered it.
-
I thought running in compatability mode fixed it
-
For anyone on XP it works but Beowulf is running W2K IIRC and the fix doesn't work for him (His is the only case I've heard of it happening on W2K)
-
I have the exact same issue as Beowulf. Windows 200 SP4, all hotfixes applied, MS Sidewinder Force Feedback joystick. Pressing wither the afterburner button or the keyboard equivalent results only in the afterburner shutdown noise being played.
-
Have a look in my FAQ's technical section and try the fix from there. I'm interested in knowing if Beowulf is an isolated case or if all people using W2K can't solve the problem the way people with XP can.
-
Originally posted by Admiral Nelson
I have the exact same issue as Beowulf. Windows 200 SP4, all hotfixes applied, MS Sidewinder Force Feedback joystick. Pressing wither the afterburner button or the keyboard equivalent results only in the afterburner shutdown noise being played.
Well here's another case, same as mine. I've tried compatability mode, no such luck.
Because this is a problem with only one action--a regular bind--(the ONLY thing wrong on my system) I am lead to believe there must be some coding issue. [V] must have simply messed up somewhere.
I would really love to play FS2 on my system, it's half the reason I bought it! Thanks for any help here. (And just so you know, I promise to FRED if this thing is fixed. I PROMISE. You know this word?)
Whoever fixes this bug gets me as a Fredder for missions of any project of their choosing. :nod:
~Beowulf
-
Well now... :drevil:
Unfortunately I'm very busy this week and the next. If Phreak doesn't get to it first, I'll look into it after 1/1. :nod:
-
I'm having this problem too, interestingly enough the problem has APPEARED after having not occured. I figured it might be an issue with pilot data, but...it doesn't seem to be. I'm going to try some more things and see if I can isolate it anymore.
Problem Stats:
Issue - Same, hit the button, afterburner shutoff sound plays.
System Specs - Win2k3 Server, P4-2.4C, 512mb RAM, GF4Ti4200
Things I recently did to my system - Windows Update to newest, BIOS flash, driver updates on NIC, Sound, and Mobostuff (sadly I just did a lot, although I don't remember where in these things the afterburner stopped working)
Things I've tried - Making new pilot, disabling joystick.
I also tried using the original FS2 EXE, which worked fine. This sucks, especially since it wasn't happening before.
Things that worked - Telling 2k3 to run the exe in compatibility mode.
This sucks, but the code's open. I'm going to see if I can do something about this, since I'm bored as hell and not that awful of a coder.
-
:welcome: Feel free to take a look at the code.
It's very odd that this problem didn't occur with the retail version. Most people reported it with both FS2_open and the retail one. Hope you find it.
-
I'm having the exact same problem as beowulf. My energy routing systems stuff is working just fine, however the thrusters don't fire even with full power. It's the oddest bug in a game I've ever heard of.
I'm also running on windows 2000 pro. I've tried rebinding and that doesn't work, and I know of no way to run the game in compatibility mode in windows 2k :(
-
Seems like MS have updated the same component that caused the XP problem in Win2K now.
Just out of interest have you recently installed a service pack or any updates? It seems strange to me that no one reported the problem on Win2K for ages and now it seems to be affected all of a sudden.
-
I haven't run any windows updates since the blaster virus, only because my computer doesn't house any critical information and doesn't run the windows web server.
-
this bug would be fixed if we were able to replicate it. figures.
-
Alright. Firstly a major disclaimer, I'm NOT familiar with this code at all so things I say could very well be stupid and wrong. If so, I'm sorry for wasting anyone's time. But here's what I've dug up.
Fortunately, as I looked through the code, I found that the afterburner shutoff sound is only referenced in three lines of code, all three in "ship/afterburner.cpp". So I poked in there, found the three possible points, and put mprintf outputs there so I could see which one was reached. For me, this block of code was the problem:
EDIT - this is "ship/afterburner.cpp" around line 245, just to make it easy to find :)
now = timer_get_milliseconds();
if ( (now - Player_afterburner_start_time) < 1300 ) {
mprintf(("Condition 1, %d - %d\n", now, Player_afterburner_start_time)); // ADDED by me
snd_play( &Snds[SND_ABURN_FAIL] );
return;
}
Looking further into it, it seems that timer_get_milliseconds() is returning a value of (to use a sample from the logged output) -921274971. This negative value counts up (i.e. a later return from the timer will give a greater number, albeit still negative).
I'm ASSUMING that the timer function is NOT supposed to return negative values. Player_afterburner_start_time is initialized to 0 and not set until after this block executes. In addition, it's set equal to timer_get_milliseconds().
Looking at that function reveals it's chock full of OS and possibly compiler dependant assembler. This is icky, and will take me much more time to pour over. But on the upside, it makes sense that something like this would be what's causing the problem. Hopefully this helps though :).
Dave
-
Sounds like you're making progress.
Originally posted by Gravaton
Looking at that function reveals it's chock full of OS and possibly compiler dependant assembler. This is icky, and will take me much more time to pour over. But on the upside, it makes sense that something like this would be what's causing the problem. Hopefully this helps though :)
That could explain why only some people running Win2K and XP have ever reported the problem.
Keep up the good work.
-
Heh seems the assembler wasn't as tough as I thought it would be, I seem to have found a possible fix for the issue. Here's the relevant chunk again (code/io/timer.cpp lines 292-308):
#if defined(_MSC_VER)
// Timing in milliseconds.
_asm mov edx, temp_large.HighPart
_asm mov eax, temp_large.LowPart
//_asm shld edx, eax, 16 ; Keep 32+11 bits
//_asm shl eax, 16
// edx:eax = number of 1.19Mhz pulses elapsed.
_asm mov ebx, Timer_freq
// Make sure we won't divide overflow. Make time wrap at about 9 hours
sub_again:
_asm sub edx, ebx ; subtract until negative...
_asm jns sub_again ; ...to prevent divide overflow...
_asm add edx, ebx ; ...then add in to get correct value.
_asm div ebx
//eax = milliseconds elapsed...
_asm mov tmp, eax
tmp is an int, and the problem SEEMS to be that, on my system, at the end of this block eax is equal to a number around 33,000,000. This, when moved into tmp (which is a regular int) gets taken to be a negative number of about -9,000,000. And at that point everyone gets all sad. The solution I've found is to turn tmp into an unsigned int (as there's no way any of the system timer functions would EVER be returning a value less then zero according to MSDN specs), and also turn the "now" variable (in code/ship/afterburner.cpp line ) for the afterburner into an unsigned int as well. This worked.
Then I realized that all that NEEDS to be changed is the "now" variable, as the timer function will return a signed int that can be converted to unsigned without losing any data. Tried it, tested it, it works.
So to sum it up, changing the declaration of now (code/ship/afterburner.cpp line 242) from "int" to "unsigned int" seems to fix this problem on my machine. The scope of this change SEEMS to be restricted to the problem area alone, but I'd once again like to reiterate that I'm not very familiar with the project overall and it's theoretically possible that this could break something or many things.
But just maybe I fixed it ;)
Dave
-
Only 3 posts and it looks like he's traced down a bug. We're impressed. :D
-
: Darth Vader: Hmmmm.... the Force is strong in this one, he shall join us or die :/Darth Vader:
:welcome:
And nice way to start! ;)
Flipside :D
-
before i reinstalled windows i was having that bug on XP, the button was on the keyboard, tried switching it, no avail.
-
A test exe perhaps?
-
Impressive! :yes:
-
Originally posted by Gravaton
tmp is an int, and the problem SEEMS to be that, on my system, at the end of this block eax is equal to a number around 33,000,000. This, when moved into tmp (which is a regular int) gets taken to be a negative number of about -9,000,000. And at that point everyone gets all sad. The solution I've found is to turn tmp into an unsigned int (as there's no way any of the system timer functions would EVER be returning a value less then zero according to MSDN specs), and also turn the "now" variable (in code/ship/afterburner.cpp line ) for the afterburner into an unsigned int as well. This worked.
Are you sure you didn't drop a couple decimal places? Why would 33M roll over to -9M ? I'm confused. If it was 3300M rolling over to -900M I would understand:3,300,000,000 (unsigned) = 0xc4b20100
-900,000,000 (signed) = 0xca5b1700Nice catch, in any case :yes: Now check it to make sure it doesn't break anything else :D
For example, see if any timing-related sexps get hosed, make sure beams don't stay on for 5 minutes (ow), make sure the HUD clock seems reasonable...
-
Hmm, you're right, the numbers do seem a little off. Sorry I haven't been exactly around, school re-started and ate my soul for a bit :) I'll take a look at things tonight and get some more exact figures.
-
penguin: he rounded ... but the bug totally makes sense
i wish i would have been reading this thread a long time ago -- the moment i noticed a time_get_milleseconds() i figured it was a sign problem
-
Originally posted by Kazan
penguin: he rounded ... but the bug totally makes sense
Heh, the rounding I get, it was the two order of magnitude (33M vs 3.3G) that puzzled me. A number like 33M would be the same, regardless of whether it's signed or not.
To pick a nice round (hex) number:
0xc800 0000 == (unsigned) 3,355,443,200 == (signed) -939,524,096.
And you're right -- makes sense; signed vs. unsigned is a major PITA.
-
erm... just out of curiosity, how goes work on this? This problem seems like a big one to me, especially because I suffer from it. I'm a WinXp Pro user, and this is greatly cramping my FS2ing...
--Rga
-
Have you tried the compatability options fix from my FAQ? It never really worked well for Win2k users but it solved the problem for most XP people.
-
Yeup. Still all buggered up.
--Rga
-
Wait for someone to post a build. I think Phreak put this in recently, but we have to check if it's correct.
-
I'm win2k and have never _ever_ had a problem with my afterburners. Hell, I use them instead of my primary thrusters.
-
Originally posted by Raa Tor'h
I'm win2k and have never _ever_ had a problem with my afterburners. Hell, I use them instead of my primary thrusters.
If you're on about my above comment I was talking about the fix never solving the problem on 2K not that everyone on 2K has the problem.
-
Is there any chance of this making it into the 3.6 build???
I don't think that there has been a build posted with this fix in place?
PLEASE PLEASE PLEASE?? :)
-
it's already in.....
-
look at any of the recent builds in the recent build forum, I think they should all have it in.
-
Yes, this was my moistake, I had an older build selected in the launcher. The afterburner bug is indeed fixed in the march 5th build. :yes:
Thanks very much!
-
-nevermind-
-
there is a table defind max AB speed wich generaly is well above the max cruiseing speed (though Silent Threat showed that wasn't required (Loki))
-
Once again, I should look around more before I post. The craft I was using had no afterburners installed. I took the afterburner key increasing my speed as the burners actually working. Beat me with a stupid stick.
-
looks like someone beat me to it :D:p