SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

That shouldn't be a problem assuming things are better defined than with the ODS! That thing's a mess. Could we use the aft FD panels first so that they can move farther back to their proper positions relative to the Xo576 bulkhead?

I wanted to start with the RCS since we have many RCS related tickets open right now.



Also: Can we keep the current orbiter and VC meshes fixed for a moment and handle the many bugs there later?



I fear, if we start now again with modifying the meshes, we have both broken code and broken meshes at the end of the year.



Give me a moment and a few iterations to devise a general way to move all VC visual definitions into JSON files and when this works nice without modifying the meshes. Then we have a working mechanism for creating a "Facelift" branch, where no C++ coding is needed for fixing at least the VC mesh issues. While you can then fix the VC, I could keep developing towards a 5.1 bug fix release. When you are done and feel fine, we can merge the Facelift branch back to trunk. And we can put out a 5.1 release with the new VC.



For 5.2, we could then start with moving the many existing animations of the orbiter into one or many JSON files without modifying the orbiter mesh. Then we can update the "Facelift" branch with the 5.2 milestone, you can work happily on the orbiter mesh, I do bug fixes after the 5.2 release, then we merge into a 5.3 Facelift when you are done - and maybe we can then go towards a 6.0 release.



How does that roadmap sound to you, can you accept it?


The question is then, what do we do with the RCS? Kick it out of the 5.x development and place it into 6.0, where I wanted to fix things with the DPS? Or do small work on it in the mean time, parallel to the bug fixes and animation refactoring? Or door C: If you need longer for fixing the meshes as I need for fixing the bugs after an official release, I start pulling RCS tickets from the backlog until we are both done?

 

[DaveS]

That roadmap sounds good to me. I'll move over to the new branch once it has been created and continue my work there. As far as the RCS is concerned, I feel it is a lower priority item than the DPS. The RCS is working good enough for it to be kicked to a later release. The DPS has so many tendrils extending into other systems that it should be THE high priority item right now. The sooner we rip that band-aid off, the better off we are.

 

[Urwumpe]

That roadmap sounds good to me. I'll move over to the new branch once it has been created and continue my work there. As far as the RCS is concerned, I feel it is a lower priority item than the DPS. The RCS is working good enough for it to be kicked to a later release. The DPS has so many tendrils extending into other systems that it should be THE high priority item right now. The sooner we rip that band-aid off, the better off we are.

In the tickets, you might find some tickets labelled "Needs refinement". Can you look over them and separate them into multiple smaller tickets, ideally with a proper description of the individual problem and how it should get fixed?

When you split it up, just refer to the new ticket in the old one, I can make an example there for you, if you like, but I lack the insight right now to evaluate the bugs and do quality assurance there. (If somebody new wants to volunteer for pure visual QA - the job should be considered open)


No problem for me with the DPS, you know it is my pet subsystem.

 

[DaveS]

In the tickets, you might find some tickets labelled "Needs refinement". Can you look over them and separate them into multiple smaller tickets, ideally with a proper description of the individual problem and how it should get fixed?

Could you point to these? I can't seem to find them.

 

[Urwumpe]

I updated the Roadmap and sketched out the work needed to be done towards an improved DPS.


https://sourceforge.net/p/shuttleultra/wiki/Roadmap/


First of all: Making the existing code work with data as provided by STS sensors.

Could you point to these? I can't seem to find them.

With this link you should be able to find them:



https://sourceforge.net/p/shuttleultra/tickets/search/?q=labels:"Needs+refinement"

---------- Post added at 18:07 ---------- Previous post was at 18:03 ----------

Does somebody know how the L-time is communicated to the crew during the launch countdown?

 

[DaveS]

Does somebody know how the L-time is communicated to the crew during the launch countdown?

AFAIK, it isn't. I think it might be set in the DPS during final switch and crew module configurations once the T-11 hour BIH has been released by the ASP. JSC officially "owns" the crew module once the T-11 hour BIH has ended while the rest of the vehicle is still "owned" by KSC until lift-off. Once ground cooling has been established on the runway post-landing, KSC "owns" the vehicle again.

 

[Urwumpe]

AFAIK, it isn't. I think it might be set in the DPS during final switch and crew module configurations once the T-11 hour BIH has been released by the ASP. JSC officially "owns" the crew module once the T-11 hour BIH has ended while the rest of the vehicle is still "owned" by KSC until lift-off. Once ground cooling has been established on the runway post-landing, KSC "owns" the vehicle again.

Nothing set there except by LDB updates to GNC later. All I can find is a statement in the Ascent checklist that the flight crew only proceeds with its functions on call by the OTC, so I have to assume that the OTC tells the flight crew when to do certain tasks.


But I have no further information about the radio calls.

 

[STS]

Is the problem with the RMS fixed for you ?

Well, I didn´t test the RMS, so I don´t have context about the issue there.


However, I will test today´s "noonly" and see if something is wrong with the RMS, and review this thread to get the full context of the issue.

 

[DaveS]

