rcbarend

Hi Pete, If still interested in the behavior of axis events AILERON_TRIM_SET and RUDDER_TRIM_SET, see this post on FS-Developer. https://www.fsdeveloper.com/forum/threads/using-event-aileron_trim_set-….444147/#post-810988 Best regards, Rob

PS: To exclude the possibility of wrong conversions in XML coding: I did a flight test with the default 737-800, and writing a value 100 to events AILERON_TRIM_SET or RUDDER_TRIM_SET indeed has a high impact on the flightpath. Meaning that if the value range of these SET events would be -16K to +16K, writing a value 100 would not be noticeable. Rob

Hi Pete, Yes, strange indeed that this works fine in your PFC. Here's how I make my conclusions. This is programmed in XML (I can't program in C++), tested with the default Accel B737-800. 50 (>K:AILERON_TRIM_SET) gives readouts for (A:AILERON TRIM PCT,percent) : 50 and (A:AILERON TRIM,degrees) : 5 Likewise: 100 (>K:AILERON_TRIM_SET) gives readouts for (A:AILERON TRIM PCT,percent) : 100 and (A:AILERON TRIM,degrees) : 10 AND -25 (>K:AILERON_TRIM_SET) gives readouts for (A:AILERON TRIM PCT,percent) : -25 and (A:AILERON TRIM,degrees) : -2.5 But 150 (>K:AILERON_TRIM_SET) still gives readouts for (A:AILERON TRIM PCT,percent) : 100 and (A:AILERON TRIM,degrees) : 10 Hence my conclusion that the value range for the event is only -100 to +100 It's also consistant with the instrument readout for AileronTrim in the VirtualCockpit of the default 737-800. What you could do: Check the event value in the log if you change your dial 1 step, and also observe the AileronTrim instrument in your Prosim 737 VC. If these are low event values in the log: yes, somewhere the -16K to +16K range appears to be scaled into the -100 to +100 range. Also check if moving the dial doesn't generate TrimLeft or TrimRight events instead of SET events; because that would explain why it works Ok. Just saying that, because AILERON_TRIM_SET isn't documented in the FSX-Accel SDK (how about the P3DV4 SDK ??) Getting curious (never done that upto now) I did the same experiment for the RudderTrim axis. Result: behaves exactly the same as the AileronTrim.; so the event value range of -100 to + 100 gives max. deflection for rudder trim. Best regards, Rob

Hi Pete, I suspected something like that ...LoL I tested this with another aircraft then the OP (I don't have that either). As said in a previous post, AILERON_TRIM is a very unique axis function; very peculiar, like the FLAPS axis. It's not a normal "axis" (you can't assign a controller lever/wheel to it via the FS menu), and with the event AILERON_TRIM_SET you can only set 201 integer values (-100 to +100) for this "axis". In FSX (don't know about FS9) upto P3Dv4.3. In case you wonder: I'm using the AileronTrim axis as "proxy" in a few applications, to control an Lvar with keys/buttons. The charm of it being, that it has 201 discrete values (either via the SET, LEFT or RIGHT events) and that there's no "control acceleration" for it .. Glad my input helped pinpointing the problem. Cheers, Rob Barendregt

Hi Pete, Maybe my remark below on the FSUIPC.log explains something …. This is with FSX-Accel and FSUIPC4 not-registered. What I did: In the FSX Controls menu, I assigned a key CTRL+SHIFT+M to the function described in the menu as "Aileron trim (center)". I also made a small XML test gauge, that generates some axis events; including writing AILERON_TRIM_SET with a value 10 This is what the FSUIPC log shows (with event and axis logging enabled): // This is the result of me pressing the CTRL-SHIFT-M key: 150844 *** EVENT: Cntrl= 66731 (0x000104ab), Param= 0 (0x00000000) AILERON_TRIM_SET // This is the result of the axis event writes in my gauge: 152516 *** EVENT: Cntrl= 66731 (0x000104ab), Param= 10 (0x0000000a) AILERON_TRIM_SET 152516 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 20 (0x00000014) THROTTLE_SET 152516 *** AXIS: Cntrl= 65694 (0x0001009e), Param= 30 (0x0000001e) ELEVATOR_SET 152516 *** AXIS: Cntrl= 65695 (0x0001009f), Param= 40 (0x00000028) AILERON_SET 152516 *** AXIS: Cntrl= 65696 (0x000100a0), Param= 50 (0x00000032) RUDDER_SET All as I expected. But what strikes me as odd, is that in the log AILERON_TRIM_SET is named "EVENT" and all other axis writes are named "AXIS". Best regards, Rob

Hi Pete, Allow me to make some comment here (since I made a few gauge applications using the FSX "aileron trim axis") The "aileron trim axis" is a very peculiar "axis" in FSX, and not properly documented in the SDK. Unlike any other axis in FSX, it doesn't take the usual value range of -16384, 0, to +16384, but a discrete value from -100 to + 100 … So: in percent. Meaning that writing 50 as value for the event AILERON_TRIM_SET results in the "axis" being set to 50 percent left-trim. Likewise, each event AILERON_TRIM_LEFT or AILERON_TRIM_RIGHT, changes the "axis" value with exactly 1 percent between -100 and +100. Yes, FSX has NO event AILERON_TRIM_CENTER, though suggested by the text "Aileron trim center" in the FSX Controls menu. If you assign a key/button to the descriptive text "Aileron trim center" in the FSX Controls menu, it generates an event AILERON_TRIM_SET with value 0. So sets the Aileron Trim "axis" to zero (== centers it). This explains why Brian has "aileron trim center" working properly when he assigns a key/button to it via the FSX key/button Controls menu. I think (but I'm guessing here) that the problem is that in the FSUIPC userinterface, you cannot assign the "axis" event AILERON_TRIM_SET to a key or button. Hope this helps …. Best regards, Rob Barendregt

