SSU V1.25 Release

[Urwumpe]

Yes, and currently the STS-125/HST SM4 manifest is at our maximum for passive payloads(SLIC, ORUC, FSS and MULE). Could need one more for the MFR.

Well, we can also use the three active attachments for passive payloads, we would just have to make the latches all passive.

 

[DaveS]

Could work.

 

[Urwumpe]

Could work.

Is there a visual difference between passive and active latches?

 

[DaveS]

Other than the V-guides, no. Not that I can see.

 

[Urwumpe]

Other than the V-guides, no. Not that I can see.

So, we could make the V-Guides also separate mesh groups, and show them if the latch is active.

 

[DaveS]

So, we could make the V-Guides also separate mesh groups, and show them if the latch is active.

Sounds good.

 

[Urwumpe]

Sounds good.

Well, I will start the payload stuff with reading the extra data from configuration files into a shared memory object.

 

[Orbinaut Pete]

Payload Retention Latch:

 

[Orbinaut Pete]

Also, in the NASA Space Shuttle manual, there are a few pages explaining all about the PRL systems & control panels, with diagrams.

(I assume you have the manual) so see pages 1092-1095 (if you haven't already)

 

[DaveS]

The grappling problem is because there's no way of releasing the graaple payload from the payload bay (the purge button on the RMS dialog is broken). There are 2 ways to fix this: update the RMS dialog and use that, or use the actual PDRS switches. I can fix the dialog within a day or two, but it'll take more time to get the PDRS switches working.

While Urwumpe is working on the payload system, maybe you could take a shot at implementing the C&W system for the RMS?

One light on the RMS C&W matrix that could be of use is the yellow REACH LIM light. And getting a MASTER ALARM is a normal part of RMS power up as explained by the SCOM:

Placing the RMS POWER switch to
PRIMARY generates an RMS master
alarm. This alarm is generated because
the panel powers up faster than the
MCIU, thereby causing the MASTER
ALARM light and tone to annunciate
before the MCIU can respond with the
proper master alarm flag. This is a
normal condition and will occur every
time the RMS POWER switch is cycled
OFF and back to PRIMARY

This could be a good introduction before we move on to the more complex Orbiter C&W system which is seperate from the RMS C&W system.

 

[Donamy]

If this is going to take awhile, should we maybe go for a quick fix on the payload release, and go for a SSU 1.25 release, then we could work on other things as well before the 1.26 release?

 

[Urwumpe]

This could be a good introduction before we move on to the more complex Orbiter C&W system which is seperate from the RMS C&W system.

The Orbiter C&W is actually not too complex, it is a pretty repetitive task. I thought about implementing it stealthy in the current release, and enable it later. But first, I would like to do a better redraw handling, I think I had introduced some inefficiency there.


-----Post Added-----

If this is going to take awhile, should we maybe go for a quick fix on the payload release, and go for a SSU 1.25 release, then we could work on other things as well before the 1.26 release?

Well, depends on the priority. A quick fix release could be the best now, and adding the great stuff later.

 

[Donamy]

That way the 125 mission could be completed.

 

[SiameseCat]

I think the best thing to do is to focus on getting the latches done for V1.25, and work on other features after that.
As far as coding the latches is concerned, I'm working on a Latch class that will handle the actual attachments. Each latch instance will be associated with an attachment point on the shuttle. We can create these instances as required by the configuration file.

 

[Donamy]

I think this is best right now. We can think about linking to the switches later.

BTW, would it be helpful, if I get the coords of boxes around switches ?

 

[DaveS]

I think the best thing to do is to focus on getting the latches done for V1.25, and work on other features after that.

I agree. Especially since the payload handling system is a little broken right now, so it would be a bit foolish not to take this opportunity and get it right from the start.

That way we won't be confusing the users by having one kinda of payload system for one release and a whole another one for another release. This would just create confusion. So it is better to have one good system in place from the start.

 

[Urwumpe]

Looks like we could use some improvements on the BSM exhaust, the exhaust should be even more under-expanded in real flight conditions (compared to sea-level).


I have found a study about the aerodynamics of the SRBs, maybe this could be useful?

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770004147_1977004147.pdf
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750003950_1975003950.pdf

 

[DaveS]

Good view of SRB sep from one of the onboard SRB cams:

 

[Urwumpe]

Good view of SRB sep from one of the onboard SRB cams:

Oh well, looks like the post-burn effects of the BSMs needs some modelling.

 

[SiameseCat]

I just noticed that I've managed to introduce a bug where any scenario that does not contain either the RMS or STBD MPMs will CTD. This should be fixed soon.
If the RMS or MPMs are not included in the scenario, an attachment with the "INVALID" ID string will be created as a placeholder; this will avoid messing up the attachment indices.


-----Post Added-----


Bug mentioned above should be fixed now.