Project Space Shuttle Vessel

[DaveS]

As I wrote, nothing in the logs to indicate a problem.

 

[GLS]

Sometimes, the scenario doesn't even load, crashes right during loading of the main SSV module.

Where in the main module? There is a bunch of logs in that one...

 

[DaveS]

Where in the main module? There is a bunch of logs in that one...

No idea. It's not always it crashes, it does load successfully and then it's a coin toss if it is going crash and if so when.

 

[Tiny_Bob]

If i could get 2 sticks connected, would SSV support simultaneous rotation and translation for the RMS?

 

[GLS]

If i could get 2 sticks connected, would SSV support simultaneous rotation and translation for the RMS?

A quick look at the code says "yes, but only while in translation mode"... in practical terms, I don't know.

 

[Tiny_Bob]

is there a reason the DAP panel would be "locked" in certain configurations? I've had times where some axis are stuck in pulse and other times, I cant switch from AUTO to FREE.

 

[GLS]

is there a reason the DAP panel would be "locked" in certain configurations? I've had times where some axis are stuck in pulse and other times, I cant switch from AUTO to FREE.

Very likely one of the PBIs was clicked, and while clicking the mouse left the click area, and so it doesn't move back up, acting as still being pressed. With the current signal processing logic, this blocks (some) of the other signals.
You need to find which PBI is in (look carefully), and click in it.

 

[Tiny_Bob]

Very likely one of the PBIs was clicked, and while clicking the mouse left the click area, and so it doesn't move back up, acting as still being pressed. With the current signal processing logic, this blocks (some) of the other signals.
You need to find which PBI is in (look carefully), and click in it.

thats what was going on haha. thanks

 

[DaveS]

No idea. It's not always it crashes, it does load successfully and then it's a coin toss if it is going crash and if so when.

This is the Orbiter log file after it has crashed during loading. It is zipped due to it's large size.

 

[DaveS]

And here's another, it's different.

 

[Tiny_Bob]

got an interesting issue. If I reload after MECO but before the MPS dump, the MPS dump never happens. not a super common thing to do but it does happen

 

[GLS]

This is the Orbiter log file after it has crashed during loading. It is zipped due to it's large size.

And here's another, it's different.

It doesn't CTD inside a SSV vessel, but inside Orbiter... possibly because of something done in a SSV vessel....
Could a bunch of Xenon_Lights be somehow overloading the lights logic in D3D9? Although they are off at the start of the scenario, they are still declared... I haven't really done much work in the vessels in the last few versions, so nothing else is standing out for me at the moment.

got an interesting issue. If I reload after MECO but before the MPS dump, the MPS dump never happens. not a super common thing to do but it does happen

Saving a scenario between T-31s and MECO (or ET sep) is currently not supported.... because long ago it wasn't made for that. Sometime in the next century, when I rework whole launch part (with aborts), it will support save/load at any point.
Also, a scenario loaded after MECO (or ET sep) will already have the MPS manifolds empty, so that's why there is no dump.

 

[DaveS]

It doesn't CTD inside a SSV vessel, but inside Orbiter... possibly because of something done in a SSV vessel....
Could a bunch of Xenon_Lights be somehow overloading the lights logic in D3D9? Although they are off at the start of the scenario, they are still declared... I haven't really done much work in the vessels in the last few versions, so nothing else is standing out for me at the moment.

Could this be Windows 11 thing?

 

[GLS]

Could this be Windiws 11 thing?

Maybe... I'm still compiling with V2017 (an update will eventually happen, maybe this year), but I'd expect any incompability to be a reliable CTD when trying to show a dialog window, and not a random CTD.

 

[Tiny_Bob]

Would it be difficult to add SPEC 2 TIME? would make rendezvous more convenient, and would be fun for rest periods to set the alarm to go off.

 

[GLS]

Would it be difficult to add SPEC 2 TIME? would make rendezvous more convenient, and would be fun for rest periods to set the alarm to go off.

Short answer: at this time, yes.

Long answer: there is a bunch of rework going on in the GPC/IDP branch (for v2.0), so I've stopped work in the DPS for 1.x versions, to avoid issues merging to the mountain of changes in the branch. Also, that clock is controlled by the FCOS, and can be set by the program "behind" SPEC 2, or by an applications program (the OMS DIPs are the usual customers, to show time to OMS ignition), but right now that timer is completely inside the OMS displays, as if it was an actual part of it, so this would need quite a rework... I think it's better just do it properly and wait for v2.0...

...but now looking at the display I notice that the "Tone alarms" are not the CRT Timer... hmm, maybe this could be cheaply hacked, and allow for this feature without much interference elsewhere.
One thing that could also be done is add an option to force (or not) x1.0 time accel when an alarm is triggered, thus time accel could be used (always moderately) to skip ahead to a certain time. This would be in the C&W subsystem, so it wouldn't go against my target of isolating the GPCs from the Orbiter API.
I need to take a better look at all this for a definitive answer.

 

[Tiny_Bob]

Short answer: at this time, yes.

Long answer: there is a bunch of rework going on in the GPC/IDP branch (for v2.0), so I've stopped work in the DPS for 1.x versions, to avoid issues merging to the mountain of changes in the branch. Also, that clock is controlled by the FCOS, and can be set by the program "behind" SPEC 2, or by an applications program (the OMS DIPs are the usual customers, to show time to OMS ignition), but right now that timer is completely inside the OMS displays, as if it was an actual part of it, so this would need quite a rework... I think it's better just do it properly and wait for v2.0...

...but now looking at the display I notice that the "Tone alarms" are not the CRT Timer... hmm, maybe this could be cheaply hacked, and allow for this feature without much interference elsewhere.
One thing that could also be done is add an option to force (or not) x1.0 time accel when an alarm is triggered, thus time accel could be used (always moderately) to skip ahead to a certain time. This would be in the C&W subsystem, so it wouldn't go against my target of isolating the GPCs from the Orbiter API.
I need to take a better look at all this for a definitive answer.

oh wow its way more involved then i thought, better to do it right the first time eh? Is there anything fun in the GPC branch? i have not had luck building SSV source, but maybe i can figure it out

 

[GLS]

oh wow its way more involved then i thought, better to do it right the first time eh?

The tone time part seems isolated, so that might be "cheap" to make.

Is there anything fun in the GPC branch? i have not had luck building SSV source, but maybe i can figure it out

Not yet, it doesn't even compile at the moment.
Here is an image of the higher resolution display that will arrive in v2.0:

 

[Tiny_Bob]

any tips for actually getting a KU lock at a reasonable distance? im pretty close with -Z tracking using the orbiter target camera.

 

[Tiny_Bob]

also the mission editor doesn't want to save my custom elevation for MC-2. keeps going back to the 29.06