As Pete said (and you allready figured out yourself) , you are mixing up people ….. Pete Dowson and Doug Dawson aren't related (as far as I know ...LoL) But if you are looking for a solution to use COP3 in P3Dv4 (using 64-bit replacement gauges), please contact me at the EMail address mentioned in the README of my COP3 package. I may have an alternative solution for you. Cheers, Rob Barendregt

Have you tried Doug Dawson's XML_VARS module (freeware) ? It displays the Lvars (and their current value) defined in all gauges included in the panel.cfg. See: http://www.douglassdawson.ca/ Rob PS: by the way, not related to FSUIPC.

Hi Pete, If it satisfies your curiosity :) : It sounds like this guy has installed my (freeware) CarrierOperationPackage, which uses the IPC interface for speed control. Hasn't contacted me though with his problems. But I doubt that his problems have anything to do with FSUIPC. Best regards, Rob Barendregt The Netherlands

Hi Pete, You never stop to amaze me on how you react to such non-sence posts like these, in such a polite way :lol: Why do you even bother to answer it at all ? Cheers, Rob Barendregt

Hi Gents, Although there probably is an "inverse" relation between my replies in this thread, and the amount of Emails/Skype-sessions/testhours with Pete :-), I personally am convinced that V3719c is VERY stable. Being a developper myself, I (and a testfriend of mine) had very frequent CTDs with V371*, untill Pete found the problem and worked around it in V3719c. Since then, I have a 100+ FS-hours, and must have done a 1000+ aircraft/flight reloads in it, without a single CTD. Now, one can never be sure that "your" CTDs are caused by the same problem as "mine", but, as Pete said, an evident problem was solved and it surely solved my CTDs. Thanks again, Pete. Cheers, Rob Barendregt

Hi Pete, If it helps: - I have a Nvidia 7900GT card. - I only change from jet to jet And in spite of my initial reaction (via Email), that suggested that with V3.7.1.6 (after an hour reloading flights and aircraft) the CTDs were gone, I've seen it three times again since. But by far not as frequent as with 3.7.1.0.; to the extent that I haven't found a sequence of flight/aircraft selection to force the CTD with V3.7.1.6 Unlike with 3.7.1.0 Best regards, Rob Barendregt

Although not related to FSUIPC directly, but if it helps any finding out why: The XML variables BRAKE LEFT POSITION and BRAKE RIGHT POSITION had the the same problem (= the read values being dependant on eachother). But that was in FS2002 ONLY (OK in FS9 or FSX), and then ONLY when those two variables were read in the same XML gauge. Maybe this is a simular problem as yours. Regards, Rob Barendregt

"He who reads replies, does not read feelings". Very true indeed; if I read that right:?: Unfortunately, written communication like in forums or Email can lead to very akward mis-interpretation of what someone is really trying to say with what he writes, or his state-of-mind when he wrote it. Like the following example, which I wrote this week in the 5th Email to a user that was asking for support on my new FSX gauges that didn't work right for him: ... "" I truely want to help, but you are (no doubt: undeliberately) misleading me every time :-) "" Which I indeed wrote with a smile on my face, but appearantly was perceived as a real insult by this user. Even intended humor can be easily understood the wrong way. And then I'm not even talking about English not being the native language of many simmers (including me); which doesn't help either :lol: And to Joao: Besides what Pete replied, also don't forget that the amount of installed FSUIPC unregistered modules probably exceeds 100-times the amount of registered versions, because of all those freeware gauges that use FSUIPC and don't expect users to have a registered version. And I expect that won't change much for FSX. Although there now is a SimConnect interface, much of this pre-FSX stuff will still work just because Pete is still supporting the old IPC interface (now via SimConnect) in FSUIPC4 in a compatible way. Which allows me to make new versions of my freeware gauges for FSX very fast, without having to invest a lot of time in converting to the SimConnect interface myself. For which I, and I guess many users, are very gratefull to Pete. Because he doesn't earn a penny on that part of FSUIPC. Regards, Rob Barendregt

Hi Pete, If it helps: I've also done some FPS tests, using V4.02 unregistered but unused by any gauges. By observing a rather static scenery ( a saved flight with a parked aircraft on a large airport, in Spot view) for a minute after loading. And repeated the tests several times. I use: AVG antivirus and ZoneAlarm firewall. - With FSUIPC and Firewall On: avg. 11.5 fps - With FSUIPC and Firewall disabled: avg. 12.5 fps - Without FSUIPC and Firewall On OR disabled: avg. 14 fps Disabling Antivirus didn't have any effect. Regards, Rob PS: measuring FSP is quite cumbersome of course, since it varies a bit continuously, so it remains a bit guessing. But I had the most stable FPS (13.6 - 14.3) with FSUIPC not installed. With FSUIPC and Firewall On, I had the lowest "peeks" downwards (sometimes less than 10)