# SSU Development thread (4.0 to 5.0)

#### GLS

And every switch actually has three electrical switches inside, providing three signals to their MDM.
...and some have 2 and other have 4. Anyway, RM is the tricky part.

#### Urwumpe

##### Not funny anymore
Donator
...and some have 2 and other have 4. Anyway, RM is the tricky part.

Yeah - not that it matters right now, since we don't simulate switch failures. And if we would somebody would kill us. :lol:

Donator

#### GLS

Likely because of the implementation - no array or list of group indices, but a starting group index
The problem is that it makes isolating changes in the meshes very hard...

#### Urwumpe

##### Not funny anymore
Donator
The problem is that it makes isolating changes in the meshes very hard...
Yeah. The complaints also make me think if it would be smarter to push the reference data for the animations into configuration files that could be edited by the graphics department.

Maybe just something like YAML:

Code:
---
Name: animation_component_name
Groups: [1,2,3,4,5]
Reference: [1,0,0]
Axis: [0,1,0]
Angle: 90
---
Name: animation_component_name
Groups: [1,2,3,4,5]
Reference: [1,0,0]
Axis: [0,1,0]
Angle: 90
...
We could make use of this library then, MIT license should be compatible:

https://github.com/jbeder/yaml-cpp

We would then still use the C++ animation definitions for the logic, but the many constants could be moved into a configuration file.

Last edited:

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Another piece of the puzzle: https://sourceforge.net/p/shuttleultra/tickets/181/
Why does the order of the groups change so much?
The reason why the order changes is that no msh exporter for any of the 3D modelling programs (be it GMAX/3DSMAX, Wings3D, Blender and AC3D) that have one are consistent or intercompatible. A msh can be exported successfully in one program but fail in another. One flaw that they do share is that none of them keeps the mesh group order the same between runs. One run results in one order and the next is different. The same goes for everything, mesh groups, texture lists as wells as the materials list.

So if any of you are game to write a new msh importer/exporter script for AC3D, I'm certainly going to use them.

#### GLS

Yeah. The complaints also make me think if it would be smarter to push the reference data for the animations into configuration files that could be edited by the graphics department.

Maybe just something like YAML:

Code:
---
Name: animation_component_name
Groups: [1,2,3,4,5]
Reference: [1,0,0]
Axis: [0,1,0]
Angle: 90
---
Name: animation_component_name
Groups: [1,2,3,4,5]
Reference: [1,0,0]
Axis: [0,1,0]
Angle: 90
...
We could make use of this library then, MIT license should be compatible:

https://github.com/jbeder/yaml-cpp

We would then still use the C++ animation definitions for the logic, but the many constants could be moved into a configuration file.
IMO, that's another thing to go wrong... changing some coordinates here
Code:
const VECTOR3 animXYZaxis = _( 1.2, 3.4, 5.6 );
vs there is the same. Also, the animations aren't something that change every day, so... :shrug:
The coding of the animations needs a coder, but AFAIK it's pretty much all done.

#### Urwumpe

