pilotjohn

I use axis slopes extensively to tweak the feel of my setup. However, I noticed that when slopes are being applied on the negative side of an axis, the calculations seems to be off, and cause "jumps". On the positive side, as the axis values increase, the slope output increases as well with no issues. On the negative side, as the axis values decrease, the slope output decreases, but then suddenly increases then continues to decrease then increases etc. It's almost as if these "incorrect" outputs are happening on the interpolation boundaries. Watching the values in the GUI, the raw negative input values do not fluctuate, but negative output values do. Below are some output samples on the aileron axis with slope 2 (the issue also manifests itself on the elevator with slope 1). I also posted a video (smooth movement to left, jumpy to the right): Notice the jumps as you go through the numbers, they decrease, then you'll have an increase, then a continued decrease and so on. 357929 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -164 (0xffffff5c) AXIS_AILERONS_SET 358023 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -768 (0xfffffd00) AXIS_AILERONS_SET 358054 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -1280 (0xfffffb00) AXIS_AILERONS_SET 358116 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -1792 (0xfffff900) AXIS_AILERONS_SET 358179 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -2140 (0xfffff7a4) AXIS_AILERONS_SET 358241 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -2560 (0xfffff600) AXIS_AILERONS_SET 358303 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -2656 (0xfffff5a0) AXIS_AILERONS_SET 358366 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -2910 (0xfffff4a2) AXIS_AILERONS_SET 358428 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3141 (0xfffff3bb) AXIS_AILERONS_SET 358506 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3328 (0xfffff300) AXIS_AILERONS_SET 358569 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3479 (0xfffff269) AXIS_AILERONS_SET 358631 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3329 (0xfffff2ff) AXIS_AILERONS_SET 358693 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3727 (0xfffff171) AXIS_AILERONS_SET 358756 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3619 (0xfffff1dd) AXIS_AILERONS_SET 358818 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4009 (0xfffff057) AXIS_AILERONS_SET 358881 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -3876 (0xfffff0dc) AXIS_AILERONS_SET 358943 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4096 (0xfffff000) AXIS_AILERONS_SET 359021 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4326 (0xffffef1a) AXIS_AILERONS_SET 359052 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4215 (0xffffef89) AXIS_AILERONS_SET 359115 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4098 (0xffffeffe) AXIS_AILERONS_SET 359177 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4516 (0xffffee5c) AXIS_AILERONS_SET 359239 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4413 (0xffffeec3) AXIS_AILERONS_SET 359302 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4827 (0xffffed25) AXIS_AILERONS_SET 359364 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4705 (0xffffed9f) AXIS_AILERONS_SET 359442 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4615 (0xffffedf9) AXIS_AILERONS_SET 359505 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5042 (0xffffec4e) AXIS_AILERONS_SET 359567 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4941 (0xffffecb3) AXIS_AILERONS_SET 359629 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -4874 (0xffffecf6) AXIS_AILERONS_SET 359692 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5315 (0xffffeb3d) AXIS_AILERONS_SET 359754 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5233 (0xffffeb8f) AXIS_AILERONS_SET 359817 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5173 (0xffffebcb) AXIS_AILERONS_SET 359879 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5376 (0xffffeb00) AXIS_AILERONS_SET 360238 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5597 (0xffffea23) AXIS_AILERONS_SET 360300 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5533 (0xffffea63) AXIS_AILERONS_SET 360378 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -5378 (0xffffeafe) AXIS_AILERONS_SET On the positive side of the axis, no such aberration exists: 368989 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 33 (0x00000021) AXIS_AILERONS_SET 369052 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 251 (0x000000fb) AXIS_AILERONS_SET 369114 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 256 (0x00000100) AXIS_AILERONS_SET 449892 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 467 (0x000001d3) AXIS_AILERONS_SET 449954 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 324 (0x00000144) AXIS_AILERONS_SET 450016 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 524 (0x0000020c) AXIS_AILERONS_SET 450094 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 699 (0x000002bb) AXIS_AILERONS_SET 450157 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 768 (0x00000300) AXIS_AILERONS_SET 450235 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 967 (0x000003c7) AXIS_AILERONS_SET 450266 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 1124 (0x00000464) AXIS_AILERONS_SET 450328 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 1280 (0x00000500) AXIS_AILERONS_SET 450391 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 1297 (0x00000511) AXIS_AILERONS_SET 450453 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 1562 (0x0000061a) AXIS_AILERONS_SET 450531 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 1792 (0x00000700) AXIS_AILERONS_SET 450594 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 1919 (0x0000077f) AXIS_AILERONS_SET 450656 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 2314 (0x0000090a) AXIS_AILERONS_SET 450718 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 2560 (0x00000a00) AXIS_AILERONS_SET 450781 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 2679 (0x00000a77) AXIS_AILERONS_SET 450843 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 2961 (0x00000b91) AXIS_AILERONS_SET 450906 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3219 (0x00000c93) AXIS_AILERONS_SET 450968 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3328 (0x00000d00) AXIS_AILERONS_SET 451046 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3370 (0x00000d2a) AXIS_AILERONS_SET 451077 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3472 (0x00000d90) AXIS_AILERONS_SET 451140 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3606 (0x00000e16) AXIS_AILERONS_SET 451202 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3731 (0x00000e93) AXIS_AILERONS_SET 451264 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3842 (0x00000f02) AXIS_AILERONS_SET 451327 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3905 (0x00000f41) AXIS_AILERONS_SET 451389 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 3956 (0x00000f74) AXIS_AILERONS_SET 451467 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4027 (0x00000fbb) AXIS_AILERONS_SET 451530 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4094 (0x00000ffe) AXIS_AILERONS_SET 451592 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4096 (0x00001000) AXIS_AILERONS_SET 451654 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4151 (0x00001037) AXIS_AILERONS_SET 451717 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4320 (0x000010e0) AXIS_AILERONS_SET 451779 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4573 (0x000011dd) AXIS_AILERONS_SET 451842 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 4846 (0x000012ee) AXIS_AILERONS_SET 451904 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 5146 (0x0000141a) AXIS_AILERONS_SET 451982 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 5376 (0x00001500) AXIS_AILERONS_SET 452013 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 5416 (0x00001528) AXIS_AILERONS_SET 452076 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 5642 (0x0000160a) AXIS_AILERONS_SET 452138 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 5944 (0x00001738) AXIS_AILERONS_SET 452200 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 6262 (0x00001876) AXIS_AILERONS_SET

