Off-Topic Discussion > The Classics
Epic Bughunt Claims Sanity, Human Blood
High Max:
^^
Iss Mneur:
--- Quote from: General Battuta on April 16, 2010, 04:29:40 pm ---
--- Quote from: Ravenholme on April 16, 2010, 04:24:56 pm ---
--- Quote from: Mongoose on April 16, 2010, 04:22:31 pm ---I knew I never used speed-matching for a reason...I just didn't realize the reason was that the engine has acquired its own "ghost." :p
--- End quote ---
Likewise, but also because I'm fairly good at just adjusting the throttle on my joystick to match my target myself
>_>
(I admit, I didn't realise there was a match speed function, but I pro'ly wouldn't use it anyway)
Oh, I will say this - you guys are... dedicated. And that's an obscure retail bug, but at least it has now been put to the sword.
--- End quote ---
Given that the scenario here in question was a non-combat cruise, match speed is a pretty useful utility function no matter what your opinions of its use in combat may be.
In any case this was a combination of speed-matching with a pairing of events. Rather specific.
--- End quote ---
Non combat cruise alright. :D I assume, that thanks to HerraTohtori's episode in the testing of the last (re)release of BP1, the weapons were locked as well (at least in the problem mission that I received) :D
--- Quote from: The E on April 16, 2010, 04:57:43 pm ---
--- Quote from: High Max on April 16, 2010, 04:48:56 pm ---
--- Quote from: The E on April 16, 2010, 03:41:34 pm ---
As for the added error checking, I'm kinda astonished that this was not caught before. Modern CPUs are supposed to do just that and start screaming when something as stupid as this happens.
--- End quote ---
Did the modern CPU not do anything because of the fact that the game is still CPU limited? Is that another side effect of it being CPU limited?
--- End quote ---
No. It's probably a side effect from some optimisation somewhere or other.
--- End quote ---
It is not an optimization thing as we are talking about floating point numbers here. One thing about the IEEE floating point number representation system is it allows for NaN (Not a Number). Because IEEE floating point numbers were designed by a bunch of scientists, it assumes that you know what the hell you are doing and if you can't handle NaN in your data, then you need to check for it or make sure you don't generate it.
Now if we were working with integers and you divided by zero then yes, the OS actually would interrupt the program. (I just tested it, VS2008 will generate a compiler error if you use have a constant expression that evaluates to zero (C2124), and Windows 7 generates the "program has experienced a fatal error" box if you slip the fact that you are dividing by zero past the compiler.)
Commander Zane:
--- Quote from: Iss Mneur on April 16, 2010, 09:28:30 pm ---I assume, that thanks to HerraTohtori's episode in the testing of the last (re)release of BP1...
--- End quote ---
I did have that particular episode on a TBP mission a couple days back.
Qent:
Wow you guys really did make it sound like something from Transcend. :P Great job on the fix!
Specifically, it's dividing zero by zero. I'm pretty sure that dividing a non-zero floating-point number by zero should always be +/-infinity.
The E:
Which I guess also evaluates to NaN....
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version