SSU Development Thread (2.0 to 3.0)

[Urwumpe]

OK, in that case there's not much that can be done. The newer stuff in the SVN repository already makes use of the new meshes/textures.

There is something that can be done. A new release.

What about the following plan:

1. We use the next week (or so) for simply doing code reviews on the trunk. Anybody may take part. Who rather wants to work on new features, no problem. I will pick some files and do nothing else but work on quality assurance there. I will look for dodgy code, write missing comments, ask questions if I fail to understand what purpose a function has.
2. At the end of the week (or so), we (or I) will make a new production branch for the next release. We will use this production branch only for bug fixes towards the next release and will not bother about features. Every friday we will make a new release from this branch. Even if it is still buggy. Rain or shine.

I would also like to invite Donamy to both stages. He might not be a C++ coder for the first stage, but in this situation, this could be an advantage for the quality assurance, by asking the right stupid questions.


For the second stage, we will need testers. I will not stop somebody from implementing new features on the trunk, but I would like to have somebody who a) works on the trunk and b) is volunteering for reintegrating bugfixes from the release branch back into the trunk, so the effort is a bit longer lasting. I will keep focus on the release branch for a while.



I lack the time for some bigger SSU work, but that doesn't mean I can't do the small stuff - and if it is just bugfixing for a weekly "banana release".

Also, I would like to see the code reviews to continue for a while on the trunk for improving code quality. Maybe we could also have a "file/class of the month" in the forum for performing a public code review so more people can participate. But this would make sense once we have at least minimal code formatting standards implemented - especially the lack of comments and source code documentation makes this currently difficult.

 

[Donamy]

I'm trying to work up a set of working SSU scenarios (ISS assembly), launch dates and Orbital elements, including payloads. A new release with the scenarios, that work out of the box is needed. IMO

 

[GLS]

On my end: I think the mps branch is reaching the end (finally!). Yes, there's still buckets of things to do, but I think for now there's nothing major, so it could in the trunk.
Currently I'm doing some work/debugging in the ET LOX ullage pressure, because it's not staying within the control band with a fixed FCV (like in real life since STS-40). Probably will have to do the pre-STS-40 implementation for now.
There's a couple more things to do here and there, and the last (big) thing I'd like to do before the merger is the BFS GNC SYS SUMM 1 display... which I really don't know where it should go...

 

[Urwumpe]

There's a couple more things to do here and there, and the last (big) thing I'd like to do before the merger is the BFS GNC SYS SUMM 1 display... which I really don't know where it should go...

I think you do it best into the IDP code... but i can check this tomorrow if you can wait there. I don't want to talk too much about the real system there, because I feel badly misunderstood then.

 

[GLS]

I think you do it best into the IDP code... but i can check this tomorrow if you can wait there. I don't want to talk too much about the real system there, because I feel badly misunderstood then.

OK, I'll wait (there's still more comments to do :lol.
One related thing: do you think there's any performance gain by drawing the static parts (lines/titles/etc) onto a DC at the start, and when time comes to draw the display, we copy the "static DC" and just write the data, as opposed to drawing the whole thing at once?

 

[Urwumpe]

OK, I'll wait (there's still more comments to do :lol.
One related thing: do you think there's any performance gain by drawing the static parts (lines/titles/etc) onto a DC at the start, and when time comes to draw the display, we copy the "static DC" and just write the data, as opposed to drawing the whole thing at once?

It would be a perfectly legal optimization IMHO.

But you should be careful, what is static and what is dynamic. The real DEU (and its emulation in the real IDP) had a separation between static FCWs and dynamic FCWs, only the dynamic FCWs had been replaced in DEU memory for the usual display updates, while the static FCWs never changed unless you switched to a new display. I already found out quite a few FCWs for the DEU, but not all... especially many static FCWs are still unknown.

Also, some displays had a lot of their static contents stored in DEU/IDP memory during prelaunch processing and never needed the GPCs to send the painting instructions for them. They had just been recalled from DEU memory instead.

I wanted to have a way to paint the displays with such instructions, so we can avoid hardcoding displays and having to test every special display code, but don't think I can find the missing instruction codes in this lifetime.

For example a lot of the title line of every display is dynamic, not static.

 

[DaveS]

