SSU Development Thread (2.0 to 3.0)

[GLS]

The following refers to the 2 MPS Dump switches on the top of the panel: I'm pretty certain that the current panel we have is the "original version" of the panel (I can't prove that, but I know it was like this in 1988). The panel in the SCOM (with the different labelling and functionality of the switches) probably dates from sometime in the 1990s (it appears in the SCOM before any mention of MEDS).
There's also the changes done to the APU switches and the painting of the MPS Power switches, that I don't know when they were made (I think the MPS Power painting is "recent").
So, my bet is that the current panel is the "original" one from the 1980s, except the painting of the MPS Power switches. I can live with the different version for now... but maybe we should add some warning to the users about the MPS Dump switches.

 

[Urwumpe]

Yeah, I also think that the panels are based on the early "post-challenger" SCOM, not the post-columbia SCOM.

 

[DaveS]

Two things with the orbiter:

Critical. The down-ward firing ACRS jets are located too fair inboard. Their centerlines should be located in line with the aft engine compartment.

Helpful charts:

Second issue, gaps between the body and the elevons:

 

[Donamy]

Two things with the orbiter:

Critical. The down-ward firing ACRS jets are located too fair inboard. Their centerlines should be located in line with the aft engine compartment.

Helpful charts:

Second issue, gaps between the body and the elevons:

I'll look at those.
Also, with the newest R15 release, my crashing issue when changing the views in the VC are fixed. However, MFDs that are turned off, look like this.

 

[DaveS]

I also noticed that the Xo1307 bulkhead still isn't right. I think this photo shows how the OMS pods and the bulkhead joins together. The brown cylinder that runs along the bulkhead is the aft door bulb seal.

 

[Donamy]

Anyone else have the MFD issue, with the newest Dx9 R15 release ?

 

[DaveS]

Anyone else have the MFD issue, with the newest Dx9 R15 release ?

MFDs are fine here.

 

[GLS]

OK, as a result of the MFD problem Donamy is having, I looked at the code to see if I could find something wrong... and I did, but it's not related to this problem. Back in r1784 when I added the capability for the overbright text in the MDU, I messed up good and basically all the text with the flashing attribute was overbright. :facepalm: I fixed this (and tested ), and attributes can now be combined, so the text can be (1) normal, (2) overbright, (3) normal flashing and (4) overbright flashing.
I also removed some more debug strings, and I'm wondering if it would be a good idea to have those debug strings inside #ifdefs, so we could use them in development, and by removing a #include they would go away for the release version...
3 more things:
-panel F8 occasionally freezes and the switches and MFDs buttons don't work (only there).
-there's some mesh/transparency issue with the view out of overhead windows when looking from anywhere but the aft station.
-is anybody else getting a tree conflict for the Space Shuttle Ultra/Centaur folder when switching from trunk to the Centaur branch?

 

[DaveS]

GLS: I don't experience any problems with any of the MFDs. There is currently a alignment issue with the VC as the main orbiter mesh has changed and the VC hasn't. It's still tuned to the old mesh, which is why the VC overhead windows doesn't match the main mesh.

And yes, I get tree conflicts when switching branches.

 

[GLS]

The MFDs are also good here, I just went looking around trying to find something wrong... and I did, but not related.
The tree conflict is strange... could it be from the branch having a folder that the trunk doesn't?

 

[Capt_hensley]

Thats called development and is absolutely normal. Every development, may it be software, TV sets or spacecraft is developed in iterations. It is a learning process, since you find out the UNK-UNKs, find solutions for the UNKs, handle technical debt created along the way and also develop new better solutions than you had been able to imagine before you started the project.





Sorry - wrong. Not wrong, that it would be much better if we could go all the Continuous Delivery way that is now commonplace in software development (which could mean weekly releases in the best case).

The error is in the assumption that a) we are not having a functional code base already and b) just having a functional code base results in better releases.

The fact is: For the amount of work to be done and the amount of developers that we have available, we are progressing well and no, we are not repeating ourself and doing the same development work all the time. We are iteratively improving SSU.

Also, we could have had about 6 releases already since September. Bad releases. With lots of bugs and lots of complaints. Public beta testing is something that we should IMHO never do again in SSU, because instead of attributing the bugs to the early beta state, downloaders will attribute bugs to the quality of SSU in general. Orbiter is a poor place for public beta testing as I observe it.

If you want to test SSU already before any half-way stable release, you are free to make your own. The source code and the artwork of SSU is open source. If you want to help the project as official tester doing real software tests (instead of just playing around with something brand new), we can sure find a way to integrate you.

Remember, this is a freetime project. We can't do 30 day sprints like it would be possible for a full-time project. We don't even have all developers available all through the year.

Thanks for the invite...

I'm still a beginner flying anything in orbiter, much less developing my Gateway Station, I'd love to contribute but I'm way behind on this. Just too much catch up work to be done for me to contribute at a worthy level.

As I said before I think the team is doing great work, even if it is free time work, you are the experts at this. It was just my opinion, and I know yours and the teams opinion is far more valuable. I'll continue to observe with baited breath and high hope for continued success.

Thanks again for replying to my ramblings...

 

[Urwumpe]

Just too much catch up work to be done for me to contribute at a worthy level.

Well, as tester, you are much more valuable if you have almost no clue about add-on development and the source code of SSU. You are not expected to know how it would behave according to the code.

You are testing SSU against the specifications then, which are mostly the NASA documents. You need to work methodically and some experience in software testing is sure helpful to build up the necessary processes for SSU, but I can assist there, if you don't have an idea how to start and what you should request from the developers and "product owners".

 

[SiameseCat]

The MFDs are also good here, I just went looking around trying to find something wrong... and I did, but not related.
The tree conflict is strange... could it be from the branch having a folder that the trunk doesn't?

I just tried switching from the trunk to the Centaur branch and back, and I didn't get any tree conflicts.

 

[Urwumpe]

I just tried switching from the trunk to the Centaur branch and back, and I didn't get any tree conflicts.

I also had no problems on the trunk, but "somebody, who should reflect this behaviour and feel really bad about it" still committed too many compiler warnings on it, which I fixed during the break while writing the next article for university.

I know that most of the warnings are really not problem. But some in the sprintf_s department had been in the deep red department, like using a three character buffer for printing an integer string, that could have three digits. The code would work from 00 to 99, but could crash SSU completely unexpected at 100: sprintf would try to write four characters then, '1', '0', '0' and '\0' as string terminator.

And also: Every warning took me just a few seconds to fix, rarely more than 10 s (reading buffer variable identifier, looking for definition, comparing buffer size with output format). Why not do this before you commit?

Finally, remember that while we usually talk about harmless compiler warnings, which are syntactically maybe appearing harmful to the compiler, but which are semantically OK because we should be knowing what we are doing, every such trivial warning too much might lead to missing the compiler warning that is really pointing us at a bug already at compile time.

 

[DaveS]

What causes the tree conflicts for me is Config\Spacecraft\CISS_CentaurG_Prime.ini and Orbitersdk\Space Shuttle Ultra\Centaur.

 

[GLS]

What causes the tree conflicts for me is Config\Spacecraft\CISS_CentaurG_Prime.ini and Orbitersdk\Space Shuttle Ultra\Centaur.

To me it's just the last folder... it could be because I have some changes in the files. When you finish the mesh I'll commit them and then we'll see if it goes away.

 

[GLS]

I just committed a few changes to the MDU/CRTMFD relating to the menus. It's different from what we had before, but (I think) it's a step forward, even though it's pretty much a hack. The only "problem" is that the selected display isn't highlighted in white in the menu as it should. It would be too much messing around to get this done because of the CRTMFD. When we get rid of it, the highlight think will be easy.
Also added 2 tickets: #79 isn't that urgent, but #78 must be fixed for this release.

 

[Urwumpe]

The only "problem" is that the selected display isn't highlighted in white in the menu as it should. It would be too much messing around to get this done because of the CRTMFD.

What is the problem?

 

[GLS]

What is the problem?

In reality the current display "key" in the menu is highlighted white. In our setup the menu is being written in the MDU and the CRTMFD is the one that decides which display is up. So we would need to have the CRTMFD communicate to the MDU which display is up, so it could do the highlighting. I tried but didn't succeed... feel free to give it a go.

 

[Urwumpe]

In reality the current display "key" in the menu is highlighted white. In our setup the menu is being written in the MDU and the CRTMFD is the one that decides which display is up. So we would need to have the CRTMFD communicate to the MDU which display is up, so it could do the highlighting. I tried but didn't succeed... feel free to give it a go.

I'll take a look there, it sounds to me like something has become more complex than I remember it.

I want to change the DPS screen drawing after the release... plan to separate GPC software and display drawing instructions, so different programs can use the same displays.