Building on Tom's Rudder Acquisition Gauge

[Guest Skymed]

With help from Tom, I have a really well functional rudder/Torque control on my chopper. I took the code, used the info from Rob about trapping keys and ran further with it and built a functional trim system for a chopper ( they do not trim available in FS9 for choppers). But as usual I am stuck, as I want to limit the trim throws to a maximum of -10 and +10 in both X,Y axis.I have tried various permutations and combinations of -10min 10 max, -10 max, 10 min and Vice Versa in the ON KEY sections with no success.Any Hints? (L:trimdown,percent) (L:elevControl,percent) != if{ (A:ELEVATOR POSITION,percent) (L:trimdown,percent) (L:elevControl,percent) - - 163.84 * /-/ (>K:ELEVATOR_SET) (L:trimdown,percent) (>L:elevControl,percent) } (L:trimleft,percent) (L:ailControl,percent) != if{ (A:AILERON POSITION,percent) (L:trimleft,percent) (L:ailControl,percent) - - 163.84 * /-/ (>K:AILERON_SET) (L:trimleft,percent) (>L:ailControl,percent) } (L:trimdown,percent) 1 - (>L:trimdown,percent) (L:trimdown,percent) 1 + (>L:trimdown,percent) (L:trimleft,percent) 1 - (>L:trimleft,percent) (L:trimleft,percent) 1 + (>L:trimleft,percent) (A:ELEVATOR POSITION,percent) (L:trimdown,percent) + 163.84 * (>K:ELEVATOR_SET) (A:AILERON POSITION,percent) (L:trimleft,percent) + 163.84 * (>K:AILERON_SET) Steve

[rcbarend 37]

Hi Steve,Doesn't this work ???? (L:trimdown,percent) 1 - -10 max(>L:trimdown,percent) (L:trimdown,percent) 1 + 10 min(>L:trimdown,percent)Rob

[Guest Skymed]

Robyou would have thought so, but that code: (L:trimdown,percent) 1 - -10max(>L:trimdown,percent) (L:trimdown,percent) 1 + 10 min(>L:trimdown,percent)limits me to -1 and +1, not -10 and +10 which is why I am confused. COuld it be someting to do with it being in an ON KEY section?Steve

[taguilo 33]

Steve,Have you tested ROTOR_LATERAL_TRIM_INC ROTOR_LATERAL_TRIM_DEC ROTOR_LATERAL_TRIM_SET?Maybe AILERONS_SET can be replaced by K:ROTOR_LATERAL_TRIM_SET, which is specific for helos.I would also test whether AXIS_ELEVATOR_TRIM_SET ELEVATOR_TRIM_UP ELEVATOR_TRIM_DN are fired, using joystick's trim buttons, keys, etc.Maybe they are but FS do nothing in case it is a helo, anyway allowing to play with LVars inside the event. I point this all because I would rather avoid to capture prefixed keys that force the user not to change its assignment.Just a thought, not much time to analyze your code, maybe later...:-)Tom

[Guest Skymed]

TomGood points but the helicopter specific trims ONLY function on the piston engined choppers as opposed to turbine engined choppers........another Microsoft quirk in design. Further, all the trims (elevator and aileron) are also non functional on all choppers hence my attempts to circumvent these limitations.Steve

[rcbarend 37]

Hi Tom,I just tested it myself, and it worked exactly expected.In other words: (L:Trimdown,percent) in/decreases by 1, and always stays within the range -10 -- +10.So it must be something else ..RobPS: two other things occured to me:1. Is "!=" the same as "== !" or "! ==" ?? It might be, but I always use "== !"2. One thing that happend to me once, which I discovered after a days of debugging:Are you sure all the used L:Vars in this gauge are UNIQUE within that panel ??? Iow. are there no other gauges that also write them ??Rob

[Guest Mathias]

