SSU Development Thread (2.0 to 3.0)

[GLS]

The lights are off when not needed to conserve reactants for the fuel cells.

Yes, that's my logic as well, but then...

It looks like too much light at the PLB windows to be just reflection from the overhead windows. And from STS-135 it's all off. :S

 

[DaveS]

The lights are off. Turning them on is part of the PI checklist, Block 4. You're forgetting about the fluorescent light that's in between the overhead windows.

 

[GLS]

The lights are off. Turning them on is part of the PI checklist, Block 4. You're forgetting about the fluorescent light that's in between the overhead windows.

I'll go over the scenarios then.

 

[Donamy]

So what is the consensus on the hatch proposal ?

 

[Urwumpe]

So what is the consensus on the hatch proposal ?

I think, in the case of not finding a better solution, we should make the hatches optional and configurable by mission file.

I think, in my own horrible opinion, from looking at how the TAA gets used, that it likely has only one hatch itself (the one on top), and the other hatches are provided by the modules it connects to.

 

[Donamy]

I will deliver the TAA and ExAirlock, with only covers for now for release. Hatches to be decided.

Sound like a plan ?

 

[GLS]

Do we really need the hatches now? Could we just add the outside parts now, and leave the inside parts for later when we have something to do in the airlock or SpaceHab, etc?

---------- Post added at 01:22 AM ---------- Previous post was at 01:22 AM ----------

I will deliver the TAA and ExAirlock, with only covers for now for release. Hatches to be decided.

Sound like a plan ?

Yes, the covers are there for sure, and we'll deal with the hatches and the insides later.

 

[Urwumpe]

I will deliver the TAA and ExAirlock, with only covers for now for release. Hatches to be decided.

Sound like a plan ?

This also sounds like a plan to me.

 

[Donamy]

Did you remove the circuit protection first?

That was it. Worked great, but boy is it slow.

 

[Urwumpe]

That was it. Worked great, but boy is it slow.

I know. :lol: Luckily there is time warp, otherwise, my pizza bill would have grown a lot.

About the SSU Workbench ... I am getting into some WPF specific issues right now, which mean more study and less coding there. Breaking the main window up into smaller elements is much harder in WPF than in JavaFX it seems. I have a TabControl with multiple pages, but it seems like the only way to have my own XAML + .cs file for one of the tabs is to use an UserControl, instead of deriving a new class from a Panel.

Would it make sense to commit this early state or would it be better to wait?

 

[GLS]

I know. :lol: Luckily there is time warp, otherwise, my pizza bill would have grown a lot.

About the SSU Workbench ... I am getting into some WPF specific issues right now, which mean more study and less coding there. Breaking the main window up into smaller elements is much harder in WPF than in JavaFX it seems. I have a TabControl with multiple pages, but it seems like the only way to have my own XAML + .cs file for one of the tabs is to use an UserControl, instead of deriving a new class from a Panel.

Would it make sense to commit this early state or would it be better to wait?

Why do you need to have a "XAML + .cs file" per tab, and what does that file do by the way?

 

[Urwumpe]

Why do you need to have a "XAML + .cs file" per tab, and what does that file do by the way?

XAML describes the user interface/View in XML format. Like FXML in JavaFX, it allows to separate the appearance of the GUI from the implementation. The idea is a model-viewmodel-view architecture there. The view is the XAML, the view model the partial class in C#, that provides the data and behaviour to the XAML view and the model the actual data.

Having such files once per tab would, analog to the VC meshes, allow editing the actual tabs simpler and make it easier to replace tabs if needed.

Instead of having one complex large XAML file, it would be one main window XAML and one "view page XAML file" to handle the actual data entry.

I know that it is no problem doing that in JavaFX, but in WPF, a lot there is different. The book I have here recommends User Controls for that task that I want (encapsulate complexity).

 

[GLS]

XAML describes the user interface/View in XML format. Like FXML in JavaFX, it allows to separate the appearance of the GUI from the implementation. The idea is a model-viewmodel-view architecture there. The view is the XAML, the view model the partial class in C#, that provides the data and behaviour to the XAML view and the model the actual data.

Having such files once per tab would, analog to the VC meshes, allow editing the actual tabs simpler and make it easier to replace tabs if needed.

Instead of having one complex large XAML file, it would be one main window XAML and one "view page XAML file" to handle the actual data entry.

I know that it is no problem doing that in JavaFX, but in WPF, a lot there is different. The book I have here recommends User Controls for that task that I want (encapsulate complexity).

I can't help... good luck.

 

[Urwumpe]

I can't help... good luck.

I know. Thank you.

 

[DaveS]

GLS: I noticed that you changed the GH2 vent arm retract rate in the revision 2276. Why did you do that? I corrected this in revision 2104. Mine was timed from a engineering film of the real GH2 vent arm being retracted at lift-off.

 

[GLS]

GLS: I noticed that you changed the GH2 vent arm retract rate in the revision 2276. Why did you do that? I corrected this in revision 2104. Mine was timed from a engineering film of the real GH2 vent arm being retracted at lift-off.

First, the numbers were different between the pads and second, I time around 1.5 seconds instead of the 2 seconds from one of the pads and the other was 0.5 seconds or there abouts. BTW I'm just counting the arm motion and not umbilicals releasing and other things we don't have.

 

[DaveS]

First, the numbers were different between the pads and second, I time around 1.5 seconds instead of the 2 seconds from one of the pads and the other was 0.5 seconds or there abouts. BTW I'm just counting the arm motion and not umbilicals releasing and other things we don't have.

The release mechanism for the GH2 vent arm is really simple: At T0 the pyro-bolt is detonated causing the vent arm to move directly back to clear the vehicle. Then it simply free-falls until is caught by a set of teeth in the IAA Support Structure which latches the arm in place and prevents any further motion.

---------- Post added at 08:19 PM ---------- Previous post was at 08:15 PM ----------

Here's two documents that details the ET GH2 Vent Arm system:

External Tank GH2 Vent Arm

Modification and development of the external tank hydrogen vent umbilical system for the space shuttle vehicle

 

[GLS]

New payload bay hardware is (finally) committed! Please check for problems.
The STS-76 scenario uses the TAA (BTW I think there's something wrong with the ScenarioEditorTLE as Mir is nowhere near in plane at launch).
Some issues:
- Donamy, can you check that one of the textures used in the ODS mesh is STScargobay.dds? You had a "cargobay.dds" but that doesn't exist;
- the docking port Y position probably needs fine tuning;
- there's loads of clipping in the external airlock VC position that I don't know how to fix;
- the forward bulkhead cover/hatch is not at same position (Y axis) as the external airlock so they don't meet (this is not a new problem).

Let me just have lunch and then finish updating the manual and I'll commit it up as well.

---------- Post added at 02:40 PM ---------- Previous post was at 01:51 PM ----------

The updated manual is up, please read it to check for errors and/or things that can be improved.
I'll now try to find the story on panel A8, and then if there's time add the Shannon and Gander runways to the AerojetDAP.

 

[Donamy]

The groups assigned to the cargobay.dds, should be assigned to docking_ring.dds

Can you change that or sshould I re-send ? I can check the positioning also.

 

[GLS]

The groups assigned to the cargobay.dds, should be assigned to docking_ring.dds

Can you change that or sshould I re-send ? I can check the positioning also.

If it's just changing the texture name at the bottom, I can do it.

---------- Post added at 03:24 PM ---------- Previous post was at 02:59 PM ----------

The groups assigned to the cargobay.dds, should be assigned to docking_ring.dds

Can you change that or sshould I re-send ? I can check the positioning also.

Done.