Pete Dowson

At all ground speeds? The blending operation of FSUIPC only sends on the tiller input at 0 ground speed, and only the rudder input at 60 knots GS (that calue is adjustable in the INI file). Between the two there's a linear transition between the two, so that at 30 knots they have equal effect. Note that, as documented, the FSUIPC tiller uses the rudder operation in the Sim, not the separate steering axis. This is for full compatibility, and really it is the only decent way to accomplish that transition. I think the nose wheel responds to the rudder input as well as the rudder. FSUIPC's functions are only to derive the input for them from separate sources. If you don't want the blending, but just want it looking right when you are outside the aircraft looking at it, , try using the Steering set assignment in the FS controls drop down list. I doubt that this will stop the nose wheel turning with rudder (that probably depends on the model), but the inputs will be separate and both always functional. That appears to be confused. What do you mean by "same setting? "Differential brakes" means that the two brake inputs are separate. If they were both going to both brakes you'd not see the "differential" notification. It sounds like you have it correct, left toe brake operating the left brakes and the right toe brake operating the right brakes. That's as it should be. Pete

Okay. That 3rd file shows it is detected: 1481671 Product= HOTAS Cougar Joystick 1481671 Manufacturer= Thrustmaster 1481671 Vendor=044F, Product=0400 (Version 1.16) 1481671 GUIDs returned for product: VID_044F&PID_0400: 1481671 GUID= {F67C0610-F0A6-11E7-8001-444553540000} 1481671 Details: Btns=18, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X65535,Y65535,Z0 AND it as acquired ready to use: 1480593 Device acquired for use: 1480593 Joystick ID = 0 (Registry okay) 1480593 0=HOTAS Cougar Joystick 1480593 0.GUID={F67C0610-F0A6-11E7-8001-444553540000} BUT another joystick device has the same ID. So that one, being seen later, takes precedence with that ID: 1857531 Device acquired for use: 1857531 Joystick ID = 0 (Registry fixed) 1857531 0=T-Rudder 1857531 0.GUID={759C66C0-DA16-11E8-8002-444553540000} I don't know how the duplicate IDs have arisen -- they are obtained from the Registry. But now see the [Joynames] section in the INI (your settings): [JoyNames] AutoAssignLetters=No 1=EDTracker Pro 1.GUID={F51072D0-D1D3-11E7-8002-444553540000} 0=T-Rudder 0.GUID={759C66C0-DA16-11E8-8002-444553540000} 2=Saitek Pro Flight X-55 Rhino Throttle 2.GUID={0EE3E360-EBEA-11E7-8001-444553540000} Try changing those two lines beginning 0 to 3=T-Rudder 3.GUID={759C66C0-DA16-11E8-8002-444553540000} making T-Rudder device 3. Or, if you already have assignments to that device, instead add these lines: 3=HOTAS Cougar Joystick3.GUID={F67C0610-F0A6-11E7-8001-444553540000} thus making the Cougar Stick device 3 instead. Now I see a very odd thing in your settings. You have buttons assigned to a Device 3 already, despite no device 3 being listed. how did that happen? If that INI from a different installation, or some earlier configuration? 8=P3,32,C66654,0 -{VIEW_VIRTUAL_COCKPIT_FORWARD}- 9=P3,36,C66691,0 -{VIEW_MAP_ORIENTATION_CYCLE}- 10=P3,38,K50,9 -{Key press: shft+2}- 11=P3,34,K122,8 -{Key press: F11}- 13=P3,0,K192,8 -{Key press: '@key}- 16=R3,6,C65607,0 -{ELEV_TRIM_DN}- 17=R3,8,C65615,0 -{ELEV_TRIM_UP}- 18=R3,7,C66277,0 -{AILERON_TRIM_RIGHT}- 19=P3,9,C66276,0 -{AILERON_TRIM_LEFT}- If you don't want those assignments, delete those lines. If you want to keep them but not for the Cougar, use device 4 above instead of 3. Pete

Why would you want it repeating? surely once centred it should not need centering again? Yes, I know. you are repeating yourself again. But you did say a keystroke assigned to the Aileron Trim Centre in FSX works. You don't need controls enable in FSX for that. So why haven't you assigned your button to that keystroke in FSUIPC, as I suggested? Pete

