Space Shuttle Ultra 1.25 Revision B development

[GLS]

Unless anyone wants something else, I'm planning to name the mission file parameter MaxSSMEThrust.

No objections on my end. :thumbup:

[DREAMS] Hopefully one day, that configuration will be done by choosing the right GPC and SSMEC software... [/DREAMS]

 

[Urwumpe]

[DREAMS] Hopefully one day, that configuration will be done by choosing the right GPC and SSMEC software... [/DREAMS]

Will be possible, though a complete emulation of the software is shelved until somebody throws a magnetic tape of the Shuttle MMU at us.

If I remember correctly, you can at least already program the MDM PROMs, I only didn't finish the tool to write MDM PROM images.

 

[SiameseCat]

Have any changes been made? I'm still working on the mission file entry, so nothings been checked in yet.

---------- Post added at 06:19 PM ---------- Previous post was at 06:16 PM ----------

Unless anyone wants something else, I'm planning to name the mission file parameter MaxSSMEThrust.

Checked in changes. I did a quick test with the STS-1 scenario (changing the Orbiter mass defined in Atlantis.h) and MECO occurred at 8:29, which is pretty close to the actual time of 8:34.

 

[DaveS]

Checked in changes. I did a quick test with the STS-1 scenario (changing the Orbiter mass defined in Atlantis.h) and MECO occurred at 8:29, which is pretty close to the actual time of 8:34.

Another thing for the mission file is ET type. Currently we're flying the SLWT, flights 1 through 5 and 7 used a SWT, while STS 6 through 90, 99 and 107 used LWT.

 

[SiameseCat]

We can handle the ET type by adding a parameter in the scenario file indicating the ET type (since the ET is always a separate vessel).

For the shuttle empty mass, a mission file parameter is probably best, since there are multiple shuttles, and the weight of each shuttle changed as modifications were made. The main issue here is if the RMS, ODS, etc. mass should be included or added separately based on whether these components are included.

 

[DaveS]

We can handle the ET type by adding a parameter in the scenario file indicating the ET type (since the ET is always a separate vessel).

For the shuttle empty mass, a mission file parameter is probably best, since there are multiple shuttles, and the weight of each shuttle changed as modifications were made. The main issue here is if the RMS, ODS, etc. mass should be included or added separately based on whether these components are included.

I think the best would be to have them separate as the Centaur missions were really restricted as was STS-93.

 

[SiameseCat]

Well, something like the Centaur would be an independent vessel attached to the shuttle and it's mass would be included that way. I'm only talking about something that's an integral part of the shuttle but may or may not be present depending on the orbiter configuration. The main ones I can think of are the RMS, airlock/ODS and the EDO. Payload support structures (e.g. for the Centaur and IUS) could also be included in the empty mass. The main problem with keeping them separate is that the published figures will usually include these numbers (at least for the RMS, etc.), so it might be a bit more work to calculate the empty mass.

 

[DaveS]

Well, something like the Centaur would be an independent vessel attached to the shuttle and it's mass would be included that way. I'm only talking about something that's an integral part of the shuttle but may or may not be present depending on the orbiter configuration. The main ones I can think of are the RMS, airlock/ODS and the EDO. Payload support structures (e.g. for the Centaur and IUS) could also be included in the empty mass. The main problem with keeping them separate is that the published figures will usually include these numbers (at least for the RMS, etc.), so it might be a bit more work to calculate the empty mass.

What I'm talking about is that those flights was/were so mass restricted, alot of otherwise standard equipment had to be left on the ground. For STS-93 they were considering leaving alot of CM equipment on the ground but they had retain them because the cg moved too far aft.

Here's a break down of what got removed for STS-93, to-date the heaviest shuttle launch:

• Wing/Elevon "flipper doors" Inconel insulators, 265 lbs
• All Remote Manipulator System hardware, 904 lbs
• Extended Duration Orbiter pallet, 7000 lbs
• PRSD Cryo tank sets 4 and 5, 1100 lbs
• RCRS CO2 removal system, 350 lbs
• GN2 tank#5, 128 lbs
• Orbiter aft ballast reduced to 0 lbs from approx. 1000 lbs
• Some midbody sill longeron stabilizing link brackets, 50 lbs

---------- Post added at 03:38 AM ---------- Previous post was at 03:25 AM ----------

Would it be possible to add the pad hissing when the vehicle is at the pad? We already have the sound file for that, was checked in last year but we have never gotten around to adding it. It would add alot of ambiance as indicated in this video:

 

