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.
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.
Another piece of the puzzle: https://sourceforge.net/p/shuttleultra/tickets/181/
Why does the order of the groups change so much?
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...
---
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
...
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.Another piece of the puzzle: https://sourceforge.net/p/shuttleultra/tickets/181/
Why does the order of the groups change so much?
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.
const VECTOR3 animXYZaxis = _( 1.2, 3.4, 5.6 );
The coding of the animations needs a coder, but AFAIK it's pretty much all done.
animStarTrackerDoorY = animationFactory->create("StarTrackerDoorY");
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...
Another piece of the puzzle: https://sourceforge.net/p/shuttleultra/tickets/181/
Why does the order of the groups change so much?
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.
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.
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:
I did some math.Where the 15kts crosswind assessment comes from?
More math? :shrug:Is there a way to find the actual winds in sim?
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.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?