SSU Development Thread (2.0 to 3.0)

[GLS]

Thanks. Just a heads up: A while ago I checked in an updated Orbiter mesh that has a few changes required for the Centaur namely the midbody T0 cavities in Bay 13. These now have the appropriate covers over them by default. I think these changes need to be merged into the ShuttleCentaur branch.

I don't think that is needed. All the stuff in the ShuttleCentaur branch is coming to the trunk anyway. Unless it's something critical for development, it can wait for the Centaur in the trunk.

 

[Urwumpe]

I did a bit of archaeology and found that this code was added in revision 250 (19/07/2008) by a certain "Urwumpe" user... so that "somebody with more knowledge" would be you.:lol:

That's not the same person as me. That person was way more stupid 4 weeks ago. (Sorry, but I can hardly remember what happened three days ago. 2008 feels like there must have been knights and dragons around.)

 

[Donamy]

Thanks. Just a heads up: A while ago I checked in an updated Orbiter mesh that has a few changes required for the Centaur namely the midbody T0 cavities in Bay 13. These now have the appropriate covers over them by default. I think these changes need to be merged into the ShuttleCentaur branch.

All vertices were welded I hope. :thumbup:

 

[DaveS]

All vertices were welded I hope. :thumbup:

Does it even matter since the vertices get unwelded when you import it? But to answer your question directly, yes the vertices have been welded. In fact, there's no vertices to be welded as I used the technique used to create the star trackers and the ARCS jet nozzles. So there's no cutting (boolean operation) at all involved.

 

[GLS]

I need the coordinates (the ones that need 3D software) for the gear arm and deploy covers on both panels F6 and F8 please...

 

[DaveS]

I need the coordinates (the ones that need 3D software) for the gear arm and deploy covers on both panels F6 and F8 please...

CDR ARM cover: -0.92, 1.99996, 14.68735
CDR DN cover: -0.87370, 1.99996, 14.68735

Dir vectors for both covers: 0, 0.965408, 0.260745

PLT is identical except for mirrored X axis.

 

[GLS]

CDR ARM cover: -0.92, 1.99996, 14.68735
CDR DN cover: -0.87370, 1.99996, 14.68735

Dir vectors for both covers: 0, 0.965408, 0.260745

PLT is identical except for mirrored X axis.

Could you check the dir vectors again? That only works for the CDR DN cover, and I've tried all +/- combinations with no sucess.

 

[DaveS]

Could you check the dir vectors again? That only works for the CDR DN cover, and I've tried all +/- combinations with no sucess.

Try these:

CDR ARM Cover: 0, 0.965408, 0.260745
CDR DN Cover: 0 -0.965408 -0.260745

 

[GLS]

Try these:

CDR ARM Cover: 0, 0.965408, 0.260745
CDR DN Cover: 0 -0.965408 -0.260745

The CDR ARM still goes away when opening, and the CDR DN does the same (this one works perfectly with 0, 0.965408, 0.260745).

---------- Post added at 06:25 PM ---------- Previous post was at 06:18 PM ----------

More info: the CDR ARM cover opens well with 0 -0.965408 -0.260745.... but it hinges on the right side of the cover instead of the left side. :facepalm:

---------- Post added at 06:29 PM ---------- Previous post was at 06:25 PM ----------

I just found the problem on the CDR side... I didn't have the reference. :blush: It now works well there.

---------- Post added at 07:02 PM ---------- Previous post was at 06:29 PM ----------

I can't find a way to get the PLT side to work.

BTW: I noticed that both these switches and the talkbacks appear to have "glass" over them. I looked on other panels and there's nothing like it anywhere. Is this normal?

 

[DaveS]

BTW: I noticed that both these switches and the talkbacks appear to have "glass" over them. I looked on other panels and there's nothing like it anywhere. Is this normal?

Yes. Probably due to some misunderstanding over the design of the panels. It wouldn't be the first one. Donamy, any comments from you since you are the original designer?

 

[GLS]

I've attached a picture of how it looks.

 

[Donamy]

I've attached a picture of how it looks.

I think that was Michael Grosberg's design.

 

[GLS]

I can't find a way to get the PLT side to work.

Anyone?
I'm trying to move panel R13L to AtlantisPanel, but I'd like to finish things at the front first, so the code changes don't mix together during the "transplant".

 

[STS]

Asking as SSU "astronaut":

Those gear switches look really cool, but I think that if you as CDR have to click them with the mouse, will make the landing harder, because you have to lose focus on the HUD to look for the switches, uncover them an click them (looking for them and 2 mouseclicks at 3000ft and the same at a critical 300 ft). Aren't those switches actioned by the Pilot while the CDR focuses on landing watching HUD and instruments, hearing and paying attention to Pilot´s callouts?

