SSU Development Thread (2.0 to 3.0)

[SiameseCat]

I think we should be ready for a release; the new mesh branch has been merged in, and I don't think there any any outstanding changes required.

I was thinking we could spend a few days testing the latest version of the code to make sure there aren't any bugs, and then we should be able to have a release on OH.

 

[Urwumpe]

I was thinking we could spend a few days testing the latest version of the code to make sure there aren't any bugs, and then we should be able to have a release on OH.

I agree there. Also, I think we should check the documentation once again before release.

How is your opinion on writing some short manual for the various scenarios of SSU? Like what you are expected to do (not as checklist, but rather as coarse flight plan)

 

[DaveS]

I still need a texture for the EDO pallet so that I can finish the update of the STS-107 payloads.

 

[Donamy]

EDO ?

 

[DaveS]

EDO ?

Extended Duration Orbiter. Basically a set of upgrades/mods to the orbiter to support extended duration missions (12+ days). Main external EDO item was a large pallet with extra sets of LH2/LOX tanks for the fuel cells. It was mounted in bay 12 and supplied the reactants through plumbing that went beneath the PLB in bay 11.

EDO pallet photos

 

[Poscik]

Any chance to have short tutorial how to use GNC for RNDZ? I mean some sort of info about conditions that have to be met before using it, and which burns it's capable to perform.

 

[SiameseCat]

How is your opinion on writing some short manual for the various scenarios of SSU? Like what you are expected to do (not as checklist, but rather as coarse flight plan)

Can you explain a bit more what you want to see in the manual?

 

[Urwumpe]

Can you explain a bit more what you want to see in the manual?

Mostly some hints for the players, what the goal is and what coarse maneuvers you should perform... I think a full flight plan is currently out of scope and would delay release too much.

 

[SiameseCat]

I think it might be a better idea to add this information in the scenario description, instead of putting it in a separate file. I'm thinking the description should look something like this (using made up numbers):

STS-120: Scenario begins 10 minutes before launch. This mission delivered the Harmony module to the ISS.

Discovery docked to the ISS at MET 001/18:00:00.
Discovery undocked from the ISS at MET 010/12:35:00
Entry Interface occurred at MET 012/16:01:00.
Touchdown occurred at MET 012/16:27:00.

 

[Urwumpe]

I think it might be a better idea to add this information in the scenario description, instead of putting it in a separate file. I'm thinking the description should look something like this (using made up numbers):

STS-120: Scenario begins 10 minutes before launch. This mission delivered the Harmony module to the ISS.

Discovery docked to the ISS at MET 001/18:00:00.
Discovery undocked from the ISS at MET 010/12:35:00
Entry Interface occurred at MET 012/16:01:00.
Touchdown occurred at MET 012/16:27:00.

Sorry, but no. You can't access the scenario description from within Orbiter, so putting the information there is absolutely useless.

 

[SiameseCat]

I don't think there's a big difference between opening the scenario file and opening a file in the Doc folder, but it might be less confusing for some people to put this in the Doc folder.

DaveS, can you add the scenario guide?

 

[Urwumpe]

I don't think there's a big difference between opening the scenario file and opening a file in the Doc folder, but it might be less confusing for some people to put this in the Doc folder.

DaveS, can you add the scenario guide?

I think you are too much thinking like a developer there. Nobody will open a scenario file with something other than Orbiter, especially not for just getting hints.

The expected documentation for the usual player will be a PDF file to open or print or copy on your tablet.

 

[GLS]

A little late but I did the "review" of the current state.... and there's still some work to do before the release:

• all MPS vents are in wrong position
• (at least) in STS-1/61-G/61-F launch scenarios the OV has a bad texture (could it be related to the 2 tails?)
• looks like the SSME flame texture has an offset in the Z axis
• the SRBs don't match the ET (Z axis offset)
• is the body flap too small in width?
• ET burned texture still has the "rainbow" on the LOX feedline
• something is sticking out at the bottom of the ET (in the "back", near the place were it "rests" when horizontal)
• could someone round the SSME GH2burn texture? it looks too square ATM, which doesn't look bad on the pad but not so much inflight
• we still have the pad/vehicle position offset problem... if someone could get me a set of "delta-latitude" and "delta-longitude" between the pad and the vehicle, I could go around all the launch scenarios and fix this

 

[DaveS]

*(at least) in STS-1/61-G/61-F launch scenarios the OV has a bad texture (could it be related to the 2 tails?): The Orbiter textures used in those scenarios hasn't been updated yet as there's no priority due to lack of payloads which makes those missions actually usable.

