Space Shuttle Ultra development thread

[Donamy]

I think it's a scenario file thing, but I could be wrong.

 

[Poscik]

I also thought about it. I'm preparing for STS-117 mission and I can't launch. I launched succesfully STS-116. No problems there, but now, it fails too. I'm just recompiling newest sources.

[EDIT]
The same at newest sources.

 

[SiameseCat]

I've been recoding some of the panels, so make sure the MPS switches onR2 are in the correct positions; the scenario file entries to record these switch positions have changed.

 

[Poscik]

All six MPS switches are "pointing upwards", so I think MPS is armed.

[EDIT]
Screen of panel R2 config for launch:

 

[Kyle]

I see your problem, put each He Isolation switch to 'Open'.

 

[Donamy]

Shouldn't the APU speed be on high ?

 

[DaveS]

Shouldn't the APU speed be on high ?

No. APU high speed setting is only used in emergency situations. Standard is NORM SPEED.

---------- Post added at 04:39 PM ---------- Previous post was at 04:28 PM ----------

I see your problem, put each He Isolation switch to 'Open'.

This enables the COPVs to pressurize the MPS. Without the proper pressurization, the SSMEs will shut down. This procedure is done by the PLT at T-16 minutes and is called MPS He RECONFIG.

MPS PWR TO ON is done prior to flight crew ingress by the Orbiter Closeout Crew.

 

[Poscik]

Damn, I forgot about those He Isol switches. Thanks Kyle.

 

[DaveS]

so 1.06 works in 2010 p1 well a great addon indded

now if i download ver. 2006 of orbiter will the shuttle be
more functional crt keypad,switches,grey radiators improved docking cam
and other things current?

No. That is all part of the SSU modules (the dynamic link libraries, *.dll files). If you want the latest stuff, you have to get the latest SSU sources and compile them yourself.

Otherwise you're out of luck.

 

[GLS]

Just something to think about for the future: I had an ideia for what to do when the SSU user overstresses the vehicle (hard landing, high Gs) or when an APU, SSME or fuel cell blows up: the simulation stops/ends and a message is displayed saying what when wrong. Essencially it would be the SSU version of the white angel on NASSP/AMSO (forget which).
Meanwhile on the MPS front, I'm re-writting some parts of the SSME controller to make it better/more capable, and then will also implement the helium subsystem, but because the semester is starting now, it will easilly all be delayed until the summer

 

[Urwumpe]

I would suggest limiting the "Angel of Death" outcome to the crew cabin: When its limits are exceeded, the crew is considered unconscious or worse and the mission is over.

While many failures would be leading to this fate in seconds, this must not happen every time, for example a lost wing is no problem as long as you are still in space. An exploded SSME is not automatically deadly.

EDIT: And don't worry about delays for new features... your studies should have the higher priority of course.

 

[STS]

If I can suggest, I would suggest exactly what XR-vessels or DGIV do. The simulation continues with the caused failures but a message displays showing that you are dead, and what happenned (ex: Something exploded, incorrect attitude on reentry, incorrect docking causing vehicle breakdown, cabin pressurization...). Of course, as Urwumpe says, this would happen only in deathly situations. If the situation is not deathly the simulation would continue with the damaged systems.

Bassicaly what I want to say is please, no AMSO´s white angel changing your focus and climbing vertically to a scape trajectory.