Nothing set there except by LDB updates to GNC later. All I can find is a statement in the Ascent checklist that the flight crew only proceeds with its functions on call by the OTC, so I have to assume that the OTC tells the flight crew when to do certain tasks.


But I have no further information about the radio calls.

Yes, the OTC is in charge of communicating with the crew (primarily CDR, PLT and MS2). The crew is normally patched into KSC Operational Intercommunications System (OIS) channel 212 which is the prime Orbiter Vehicle comm channel. The Launch Team can also talk to the crew through the A/G loops as well as ICOM and UHF. The crew doesn't do anything without permission from the launch team in the Firing Room, that even includes moving the CDR/PLT seats and adjusting the brightness of the MDUs as they can be interpreted as something wrong with the EPS. Things get way more relaxed in orbit.


These two videos have the complete launch coverage of STS-135:

 

[STS]

I wanted to start with the RCS since we have many RCS related tickets open right now.



Also: Can we keep the current orbiter and VC meshes fixed for a moment and handle the many bugs there later?



I fear, if we start now again with modifying the meshes, we have both broken code and broken meshes at the end of the year.



Give me a moment and a few iterations to devise a general way to move all VC visual definitions into JSON files and when this works nice without modifying the meshes. Then we have a working mechanism for creating a "Facelift" branch, where no C++ coding is needed for fixing at least the VC mesh issues. While you can then fix the VC, I could keep developing towards a 5.1 bug fix release. When you are done and feel fine, we can merge the Facelift branch back to trunk. And we can put out a 5.1 release with the new VC.



For 5.2, we could then start with moving the many existing animations of the orbiter into one or many JSON files without modifying the orbiter mesh. Then we can update the "Facelift" branch with the 5.2 milestone, you can work happily on the orbiter mesh, I do bug fixes after the 5.2 release, then we merge into a 5.3 Facelift when you are done - and maybe we can then go towards a 6.0 release.



How does that roadmap sound to you, can you accept it?


The question is then, what do we do with the RCS? Kick it out of the 5.x development and place it into 6.0, where I wanted to fix things with the DPS? Or do small work on it in the mean time, parallel to the bug fixes and animation refactoring? Or door C: If you need longer for fixing the meshes as I need for fixing the bugs after an official release, I start pulling RCS tickets from the backlog until we are both done?

That roadmap sounds good to me. I'll move over to the new branch once it has been created and continue my work there. As far as the RCS is concerned, I feel it is a lower priority item than the DPS. The RCS is working good enough for it to be kicked to a later release. The DPS has so many tendrils extending into other systems that it should be THE high priority item right now. The sooner we rip that band-aid off, the better off we are.

About DPS and RCS, does DAP Config have something to do with working on the DPS?

This is, as I read that you want to work on DPS, I think that taking a look at the DAP Config issues I reported on another thread, has priority. But I don´t know if this is DPS or RCS.

 

[DaveS]

GLS: Could you provide an up-to-date list of the meshes that needs to be cleaned? I'd like deal with them as soon as possible.

 

[GLS]

GLS: Could you provide an up-to-date list of the meshes that needs to be cleaned? I'd like deal with them as soon as possible.

Nothing personal but... AFAIK that's your problem. :shrug:
My last months in SSU were spent busting my a*s with the meshes and I got no help (thus my leaving of the project), so don't expect help from me.

 

[STS]

Do this tickets serve as a list of meshes to be reviewed?


#170 PLB bay 13 holes/covers

#177 Orbiter.msh issues

#183 External Airlock mesh issues

#206 Mesh changes to eliminate flight deck window issues

#174 ODS sleeves

#184 ODS guide plates

#182 HUD not fully visible

 

[Urwumpe]

Do this tickets serve as a list of meshes to be reviewed?


#170 PLB bay 13 holes/covers

#177 Orbiter.msh issues

#183 External Airlock mesh issues

#206 Mesh changes to eliminate flight deck window issues

#174 ODS sleeves

#184 ODS guide plates

#182 HUD not fully visible

Yes, mostly, I already tried to categorize some of the tickets today for getting an overview of what has to be done.

 

[Urwumpe]

I could also add another one there to the list...

 

[Urwumpe]

Another one for the taskboard: Do we have a MCC building mesh yet?

 

[DaveS]

Another one for the taskboard: Do we have a MCC building mesh yet?

No, we don't. We don't even have a rudimentary JSC campus.

 

[Urwumpe]

No, we don't. We don't even have a rudimentary JSC campus.

That campus could be a nice task for somebody without C++ experience to contribute.


I just check what could be the start into adding mission control functions to SSU.

 

[DaveS]

That campus could be a nice task for somebody without C++ experience to contribute.


I just check what could be the start into adding mission control functions to SSU.

Well, there's this old add-on: https://www.orbithangar.com/showAddon.php?id=c54ba45b-ea60-49a7-85f6-fb763235823b

 

[Urwumpe]

Well, there's this old add-on: https://www.orbithangar.com/showAddon.php?id=c54ba45b-ea60-49a7-85f6-fb763235823b

A bit old - would have to see how it looks like in 2016. Also, I would prefer our own solution for license reasons.