Space Shuttle Ultra 1.25 Revision B development

While looking for some R2 stuff, I found this homepage with some really great shots of the PCR (Look at "The Thing"), DaveS, you might be interested in this:

http://www.edcheung.com/job/sm4/sm4d.htm

What I see here in a checklist on my smartphone:

Group: MPS
Group: PRPLT DUMP

Switch: SEQUENCE START (MPS PRPLT DUMP SEQUENCE START): START, GPC, STOP
Switch: BACKUP LH2 VLV (MPS PRPLT DUMP BACKUP LH2 VLV): OPEN, GPC, CLOSE


(Source: Contigency Deorbit Prep, Generic, Rev L, May 8, 2007)
 
Managed to "fix" the Left He I/C switch problem on panel R2! I compared the 2 sets of coordinates from DaveS and found that the "offset" between them was +/- the same except for that switch. I though maybe there's a writing error somewhere, and changed the number from
He INTERCONNECT LEFT: 1.1014, 14.187, 1.7986
to
He INTERCONNECT LEFT: 1.0114, 14.187, 1.7986
and it worked!!!:tiphat:

On the other "problem", the PBs on panel C3, I still don't know what to do... the covers move but I can't get the PBs to respond in anyway...
 
On the other "problem", the PBs on panel C3, I still don't know what to do... the covers move but I can't get the PBs to respond in anyway...
I checked the mesh and there's actually no PBs underneath the covers. It's just the covers and nothing else.
 
I checked the mesh and there's actually no PBs underneath the covers. It's just the covers and nothing else.

Then I can't do nothing... still, there is no rush as I have A LOT of work to do in other areas.
 
Given that the new "Block 2" orbiter mesh/textures won't be ready for a while, would it be possible to implement accurate operation of Ku band system? I checked in the actual equations used by the system a while ago which is what prevented us for getting it up and running in the first place. It would be nice the dish/gimbals actually do something other being just static.
 
Given that the new "Block 2" orbiter mesh/textures won't be ready for a while, would it be possible to implement accurate operation of Ku band system? I checked in the actual equations used by the system a while ago which is what prevented us for getting it up and running in the first place. It would be nice the dish/gimbals actually do something other being just static.

I am currently at the ATVC hydraulics in SSU and will divert some of my resources this weekend to partying and a two stage rocket, so I won't implement something quickly there.
 
I checked in the changes I made to the CRTMFD OMS/MPS display. It now resembles the real one and looks a bit better:

Updated_OMS_MPS_CRTMFD.jpg


If someone can dig up a photo of the real APU/HYD display, I'll work on that as well.
 
Last edited:
Is the SCOM drawing on page 2.1-19 (page 101) too inaccurate?

Otherwise use the training manual...

http://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

Also, the coordinates in the display there go to 1151...
It's not that it's inaccurate, it's that's a b&w drawing. I need photos to be get the color scheme right. It's no longer a one color(green) display. MEDS introduced colors, not even the various TRAJ DPS screens are one color screens anymore.
 
It's not that it's inaccurate, it's that's a b&w drawing. I need photos to be get the color scheme right. It's no longer a one color(green) display. MEDS introduced colors, not even the various TRAJ DPS screens are one color screens anymore.

The colors are VERY likely limited to 6 or even less. I am pretty sure, the color scheme of the APU/HYD display is the same as for the MPS/OMS display

The APU/HYD/WSB workbook also contains the color coding for the various indicator ranges.
 
Last edited:
iirc the APU display is just white, green, and red.
After a bit of research, I can confirm this. I can also tell that the emulated DPS screens use the same font, which in our case is Arial.

---------- Post added at 09:57 PM ---------- Previous post was at 09:52 PM ----------

The updated APU/HYD display has now been checked in.
 
After a bit of research, I can confirm this. I can also tell that the emulated DPS screens use the same font, which in our case is Arial.

At least something sans serife.
 
I'm doing some work on panel C3, can someone tell me how we are handling PBs? Can they be part of the main C3 mesh or do they need to be separate groups?
 
I'm doing some work on panel C3, can someone tell me how we are handling PBs? Can they be part of the main C3 mesh or do they need to be separate groups?

If animated, they should be separate groups, so we can push them up/down.

If they have a light effect, I would suggest a small improvement to what we do today, having two materials that we can assign to the PB group.

I want the same for the C&W lights, can you modify this?

Switching materials is MUCH faster than the bitblit operations we currently do.
 
If animated, they should be separate groups, so we can push them up/down.

If they have a light effect, I would suggest a small improvement to what we do today, having two materials that we can assign to the PB group.

I want the same for the C&W lights, can you modify this?

Switching materials is MUCH faster than the bitblit operations we currently do.
The DAP PBs have a strip that light up when they're selected, the same goes for the channel PBs on F1/F4. The rest are just normal PBs with no lights.

It should be no problem adding a "dark" material.

---------- Post added 08-25-13 at 12:27 AM ---------- Previous post was 08-24-13 at 11:56 PM ----------

For the C&W lights: Do you want each light as separate group or will a combined group suffice?
 

For the C&W lights: Do you want each light as separate group or will a combined group suffice?

Each separate. Each with a numerical ID as group name. All using the same texture for the off state and another texture for the lightened state. Ideally we can make the lights a bit emissive then.

For getting the two materials into the mesh, you could cheat a bit by making one light on and the others off, we then just need to remember that we need to initialize the mesh properly before use.
 
Finally done with the C/W matrix on F7. Each light is now separate and named with the prefix of "CW_". Should the dark material be the default material?
 
Finally done with the C/W matrix on F7. Each light is now separate and named with the prefix of "CW_". Should the dark material be the default material?


See above... I think when you make it the default material, the other material would not be written into the mesh file, since it is not used. You would always need to manually edit the mesh afterwards and add the material.
 
the other material would not be written into the mesh file, since it is not used. You would always need to manually edit the mesh afterwards and add the material.
Not really, if I add it to a something simple like a plane that's really small and practically invisible. This way it would always be written and included and ready to be used.

---------- Post added at 05:23 PM ---------- Previous post was at 03:28 PM ----------

Checked in the updated VC mesh. Let me know if you spot any problems.

---------- Post added at 05:42 PM ---------- Previous post was at 05:23 PM ----------

A bare-bones technical document on the SSU VC has been checked in.

---------- Post added at 10:07 PM ---------- Previous post was at 05:42 PM ----------

I have checked in fixed files that takes care of the undeclared identifier errors that was caused by the VC updates.

---------- Post added 08-26-13 at 12:55 AM ---------- Previous post was 08-25-13 at 10:07 PM ----------

I checked in a few fixes to a number of mistakes that I had done. This includes checking in updated textures for the F7 C/W matrix and the C3 panel.
 
Back
Top