Thanks... I just posted another questions, but likely the same answer applies.

Is there a way to assign multiple FS events to send per button press?

Is there anyway to accomplish a state/setting switch based on a key/joystick press? What I'm trying to accomplish is to use something like a "mode selector" to use one single switch to start selected engines. Similar to "Shift E+1..4" in FSX, the idea is to press something like Shift+1 (or a joystick button) which would load settings in FSUIPC that would cause the magneto switch on my panel to act on Engine1, and then press Shift+2 (or another joystick button) which would load another settings profile that would be configured to act on Engine2. Or is there some other way someone can suggest to configure this behavior?

Works like a charm... Thanks, and keep up the good work!

Sounds good to me...

I think it's a good point, and now that I rethink my use, I would likely want to decrease granularity, but now quite to the day. I would probably use an hourly save, with a format like %Y%M%D%h%m, or maybe a 5-15 minute save. Those that won't read the manual won't know about the expansion capability anyway, and the feature will continue to provide the same facility as it has now. For those that don't care about the date, they can just use %A, but for those that want to be very granular, they have the option. I think it's better to have the capability, with a short warning message in the manual about potential misuse, than to force a date-only option. And while I would normally use the hourly option, I can imagine scenarios where I would want the level granularity that minutes and seconds would provide (for example retrying some decision that was wrong, that might have happened 5 minutes ago, like flying up a box canyon, but it's a scenario where I won't know when the bad decision will be made and when it can be corrected, so the granular archive is needed). Having a more granular definition for date/time, would also allow users to mimic Auto-Save naming schemes without using YYYY or MM. Perhaps %d %h%m%s, with %d being an expansion for the name of the day of the week. Lastly, it's pretty easy to trim the directory from excess files, even manually, if a misconfiguration occurs and many files are created. So while I whole heartedly agree with the concept of trying to save the user from him/herself, advanced users should be given the choice and option to kill their filesystem. Maybe there's a way to do both, with manually setting things in INI and limiting what can be "entered" in the text field in the GUI? But that seems like more work for you. :)