[SiameseCat]

IMHO, the best solution is to use the value specified in the mission file as the orbiter dry mass. Otherwise, simulating something like STS-93 will require a lot of extra mission file entries, and a proper simulation of all the systems affected. If we just have a single "TotalDryMass" entry, we can specify that the RMS and EDO pallet (when we simulate it) are not installed, set the removed tanks to be empty, and put the correct dry mass in the mission file. This seems simpler (both for programming and creating scenario/mission files) than specifying each component that has been removed.

 

[DaveS]

IMHO, the best solution is to use the value specified in the mission file as the orbiter dry mass. Otherwise, simulating something like STS-93 will require a lot of extra mission file entries, and a proper simulation of all the systems affected. If we just have a single "TotalDryMass" entry, we can specify that the RMS and EDO pallet (when we simulate it) are not installed, set the removed tanks to be empty, and put the correct dry mass in the mission file. This seems simpler (both for programming and creating scenario/mission files) than specifying each component that has been removed.

True enough. So we have settled then on using TotalDryMass? Also, what about the cryo hiss request?

 

[Urwumpe]

Is it really necessary that the function definitions of SubsystemDirector are written into the header file?

 

[SiameseCat]

It seems to be the easiest way of handling the templates - putting the function definitions in a cpp file caused compile errors.

 

[Urwumpe]

It seems to be the easiest way of handling the templates - putting the function definitions in a cpp file caused compile errors.

Shouldn't be the case. I remember there was a bug in the handling of templates in cpp files, but it was solved.

EDIT: Just tested it, and I got no problems, not even warnings.

EDIT2: Fails on linker... standard solution of export template<TVessel> doesn't work out.

---------- Post added at 03:23 PM ---------- Previous post was at 01:51 PM ----------

Does somebody have any information about the Main Event Controllers? From what I can tell, it acts like a special kind of MDM, with more powerful discrete output modules.

 

[SiameseCat]

Can someone add the launch pad lights, now that multiple light sources are supported? I'd like to get rid of the hack we currently have, of changing the mesh properties.

 

[Urwumpe]

Can someone add the launch pad lights, now that multiple light sources are supported? I'd like to get rid of the hack we currently have, of changing the mesh properties.

I currently do a generic DLL that can deal with all the wheeled transports, maybe I can include the lights as towed vehicle.

 

[DaveS]

Can someone add the launch pad lights, now that multiple light sources are supported? I'd like to get rid of the hack we currently have, of changing the mesh properties.

Well, if you add the code, I can tweak the settings. The ones on the pad is called the stadium lights and are considered the "second stage" of pad lighting. First stage lighting is the various small lights on the structures themselves and the third and final stage is the Xenon lights and they're usually only activated when they plan to fill the ET.

I checked in a mesh of the Xenon light units earlier. There's two light units each mounted a single trailer.

I have attached a map of 39A where each red line represent one trailer.

 

[SiameseCat]

I'm thinking the best way of handling the pad lights is to have a single vessel that defines all the lights and is responsible for activating them.

Another option (closer to what happens in real life, but more complex) is to have multiple vessels that define lights (Pad, trailers, etc.) and use a Lua script to turn the lights on/off. Unless we want to move the trailers around, or remove a trailer, this option seems unnecessarily complex to me.

 

[DaveS]

I'm thinking the best way of handling the pad lights is to have a single vessel that defines all the lights and is responsible for activating them.

Another option (closer to what happens in real life, but more complex) is to have multiple vessels that define lights (Pad, trailers, etc.) and use a Lua script to turn the lights on/off. Unless we want to move the trailers around, or remove a trailer, this option seems unnecessarily complex to me.

Well, lately for the night shuttle rollouts they have used some of Xenon lights to light up the shuttle as it left the VAB. They did it for the Ares 1X rollout as well.

It's up to you. Initially just to work out the settings, I think having one module is good start. We can extend it later when needed/required.

 

[Urwumpe]

Well, lately for the night shuttle rollouts they have used some of Xenon lights to light up the shuttle as it left the VAB. They did it for the Ares 1X rollout as well.

It's up to you. Initially just to work out the settings, I think having one module is good start. We can extend it later when needed/required.

One reason more to have the Xenon lights as separate vessels. The remaining lights could be done as part of the FSS.

 

[DaveS]

One reason more to have the Xenon lights as separate vessels. The remaining lights could be done as part of the FSS.

Well, currently the FSS is part of the actual SSU_Pad vessel along with the RSS.