##### Not funny anymore
Donator
The coding of the animations needs a coder, but AFAIK it's pretty much all done.
And if something changes, we are all talking about who is going to code it. Also its better to have less specialized code than more - and constants in the source code are code as well. We need quality assurance on those as well, and its easier to do if they are all in one place and can at least be sanity checked (For example, such a configuration file could be automatically tested for grave position or direction errors, literals in code can't)

In the best case we could create an animation just by saying:

Code:
animStarTrackerDoorY = animationFactory->create("StarTrackerDoorY");
Which would mean: We have lots of code less. And lots of error sources less. And better testability. And more possibilities for code reuse. For example, such an animation framework could also be ported to other add-ons, like the launch pads, the crawler or whatever payload. All having the same code. All using the same configuration file syntax.

Last edited:

#### GLS

How much more will animations change in the future and how much time would that eat on the "coding department", versus how long will it take to change EVERY SINGLE ANIMATION to that new system? I think the latter one is much more expensive...

#### Urwumpe

##### Not funny anymore
Donator
How much more will animations change in the future and how much time would that eat on the "coding department", versus how long will it take to change EVERY SINGLE ANIMATION to that new system? I think the latter one is much more expensive...
Fine. :facepalm:

I'll copy a permalink to these posts for next year, just so the "I have told you" has more momentum.

#### GLS

Another piece of the puzzle: https://sourceforge.net/p/shuttleultra/tickets/181/
Why does the order of the groups change so much?
I'm changing the hide/show logic so the groups don't have to be sequential.

---------- Post added at 05:27 PM ---------- Previous post was at 05:24 PM ----------

Fine. :facepalm:

I'll copy a permalink to these posts for next year, just so the "I have told you" has more momentum.
Just because I don't see the (immediate) need for it and because I don't have the time, doesn't mean you can't do it.

#### Urwumpe

##### Not funny anymore
Donator
Just because I don't see the (immediate) need for it and because I don't have the time, doesn't mean you can't do it.
Just because I am not seeing any agreement to implement this in SSU (And get the nagging because we are again releasing late), doesn't mean I can't implement it elsewhere. Its a too good idea to waste.

#### GLS

Just because I am not seeing any agreement to implement this in SSU (And get the nagging because we are again releasing late), doesn't mean I can't implement it elsewhere. Its a too good idea to waste.
The SSU Workbench is also a good idea, but ATM nobody is coding it... :shrug:

Anyway, I now closed ticket #181 as now the code no longer depends of mesh group order.

---------- Post added 06-30-18 at 12:17 AM ---------- Previous post was 06-29-18 at 05:44 PM ----------

Radar Altimeter data now reaches the HUD!
Maybe the "regular altitude" does have just a 20ft precision (or whatever the number is)... with the radar taking over at 5Kft it is smooth all the way down, so we don't really see what it would be like without it.

Anyway, I haven't added any RM on the data so turning the MDMs off will just freeze the data and no warning will be given. That will have to wait.

#### GLS

Aside for more tuning on the FCS, the only major item left to do in Autoland is adding the other 3 trajectories, and this is where I-LOADs come into play... I just need to figure out how. :uhh:
For selecting, e.g. the aim point, there is one variable that keeps "1" or "2" according to the selection, and 2 I-LOADs with the position of the aim point. What I don't know is if the selection of one of the I-LOADs is made "on-the-fly" each time it is needed, or if when the selection is made/altered there is a memory location that gets the selected I-LOAD value, and thus the code always goes to that memory location and doesn't have to bother selecting anything.

#### Wolf

##### Donator
Donator
Is there a way to verify how intense are the winds generated by Orbiter? The AFDS on final approach is unable to keep track of the lateral path due to the winds, it chases the diamond right and left all the way down to the RWY in a series of S-turns. That's not a very stable approach. Not even Eastwood in "Space Cowboys" had done such a scary thing :rofl:

#### GLS

Is there a way to verify how intense are the winds generated by Orbiter? The AFDS on final approach is unable to keep track of the lateral path due to the winds, it chases the diamond right and left all the way down to the RWY in a series of S-turns. That's not a very stable approach. Not even Eastwood in "Space Cowboys" had done such a scary thing :rofl:
They seem to be quite high at times... in the landing scenario I'm using I think I'm getting crosswinds around the 15 knot limit. :uhh:
There are some issues with lateral control in the current code in the trunk. I've changed some things in the OrbitersimBeta branch, both in the FCS and in the Orbiter aerosurface functions used, and now it isn't that dramatic at all... but the rudder doesn't seem to do much (and the yaw FCS channel isn't responding as expected to rolls :facepalm

Anyway, I thought of making one of those "wind socks", but it wouldn't be of much use to have it in the ground while you're flying at 30kft... :shrug:

#### Wolf

##### Donator
Donator
They seem to be quite high at times... in the landing scenario I'm using I think I'm getting crosswinds around the 15 knot limit. :uhh:
There are some issues with lateral control in the current code in the trunk. I've changed some things in the OrbitersimBeta branch, both in the FCS and in the Orbiter aerosurface functions used, and now it isn't that dramatic at all... but the rudder doesn't seem to do much (and the yaw FCS channel isn't responding as expected to rolls :facepalm

Anyway, I thought of making one of those "wind socks", but it wouldn't be of much use to have it in the ground while you're flying at 30kft... :shrug:
Where the 15kts crosswind assessment comes from? Is there a way to find the actual winds in sim? What is the logic behind this feature, wind direction and intensity are generated randomly? And what about the change as a function of altitude? (Intensity rising as altitude increases plus change of direction with altitude due to Coriolis effect)? What about terrain also? Does it interfere and alter winds or orography is just ignored?

Sorry I did not mean to flood you with all these questions (out of topic BTW) but I was wondering that maybe you know the logic behind Orbiter winds and how it works

Last edited:

#### GLS

Where the 15kts crosswind assessment comes from?
I did some math.

Is there a way to find the actual winds in sim?
More math? :shrug:

What is the logic behind this feature, wind direction and intensity are generated randomly? And what about the change as a function of altitude? (Intensity rising as altitude increases plus change of direction with altitude due to Coriolis effect)? What about terrain also? Does it interfere and alter winds or orography is just ignored?
Probably there is a pattern, as I get pretty much the same wind speed and direction every time I run a certain scenario... I don't know if Martin posted info about the winds, but you can always ask.