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

[GLS]

Does not look so Ap was 80 NM then according to the cycle 3 document. But OMS-1 targeting is much easier than expected... look at the loaded target data.

I wouldn't put much weight on those numbers as the STS-1 OMS-1 burn was 87.0s long and produced a 164.5fps dV.
But the display is interesting, as it is very different from the "current" one. It will help in the 2030s when we finally implement different GPC software versions. :lol:

 

[Urwumpe]

I wouldn't put much weight on those numbers as the STS-1 OMS-1 burn was 87.0s long and produced a 164.5fps dV.
But the display is interesting, as it is very different from the "current" one. It will help in the 2030s when we finally implement different GPC software versions. :lol:

Actual burn and targets are not the same, as you know.

 

[GLS]

Actual burn and targets are not the same, as you know.

I'll give you that one, but I think that in this case the difference is too big for that to apply.

 

[Urwumpe]

I'll give you that one, but I think that in this case the difference is too big for that to apply.

Not sure - the burn targets are on the right in this version, PEG4. Ht=150 NM sounds orderly.

On the left are the simulated VGO values, which must not apply to reality, since they are calculated depending on the MECO conditions. Remember, this is STS-1, NASA did not yet know how the performance of the STS will be like in reality.

 

[GLS]

Looks like I managed to put my brain in gear and figured the orbital mechanics out. Looking at the STS-6 data, I'm getting good results: OMS-1 has ~3fps difference, less than a minute off in the OMS-2 TIG and ~10fps difference. I still have to try this in Orbiter but it's looking good.

 

[Urwumpe]

Looks like I managed to put my brain in gear and figured the orbital mechanics out. Looking at the STS-6 data, I'm getting good results: OMS-1 has ~3fps difference, less than a minute off in the OMS-2 TIG and ~10fps difference. I still have to try this in Orbiter but it's looking good.

Are you using PEG7 or PEG4 now? By what I can find, OMS-1 and OMS-2 used the PEG4 algorithm, contrary to the old MECOTool implementation, which used PEG7 because PEG4 did not work then.

 

[GLS]

Are you using PEG7 or PEG4 now? By what I can find, OMS-1 and OMS-2 used the PEG4 algorithm, contrary to the old MECOTool implementation, which used PEG7 because PEG4 did not work then.

PEG7.
Yes, I think only the "orbital" burns used PEG7, on the way up and down it was PEG4, but as that has not been implemented yet, PEG7 will have to do for now.

 

[Urwumpe]

PEG7.
Yes, I think only the "orbital" burns used PEG7, on the way up and down it was PEG4, but as that has not been implemented yet, PEG7 will have to do for now.

......... I used PEG4 lately for maneuvers. :blink:

 

[GLS]

For the first test in Orbiter I targeted a 300Km (circular) orbit. Got a 288x324... somewhat less than perfect. It seemed good right after the OMS-1.... until I decided to take out the residuals. It had the apogee at 301 and the correction decreased it. Then the OMS-2 was clearly too much and that's where the 324 came from. OMS-2 TIG was less than a minute off the apogee. I'll look at the post OMS-1 orbit to see if it matches with the math but overall, while not perfect I'm not displeased. Some of these errors come from the MECO results (it fails to nail the FPA) and also the wonky OMS burns.

 

[DaveS]

For the first test in Orbiter I targeted a 300Km (circular) orbit. Got a 288x324... somewhat less than perfect. It seemed good right after the OMS-1.... until I decided to take out the residuals. It had the apogee at 301 and the correction decreased it. Then the OMS-2 was clearly too much and that's where the 324 came from. OMS-2 TIG was less than a minute off the apogee. I'll look at the post OMS-1 orbit to see if it matches with the math but overall, while not perfect I'm not displeased. Some of these errors come from the MECO results (it fails to nail the FPA) and also the wonky OMS burns.

Well, the OMS burns are known to off, I have even filed a ticket for it: https://sourceforge.net/p/shuttleultra/tickets/95/

 

[GLS]

Well, the OMS burns are known to off, I have even filed a ticket for it: https://sourceforge.net/p/shuttleultra/tickets/95/

