Aircraft Development

We have our first clickable control! Huzzah! (It's just pretty much copy pasta from the F4U, trying to work out all the different parameters - I'm unsure what the "Base" versions are, i.e PropellerSpeed vs PropellerSpeedBase.

Hey guys,

I'm currently trying to wrap my head further around the rigidbodygraphics and linking with the dynamics. I've been trying to get the control column to work independently from each other, but still be linked i.e the spade rotates from a fixed point on the control column. Here's what I have so far;

            <[graphics_input][StickElevator][]
                <[uint32][InputID][ServoElevator.Output]>
                <[float64][Scaling][0.6]>
            >
            <[graphics_input][StickAileron][]
                <[uint32][InputID][Aileron.Output]>
                <[float64][Scaling][0.8]>
            >
            <[hingedbodygraphics][ControlColumn][]
                <[uint32][PositionID]   [Fuselage.R]>
                <[uint32][OrientationID][Fuselage.Q]>
                <[string8][GeometryList][ SpadeColumn ]>
                <[string8][InputAngle][StickElevator.Output]>
                <[tmvector3d][Axis] [ -0.000 -1.0000 -0.0000 ]>
                <[tmvector3d][Pivot][ -0.8609 0.0049 -0.5122 ]>
                <[float64][AngleMax][1]>
            >
            
            <[hingedbodygraphics][Spade][]
                <[uint32][PositionID]   [Fuselage.R]>
                <[uint32][OrientationID][Fuselage.Q]>
                <[string8][GeometryList][ SpadeGrip BrakeLever ]>
                <[string8][InputAngle][StickAileron.Output]>
                <[tmvector3d][Axis] [ -0.9988 0.0491 0.0000 ]>
                <[tmvector3d][Pivot][ -0.9887 0.0001 0.0778 ]>
                <[float64][AngleMax][1]>
            >

So how would one go about linking these so that the Spade follows the Control Column rotation, but rotates on its own too?

TLDR; layered elements w/ their own rotations?

Cheers,

Alex

Edit: Got it, was easy peazy.

Just add the 'parent' to the [Graphics] parameter like this;

            <[hingedbodygraphics][ControlColumn][]
                <[uint32][PositionID]   [Fuselage.R]>
                <[uint32][OrientationID][Fuselage.Q]>
                <[string8][GeometryList][ SpadeColumn ]>
                <[string8][InputAngle][StickElevator.Output]>
                <[tmvector3d][Axis] [ -0.000 -1.0000 -0.0000 ]>
                <[tmvector3d][Pivot][ -0.8609 0.0049 -0.5122 ]>
                <[float64][AngleMax][1]>
            >
            
            <[hingedbodygraphics][Spade][]
               * <[uint32][Graphics][ControlColumn]> *
                <[string8][GeometryList][ SpadeGrip BrakeLever ]>
                <[string8][InputAngle][StickAileron.Output]>
                <[tmvector3d][Axis] [ -0.9988 0.0491 0.0000 ]>
                <[tmvector3d][Pivot][ -0.9887 0.0001 0.0778 ]>
                <[float64][AngleMax][1]>
            >

Interesting. Thanks Jan! I think that's the way the F4U did it, but I couldn't wrap my head around the transform part... I'll see if I can work it out.

Cheers,

Alex

Edit: Got it working! Not really anymore trouble than the other way so that's nice.

Thanks !

Hey guys, just sharing some info Jan sent me in regards to Inputs

Quote

The idea behind the inputs is to receive a message from the assigned joysticks, from the controls.tmd or other background services of our sim, e.g. the simulated copilot that interacts with the aircraft. These messages are send from any location within the sim and can be received anywhere else, like a communication across the entire sim without the need for direct linking. But that's in the background, not that important...

Important for you is: Some of the objects that you add into the tmd file in the dynamics section receive messages from your joystick or controls.tmd and are treated exactly the same way. These message receivers are usually called input_something, e.g. input_switch or input_lever or input_discrete. Each of them has slightly different behavior and is typically only used for that one particular control. E.g. a throttle lever would use the input_lever, a binary switch would use the input_switch, a button the input_button, etc.

Now regarding the outputs from the dynamics section... The dynamics, graphics and sound sections run in separate threads and they usually only need to communicate one way from dynamics to graphics or from dynamics to sound. There is no back connection from the sound to the physics since the sound does not really affect any physics that much in real life and the light that you receive from the "graphics" also does not really affect the physical behavior. The only thing that would do that is a photo-light-sensor. Ok, understood. The outputs that we define collect the physical states and then send them over to the graphics section for the animation process (next frame). That means any physical value, e.g. the flap position or the selected flap position over time needs to be passed from the physics to the graphics section. There is the normal "output" object that takes any input value, gives it a new name and sends the value to the graphics (example: AirspeedIndicator.IndicatedAirspeed would have to be renamed as "IndicatedAirspeed" or just "Airspeed" before it can be send to the graphics). There are also "output_free" objects that can be used to keep the original name (e.g. Input "Flaps.Output" would be available again as "Flaps"). And some of the input objects mentioned above also directly send out their position. E.g. the input_switch and input_button send out their state to the graphics, because nearly all of them will have a graphics for that switch or moving button. Other inputs like the input_discrete will require an object of type "output_free" or "output" to get the value over to the graphics.

Inside the graphics section you can receive these values from the physics by several means, easiest to understand: "graphics_input". Movinggraphics and hingedbodygraphics also can directly receive the values, when you use InputID or AngleID. Then you don't need to add the graphics_input. For the transformations you will need the graphics_input objects...

To summarize that chain:

Controls.tmd or keyboard short-cut generates a message called "Controls.Flaps". The message also contains a qualifier attribute that allows us to distinguish between a "step" or a "set to exact value" or "drag by this much" or "button depressed" (e.g. brakes), etc.

(Message "Controls.Flaps" ) controls->dynamics

Objects in the dynamics section receive the message, e.g. your input_lever that has the Input set to "Controls.Flaps" which we usually call "FlapsInput".

(By value) FlapsInput -> ServoFlaps

The flaps servo can directly access the selected value from the flap input (with FlapsInput.Output) and will drive the flap position towards the input over time.

(By value) ServoFlaps -> aerowing, output

The value of the actual flap position (ServoFlaps.Output) is used by other elements in the physics section, e.g. the aerowing, etc.

If an "output_free" object is specified it will save the value of the flaps until the threads for the graphics and physics join in the synchronized method to exchange the data.

(output-message) output -> graphics_input

The graphics section receives the value from the physics per "graphics_input" InputID = ServoFlaps.Output, you can give the graphics_input another name if you want or keep it identical (makes things easier), here we would use "ServoFlaps" again.

(By value) graphics_input -> graphics_mapping, transformations, etc.

Within the graphics section you can now use the physical position of the flaps to animate the geometries, for the flaps you will probably send them to a graphics_rotation and then to your rigidbodygraphics/bendingbodygraphics for the flaps (as InputTransform).

Similarly to how the graphics section receives the flaps position it can also receive the FlapsInput, if the flaps input either has its own built in output or when you add a new one.

And just like in the graphics section the controls.tmd also can access the outputs from the physics to change the position or angle of the clickspots. E.g. the tip of the flap lever would probably move and you want to keep the visual and the haptical positions in sync... but you don't have to.

Display More

Hey guys,

Just wondering if there is a way to get a custom 'hud'/parallax effect for the gunsight?

Cheers

Great progress has been made on the Spit over the last few days/week. Here are a just a few of the changes;

• A number of clickable controls have been added, such as mixture, throttle, RPM, Elevator trim, Spade, Flaps and most likely a few I've missed.
• Flaps have been edited to reflect the real values
• Materials have been changed to use the appropriate shaders
• A few instruments have been added (RPM, Airspeed)
• Edited some textures to work better with AFS2 (still need to do a lot of tweaking)

Multiple changes to the FM have been done by the legend himself, Jet-Pack, including;

• Airfoils & mass are now accurate
• Corrected engine values
• Added prop graphics including fading & blade pitch animation
• Added/fixed preliminary gear physics
• Tweaked trim

Again, big thanks to Jan for all his help!

Quote from adak47

So this is now working in FS 2? When is the release date? It looks great!

No ETA at the moment. You will know as soon as I do Hopefully soon!

It'd be great if one of the IPACS guys a description for all of the shaders and what they are good for. Like, what is the difference between glass, window and canopy? When should one be used over the other? I just discovered the darken shader is transparent and makes things behind it darker. What's the difference between "standard" and "default"?

In the mean time, do you have any idea larrylynx?