Good day to all ,

I am struggling to execute RPN :  -120·(>K:ROTOR_LATERAL_TRIM_SET).  or 120 ·1/-/ ·(>K:ROTOR_LATERAL_TRIM_SET) works ok with positive input like 4000·(>K:ROTOR_LATERAL_TRIM_SET)

Sure it is my fault at RPN notation....

Also tried JSCRIPT : (K:ROTOR_LATERAL_TRIM_DEC).exec(-120); Not work.

Solved with a for loop using (K:ROTOR_LATERAL_TRIM_DEC).exec(1); ( done n times , n=120 in the example.

Please some advice for doing directly , if posible.

Thank you

 

 

 

Edited July 17, 20241 yr by fasencio

4 hours ago, fasencio said:

Please some advice for doing directly , if posible.

-120·(>K:ROTOR_LATERAL_TRIM_SET)

looks OK to me. Must be that particular event that is not working as advertised. The spec says that the value range is -16K to +16K

When in doubt, try sending the script to the sim for processing:
(SIMPROC)·-120·(>K:ROTOR_LATERAL_TRIM_SET)

I would also try other values with the DEC event, the spec mentions a "parameter" that sets the amount of change?

120·(>K:ROTOR_LATERAL_TRIM_DEC)

Negative values in general are working fine. Try for example (>K:AXIS_CYCLIC_LATERAL_SET)

2 minutes ago, Lorby_SI said:

Negative values in general are working fine.

Thank you Sir.

Will test tomorrow.

Greetings

14 hours ago, Lorby_SI said:

(SIMPROC)·-120·(>K:ROTOR_LATERAL_TRIM_SET)

Good day Sir.

Did not work either. Must be a flaw in the event itself. ( output defaults to +1 value for any negative input.)

Fortunately your suggestion to use direct Axis control works ok in both directions.

And using this event , there is still a precisiòn of 1/16k , enough for my purposes. Will be using this one.

14 hours ago, Lorby_SI said:

Try for example (>K:AXIS_CYCLIC_LATERAL_SET)

Thank you for prompt answer.

Your software is an gratifying, very powerfull tool to have. 😉

Greetings, Francisco

 

20 minutes ago, fasencio said:

Must be a flaw in the event itself.

It wouldn't be the first non- oder only partially functional event in the SDK (see: Camera events...) But still, it es relatively new, and I can't imagine that Asobo didn't test it? The main irritation is that it doesn't work with SIMPROC either, MSFS has no excuse when you use that. Maybe the value range is totally different, like 0 to 32K?

Then again, the AVar reading this item is defined as "Percent over 100". Negative values don't make a lot of sense with that (although they do work). So maybe the team working on the SDK got that part wrong.