Steve, if it is helicopter pitch trim you want check for a file named helitrim.zipat flightsim.com (and probably in all sorts of other places though not here). I used the AXIS command to override joystick pitch input as long as that pitch input is forward and smaller than the AXIS setting of my pitch trim gauge. If joystick forward deflection is larger than the trimmed value the joystick is once again in full control. Same goes for nose-up pitch, though that immediately stops the overriding via the AXIS command.That gague also reacts to the classic numpad 7 and 1 ptich trim keyboard commands of FS.It was programmed for FS2002 but will also work in FS2004, though full power level forward flight cannot be completely trimmed there. It is in C, not XML...

[Guest Skymed]

@Mathias: yessir that gauge is a masterpiece, but I need one in XML for other stuff I am doing, so will continue the search for the XML grail :-))@Rob/Tom ( and continuing on from the rudder post earlier)Been doing some testing and some very interesting results. Based on Robs question I have been testing various combinations of:

PS: two other things occured to me:1. Is "!=" the same as "== !" or "!==" ?? It might be, but I always use "== !" [/end quote Rob]and I can confirm that they are NOT the same. Using != gives wild jittery inputs that would confirm Toms earlier statement about the external visuals on the rudder. I have tried 4 different joysticks as well as pure keyboard input and the "spikes" and jittery input varying from +/- 20 degrees of rudder occur with != . However, testing has confirmed that, with the code I am using: (NOTE ! == ) (L:addrudder,percent) (L:AddruddControl,percent) ! == if{ (A:RUDDER POSITION,percent) (L:addrudder,percent) (L:AddruddControl,percent) - - 163.84 /-/ * (>K:RUDDER_SET) (L:addrudder,percent) (>L:AddruddControl,percent) } (A:RUDDER POSITION,percent) (L:addrudder,percent) - 163.84 /-/ * (>K:RUDDER_SET) There is NO jitter, it is rock stable except when the rudder is deflected to the right(positive values on rudder deflection) or the rudder is actually in motion.The rudder will not deflect upon variances in the (L:addrudder,percent) until the rudder is manually moved at which time it picks up the change and stays there until (L:addrudder,percent) changes AND the rudder is manually moved.All quite interesting.Steve

[taguilo 33]

Steve(And this is for Rob also)"!=" IS the same as "== !" "A B !=" means A NOT EQUAL to B or, maybe easier to understand, the same as "A<>B" in other prog languages. "A B == !" means A EQUAL B RESULT NEGATED, or the same as "A is equal to B, TRUE? then 1 else 0; then NEGATE (bool invert) the result= if was 1 now is 0 and vice versa.Now, in this case, "!=" IS NOT THE SAME AS "! =="In "(L:AddruddControl,percent) ! ==" you are doing a bool negation of a value that is not logic (is a number-percent) and then comparing the result to the first variable. The stack final value is different from the first example that's the reason you are obtaining a different behavior.Actually the jitter effect you see is pretty normal and happens because of the code inside the AXIS_RUDDER_SET event. It occurs as the value of the AVar is ALWAYS the one it had in the PREVIOUS cycle, not the NEW one the event will assign, which in fact you won't know until the next cycle, and so on. This jittering is imperceptible when flying the a/c, so appart from the fancy effect, nothing to worry about.I for you would go back to the "!=" :-)Tom

[rcbarend 37]

He Tom,Of course you are absolute right !!!.Now I remember why I always use "== !" if I want to test that two variables are "NotEqual", which works the same for either for boolean variables AND non-boolean values :-)Cheers, Rob

[Guest Skymed]