I've seen it, sadly I only have 2 hands and so much knowledge.

 

[Urwumpe]

I've seen it, sadly I only have 2 hands and so much knowledge.

I'll take a look at it at the end of the DPS transition, I am sure having a better DPS implementation behind it will fix some timing related problems as well.

We really need more developers for some special areas. Maybe it will be easier to start, if the DPS software is really not depending too much on the implementation of the subsystems.

 

[GLS]

I'll take a look at it at the end of the DPS transition, I am sure having a better DPS implementation behind it will fix some timing related problems as well.

We really need more developers for some special areas. Maybe it will be easier to start, if the DPS software is really not depending too much on the implementation of the subsystems.

BTW, when you do that, please take the CRT timer out of there and put it... "somewhere" where it can be used by humans and software, including the MNVR display.

 

[Urwumpe]

BTW, when you do that, please take the CRT timer out of there and put it... "somewhere" where it can be used by humans and software, including the MNVR display.

I'll take a look.

How will we track the requirements in SSU? Right now, the creative chaos worked well enough and the ticket tracker was good enough, but I think for more complex tasks, we need to be better organized so nothing goes missing.

EDIT: In the beta, did you already make CRT a vessel-specific MFD?

 

[DaveS]

I'll take a look.

How will we track the requirements in SSU? Right now, the creative chaos worked well enough and the ticket tracker was good enough, but I think for more complex tasks, we need to be better organized so nothing goes missing.

EDIT: In the beta, did you already make CRT a vessel-specific MFD?

CRTMFD is a thing of the past, it doesn't exist anymore.

 

[GLS]

How will we track the requirements in SSU? Right now, the creative chaos worked well enough and the ticket tracker was good enough, but I think for more complex tasks, we need to be better organized so nothing goes missing.

I have no idea. :facepalm:

EDIT: In the beta, did you already make CRT a vessel-specific MFD?

Yes, it was initially tested in the IUS and Centaur vessels, and it's all inside the main dll, so no more CRTMFD.dll to deal with. Also the menu/display save issues when switching seats is history, as now it is up to the MDUs to save the info of what is being displayed in there. My only "complaint" is that I can't control the initial MFD that is displayed when one turns on the MDU for the first time, it always goes to the SurfaceMFD. Also, the text formating for the MDU port info/fault line/etc is also done, so when that gets done, one only needs to plug in the data. I did as much as I could there.

 

[Urwumpe]

I have no idea. :facepalm:

I'll take a look then for some tool. Not sure if Sourceforge has something that goes beyond a ticket tracker. Maybe we can also do this without a web-based tool, just by keeping the needed data in the repository.

 

[GLS]

For my test scenario, the post OMS-1 orbit is predicted to be 300x90Kms and I'm getting 298x101... and going up to the apogee for the OMS-2, the apogee dropped to 287... I think the Sun and the Moon are not helping us. :shrug:
All in all, it doesn't seem that far off as the math is assuming that 2-minute burns are instantaneous, plus the other issues, so I'm going to commit the changes. Should I also commit the .exe or post it here so others can play with it?

 

[GLS]

This made me check the compression format of the ET textures and it's all DXT1, which in my "graphics ignorance" I think is what we want. As I had "the hands in the doe" I checked a few more textures and some vc panel textures that are 32bpp BGRA... is that good, bad, or doesn't matter for performance? And is it needed, as those files are bigger than the others?

I compared one of the current 32bpp BGRA textures with a DXT1 version (created by saving the BGRA in DXT1), and the DXT1 shows up with artifacts. The artifacts are very noticeable at 400% scale but barely noticeable at 100%, and during the simulation the textures are normally displayed at much smaller scale, so IMO the quality is the same. Any graphics experts that can expand on this? Is it worth using DXT1 over the BGRA for performance, or the smaller file size of the DXT1 doesn't make a difference?

 

[GLS]

Can we choose when to show the (old) runway textures based on resolution level? The White Sands runways are visible enough at level 19 to not need the runway textures, but if we drop the resolution (I'm sure many users can't use level 19) having the runway textures would really help.