Rob, I've been testing the assignment of Aileron Trim Set in FSUIPC, as an FS control to be sent. I am using P3D4, not FSX though. It is sent but it has no effect here. It changes nothing. I was monitoring the state of SimConnect Values (SimVars) "AILERON TRIM PCT" and ""AILERON TRIM", reading the first as a "percentage" value, and the latter in radians. Neither changed at all when sending the Aileron Trim Set control direct to the sim, whether by button assignment or axis. The fact that the values would mostly be outside the -100 to +100 range might account for that if such values made the request a reject, but the zero point should be able to still operate. However, if I assign "direct to FSUIPC" instead ("aileron trim"), then it writes direct to SimVar "AILERON TRIM PCT", converting the input range -16384 - +16383 to -100 to +100 beforehand. That works fine, as illustrated by this loog fragment: 2277770 Monitor IPC:0C02 (S16) = -15995 2277770 SimRead: 0C02="AILERON TRIM PCT" FLT64: -97.6318823726 2277770 Monitor IPC:2EB0 (FLT64) = -0.1704 2277770 SimRead: 2EB0="AILERON TRIM" FLT64: -0.170399699188 2277817 Monitor IPC:0C02 (S16) = -16253 2277817 SimRead: 0C02="AILERON TRIM PCT" FLT64: -99.2065894067 2277817 Monitor IPC:2EB0 (FLT64) = -0.1731 2277817 SimRead: 2EB0="AILERON TRIM" FLT64: -0.173148081433 2277848 Monitor IPC:0C02 (S16) = -15995 2277848 SimRead: 0C02="AILERON TRIM PCT" FLT64: -97.6318823726 2277848 Monitor IPC:2EB0 (FLT64) = -0.1704 2277848 SimRead: 2EB0="AILERON TRIM" FLT64: -0.170399699188 2277864 Monitor IPC:0C02 (S16) = -16253 2277864 SimRead: 0C02="AILERON TRIM PCT" FLT64: -99.2065894067 2277864 Monitor IPC:2EB0 (FLT64) = -0.1731 2277864 SimRead: 2EB0="AILERON TRIM" FLT64: -0.173148081433 So, I simply don't know what's going on with "Aileron Trim Set", but the direct approach works fine. If N8862V is still reading this, then that is something he could try, just to see if it works with his aircraft -- assign the Aileron Trim in FSUIPC Axis Assignments but use the "direct to FSUIPC" option. if that changes the trim in his aircraft, then a button assignment alternative could be arranged (it involves having a macro writing zero to one offset then an internal control number to another offset. There's a range of internal controls (internal to fSUIPC) which use the 'direct to FSUIPC' methods). For FSUIPC5 I could intercept the FS control for Aileron Trim Set and route it direct to SimConnect instead of forwarding it as a control, but I'd better not else I'd ruin any special implementations folks have made using that control for other purpose. Pete

No, no inconvenience at all. it is just rather curious. Provided my suggested solution of assigning to your keystroke in FSUIPC works for you (as it should), then I really consider the original matter closed. I'm now mainly curious about this range of values discrepancy. That's really another matter. Pete

I don't know of anything. Could you find these files, in the FSX Modules folder, and attach them or show them to me please, and I'll check: FSUIPC4.INI FSUIPC4.LOG FSUIPC4 Joyscan.csv Pete

Please test with a different aircraft, preferably a default one, and see what you get. Also, of course, check that you don't have any other assignment to the same throttle axis, whether in FSUIPC or the Sim. The different between an axis reading of 400 and one of 800 is within normal variation without moving the lever for some joysticks Differences of 256 and 512 are often just a tiny way apart and within resistance measurement variation for poentiometers when the total scale is -16384 to +16383. This is why your odd reading suggests another input with a slight jitter. FSUIPC only reacts to changes in the input, so if there were no jitter it would change your 0. Pete

In flight the spoilers/speedbrake only go to the flight detente, not full spoiler as after touch down. This is so even if the lever is moved to full spoiler position. However, it sounds like you've not calibrated the arm position. My PFC calibration provides for the Arm position by having a "centre". Is that calibrated? What you could try as well is unchecking the enabling tick in the PFC driver and calibrating in FSUIPC instead, though mine works well with PFC handling alone. What range of axis values do you see in the PFC driver? Pete

Hmm. Something is scalng it when assigned as an axis in FSUIPC then. I have both rudder trim and aileron trims in my 737 cockpit, calibrated through FSUIPC, and with the ProSim 737 they both seem to work quite normally. Of course I've never tried extreme positions away from centre, but even so, the normal increment on the type of pot in use in my PFC cockpit only gives about 128 unique positions over the -16k to +16k range, so just a slight movement would exceed the 100. Yet the trim works fine. Next tme I have the cockpit running I'll do some monitoring of the values and see what is going on there. Pete