I'm not on board with Prepar3D either, just wondering out loud... I agree FSX without EZCA is sterile. :) I haven't done any development for FSX but read plenty. I've been wishing for a nice clean flight/landing judge add-on, so this and that might be the push needed for me to start up VC++.

I'm assuming you've tried by using SIMCONNECT_DATA_FACILITY_AIRPORT and then calculating the closest one yourself? And that's the facility that doesn't get you all the airports, or may not get you the closest one... I wonder if this is fixed in Prepar3D.

Odd... I also run UT2, but don't have the hang problem. I see a Previous Flight save pretty consistently, but on several occasions it failed to load, and once or twice crashed FSX in weather.dll. I guess which is all the more reason why the "also save flight as" option expansion is likely a better solution.

AC and real date/time only would be fine (I fly sim time mostly, and when the flight is loaded I'm back to sim time.) Real time will also allow me to pick the latest drop-off point. Thanks for considering it! If you're not using something like strftime() for the date/time stuff, and you think it's useful, then maybe sim. time could be available as well (e.g. Y2/M2/D2) but that's not necessary for what I envision. The only reason I thought location would be available is because I noticed that FSX keeps a pretty consistent log of my flight, including airports at which I've done only a touch-and-go, so I thought it might be some obvious thing it provides. If something's possible without too much fuss, great, if not, no worries. Thanks, again! John

Sorry, I likely edited the above post after you read it... So would adding a small variable expansion capability to "Also save to a Flight called" be too much work? In the end, after all this thinking, that's really all I would need to get the functionality I'm seeking, and then some. And I'm sure there would be other uses for it... Please?

1. For me, it would be enough to get a saved flight tagged with the plane, period. Stripping anything but numbers and letters, and trimming to some limit like 50, 64, or 100 characters should be good enough and work in most cases (for those cases where two names conflict, the user could always edit the aircraft title to fix the problem and get a title to their liking - life's a compromise). This would allow you to resume the flight from where you left the plane if you want, or just do whatever you normally do. No need to make things automatic. I start FSX, if I want to continue where I left my Scout, I just load the "Previous Flight ACAScoutTundra" or whatever the name of the plane would be. If I don't want to continue, I just set up the flight I want as I normally would. I may be wrong, but this seems like it would be rather trivial since it would require just another call to the flight saving code with a different file name. 2. Would it be possible to save flights any time a "new flight" is selected? That is, anytime a flight is ended, or before a new AC is selected, or a new scenery or world position is selected? This would allow for #1 above to be used in cases where you switch planes, sceneries, or just end a flight to start a new one, without having to exit FSX. 3. I understand the naming has been around for a while. Perhaps an option could be offered to use different format. Or, there could be a textfield that would allow the definition of the name using some simple markup, in the form of strftime() plus some FSUIPC built-ins like the AC title (the default markup would be the current format). This would provide two things: one, an near-automatic archiving capability without having to rename files after exiting FSX, and two, it could be used for #1/#2 above by making this the only change in FSUIPC. You could configure your auto-save options to save with something like "AutoSave $AC %Y%m%d%H%M%S" and to save on ground. Then your only requirement would be to wait long enough after shutdown for the auto-save interval to be triggered (e.g. arrive at airport, taxi to parking, shutdown, wait 1 minute). This would even provide a solution for having multiple plane locations for the same plane, since the you could pick the location for the given date. Does FSX provide the current airport? Perhaps that could be an expansion field as well, something like $LOC, if there's not airport then replace with something like "NOLOC" or "INFLIGHT". In order of "wants", they are in order of importance. But #3 would provide the functionality of #1 and #2 so that would be perfectly welcome as well, and might be the most efficient use of your time. I would be even willing to write the file naming expansion code for you to insert wherever. So there's more than one way to do this, and whichever would be easier for you, I'm all for it. But, the more I read over my choices above and think about their use, the more it seems that #3 would solve a lot of these. :) Or, perhaps even easier yet, the "Also save to a Flight called" option could be used for this feature. All it needs then is the macro/var expansion capability for date/time and AC/LOC or whatever might be possible; no GUI changes, just some extra code to strip/trim AC name, perhaps LOC if possible, substitute for $AC/$LOC or whatever, and then pass through strftime() and done. I get goosebumps just thinking about it: a history of pretty much all your flights, cataloged automatically by date/time and AC and/or LOC, that you can pick and reload (relive) at your leisure.

I am a big fan of the auto-save and previous flight save feature of FSUIPC. I have a question: When is the "previous flight" saved? When the flight is ended and/or FSX is exited? I don't see it in the manual. I also have some suggestions: The auto-save filenames should include YYYYMMDDHHmmSS so that they're easily located (e.g. last one) and to make it convenient for archiving. Lastly, I'd like to see a per-aircraft "previous flight" save option. This would allow me to resume a flight where I left off on a per plane basis. Wherever I left my Scout Tundra is where I can resume from. Or, wherever I left the Islander is where I can resume it form. So in addition to the above, there would be like a "Previous Flight - Scout Tundra Blue+White Whatever" saved file. Regards, John

Third time's the charm... It's fixed, it works! Thanks, John

I know how it is... I tested with the aileron axis, and that works correctly: Ailerons (SLOPE 4) ---> 1.jpg 475662 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 10649 (0x00002999) AXIS_AILERONS_SET Ailerons (SLOPE 0) ---> 2.jpg 837163 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 12953 (0x00003299) AXIS_AILERONS_SET Brakes (Left SLOPE 0, Right SLOPE 4) ---> 3.jpg 685874 *** TOE BRAKE AXIS, Right set = 176 (IN=16192, OUT=12450) 685874 *** Both toe brakes over threshold: FS BRAKES control sent 685905 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450) 685936 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET 685936 *** AXIS: Cntrl= 66388 (0x00010354), Param= 12451 (0x000030a3) AXIS_RIGHT_BRAKE_SET Notice how the ailerons output the same thing as the GUI, however the two brakes (one at SLOPE 0, the other at 4) log the same thing despite the GUI showing two different things.

I've also disabled filtering, just to be sure. So with a slope of 4 you are getting an OUT of 12450? I think that is the OUT value that should occur without a SLOPE.... If I remove the SLOPE I see that value (~12700) in OUT in the GUI and in the logs. But if I add in a SLOPE of 4, the GUI shows an OUT of ~9700 but the logs still show an out value of ~12700. So shouldn't the GUI and logs agree +/- a few hundred? Without a SLOPE they agree. With a SLOPE the GUI shows 9700+/- while the logs show 12700+/-. I'm mapping a range of 32768 (-16k to 16k) to a range of 36864 (-16k to 20k). So at an input of +16k (fully pressed brakes) the OUT should be about 12743 (or (32768 / 36864 * 32768) - 16384) without a SLOPE map, which appears correct. But depending o the SLOPE setting, since the IN of 16384 is not the MAX value, the OUT should be less and less with higher an higher slopes. Am I correct? This appears to happen in the GUI, but not the logs. I'll verify one more time to be sure, and I'll try to reproduce with another axes where the SLOPE appears to work correctly.

Hmm... I'm still getting the same behavior with 4.709a. GUI OUT shows 9744, but log param shows 12451, and wheels lock. If I remove SLOPE and change MAX to 24576, OUT/param show 9500 as expected and no wheel lock.

I think most just don't care enough... but don't feel bad. It's like this for me with everything: if I touch it, I'll inevitably find something that's been broken/missing/wrong that no one noticed before. :) Thanks for the great support BTW!

Thanks I'll test... so the reason for the artificial maximum is because the pressure required to press the brakes on Saitek is very low and linear and thus braking always goes to the stops. It's hard to not go to the stops and stay coordinated with both brakes (there's no feel of pressure). Going to the stops always locks brakes in FSX. Going to stops and locked brakes are completely unrealistic, and seem to provide unrealistic stopping distances (I'm an RW pilot as well a sim hobbyist). I noticed that going to 80% max provides no locked wheels and a more realistic feel. The reason for the slope is that because the "throw" of the Saitek brake is so short, I wanted finer control over individual brakes in the beginning of the movement, which also is more natural (the initial movement provides a lot less stopping power, then the final "to the stops" effort; while the level of effort required to push is not simulated by Saitek, the slope adjusts the result of the axes movement.)

Brakes axes are assigned in FS, not direct control by FSUIPC... Here are the settings: LeftBrake=-16193,20480/8 RightBrake=-16193,20480/8 SlopeLeftBrake=4 SlopeRightBrake=4 When the brakes on my Saitek rudder are fully depressed, the GUI shows the attached screenshots, and the log shows: ********* FSUIPC4, Version 4.709 by Pete Dowson ********* User Name=... User Addr=... FSUIPC4 Key is provided WIDEFS7 not user registered, or expired [Continuation log requested by user] Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed 318383 System time = 21/06/2011 14:28:41, Simulator time = 08:30:45 (15:30Z) 318383 LogOptions changed, now 10000000 00000001 320629 *** AXIS: Cntrl= 66388 (0x00010354), Param= -12637 (0xffffcea3) AXIS_RIGHT_BRAKE_SET 320629 *** TOE BRAKE AXIS, Right set = 10 320660 *** AXIS: Cntrl= 66388 (0x00010354), Param= -14745 (0xffffc667) AXIS_RIGHT_BRAKE_SET 320660 *** AXIS: Cntrl= 66387 (0x00010353), Param= -14923 (0xffffc5b5) AXIS_LEFT_BRAKE_SET 320660 *** TOE BRAKE AXIS, Left set = 4 320660 *** TOE BRAKE AXIS, Right set = 23 320692 *** TOE BRAKE AXIS, Left set = 20 320692 *** TOE BRAKE AXIS, Right set = 45 320723 *** AXIS: Cntrl= 66387 (0x00010353), Param= -13107 (0xffffcccd) AXIS_LEFT_BRAKE_SET 320723 *** AXIS: Cntrl= 66388 (0x00010354), Param= -9011 (0xffffdccd) AXIS_RIGHT_BRAKE_SET 320723 *** TOE BRAKE AXIS, Left set = 48 320723 *** TOE BRAKE AXIS, Right set = 81 320754 *** TOE BRAKE AXIS, Left set = 86 320754 *** TOE BRAKE AXIS, Right set = 155 320785 *** AXIS: Cntrl= 66387 (0x00010353), Param= -2294 (0xfffff70a) AXIS_LEFT_BRAKE_SET 320785 *** AXIS: Cntrl= 66388 (0x00010354), Param= 9010 (0x00002332) AXIS_RIGHT_BRAKE_SET 320801 *** TOE BRAKE AXIS, Left set = 155 320801 *** Both toe brakes over threshold: FS BRAKES control sent 320801 *** TOE BRAKE AXIS, Right set = 176 320832 *** TOE BRAKE AXIS, Left set = 176 320863 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET 320863 *** AXIS: Cntrl= 66388 (0x00010354), Param= 12451 (0x000030a3) AXIS_RIGHT_BRAKE_SET

Just tested... reads 4.709 in GUI, shows correct value in GUI (9744 OUT for 16384 IN with 20480 MAX and 4 SLOPE) but it's still sending the unsloped value according to the logs (param = 12136).

Thanks...!

It's 4.703. But, I just installed 4.708 and it has the same behavior. I figured out the center settings... one other question, what are the /8 or /40 after the calibration settings?

No, it's not the coincident point. So I have MIN at -16384, MAX at 21502, SLOPE at 15. At these settings, an IN value at 16384 (fully depressed brakes) provide an OUT value of about 5100 according to the GUI. However, the logs show that it's sending a param value of around 11700, which would be the OUT value if the SLOPE were 0. It seems like the GUI is showing the correct value (5100) but the incorrect value (no slope) is being sent to FS. Is there any other way to verify this? 1. I set MIN/MAX/SLOPE as above. I fully depress the brakes, and see an OUT of around 5100 in the GUI. 2. I return to FSX, fully depress the brakes, switch to the modules directory open FSUIPC.log and see the last two lines showing around 11700 as params being sent. 3. I return to FSUIPC, set brakes SLOPE to 0, full depress brakes, and see an OUT of around 11700. So during condition 1/2, the GUI is showing 5100 OUT but the logs are showing 11700 being sent. I'm not sure if this is a bug, or if I'm missing something somewhere... And on this separate note, is there a way to change this "null" central zone?