- Oct 20, 2007
- Reaction score
- 46N 123W
More details then...
On my machine at least it's 100% reproducible (none of that funny "it only happens when you're not looking" business). Here are the exact conditions under which it happens (as far as I can tell):
- It never happens if at least one of the reactors is at least at the "Compressing Fuel" stage.
- It always happens immediately if all the reactors are off.
- It always happens immediately if 4 reactors are off, and one is at the "Ionizing Fuel" stage, and its top green bar is all the way full.
- When one reactor is at the "Ionizing Fuel" stage, but its top green bar is not full, and all the other reactors are off, it will not crash until the top green bar is full, at which point it always crashes.
- I don't know about the "Fuel Flow started" stage, because I can't start a reactor, and then shut down another by the time it's already at "Ionizing Fuel"
That's the dialog box I get ("orbiter.exe has encountered a problem and needs to close..."). When I ask to see what the error report contains, it tells me this:
I'm no windows guru, so I'll leave it to others to interpret that. Unfortunately I can't tell what BEX means, so it's hard to say whether it was a seg fault, a divide by zero, or what. Also, if you want the mdmp file or the appcompat.txt file, I can upload them for you.
After the error occurs, Orbiter.log shows nothing unusual.
And by the way, I'm curious about one particular stage in the reactor start up. What does "Injecting Pixie Dust" mean :rofl:!?
I guess I really ought to label those bars. From top to bottom, they're:
* Core Mass
* Electrical Drain/Generation Capacity
* Fuel Flow
* Core Temperature
* CT Detail (lower range)
* Turbulence/Instability (Which I'm thinking of dropping because when I went to extend the instability code into points in the cycle in which it might actually be relevant, I found that I couldn't get the instability to... stabilize... oh, just a sec... maybe... and because the algorithm is probably totally unrealistic anyway.)
In all the crash situations none of the reactors is drawing fuel from the fuel system... (Either the reactor is turned off, or it has gotten its initial fuel load but the fuel hasn't gotten hot enough to start fusing.)
I'm guessing that if you turn off the cross-feed (just click on the button that's lit), while reactors 3 and/or 4 are the only reactors running, you'll get the same crash.
Hmmm... I wonder if trying to typecast a MAX_FLT into an int would cause a buffer overflow (which is what Event type: BEX supposedly is) on some processors (like newer ones than mine, which have hardware checks for buffer overflows)... Come to think of it, it probably would, since MAX_FLT > MAX_INT. There's a lesson to be learned; don't use MAX_ANYTHING for a return code. :blush:
Try sticking the contents of the attached zip file in the modules directory of your test installation and see if it works better.