If we're going to make a release soon, I'd like to finish the new STS-107 payloads. But to do that, I need a texture for the EDO pallet. Donamy, do you think you could help here?

Photos can be found here: https://www.dropbox.com/sh/mpcv2vd4e3cobb0/AAAcURrih23PtErnwT_U7lU1a?dl=0

 

[Urwumpe]

If we're going to make a release soon, I'd like to finish the new STS-107 payloads. But to do that, I need a texture for the EDO pallet. Donamy, do you think you could help here?

Photos can be found here: https://www.dropbox.com/sh/mpcv2vd4e3cobb0/AAAcURrih23PtErnwT_U7lU1a?dl=0

Then finish it while we are doing some code reviews... I want to start the release branch with as clean code as we can afford. At a fixed time, we will do the branch and every feature that is not ready for release will have to wait for a later moment. I also would like to have the MPS stuff from GLS included, but I think a timely start of the release process is much more important than features.

 

[GLS]

Can anybody confirm that the ET LOX tumble valve and LOX vent/relief valve, vent thru the louvers in the nose cap?
If so then the current ET LOX vent (in the ground umbilical) should be called LH2 vent.... :facepalm:

 

[Urwumpe]

Can anybody confirm that the ET LOX tumble valve and LOX vent/relief valve, vent thru the louvers in the nose cap?
If so then the current ET LOX vent (in the ground umbilical) should be called LH2 vent.... :facepalm:

I think the tumble valve was in the Intertank section, at least the videos of it look like it.

 

[GLS]

I think the tumble valve was in the Intertank section, at least the videos of it look like it.

So did I, but in the few schematics I've seen, there's only 2 lines from the ground to the LOX tank: vent valve control (He pressure) and nose cone purge. Unless the "tumble vent" is thru the vent valve control line, I think the vent we see in those videos is LH2/GH2 from the LH2 ullage relief/vent valve...

 

[DaveS]

Can anybody confirm that the ET LOX tumble valve and LOX vent/relief valve, vent thru the louvers in the nose cap?
If so then the current ET LOX vent (in the ground umbilical) should be called LH2 vent.... :facepalm:

The tumble valve was located on the LOX tank FWD ogive plate along with the other LOX hardware:

 

[GLS]

So that settles it then, the vents in the videos are hydrogen not oxygen.
Thanks!

 

[DaveS]

So that settles it then, the vents in the videos are hydrogen not oxygen.
Thanks!

The LOX tumble valve only existed for a few tanks after which it was deleted as unnecessary and to save weight, much like the ET Range Safety System.

 

[GLS]

The LOX tumble valve only existed for a few tanks after which it was deleted as unnecessary and to save weight, much like the ET Range Safety System.

I had some ideia it was removed, so for now I'm not doing it. Sometime in the future it will appear.

 

[Donamy]

If we're going to make a release soon, I'd like to finish the new STS-107 payloads. But to do that, I need a texture for the EDO pallet. Donamy, do you think you could help here?

Photos can be found here: https://www.dropbox.com/sh/mpcv2vd4e3cobb0/AAAcURrih23PtErnwT_U7lU1a?dl=0

You could use the ones from the STS-118 addon.

 

[SiameseCat]

I think a new release is a good idea. I'm busy for the next 2 weeks or so, so I won't be able to do any work (I'll keep an eye on the forums in case anyone has questions).

Regarding the new MPS stuff: does this require scenario changes? If we have to update scenarios to handle the new MPS, we should try to include the MPS stuff in the next release.

 

[DaveS]

You could use the ones from the STS-118 addon.

STS-118 didn't carry a EDO pallet. I think you're confusing the EDO pallet with the SpaceHAB module. The EDO pallet always occupied bays 12/13 of the PLB to provide extra LH2/LOX for the fuel cells to enable extended mission durations.

 

[Donamy]

It looks like it uses the same fabric covering.

 

[GLS]

Regarding the new MPS stuff: does this require scenario changes? If we have to update scenarios to handle the new MPS, we should try to include the MPS stuff in the next release.

Yes, there are some changes. I have the "SSU" scenarios updated (in the mps branch for now) and I'll provide "canned" versions of the scenario blocks in question, so anyone can go there and copy what they need.