SSU Development Thread (2.0 to 3.0)

[GLS]

Due to the current display split between the CRTMFD and the IDP/etc, and also the lack of BFS, I need some pointers as to where and how I implement the BFS SYS SUMM 1 display, so we can all see more MPS data (and other stuff as well).

 

[Donamy]

I have a problem with the Orbiter mesh. There are all kinds of distortions around the startrackers and detached vertices on the port OMSpod. Also, the windows show spaces around them.

 

[DaveS]

I have a problem with the Orbiter mesh. There are all kinds of distortions around the startrackers and detached vertices on the port OMSpod. Also, the windows show spaces around them.

Could a screenshot be provided please? Alos, do you know what revision of the meshes/source code for the modules?

I'm using the latest checkd-in versions and I have no issues.

 

[Donamy]

I don't know what rev it is, but was downloaded 2 days ago.

 

[DaveS]

I don't know what rev it is, but was downloaded 2 days ago.

Looks like it's the old mesh, not the new one. Just to be absolutely clear, you downloaded this as a zipfile and not through a SVN client such as TortoiseSVN?

 

[Donamy]

yes

 

[Urwumpe]

yes

That could be the reason there - most of the activity is via SVN... Did you never try TortoiseSVN? It is really simple to use.

 

[DaveS]

yes

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.

---------- Post added at 09:43 PM ---------- Previous post was at 09:41 PM ----------

That could be the reason there - most of the activity is via SVN... Did you never try TortoiseSVN? It is really simple to use.

Yes, I even wrote up how to get an up to date SSU installation in this thread: http://www.orbiter-forum.com/showthread.php?t=30336

I have verified the instructions in that thread several times and they're fine.

 

[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: