Nah, you were right first time
All praise Jan!
,
Without his help we would all be just scratching our heads and heading off to the pub, and I don't drink
No need to miss out - I'll have a pint for you!
Nah, you were right first time
All praise Jan!
,
Without his help we would all be just scratching our heads and heading off to the pub, and I don't drink
No need to miss out - I'll have a pint for you!
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.
The base is located at the base of the switch or lever, it is a location that you can point your mouse cursor at and use your mousewheel to manipulate the switch or lever. As you rotate the mouse wheel the switch position or lever position might change and the tip of the switch or lever now moved away. But the base stayed in place and you can just keep scrolling.
It's like a safe zone where you can always hit a switch or lever easily even in turbulence or whilst you manipulate it. Unlike the non-base controls you cannot grab a base with your mouse or vr hands and pull it. It also makes it easier to hit a tiny switch with your mouse.
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]>
>
Display More
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]>
>
Display More
Hi Alex,
There are plenty of aircraft that use this animations like that. I have never linked two hingedbodies before, but aparently that works too....
Usually we use a rigidbodygraphics for the column and then often another rigidbodygraphics for the yoke. Any rigidbodygraphics can have an input transform, which can be a chain of transformations, e.g. first rotate the switch on the yoke, then rotate the yoke with the aileron, then rotate all that around the column foot point with the elevator. And on top of that I added some yoke hides that either push the yoke down or "away". These transformations are called graphics_rotation and graphics_translation... The benefit is that you can chain these without an actual graphics pointer to another object, so they work independant of the order of the graphics section (which goes down each element one by one and if the linked graphics pointer is below the current one the older transformation from the frame before is used, which looks strange or it doesn't work at at all).... So ideally you just want to chain these graphics transformations instead of making one graphics object depend on the other.
But of course it's a lot more practical just to use a hingedbodygraphics on top of a rigidbodygraphics, I have done that a lot. But I would not recommend putting one hingedbody ontop of another hingedbodygraphics.... for me these hingedbodies sole purpose are switches there you can use the InputID instead of the InputAngle and then scale the switch deflection with the AngleMax... Then it is very clean: switch in physics, switch in graphics, switch in dynamics and the rest (e.g. the system logic following that switch position) is completely out of the way of the movement of that switch.
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 !
Behind the scenes the graphics_translation and graphics_rotation are just matrix multiplications....
Hey guys, just sharing some info Jan sent me in regards to Inputs
QuoteDisplay MoreThe 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.
Hey guys, just sharing some info Jan sent me in regards to Inputs
One day someone might make a little YouTube training course introducing these concepts from the top down with some visual references and I bet a lot more people would feel inspired to have a go at this. The way Rodeo did for scenery.
Hey guys,
Just wondering if there is a way to get a custom 'hud'/parallax effect for the gunsight?
Cheers
Display MoreAttention folks.
We have an aerodynamically stable and flyable aircraft.
That's right, the Spitfire no longer thinks it's a rocket destined for Mars.
All praise Jan!
So this is now working in FS 2? When is the release date? It looks great!
This morning's arrival was the ever impressive Antonov An-2, the largest single-engine airplane in the world. This Russian mass-produced utility/agricultural is huge in so many ways. The An-2 has remarkable lifting power and can takeoff from the poorest of runways. With a 60 foot wingspan and a takeoff weight of 7.275 pounds it can easily carry 12 passengers over 500 miles at 120 mph.
That huge 4-prop 9-cylinder, 1,000 hp radial engine is the Shvetsov ASh-62. This is the Russian version developed under license from the famous Wright R-1820 Cyclone. This engine was standard fare on the DC-3 and B-17 Flying Fortress in WWII.
At last count, the An-2 has been in continuous production someplace in the world for 45 years. 13,000 were built in Poland between 1961 and 2001. China continues to build the An-2 under license as the Shijiazhuang Y-5.
I almost forgot to mention that the An-2 is a biplane with leading edge slats with a typical landing speed of a remarkable 30 mph. Over the years, the An-2 has been fitting with skis, floats, turboprops, agricultural sprayers, fire-fighting equipment and used as a water bomber, polar research vehicles, air ambulances, cargo/paratrooper, mail delivery, and high altitude weather reconnaissance. China uses their Y-5 turboprop version as a 5-seat VIP transport.
The An-2 should be an outstanding addition to our Aerofly FS2 fleet. Wait 'til you see how much is packed into the cockpit - all for the single pilot.
Regards,
Ray
The An-2 should be an outstanding addition to our Aerofly FS2 fleet. Wait 'til you see how much is packed into the cockpit - all for the single pilot.
Yes, the An-2 would be a great addition to the FS 2 fleet!
Yes, the An-2 would be a great addition to the FS 2 fleet!
Maybe we can get the instrument panel gauges fine tuned in time to use the An-2 for a people hauler in the upcoming Lukla scenery package. There has been some concern expressed about the high altitude ops. This should work just fine. There is a bit of extra reflectivity along the inside of the metal framing of the canopy/windscreen/windows.
I'm thinking the Wilga should also be a good STOL package for all those short and high Lukla airports.
Regards,
Ray
I'm thinking the Wilga should also be a good STOL package for all those short and high Lukla airports.
Yes a "typical" landing speed of 30 mph for an aircraft that large and heavy is amazing -- those two wings must generate a lot of lift!
Great progress has been made on the Spit over the last few days/week. Here are a just a few of the changes;
Multiple changes to the FM have been done by the legend himself, Jet-Pack, including;
Again, big thanks to Jan for all his help!
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!
Alex... that prop blurring looks excellent. I think AF2 does that better than any other Flight sim I've tried IMOP. Gonna try what I suggested for that with the spinner?... I shall be interested to see if it works for my project.
Matt
Looking good Mon Capitan, looking forward to giving it a whirl old boy
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?
Hi Donny
Sorry me old mucker but I can offer no help, only recently found out about some of the shaders myself. As we have interior and exterior I don't get standard and default unless they are there for the scenery guys. Perhaps canopy needs to be used to get internal reflections rather than glass as I never did get any with glass, just a guess here. Again, should we be using canopy rather than glass as that's for scenery and not aircraft
And of course there are decals, I know how to use these for scenery but quite how they are used for aircraft remains a mystery, never really seen the need to use one but that may change with the Lynx when adding aircraft numbers as thats the only use I can see at the moment
Reading the wiki
exterior........... everything that is not in the cockpit/cabin, outer faces of windows and canopy
interior ...........everything that is in the cockpit and cabin, inside of windows and canopy
Even these can be taken different ways. Does exterior include windows and canopy polygons or is it saying, not these but that's the bounding area, Interior would seem to include windows and canopy or is it also saying that's where the bounding area is again
Also, can we add more then one shader to a material. Guess the IPACS aircraft modeller should make an appearance and help out
Steve