And the battle with this gauge continues:( The thing about a chopper is that Tq changes must be instantly transmitted to the pedals (rudder) without a delay, so the (A:RUDDER POSITION,percent) (L:addrudder,percent) - -100 max 100 min 163.84 /-/ * (>K:RUDDER_SET) does not do this, as the pedals must be moved to see the changed state from (L:addrudder,percent). Otherwise one can change that variable all day and there is no reaction at the rudder until the pedals are physically moved and it updates the rudder position. So, trying to think ahead, I would add this line to make the rudders react immediately when throttle is changed: (A:RUDDER POSITION,percent) (L:addrudder,percent) - 163.84 /-/ * (>K:RUDDER_SET) My reasoning being that the code after will be executed when the throttle is moved. Well it appears not the case, as what actually seems to happen is that when the throttle is moved the position of the throttle is actually fed into the rudder instead.Another interesting point is that, after the initialisation of (>L:AddruddControl,percent) it never again seems to change values, even though the (L:addrudder,percent) is constantly changing and so should be updating (>L:AddruddControl,percent) from (L:addrudder,percent) (L:AddruddControl,percent) ! = if{ (A:RUDDER POSITION,percent) (L:addrudder,percent) - (L:AddruddControl,percent) - -100 max 100 min 163.84 /-/ * (>K:RUDDER_SET) (L:addrudder,percent) (>L:AddruddControl,percent) } Maybe Im just getting senile, but here is the whole thing. (L:Torquecorrected,enum) 2 / 20 - /-/ (>L:addrudder,percent) (L:addrudder,percent) (L:AddruddControl,percent) ! = if{ (A:RUDDER POSITION,percent) (L:addrudder,percent) - (L:AddruddControl,percent) - -100 max 100 min 163.84 /-/ * (>K:RUDDER_SET) (L:addrudder,percent) (>L:AddruddControl,percent) } (A:RUDDER POSITION,percent) (L:addrudder,percent) - -100 max 100 min 163.84 /-/ * (>K:RUDDER_SET) (A:RUDDER POSITION,percent) (L:addrudder,percent) - 163.84 /-/ * (>K:RUDDER_SET) Steve

[spokes2112 179]

Steve,How are you doin? I can see a few things, but keep in mind, a few ( X 6 ) cocktails have been consumed here, so......1. Either the transfer from your code has been warped FUBAR to this post or,,,, there are some spaces that shouldn't be there. XML is very space dependent especially with mathematical code within tags.2. I wouldn't use L: vars ( no matter what any one else says ) when testing/designing because the gauge, if reset by the K:PANEL_RELOAD command does not reset the values to zero in a L:var after a retry. You may be locked in a "zero" loop. Use G:vars and take note what they mean for testing. And replace "ONLY" if they are needed for intergauge, or interpanel ( VC, Non-VC ) interaction. 2a. If you do plan on using L:Vars for the final release.. I wouldn't use "percent" as a variable unit. To have a percent there must be a relative value to compare to.. The use of "enum" would suffice as "the number cruncher would put it I.E. machine code" (0.98, enum) = 0.02 less than 1. (0.98, percent) = 0.98 of what? That is how I assume how it would work. 3. either the spacing ( above ) or,,,(L:addrudder,percent) (L:AddruddControl,percent) ! = equals... RUDadd and the "opposite" of RUDaddCONT if they equal then... do some magic.A "not" I.E. ! used after a value is only good for comparisons -or- for boolean ( basically the same thing )Probably should be RUDadd and RUDaddCONT == ! ( if they donot equal ) then do the magic. Hence RPN. "The opposite of the result of the equal of RUDadd and RUDaddCONT"4. Logic looks correct :-) You'll get her...5. I'm rambling, read the news.. Time for nighty.. Hope you get it. Regards,Roman

[taguilo 33]

Steve,I think this has turned way too much confusing...I won't go more in details, just want to advise you to stick to the code that "worked brilliant" (your words), which indeed DOES!Trust me, it passed all my testings :-)Value> (A:general eng propeller lever position:2,percent) 50 > if{ (A:general eng propeller lever position:2,percent) 5 / (>L:addrudder,percent) }els{ 0 (>L:addrudder,percent) } (L:addrudder,percent) (L:AddruddControl,percent) != if{ (A:RUDDER POSITION,percent) (L:Addrudder,percent) (L:AddruddControl,percent) - - 163.84 /-/ *(>K:RUDDER_SET) (L:addrudder,percent) (>L:AddruddControl,percent) } (A:RUDDER POSITION,percent) (L:Addrudder,percent) - 163.84 /-/ * (>K:RUDDER_SET) Keep the rotor up!!TomPS: The different behavior stated in the former post has nothing to do with using L:Vars, or "percent" units. It's only a bit of wrong coding.

[Guest Skymed]

Spinny bit on top.................got ya :-)Steve