Project Space Shuttle Vessel

[DaveS]

Another crash, this time on the pad, while paused, same error as earlier though: https://www.dropbox.com/scl/fi/p37t...used.jpg?rlkey=jbu2h7hd2m994u6ja4qdzzr5j&dl=0

Line 299 of DrawAPI.h is the end of the following bit code:

inline FVECTOR3 operator* (float f) const
{
    return FVECTOR3(x * f, y * f, z * f);
}

Pause time was only a few minutes.

 

[GLS]

Another crash, this time on the pad, while paused, same error as earlier though: https://www.dropbox.com/scl/fi/p37t...used.jpg?rlkey=jbu2h7hd2m994u6ja4qdzzr5j&dl=0

Line 299 of DrawAPI.h is the end of the following bit code:

inline FVECTOR3 operator* (float f) const
{
    return FVECTOR3(x * f, y * f, z * f);
}

Pause time was only a few minutes.

The variables are trash at that point and that is just when it finally stops, but the issue is upstream somewhere... if it crashes while paused, then I think it exonerates the physics.
Try the following cases to see if it crashes:

• turning all MFDs off (delete all the MFD blocks in the scenario)
• no vc and MFDs on (delete the BEGIN_VC block)
• no vc and no MFDs

 

[DaveS]

Another day, another crash, this time here: https://www.dropbox.com/scl/fi/nuqk...ent4.jpg?rlkey=k77oknl6j0xgw7dagjgpfu7ke&dl=0

Details are: Unpaused, 0.1x time accel, exterior camera view, pre-launch at T-8:47.8, mission STS-109, so OV-102 8th mod, PLB liner, keel camera, LC-39A 1995 config.

 

[DaveS]

Another detail is this happen with the MDUs turned completely off, no MFD blocks in the scenario, only the VC block.

 

[GLS]

Another detail is this happen with the MDUs turned completely off, no MFB blocks in the scenario, only the VC block.

And without MFDs and VC?

 

[DaveS]

See my additional reply, it was without the MFDs from the start. Forgot that I deleted the blocks in the scenario last night.

 

[Tiny_Bob]

is there a good list or way to determine what flights use what "mod" for things like the OV and boosters? the OV should be pretty easy, but the boosters are giving me a harder time.

 

[GLS]

is there a good list or way to determine what flights use what "mod" for things like the OV and boosters? the OV should be pretty easy, but the boosters are giving me a harder time.

There's an old pdf (or more than one), with the stack markings (with that name, I think), and that is where the nomenclature of the textures comes from. I don't really know where my copy is (I can try to find it), but it should still be online somewhere...
From memory:

• ET is SWT+FRL for the first 2 flights, LWT from then until STS-87 or so, then SLWT (except for STS-107). Each type only has one default texture, but another can be configured.
• SRM: SPM until STS-5 or 6 or 7?, then HPM until 51-L, then RSRM, and FWC for VAFB. The textures depend on the SRM used.

There should be a texture or 2 missing, but I'm not losing a second with this until I rework the configuration.

 

[DaveS]

It was all SWT until STS-6 which introduced the LWT, then back SWT for STS-7. SLWT was introduced on STS-91, the last Shuttle/Mir mission. STS-99 used a LWT as did STS-107. STS-87 was the first launch to do the Roll To Heads Up (RTHU) during the second stage launch.

 

[DaveS]

AXM Model's Shuttle Reference: https://axmpaperspacescalemodels.com/index.php/shuttle-reference/

 

[Abby/Keru2947]

Hi!
I've been doing some back reading and just noticed this post. (It probably wasn't visible at the time, as it was your first and needed moderator approval to show up)

About the aborts, many things are missing for that, namely ascent logic, but also a better OMS/RCS to allow for prop dumps during ascent. Better OMS/RCS will then need better logic to handle the orbit segment of the flight. So instead of making everything at once, I'm working first on the OMS/RCS and orbit for v2.0 (and it's already a massive rework) and then later I'll work the ascent, and aborts, as I'll have all that is needed for those.

