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

Status
Not open for further replies.

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
...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:
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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! :hailprobe:
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
In relation to the question here, from diagram 10.2 in JSC-11174:
attachment.php
 

Attachments

  • srbhdpbsm.PNG
    srbhdpbsm.PNG
    44.1 KB · Views: 353
Status
Not open for further replies.
Top