*the SRBs don't match the ET (Z axis offset): New ETs are in the works that will fix this. But those require new resized pads as well so they have been put on the back burner for now.

*ET burned texture still has the "rainbow" on the LOX feedline: There's actually no post-SRB sep versions of the textures yet.

*something is sticking out at the bottom of the ET (in the "back", near the place were it "rests" when horizontal): See the other points re ET meshes/textures

*we still have the pad/vehicle position offset problem... if someone could get me a set of "delta-latitude" and "delta-longitude" between the pad and the vehicle, I could go around all the launch scenarios and fix this: Are you talking about the scenario position of the pad or actual deltas between each pad element(FSS/RSS/Hardstand/MLP)?

---------- Post added at 07:50 AM ---------- Previous post was at 04:50 AM ----------

This screenshot shows a few problems with the Columbia texture. Right now all of the midbody vent doors share the same texture which on Discovery, Atlantis and Endeavour isn't a problem. But on Columbia and Challenger, midbody vent door #3(fwd most vent door) was black. This is currently not possible due to the texture sharing.

Also, the texture mapping for the payload bay doors and midbody is off. It's currently mapped too low and doesn't line up with the hinge line on the actual texture map. Also from some angles, the name and NASA worm logo appears squished height-wise.

---------- Post added at 08:52 AM ---------- Previous post was at 07:50 AM ----------

Current version of the psd file can be found here: https://dl.dropboxusercontent.com/u/24122088/Orbiter_blank.psd

 

[GLS]

*(at least) in STS-1/61-G/61-F launch scenarios the OV has a bad texture (could it be related to the 2 tails?): The Orbiter textures used in those scenarios hasn't been updated yet as there's no priority due to lack of payloads which makes those missions actually usable.

But we're still going to have at least 1 texture for OV-099 and OV-102 in a release, right?

*the SRBs don't match the ET (Z axis offset): New ETs are in the works that will fix this. But those require new resized pads as well so they have been put on the back burner for now.

*something is sticking out at the bottom of the ET (in the "back", near the place were it "rests" when horizontal): See the other points re ET meshes/textures

*we still have the pad/vehicle position offset problem... if someone could get me a set of "delta-latitude" and "delta-longitude" between the pad and the vehicle, I could go around all the launch scenarios and fix this: Are you talking about the scenario position of the pad or actual deltas between each pad element(FSS/RSS/Hardstand/MLP)?

I see now that these points are +/- all related. My intent on the last point was to have as good as possible alignment between vehicle and pad (not the pad structures that already look good).

*ET burned texture still has the "rainbow" on the LOX feedline: There's actually no post-SRB sep versions of the textures yet.

Well, there's a texture change going on at SRB sep. BTW, not sure if I asked this before, but is it possible to manipulate textures in orbiter so that we have a texture for the ET and a burned texture, but only with the "burned areas" and the rest transparent, and when needed we overlay that on the normal texture achieving the burned effect?

 

[DaveS]

But we're still going to have at least 1 texture for OV-099 and OV-102 in a release, right?

Currently we don't have any real missions for them. The CCE (Centaur Cargo Element) for STS-61F/G is just really a dummy for now. Even the default Carina satellite is more functional and it is just a cfg.

Well, there's a texture change going on at SRB sep. BTW, not sure if I asked this before, but is it possible to manipulate textures in orbiter so that we have a texture for the ET and a burned texture, but only with the "burned areas" and the rest transparent, and when needed we overlay that on the normal texture achieving the burned effect?

Currently we don't have any burnt textures at all. So the texture switching doesn't really do anything.

 

[GLS]

Oh yes we do have a burned texture, and yes it shows up at SRB sep. Please run a fast launch scenario and you'll see.

 

[DaveS]

Oh yes we do have a burned texture, and yes it shows up at SRB sep. Please run a fast launch scenario and you'll see.

It's an old one, not compatible at all with the current line of ET meshes. And it is only for the SLWT.

 

[GLS]

Anyway it's still shows up at every launch.
How about the texture manipulation thing, is it possible? If that doesn't work, having a burned image with the rest transparent would probably help in creating the burned texture, one would just overlay the normal ET texture with the "burned transparency".

 

[SiameseCat]

We can comment out the code to change the ET texture at SRB sep, and re-enable it once we have working textures.

GLS, can you post a list of the scenarios with pad offset problems? The shuttle should be attached to the MLP (and the MLP should be attached to the pad), so there shouldn't be any offset issues.