Strange. Here, with FSX-SE, I could not detect any event when using that sim assignment. Do you have the same aircraft to test on as the OP? Originally, till I tested here on a "normal" aircraft, I assumed what was happening on that specific aircraft was that it was somehow capturing the even before FSUIPC could see it, and before whatever is sent by FSUIPC would have been seen. But that wouldn't explain why I couldn't see the axis logged here. Actually, that's a good spot. It's an error. I only differentiate between the two by checking the control number value -- axes are checked. But that number is missing from that check! Too late to fix for FSUIPC3 and FSUIPC4, but I'll fix that for FSUIPC5. I'll need to see if I've missed any others! It's quite a complicated differentiation. There are many "SET" controls. Some are for discrete values (eg Magnetos), even just on/off settings (Slew Set). But there are a number which are continuous, like heading set and altitude set, though those have more specific limits than definble as "Max" and "Min". I guess what i should be defining as Axes for logging purposes are those I provide calibration for. And that does include the Main control trims. Elevator, Aileron, Rudder. And I missed those last two. I'll revise the function making the choice to use the same list I use for calibration enabling instead. Thanks! Pete

Well you seem really good for 86. I am 75 and feel I'm losing it sometimes! Hope I'm still all there at your age! Pete

I KNOW what your problem is!!! You have repeatedly told me in this thread! Please don't keep repeating all that. As I explained, I am trying to find out WHAT control your "aileron trim centre" uses in FSX. There is no such control listed in the standard list of controls installed by FSX or P3D. Another contributor in this thread said it sent aileron trim set" with a parameter of 0, which is why I suggested assigning to that in FSUIPC. However you found that was not working. SO, I was trying to get you to do some logging in FSUIPC so I could identify what exactly FSX was doing when you used that FSX assignment. Unfortunately, for reasons I don't understand, you never bothered to follow my instructions to generate the correct logging, so i am none the wiser! I cannot help you without the proper information. [LATER] I was going to post just the above when I thought I'd find a way to end this thread one way or the other. So I re-installed FSX (actually it's FSX-SE, which has the same contrls but is a big improvement over FSX which I no longer have). I have actually not used FSX or even FSX-SE for a long time now. The Aileron Trim (Centrer) control in FSX-SE (for that is how it is shown) works, but does NOT use any assignable control in FSUIPC. It appears to work internally somehow. The Aileron Trim Set assigned in FSUIPC, with parameter 0 also works, at least in all the aircraft I have which supports such. I do not have anything by Dodosim. I can only think that your Dodosim aircraft implements its aileron trim in a different way, not relying on the standard controls which are evidently not used by FSX for Aileron Trim (Centre). So the only way you can assign to a button in FSUIPC is to retain your FSX-assigned keypress for Aileron Trim (Centre) and simply assign the button to that keypress. You don't need to re-enable controllers in FSX to do this. Okay? Pete

It only makes the second one when you click the "NEW LOG" button. that simply preserves the log up until the time you click that button. If you recall, I specifically asked you NOT to click it! Anyway, the main log (the larger one, which continues from the other) contains: 158060 [Buttons.Dodosim 206 FSX GDSIM H] 9=R0,0,C66731,0 158060 Repeating flag set: bRef=0, Joy=0, Btn=0 (RepeatDelayCtr=1) 158060 FS Control Sent: Ctrl=66731, Param=0 So your button, programmed in FSUIPC, is correctly sending the Aileron Trim Set control with parameter 0. You must be pressing it lots of times, or holding it down for some reason. You have programmed it to repeat -- why? Why would you was a trim reset button to repeeatedly reset the trim over and over? Unfortunately there is no entry for you pressing any key, whether assigned in the sim or not. So there is nothing for me to check why control 66731 doesn't work for you whilst your key assignment does. You don't appear to have Button/Key logging enabled at all -- only one logging option is enabled in fact. Pete

Yes, but the axis event logging doesn't appear to be enabled. I can't check for sure because for some reason you started a "New Log". Please do not do that -- the log then doesn't contain essential information logged at the beginning. The log does show that either the aircraft you are using has a bug where it sends a PANEL_ID_OPEN control once every second, or you have some button programmed for that stuck somehow and repeating -- though in that case I would expect a faster repeat. The log entry you are referring to saying 66731.0 is merely the parameter from your INI file for the button you assigned. That is logged because you enabled Button/Key logging. Pete

