P3D v5 Adding two sim variables values together to produce a simple animation

[DBushell]

I'm trying to animate a basic pitch/alpha indicator for an ADI. The pitch rate and alpha are combined into a single value to move a marker up and down.

I'm rubbish at maths, but I believe the values should be made up of the Vertical speed being divided by 100 (eg 6000 becomes 60) this would then be added to AoA with the result being the animation.

I've got as far as this, but not getting anything back. if{ (A:INCIDENCE ALPHA, degrees) + (A:VERTICAL SPEED,feet per second) 100 / }

Also what does everyone use for P3D V5 to see gauge simulation variables - I have the L Var gauge by Doug which is great.

 

[tgibson]

Try

if{ (A:INCIDENCE ALPHA, degrees) (A:VERTICAL SPEED,feet per second) 100 / + }

 

[DragonflightDesign]

Unashamedly stolen from Wikipedia:

'In reverse Polish notation, the operators follow their operands; for instance, to add 3 and 4 together, one would write 3 4 + rather than 3 + 4. If there are multiple operations, operators are given immediately after their final operands (often an operator takes two operands, in which case the operator is written after the second operand); so the expression written 3 − 4 + 5 in conventional notation would be written 3 4 − 5 + in reverse Polish notation: 4 is first subtracted from 3, then 5 is added to it. An advantage of reverse Polish notation is that it removes the need for parentheses that are required by infix notation. While 3 − 4 × 5 can also be written 3 − (4 × 5), that means something quite different from (3 − 4) × 5. In reverse Polish notation, the former could be written 3 4 5 × −, which unambiguously means 3 (4 5 ×) − which reduces to 3 20 − (which can further be reduced to -17); the latter could be written 3 4 − 5 × (or 5 3 4 − ×, if keeping similar formatting), which unambiguously means (3 4 −) 5 ×. '

It might help?

 

[DBushell]

Ah I forgot about that, thanks, must remember!

 

[DBushell]

OK so the following works and animates, however the two variables are not being added. For example, with vertical speed at 0 but alpha of 10 degrees, the code is generating 0 whereas it should be generating 10. It seems to be following only the vertical speed calculation.

(A:INCIDENCE ALPHA, radians) (A:VERTICAL SPEED, ft/min) 100 / 60 +

What I'm trying to achieve is say alpha = 20 degrees, Vertical speed is say 1000 fpm divided by 100=10 so 20 + 10 = 30 and 30 would be the animation position.

Is there something else I have round the wrong way?

??

 

[sal1800]

You're close but it needs a few tweaks. One of the things about RPN is it's stack-based, so in your code above it's never using the Alpha simvar because Alpha goes on the stack as "a", VS as "b", 100 as "c", then b/c is evaluated and added as "b", then 60 is "c", then b+c becomes "b" and "a" is never used.

Try this one:
(A:INCIDENCE ALPHA, radians) rddg (A:VERTICAL SPEED, ft/min) 100 / + 60 +
Translates to: Alpha -> convert radians to degrees + (vertical speed / 100) + 60

Here's the RPN documentation: http://www.prepar3d.com/SDKv3/LearningCenter/utilities/scripting/rpn_scripting.html
It takes a little getting used to, but after a while, it starts to make sense.

 

[DBushell]

Thanks sal1800, the extra + has worked wonders! I need to re-read your explanation a few times

 

[Anthony31]

or you can just do (A:INCIDENCE ALPHA, degrees) which should return -90 to 90 (I don't think AOA goes over 90 degrees) instead of -1.57 to 1.57 which is the range that radians would return. radians = degrees * 3.1415926 (pi) / 180

 

[DBushell]

or you can just do (A:INCIDENCE ALPHA, degrees) which should return -90 to 90 (I don't think AOA goes over 90 degrees) instead of -1.57 to 1.57 which is the range that radians would return. radians = degrees * 3.1415926 (pi) / 180

Does the rddg negate the impact of using Radians? It seems to work pretty well.

 

[sal1800]

Does the rddg negate the impact of using Radians? It seems to work pretty well.

It results in the same thing. Since your initial example had radians as the unit, I thought it might be useful to see that RPN has a way to convert it.
I suppose we could speculate which method yields more performance, but I doubt there would be any significant difference.
There's another useful angle conversion with the "dnor" and "rnor" keywords. These normalize plus and minus angles to 0-360 range. Important for animation since keyframes can't be negative values.