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

[DaveS]

How about a separate VC mesh, that doesn't have to fit the whole Orbiter mesh?

That is what we have now. The problem is that that we have to render the exterior mesh as well as the VC for the payload bay and everything else to show up when in VC view mode. If we didn't you would only see an empty void when looking through the aft windows. No PLB, no doors, nothing. Just empty space.

I'm sorry but there's no quick fix for this. The VC have to be fixed in the mesh, not in the code.

 

[Donamy]

Code also, I would think. for animations and mfd's.

 

[Urwumpe]

Code also, I would think. for animations and mfd's.

Theoretically, it would be possible to define the panels in configuration files, the framework was once designed with that in mind.

 

[GLS]

Code also, I would think. for animations and mfd's.

Yes, the click and animation coordinates will have to be corrected... I volunteer to do that.
As things will have to change, we should take the opportunity to correct a few things in the vc, and maybe also add "proper" lighting to it. We should also allow the Columbia cockpit to be simulated (and the other OVs as well, as they were all different). As I've broken the panel meshes, the work can be done incrementally, one panel at a time without touching the other panels, but still should be done in a branch as it will not look pretty until it's finished.

 

[GLS]

Most of the work on the roll and yaw channels is finished! Only their rollout portions, and the NWS channel, are missing.
The Wraparound version isn't really working... bad aero? (btw: any idea where our aero data came from?)
Another "interesting thing" is that the stability rates, vs the "basic" axis rates, appear to make roll and yaw unstable... could Orbiter be giving us roll and yaw rates that are already coupled via AoA?

 

[Urwumpe]

Most of the work on the roll and yaw channels is finished! Only their rollout portions, and the NWS channel, are missing.
The Wraparound version isn't really working... bad aero? (btw: any idea where our aero data came from?)
Another "interesting thing" is that the stability rates, vs the "basic" axis rates, appear to make roll and yaw unstable... could Orbiter be giving us roll and yaw rates that are already coupled via AoA?

Not sure there - the aero data is from a NASA publication about the aerodynamic model, but I am not sure if the moments are also real.

 

[DaveS]

GLS: I noted this in the revision notes for revision 2926: ">> added Jet Selection Logic to command RCS (currently only used in MM304 and 305)"

Could this be further extended to work in OPS2? I think that would enable us to close tickets 102 and 18. Or do we still need the DPS for those?

 

[GLS]

GLS: I noted this in the revision notes for revision 2926: ">> added Jet Selection Logic to command RCS (currently only used in MM304 and 305)"

Could this be further extended to work in OPS2? I think that would enable us to close tickets 102 and 18. Or do we still need the DPS for those?

No it wouldn't fix those. In fact the current JSL is just a way to "isolate" from the FCS the hack to command the RCS. We need both each individual RCS engine and logic to control what fires.

For entry the FCS commands "x jets fire in this axis, y in that axis, and z in the other", and the JSL has a table (or something) that translates those commands into individual RCS engine commands. It should be the same for the other phases of flight, but much more complex as it has to handle the FRCS and translations. Anyway, as we don't have the RCS "hardware" we must hack the software to make things work. :shrug:
So currently I take, e.g., the yaw jet command (which is a number from -4 (left) to +4 (right)), and divide by 6, as that is the number of yaw RCS engines we are firing, thus giving the "percentage" of power required.

For now the RCS won't change, but that is something that I'd like to fix. Although the hardware side is easy, it will be hard to create the logic to handle the 6 commands (isolated or in some combination), plus RCS deselections and priorities.

 

[GLS]

One step closer to finishing the entry updates: the roll and yaw FCS channels are +/- done!
Still tons of "details" missing, but I've now updated the entry scenarios* if anyone wants to see the vehicle go from orbit to the runway by itself, or wants to go CSS and crash it... :shrug:
BTW: the pitch and roll error needles are accurate, HUD only has roll error (and probably not displayed correctly...).

*) Scenario load/save will probably only work, partially, in MM305.

 

[GLS]

Any news from the graphics department?

 

[Donamy]

Any news from the graphics department?

As far as ....?

 

[GLS]

As far as ....?

Any developments? :shrug:

 

[Donamy]

I thought it was finished. :shrug:

 

[DaveS]

I thought it was finished. :shrug:

Here's the items GLS is talking about:
https://sourceforge.net/p/shuttleultra/tickets/177/
https://sourceforge.net/p/shuttleultra/tickets/178/
https://sourceforge.net/p/shuttleultra/tickets/184/
https://sourceforge.net/p/shuttleultra/tickets/179/
https://sourceforge.net/p/shuttleultra/tickets/176/
https://sourceforge.net/p/shuttleultra/tickets/173/
https://sourceforge.net/p/shuttleultra/tickets/172/
https://sourceforge.net/p/shuttleultra/tickets/170/


So as you can tell, not finished. And as an answer to GLS's question: Not going to be done anytime soon, sorry.

 

[GLS]

Here's the items GLS is talking about:
https://sourceforge.net/p/shuttleultra/tickets/177/
https://sourceforge.net/p/shuttleultra/tickets/178/
https://sourceforge.net/p/shuttleultra/tickets/184/
https://sourceforge.net/p/shuttleultra/tickets/179/
https://sourceforge.net/p/shuttleultra/tickets/176/
https://sourceforge.net/p/shuttleultra/tickets/173/
https://sourceforge.net/p/shuttleultra/tickets/172/
https://sourceforge.net/p/shuttleultra/tickets/170/


So as you can tell, not finished. And as an answer to GLS's question: Not going to be done anytime soon, sorry.

I better start up blender then...
At least the hidden faces are easy for me to deal with... but boring.:facepalm:

 

[DaveS]

I better start up blender then...
At least the hidden faces are easy for me to deal with... but boring.:facepalm:

The orbiter is 98% done, it's everything else that's holding things up.

 

[GLS]

The orbiter is 98% done, it's everything else that's holding things up.

My performance at the triangle business is, IMO, not bad, so I can help once I get the landing part done. More advanced editing would take time.

 

[Donamy]

My performance at the triangle business is, IMO, not bad, so I can help once I get the landing part done. More advanced editing would take time.

I don't even know which Orbiter msh I have anymore. :shrug:

 

[GLS]

It's still a "preliminary measurement", but still interesting: the new entry code (with the baseline DAP) uses about 1/10th of the propellant that the entry code in the trunk uses, and it is +/- in line with the real prop usage.

 

[GLS]

As part of the entry work, I've spent many hours looking at the rear of the Orbiter (no jokes please... ) and IMO the model should have the aft face of the wings (and body flap "mount"), so we can't look into the wings from behind. I shouldn't be expensive (maybe 10-15 triangles total?) and would allow a small gap between the elevons and the wings to exist without seeing holes. :shrug: