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

[GLS]

BEGIN_CAMERA
  TARGET Discovery
  MODE Cockpit
  FOV 50.07
END_CAMERA

[B][COLOR="Red"]BEGIN_HUD
  TYPE Surface
END_HUD[/COLOR][/B]

BEGIN_MFD Left
  TYPE User
  MODE CRT
END_MFD

You can't forget that we are running in Orbiter, so all the usual "rules" still apply to SSU.

  @PANEL F3
  "Drag Chute ARM Cover" [0]
  "Drag Chute DPY Cover" [0]
  "Drag Chute JETT Cover" [0]
  "HUD Power CDR" [COLOR="Blue"][B]ON[/B][/COLOR]
  "HUD Power PLT" [COLOR="Blue"][B]ON[/B][/COLOR]
  @ENDPANEL

This is "our side" of the HUD power control.

 

[DaveS]

This is "our side" of the HUD power control.

Shouldn't our HUD PWR switches tell Orbiter to actually turn the HUD on? This is what the HUD Extend/Retract switch in the default DG does, only that there's an animation involved. That is what got me confused, I thought our switches did the same thing.

 

[GLS]

Shouldn't our HUD PWR switches tell Orbiter to actually turn the HUD on? This is what the HUD Extend/Retract switch in the default DG does, only that there's an animation involved. That is what got me confused, I thought our switches did the same thing.

I'll have to look into that. Please create a ticket so it is not forgotten.

 

[DaveS]

I'll have to look into that. Please create a ticket so it is not forgotten.

OK, ticket created for it.

 

[DaveS]

After alot of research and measuring, I'm happy to report that the vertical offset issue between the MLP and the shuttle stack have been fixed. Turns out the problem was with the SRB holddown posts on the MLP itself. They were situated just a little bit too far up the exhaust holes and some tweaking of that and things have resolved themselves.

I'm still working a few minor issues with the MLP but things look good now. The orbiter is receiving changes so it will be a bit longer on that.

 

[GLS]

I'm still working a few minor issues with the MLP but things look good now.

Don't forget to delete the thousands of hidden faces inside pretty much every pipe.... and I noticed the other day that there are no rainbirds... :shifty:

The orbiter is receiving changes so it will be a bit longer on that.

Try to commit a working version (but not necessarily perfect/final) after some changes, instead of making one commit with a ton of changes. This way it is easier to debug any issues.

 

[Donamy]

Don't forget to delete the thousands of hidden faces inside pretty much every pipe.... and I noticed the other day that there are no rainbirds... :shifty:

Hidden faces might be cause by 2 sided triangles. Changing all parts to one sided usually solves that problem, but sometimes you may have to reverse the normals direction.

 

[GLS]

Hidden faces might be cause by 2 sided triangles. Changing all parts to one sided usually solves that problem, but sometimes you may have to reverse the normals direction.

It's not that. Try "flying" inside a pipe and you'll see "disks" in the bends of the pipes... adding all of that vs the total pipe "cost", and the waste is huge.

 

[Donamy]

It's not that. Try "flying" inside a pipe and you'll see "disks" in the bends of the pipes... adding all of that vs the total pipe "cost", and the waste is huge.

Ah, they were extruded incorrectly.

 

[DaveS]

Ah, they were extruded incorrectly.

No extrusions whatsoever. All of the MLP was done in GMAX, not AC3D, as GMAX has better control of bends than AC3D through its "Bend" modifier. I have since managed to reduce the overall MLP triangle count by ~40% and it still looks good.

 

[GLS]

I feel I have to point out that my "crusaide" isn't against detail (if it is correct and not super-duper expensive), but instead against faces/vertices that are not visible, so if removed the visual does not change. That is 100% free performance.

Meanwhile in the "guidance land" I'm now working the TAEM guidance... but the FCS is a royal PITA... :facepalm:

 

[Urwumpe]

Meanwhile in the "guidance land" I'm now working the TAEM guidance... but the FCS is a royal PITA... :facepalm:

The bad news: There can't be a FCS that isn't a royal PITA.

 

[GLS]

So I noticed that the vertical velocity as returned by GetGroundspeedVector(FRAME_HORIZON) is subject to the terrain the vehicle is flying over, so when flying over rugged terrain it jumps quite a bit. (Let's call this "relative velocity", VR.)
If I get the vertical component (stright to the center of the Earth) of the velocity of the vehicle in relation to the center of the Earth (and this would be "inertial velocity", VI), could I use it to "replace" the vertical component returned by GetGroundspeedVector?

I think the rotation of the Earth doesn't "contaminate" the vertical component of VI, so that should be "pure", and in VR, the horizontal components should not be affected by the terrain below, so it seems a fair match... :shrug:
... or is there a more direct/better/correct way to get a "clean" vertical velocity?

 

[Kubala95]

If I can join to discussion:

In my understanding vertical velocity is the same as radial velocity relative to center of the Earth.
We know that r = sqrt(x^2 + y^2 + z^2) so we can differentiate it due to time and gain:

dr/dt = (dx/dt * x + dy/dt * y + dz/dt * z) / sqrt(x^2 + y^2 + z^2) = (dx/dt * x + dy/dt * y + dz/dt * z) / r

x,y,z and dx/dt,dy/dt,dz/dt are of course components of position and velocity vectors relative to the Earth. This should be possible to get using the VESSEL::GetRelativePos() and VESSEL::GetRelativeVel() methods.

I'm not sure if this inference is correct but maybe will be helpful.

 

[GLS]

So, yesterday I managed to get the vehicle to fly a TAEM all the way to the runway... ...the prefinal turn was SCARY (for some reason they placed the roll limit at 100º, so it is not shy of banking if it needs :lol, but it got to the A/L interface perfectly and from then on it was all tested.
And so now comes the usual issue of the missing data: I'm missing some I-LOADs to calculate the altitude reference... some can be calculated from others, but I can't do magic. :uhh: What I can do is make an "+/- educated guess" from what I know and from what is available... <- IMO, the most likely scenario :shrug:
DaveS, do you have the ENT GUID 2102? That might have some juice to squeeze.

 

[DaveS]

GLS: Here you go:

https://sourceforge.net/projects/sh...s/Entry, TAEM and Approach 21002.pdf/download

 

[GLS]

GLS: Here you go:

https://sourceforge.net/projects/sh...s/Entry, TAEM and Approach 21002.pdf/download

Hmm... that one I have. Either that's not it, or that's it and it changed name.:shrug:

 

[DaveS]

For the last couple days I have been trying to figure out why the GOX vents through MPS intermediate seal turbopump drain lines doesn't want to line up. I've checked everything. Everything seems to check out. Is there some logic I'm missing in the set up? The actual coordinates is with the nozzles in the installed NULL positions which I got directly from AC3D.

https://www.dropbox.com/s/24l5l3wrzhl4uh8/Misaligned_GOX_vents.jpg?dl=0

 

[Urwumpe]

Are the positions calculated correctly in SSU?

 

[DaveS]

Are the positions calculated correctly in SSU?

That I have no idea about.