Okay. That is correct. 66731 is the internal control number used for that control. Yes. If it is using that control, and youhave got Event logging enabled (and ias it's an axis event it needs to axis event logging enabled, then it will show. If you've not enabled that then please now enable it and repeat both tests. It sounds like you've only enable Buton/Key logging. Yes, you've already said that several times! That's why I want to see your logging to work out what is going on! Pete

Actually you can. You just need to supply the value as parameter. This is what I did suggest, but I can only think the OP made an error, because if that is what the "centre" control is sending, as i surmised (but wanted proof via the Logging), then it should (must) operate identically. In FSUIPC you can also assign button\key type events to axes, but in this case you have to do it on the right-hand side, assigning the events to points, or rather ranges, of the axis movement. That's often used for Gear levers, for instance, via Gear Up and Gear Down controls. Thanks, Pete

"Connections" in such an interface aren't like communication connections which can "get broken". The interface uses SHARED MEMEORY -- a block of real memory which is accessible to both processes. As I pointed out before, everything to do with this is help in these fixed postion values: static HWND m_hWnd = 0; // FS6 window handle static UINT m_msg = 0; // id of registered window message static ATOM m_atom = 0; // global atom containing name of file-mapping object static HANDLE m_hMap = 0; // handle of file-mapping object static BYTE* m_pView = 0; // pointer to view of file-mapping object static BYTE* m_pNext = 0; // ... Your code is corrupting some of these. You can see m_hMap an m_pview are next to each other, so you have something tramplying on both. To find where just use the Debugger facility to set a breakpoint on one of the values, AFTER you've opened the interface. m_atom is a 16-bit handle. m_pView is a 32-bit memory pointer (64-bit in a 64-bit program). The close Close and Open and immediate check works because you haven't executed any of your code, including the part which is going wrong. Sorry, I don't see how I can help any further. You need to do the debugging. Pete

That's the only Log FSUIPC produces. It renames any previous one with a "Prev" addition. Actually there are a log more available in FSUIPC than exposed by the FSX interface. The log you kindly provided shows you did NOT enable event logging in FSUIPC Options as requested, so even if you had used that control nothing would have shown. Do you have a problem enabling that option? Is there something about that you don't understand? This appears to be pretty much a repeat of things we've already been over! Please review the previous messages in this thread. "Aileron Trim Set" is an axis control, not a normal button control assignable to buttons or keys in FSX. It is used by those who use joystick or specialist controls with suitable axes for such trims (some aircraft, notable airliners, have aileron and rudder trim adjustmets as well as the usual elevator trim). Pete

I assume you are linking with the supplied static LIB? The source for the library is included in the package, because most folks prefer to build-in the source itself as part of their program -- makes it easier to debug and therefore see what is going on. In the source you will see it is all done in local storage in the library., thus: /****************************************************************************** START of FSUIPC_User ******************************************************************************/ static HWND m_hWnd = 0; // FS6 window handle static UINT m_msg = 0; // id of registered window message static ATOM m_atom = 0; // global atom containing name of file-mapping object static HANDLE m_hMap = 0; // handle of file-mapping object static BYTE* m_pView = 0; // pointer to view of file-mapping object static BYTE* m_pNext = 0; // ... Note that the FSUIPC_Read action merely transfers information already in the shared menory. It is the FSUIPC_Peocess call that interacts with FSUIPC, sending the accumulated writes and reads. Which makes this line in your code look rather odd: if (FSUIPC_Read(0x0238, 3, localFsTimeRaw, &dwResult) && FSUIPC_Process(&dwResult)) and this pair: FSUIPC_Read(0xC824, sizeof(timeStamp), &timeStamp, &dwResult); FSUIPC_Process(&dwResult); Why are you doing the read/write interaction with FSUIPC after you do the reads? Anyway, to help you debug the problem, the error you are getting ("NOTOPEN") is returned when you try to do a Process, Read or Write when that m_pView is zero. It is that which points to the shared memory, and should remain non-zero (it is an address in memory) from the time you Open till the time you Close. You will see from the source of FSUIPC_User.cpp that those two places are the only times it is being set, so either your code is Closing the link somewhere, or it is being overwritten somehow. Pete

Well, the Log file you attached certainly shows it to be there -- or at least requested from SimConnect. That's what this line means: 1872 FSUIPC Menu entry added FSUIPC can do no more than ask for it to be added. But you seem to have some much more serious problem. Look: 591556 Sim stopped: average frame rate for last 141 secs = 8.7 fps 591556 Max AI traffic was 0 aircraft 679665 Starting everything now ... 681069 Advanced Weather Interface Enabled 1024646 Sim stopped: average frame rate for last 161 secs = 9.1 fps 1024646 Max AI traffic was 190 aircraft 1179399 C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\jf_TristarAdv_FMC\JF_1011.AIR 1183673 Aircraft="JF TriStar Pro 500 Delta FMC" 2118478 Sim stopped: average frame rate for last 814 secs = 5.7 fps 2118478 Max AI traffic was 214 aircraft Average frame rates in the single digits!? Event less than 6 fps? How can you use such a sim installation? You ran FSUIPC for 2118 seconds (over 35 minutes) with this really poor performance!?. Please always provide a complete log -- i.e. after FS is closed. There's a lot of important information logged on termination too. Anyway, there's nothing showing up as wrong with the FSUIPC installation. And whilst I think you first need to work out what is so wrong with the installation to make the performance so bad, can you tell me what you do see listed in the AddOns menu, please? Maybe a process of elimination is needed amonsgst the add-ons. A worthwhile job in any case to sort the performance out. Pete

Please enable event logging, operate this control you are using for aileron trim centre, and show me the resulting log. I'm really curious. There is no such control listed, so I'm not sure what it is you are assigning to and I'd like to know! FSUIPC doesn't have a list of controls built in. the gets them all by reading the list in the flight sim. That way it always provides all of the controls which are actually possible. If it is a regular control of some sort then you will certainly be able to use FSUIPC to send it. We just need to know what is really is! Thanks, Pete

Just the Joynames section! Here's that section from your old INI (with the oddly placed space lines removed: [JoyNames] AutoAssignLetters=Yes 1=USB ADAPTOR 1.GUID={EE32BE70-6492-11DF-8001-444553540000} U=<< MISSING JOYSTICK >> R=<< MISSING JOYSTICK >> A=Saitek Pro Flight Yoke B=USB ADAPTOR B.GUID={EE32BE70-6492-11DF-8001-444553540000} C=Saitek Pro Flight Combat Rudder Pedals C.GUID={844B0DD0-9238-11E0-8001-444553540000} 2=Saitek Pro Flight Combat Rudder Pedals 2.GUID={844B0DD0-9238-11E0-8001-444553540000} 0=Saitek Pro Flight Yoke 0.GUID={76070770-648E-11DF-800E-444553540000} The missing U and R lines in both can just be deleted. They must be historical as you have no such assignments. (In fact you have very few assignments, so with all your confusion I would have thought it quickier to start over in any case -- 13 axis assignments and only 3 buttons assigned! From what you were saying I thought it was a mammoth set of assignments and profiles! (Your calibrations would have still been okay). Anyway, your active devices above are just: 0=Saitek Pro Flight Yoke 0.GUID={76070770-648E-11DF-800E-444553540000} A=Saitek Pro Flight Yoke (with a missing A.GUID line which should be there too!!!) 1=USB ADAPTOR 1.GUID={EE32BE70-6492-11DF-8001-444553540000} B=USB ADAPTOR B.GUID={EE32BE70-6492-11DF-8001-444553540000} 2=Saitek Pro Flight Combat Rudder Pedals 2.GUID={844B0DD0-9238-11E0-8001-444553540000} C=Saitek Pro Flight Combat Rudder Pedals C.GUID={844B0DD0-9238-11E0-8001-444553540000} Doing the same arrangement from the new INI 0=Saitek Pro Flight Yoke 0.GUID={419D8620-EA3C-11E8-8001-444553540000} A=Saitek Pro Flight Yoke 1=USB ADAPTOR << MISSING JOYSTICK >> 1.GUID={419DAD30-EA3C-11E8-8002-444553540000} B=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> 2=Saitek Pro Flight Combat Rudder Pedals 2.GUID={A675B770-EA3C-11E8-8001-444553540000} C=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> You see that all the GUIDs are different? That is because they are generated new by Windows when it first sees the device! That was your problem. The actual ID numbers (0, 1, 2) are okay. So, it is almost correct. You only need to reproduce the 0, 1 and 2 lines and put the A, B and C in. Thus: 0=Saitek Pro Flight Yoke 0.GUID={419D8620-EA3C-11E8-8001-444553540000} A=Saitek Pro Flight Yoke A.GUID={419D8620-EA3C-11E8-8001-444553540000} 1=USB ADAPTOR 1.GUID={419DAD30-EA3C-11E8-8002-444553540000} B=USB ADAPTOR B.GUID={419DAD30-EA3C-11E8-8002-444553540000} 2=Saitek Pro Flight Combat Rudder Pedals 2.GUID={A675B770-EA3C-11E8-8001-444553540000} C=Saitek Pro Flight Combat Rudder Pedals C.GUID={A675B770-EA3C-11E8-8001-444553540000} This business is actually described in the Joy Letters section of the User Guide. The Log is useful in that it contains this: 109 ---------------------- Joystick Device Scan ----------------------- 109 Product= Saitek Pro Flight Yoke 109 Manufacturer= Saitek 109 Vendor=06A3, Product=0BAC (Version 2.1) 109 GUIDs returned for product: VID_06A3&PID_0BAC: 109 GUID= {419D8620-EA3C-11E8-8001-444553540000} 109 Details: Btns=23, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U255,V255,X1023,Y1023,Z255 109 Product= USB ADAPTOR 125 Vendor=079D, Product=0201 (Version 2.9) 125 GUIDs returned for product: VID_079D&PID_0201: 125 GUID= {419DAD30-EA3C-11E8-8002-444553540000} 125 Details: Btns=8, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R255,U0,V0,X255,Y255,Z255 125 Product= Saitek Pro Flight Combat Rudder Pedals 125 Manufacturer= Saitek 125 Vendor=06A3, Product=0764 (Version 2.0) 125 GUIDs returned for product: VID_06A3&PID_0764: 125 GUID= {A675B770-EA3C-11E8-8001-444553540000} 125 Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R1023,U0,V0,X127,Y127,Z0 125 ------------------------------------------------------------------- 125 Device acquired for use: 125 Joystick ID = 0 (Registry okay) 125 0=Saitek Pro Flight Yoke 125 0.GUID={419D8620-EA3C-11E8-8001-444553540000} 125 Device acquired for use: 125 Joystick ID = 1 (Registry okay) 125 1=USB ADAPTOR 125 1.GUID={419DAD30-EA3C-11E8-8002-444553540000} 125 Device acquired for use: 125 Joystick ID = 2 (Registry okay) 125 2=Saitek Pro Flight Combat Rudder Pedals 125 2.GUID={A675B770-EA3C-11E8-8001-444553540000} 125 ------------------------------------------------------------------- See the "(Registry okay)" comments there? That means the device ID in the Registry concurs with the numbers assigned in the INI. I bet this Log isn't the first one from the new installation, because I think it is unlikely the IDs were originally the same. All recent versions of FSUIPC actually fix the ID in the registry if they disagree. That's just a safeguard for folks not using Joy Letters. Pete

MOVED TO SUPPORT FORUM, SO IT CAN BE ANSWERED! There is no "Aileron Trim Centre" control. These are the Aileron Trim controls: AILERON TRIM SET 66731 AILERON TRIM LEFT 66276 AILERON TRIM RIGHT 66277 If you think otherwise, just enable Event logging in FSUIPC's logging, operate the button function you think does it, and see what is logged. You CAN centre the trim by using AILERON TRIM SET with a parameter of 0. Please always post support questions to the Support Forum (i.e. here), not to the reference subforums, where they may go unnoticed for a good while. Pete

Are you sure you are actually changing that file? Because there's no way FSUIPC will ignore any settings it is able to read! Ah, if you are only talking about joystick device assignments, then it is extremely unlikely that both PCs have the same IDs and same GUIDs for the same devices. You need to check your orginal INI'd [Joynames] section and compare with the new one generated, or the one logged in the LOG file. hen you can edit them to be the same. (This is much easier if you had first set FSUIPC to use JoyLetters -- i.e. on the first PC. The "POWER USERS" note you refer to is referring to changing from P3D3 (or FSX) to P3D4 on the same PC without other changes like removing and reconnecting all devices. No way will two separate PCs generate the same GUIDs for the devices, and they are crucial to the DirectInput access FSUIPC uses. The same thing would apply with FSX on both PCs. It isn't related to FSX or P3D3 to P3D4. Pete

You probably need to reverse it. The "third of the way down" (assuming by "down" you mean towards you?) is probably the Flight Detente. Full spoiler action only works after touch down. There's an "arm" position to be calibrated as well. Pete