I thing there could be a hotkey to Arm and Deploy, that also shows the panel animations (I don´t know if already this is how you are thinking about this).

 

[DaveS]

Anyone?
I'm trying to move panel R13L to AtlantisPanel, but I'd like to finish things at the front first, so the code changes don't mix together during the "transplant".

It's going to be hard to troubleshoot code we can't review so can you check it in?

 

[Urwumpe]

I thing there could be a hotkey to Arm and Deploy, that also shows the panel animations (I don´t know if already this is how you are thinking about this).

AFAIR, there is a key binding for that. CTRL+G for arming and G for deploying the armed gear, I think.

The VC binding is just needed for simplifying the code actually - if all can be mapped to the switches and pushbuttons, we can use similar code everywhere and avoid special solutions for hotkeys.

My personal ideal solution would be a hotkey action service in SSU - a class, that executes abstract actions on the VC model, like "Open switch cover and press button". This would again remove a lot of extra code and in the long term, we could make the hotkeys (slightly) configurable.

 

[GLS]

It's going to be hard to troubleshoot code we can't review so can you check it in?

Just committed it.
The area of interest starts in line 96 of PanelF8.cpp and is marked by "\\\\\\\\\\\\\\\\\\\\\\\\\\\" the the end of the lines.

Asking as SSU "astronaut":

Those gear switches look really cool, but I think that if you as CDR have to click them with the mouse, will make the landing harder, because you have to lose focus on the HUD to look for the switches, uncover them an click them (looking for them and 2 mouseclicks at 3000ft and the same at a critical 300 ft). Aren't those switches actioned by the Pilot while the CDR focuses on landing watching HUD and instruments, hearing and paying attention to Pilot´s callouts?

I thing there could be a hotkey to Arm and Deploy, that also shows the panel animations (I don´t know if already this is how you are thinking about this).

Thanks!
The gear arm and deploy is automatic, so you don't have to worry about it. There is also a key combination (Ctrl+G and G) to do the same manually if you want. This change is mostly visual, as it adds the lights to the buttons, but it also adds another way to get the gear down.

 

[DaveS]

Hey, just a heads up from me. You might have read in the Random Comments thread that a few days ago I had some PC issues. Well, earlier yesterday, it died entirely, no recovery possible. Everything SSU related is intact though, so no actual progress losses other than just the ability to perform the work.

Based on my current finacial situation, the earliest possible "Return To Flight" for me would be end of the year. I will however be able to perform limited research and comments on general development.

 

[GLS]

Hey, just a heads up from me. You might have read in the Random Comments thread that a few days ago I had some PC issues. Well, earlier yesterday, it died entirely, no recovery possible. Everything SSU related is intact though, so no actual progress losses other than just the ability to perform the work.

Based on my current finacial situation, the earliest possible "Return To Flight" for me would be end of the year. I will however be able to perform limited research and comments on general development.

I'm sad to hear that.

---------- Post added at 03:27 PM ---------- Previous post was at 11:18 AM ----------

The updated panel R13L is up, please test to make sure it works as expected.

---------- Post added at 04:47 PM ---------- Previous post was at 03:27 PM ----------

Please disregard the PLT landing gear cover issue, as thru much trial and error I managed to get those covers to animate properly.


---------- Post added 07-10-15 at 01:57 AM ---------- Previous post was 07-09-15 at 04:47 PM ----------

Just updated panel A4 to AtlantisPanel, and had to work more than I expected: the coordinates were all messed up... :facepalm:
Decided not to go on another trial-and-error adventure to find the correct coordinates, and inspired by the 3d modeling thread, I got blender (and a .msh plugin by vlad32768) and tried to get the points myself. Easier said than done, as I didn't find blender to be as intuitive as I expected. I couldn't select specific vertices but only nearby points, but it looks like it's good enough as the panel boundaries and the switch movement look OK.

---------- Post added at 01:19 PM ---------- Previous post was at 01:57 AM ----------

I just created a new ticket related to a problem I was having in panel A8 and can't find the problem. I didn't mentioned in it (because I think it's a different problem), but occasionally I also have a similar problem in panel F8, where the MDUs and switches stop responding mid simulation. Has anyone experienced these issues?

 

[Urwumpe]

II just created a new ticket related to a problem I was having in panel A8 and can't find the problem. I didn't mentioned in it (because I think it's a different problem), but occasionally I also have a similar problem in panel F8, where the MDUs and switches stop responding mid simulation. Has anyone experienced these issues?

I remember problems with the O5 panel that was very selectively reacting to mouse events, and which seemed to have its cause in the events getting routed to the A panels on the opposing side of the "VC camera"

Was visible in panel debug mode, but I failed to find the cause for that behavior as well.