Project Space Shuttle Vessel

[DaveS]

No joy on v1.11, same CTD during the OMS-2 burn.

 

[GLS]

No joy on v1.11, same CTD during the OMS-2 burn.

Wasn't it happening during scenario loading?
Is there anything in the log on that CTD?

 

[DaveS]

Nothing special in the logs. This is the post where I first reported it: https://www.orbiter-forum.com/threads/space-shuttle-vessel.37856/post-636422

 

[DaveS]

Logs were posted here: https://www.orbiter-forum.com/threads/space-shuttle-vessel.37856/post-636592 and the post below it.

 

[GLS]

Other than running a debug session of SSV and/or Orbiter to find exactly where it crashes, it will have to be an "elimination game":

• XRSound on vs off
• empty PLB vs different payloads
• KSC vs VAFB
• low inclination vs high inclination
• RMS installed vs not installed
• External Airlock
• ODS
• different OVs, ETs, SRBs
• old CCTV cameras vs new
• local lights on vs off

Looking at the changes from Orbiter 2016, I changed the D3D9 calls (which is now inside Orbiter), switched to XRSound, and there is the new docking logic, which should be dormant until it actually happens.

 

[DaveS]

The only things on that list I haven't tried is the lights and the launch site.

 

[DaveS]

Now I checked off the entire the list. Nothing have an effect.

 

[DaveS]

And that the logs are useless is a known issue which is documented here as an official issue report: github.com/orbitersim/orbiter/issues/382

 

[GLS]

Can you try a nightly build of Orbiter?

 

[DaveS]

Tried the latest nightly build of Orbiter-x86 and no change. Still crashes.

 

[Tiny_Bob]

unrelated to this, but i was doing a VAFB launch, and the whole pad just kinda became unattached from earth.

UPDATE: It seems to do this with any VAFB launch, even the premade scns that come with SSV.

 

[n72.75]

In my experience random crashes are caused most offen by pointers that:

Have the proper checks for being null.

and

Aren't being set to null when an object is deleted or first created.

Does it ever crash when  closing orbiter?

 

[DaveS]

In my experience random crashes are caused most offen by pointers that:

Have the proper checks for being null.

and

Aren't being set to null when an object is deleted or first created.

Does it ever crash when  closing orbiter?

Not that I have experienced as of yet. It's this as of yet unexplained sudden exit that only occurs when using a prelaunch scenario. No way to predict when it will happen, just that there's an chance of it happening.

 

[dennis.krenz]

Not that I have experienced as of yet. It's this as of yet unexplained sudden exit that only occurs when using a prelaunch scenario. No way to predict when it will happen, just that there's an chance of it happening.

Not a quicksave? Does it crash at the same time (simt, mission step, user action)? In that case, a quicksave before could maybe help.

@GLS What is the current state of the C&W system?

 

[DaveS]

Not a quicksave? Does it crash at the same time (simt, mission step, user action)? In that case, a quicksave before could maybe help.

No. It is completely random other than it requires a prelaunch scenario start. That's it.

 

[GLS]

Tried the latest nightly build of Orbiter-x86 and no change. Still crashes.

Final attempt to isolate things, before suggesting a debug session: using ScenarioEditor to delete all other vessels right after ET sep, does it make a difference?

unrelated to this, but i was doing a VAFB launch, and the whole pad just kinda became unattached from earth.

UPDATE: It seems to do this with any VAFB launch, even the premade scns that come with SSV.
View attachment 47603

That is new...
What surface resolution have you, and when does the tectonic shift happen?

In my experience random crashes are caused most offen by pointers that:

Have the proper checks for being null.

and

Aren't being set to null when an object is deleted or first created.

Does it ever crash when  closing orbiter?

I have placed try/catch blocks on all the callbacks, to try and catch (ba-dum-tis) my mistakes, but sadly that doesn't work on all exceptions.

@GLS What is the current state of the C&W system?

I think the hardware side is done, it now needs (more) subsystem signals to trigger alarms, and the software side is a bit messy due to lack of info (and very incomplete), but the output to the hardware to trigger the sound and light is working. This should improve a bit in v2.0.
BTW: I'm finishing a small change that will return time acceleration to x1.0 when an alarm happens.

 

[dennis.krenz]

I think the hardware side is done, it now needs (more) subsystem signals to trigger alarms, and the software side is a bit messy due to lack of info (and very incomplete), but the output to the hardware to trigger the sound and light is working. This should improve a bit in v2.0.
BTW: I'm finishing a small change that will return time acceleration to x1.0 when an alarm happens.

Good to know, maybe it could also give a ahead warning if some subsystem simulation is running wild. But I don't expect it to be the cause of the CTD. Just another help for debugging things. The OI subsystem would also be helpful, but it will be binding a lot of effort in the future and should better be done well-thought and slowly to avoid doing the same work multiple times.

For the missing info, just let me know what should be researched and abuse me as AI agent. I should have a few hours available next week for diving deep through the block diagrams of the Shuttle, if I can find them again on my ExtHDD.

 

[GLS]

Good to know, maybe it could also give a ahead warning if some subsystem simulation is running wild. But I don't expect it to be the cause of the CTD. Just another help for debugging things. The OI subsystem would also be helpful, but it will be binding a lot of effort in the future and should better be done well-thought and slowly to avoid doing the same work multiple times.

Yeah, telemetry would be nice, but there is no PCMMU and the subsystems and GPC modules need to produce the correct data to feed to a telemetry stream. The DPS should be closer to that after v2.0.
Anyway, I think this is happening inside Orbiter, and caused by something I did wrong...

For the missing info, just let me know what should be researched and abuse me as AI agent. I should have a few hours available next week for diving deep through the block diagrams of the Shuttle, if I can find them again on my ExtHDD.

I still need to finish figuring out the control segment stuff first, but after that I'll have a go at the fault message logic to try and improve that.

 

[DaveS]

Final attempt to isolate things, before suggesting a debug session: using ScenarioEditor to delete all other vessels right after ET sep, does it make a difference?

Negative. No change whatsoever.

 

[dennis.krenz]

Yeah, telemetry would be nice, but there is no PCMMU and the subsystems and GPC modules need to produce the correct data to feed to a telemetry stream. The DPS should be closer to that after v2.0.
Anyway, I think this is happening inside Orbiter, and caused by something I did wrong...

Well, keep in mind that the GPCs provide only a (small) part of the telemetry stream. I look forward seeing your new DPS, my concepts were likely done with too many badly thought gaps that I didn't check first with exploration.

Also, it doesn't crash in Orbiter without a trigger event. Did you check that all animations refer existing meshes or meshgroups? AFAIR, the thrustergroups are completely erased on staging and I don't think you refer to bad thruster handles when recreating them... maybe you can auto-check this and write a warning in the Orbiter log, if a bad handle is passed, shouldn't be hard to implement.

@DaveS Does it always happen during OMS-2? Do you know if there are any automated post-launch processes still going on at this point?

I still need to finish figuring out the control segment stuff first, but after that I'll have a go at the fault message logic to try and improve that.

You and me might find that in the FCOS software specification. Do you want some references?