As for the SSMEs failing, actually it is the SSME controller that shuts down an unhealthy engine. If you kill the power to the controller (yellow switches on panel R2), there is a sort of "dead-man switch" in the engine that will cause it to shutdown. The GPCs will have no idea what happened, except that the engine no longer sends data, and you need to press the correct Shutdown PB on panel C3 to let the GPCs know that the engine is gone. The failure handling in the SSME controller is more or less functional, but as there are no failures yet, it isn't exercised. You can always manually kill APUs, EIUs, MDMs and create an hydraulic lockup, command/data path failure, display and/or switch failure, and try to work around the situation... but there are no automated aborts yet.

I was just thinking about this yesterday actually. Been working on making 51-F as a custom mission, only thing that I obviously can’t do is the center engine failure and ATO. I don’t know how much is publicly available in terms of info on the ATO guidance, but I don’t need abort modes to make the mission work anyways This is all looking amazing by the way, keep it up!

 

[GLS]

I was just thinking about this yesterday actually. Been working on making 51-F as a custom mission, only thing that I obviously can’t do is the center engine failure and ATO. I don’t know how much is publicly available in terms of info on the ATO guidance, but I don’t need abort modes to make the mission work anyways This is all looking amazing by the way, keep it up!

Hi there!
For now you can hit the center shutdown PB on panel C3 at T+5:45, leave guidance in Auto, and it should still get to MECO.... which was +/- the same in an ATO, you just don't have the help of the OMS dump.

 

[Tiny_Bob]

you just don't have the help of the OMS dump.

Can you adjust the OMS Assist start time or just the duration? that could be a way to fake it

 

[Tiny_Bob]

still getting the error. ill attach the build output.

Update on this: with some help from Indy, I got it to build. lua.lib isn't where SSV expects it to be so it was running into problems.

 

[GLS]

Can you adjust the OMS Assist start time or just the duration? that could be a way to fake it

The start is fixed at MM103+10s, but the quantity and time are displayed in SPEC 50.... well, not yet in SSV, but it should be on v2.0, along with the capability to start and stop an OMS dump as one desires, so by then faking an abort will be easier.

 

[Tiny_Bob]

Remove the extra 0, and replace the touchdown points with:

        static TOUCHDOWNVTX tdvtx[4] = {
            {_V( 0.0, -16.0, 2.0 ), 1e8, 1e2, 5, 5},
            {_V( -1.732051, -16.0, -1.0 ), 1e8, 1e2, 5, 5},
            {_V( 1.732051, -16.0, -1.0 ), 1e8, 1e2, 5, 5},
            {_V( 0.0, 50.0, 0.0 ), 1e8, 1e2, 5}

old issue, but this doesnt help, it makes it worse. but im confident its a my orbiter install problem, unless anyone else has a similar experience

 

[GLS]

old issue, but this doesnt help, it makes it worse. but im confident its a my orbiter install problem, unless anyone else has a similar experience

Still, what could be wrong with your install? Did you change the terrain at VAFB, or not extract the SSV elevation tiles? The area where the pad sits should be flat.

 

[Tiny_Bob]

not extract the SSV elevation tiles

is there a way to check the elevation map? and i just did a fresh SSV install from github (latest from the trunk branch), so it all should be correct.

 

[GLS]

is there a way to check the elevation map? and i just did a fresh SSV install from github (latest from the trunk branch), so it all should be correct.

Hmm, there should be a bunch of *.elv files in the Earth texture folder... it is probably easier to check in Orbiter: take a scenario without SLC-6 (but still with Context SSV), go view its location, and there should be a flat square, with a small wall to the East.

 

[DaveS]

Just a complete shot in the dark here, but do you have a plug-in called "Attachment Manager" active? If so, try disabling it.