As I wrote earlier, it is completely random, it can happen at any time, not just OMS-2. Had it happen during first stage ascent, second stage ascent, during +X translation post-ET sep, configuring switches, you name it.
Project Space Shuttle Vessel
- Thread starter GLS
- Start date
dennis.krenz
Well-known member
But always with user actions shortly (lets say, <3 seconds) before it happens?
dennis.krenz
Well-known member
No. Can be minutes between any action and the crash.
Tiny_Bob
Addon Developer
Ill check when i am back, but it moves at engine start, then flips out when the stack is released. i have not checked to see if the happens at KSC too, but it came up recently as far as i can remember. I have not updated SSV in a while, and the only changes between the current release and what i have is the ascent guidance improvements.
dennis.krenz
Well-known member
Ouch. Have you checked the Geforce drivers? Maybe it isn't caused by Orbiter...
dennis.krenz
Well-known member
Yes. I've tried just about everything here on my end but with very limited information. Maybe D3D9Client is just getting too old for an ever changing OS?We really hunt ghosts here.
dennis.krenz
Well-known member
Possible, but then we should get the same problems with other add-ons and other users, too. Also, we are not even talking about Linux there. Also it isn't a hardware or device driver issue, it must be something happening in Orbiter.exe. That COULD be DirectX9 related, but I have serious doubts.
One idea I have left: Is there a broken surface base on Earth, that gets processed for rendering in the moment in crashes?
GLS
Well-known member
I'm fairly certain the animations are all centralized (panels or subsystems), so IMO if that is the problem, then it should have been visible long before.
AFAIK, the RCS is created once at the start. The CTD also seems to happen at the pad, and no RCS is fired at that point. Also, Orbiter could/should check if it gets a NULL handle in several functions, it shouldn't be a performance hit, and if it is, make the check only in debug builds.
I know it is in the ALT FCOS spec doc. This whole thing is taking more time than it should because the FCOS of that document is not what was flown in space (that FCOS plus G1 plus SM was way too large for the available memory), so I need to "massage" things a bit. If you have a FCOS spec from like 1979 or later, I'll take it.
For v1.12 I did change the touchdown points at SLC-6 to fix a tiny tilt that existed... maybe with a lower surface resolution the touchdown points are no longer leveled?
Or perhaps it is not heavy enough... could you add another 0 to the SetEmptyMass at SLC6.cpp:244, to see if that keeps it on the ground?
The only way forward I see is you running debug builds of SSV and/or Orbiter attached to VS, to see where it crashes.
This assuming the CTD also occurs in the debug builds, which is far from certain.
Tiny_Bob
Addon Developer
Tiny_Bob
Addon Developer
GLS
Well-known member
Where did it fail?
Tried building v1.15 sources in debug mode but the solution failed due to a non-existant orbiterD.lib. Builds perfectly fine in Release mode however.The only way forward I see is you running debug builds of SSV and/or Orbiter attached to VS, to see where it crashes.
This assuming the CTD also occurs in the debug builds, which is far from certain.
Lately, all of the crashes have been around OMS-2 TIG-2 minutes, usually inside of that, just after enabling left FLT CNTLR PWR on F6 and taking both OMS engines to ARM/PRESS on C3. Not sure if that means anything.
GLS
Well-known member
Yeah, you need to get the Orbiter debug libs (I think there is an official package somewhere), and add a "D" to the name of them so both debug and release libs can co-exist in the same folder.
First run without CTDs...
Managed to build a debug version of SSV and the CTD is still there at the same point. I'm starting to think that this might have something to do with the automated vacuum inerting as I think the second one is supposed to happen somewhere around the OMS-2 TIG.
GLS
Well-known member
Good! Now open the Launchpad, and before starting the scenario go to VS, Debug > Attach to Process > Select Orbiter(_ng).exe, and then launch the scenario. Now the CTD should be caught by VS, and it will indicate where in SSV it went kaput, or it will just say it was inside Orbiter somewhere, which would then need a debug Orbiter build to track down.
That only happens after transition to MM106.
