Pete Dowson

Sorry, what does that mean? You had them calibrated in FSUIPC and they still are? didn't pressing RESET change that button back to SET (the default0. if not then there's something very very seriously odd with your system. it would mean FSUIPc is not recieving mouse clicks on its buttons! Yes, so giving the range 0-16383. BUT that controls the sim throttles and your aircraft model is apparently overriding those. Isn't that why you were sending the value on using the ipc.control function? That control needs values -16384 to +16383. You are only sending it 0 to +16383, so you only get the top half of the range. So, before sending the value, multiply it by 2 and subtract 16384. Here's my version of your earlier Lua function:: function Throttle_1_Set (off, val) th1_set = (2 * val) - 16384 ipc.control(66420, th1_set) end event.offset(0x089A, "UW", "Throttle_1_Set") Pete

J2 is standard 2 jet engine throttle assignment. The -n part is the quadrant level 0 = left most, 5 = right-most. so normally 0=speedbrake, 1= throttle 1, 2 = reverser 1, 3=reverser 2, 4 = throttle 2, 5 = flaps 5,5 are internal flags related to the options you selected The rest is the calibration you made: 0 is the lowest possible value, then your lowest set, then two central values (for central null zone) -- not used on jet throttles, then your set max, then theoreticl max 9127). NO! You change those in the calibration. You can't do anything different by messing with the parameters in the INI. I think the problem is that you are taking the range 0-16383, which is the full throttle range inside the sim, and using it as the parameter for an Axis Throttle set control. Those latter controls are only used for forward thrust -- they hav no reverse zone. Furthermore they use the whole range -16384 to +16383 for forward thrust. So your idla, 0 , looks half=way through. I think, in your Lua, you need to add 16384 and divide the rresult by 2. Only the old "ThrottleN set" controls, originally used in FS98, have a reverse range. That's what FSUIPC's calibration uses. They can be assigned in FSUIPC, but I doubt they'd work in your aircraft (though you could try that first I suppose). Pete

Please do NOT remove anything! Just ZIP the file. It is all text and ZIPs up really small. Actually, cross-checking your FSX version, 62615, with my list, that version is a little old. the last version from Dovetail Games was 62617. Each of their updates improved on the previous, so it is always worth keeping up to date. Pete

In the example Lua plug-ins ZIP file in your FSUIPC Documents folder. The ones supplied are also listed in the Lua documentation, also in the FSUIPC Documents folder. In fact all the FSUIPC documentation is in that folder. Pete

I've no idea. You need to check what the LVars are doing by using the Log LVars lua plug-in. That will show the LVar names exactly as they should be, and their values, changing in real time. Pete

Looks pretty much default. You don't appear to be using FSUIPC for anything, but the LOG file would be more informative. You said: Do you mean beyond 63003, the one released last week on Steam by Microsoft? Looking at the INI you are still on the last release by Dovetail Games: FSVersionUsed="Microsoft Flight Simulator X",10.0.62615.0 SimConnectUsed=10.0.62615.0 Pete

There's been no change in any of this. Can you check that you haven't got the Information Text option turned off in P3D? If you have it suppresses SimConnect windows and allows them to be diverted (via FSUIPC/WideFS) to a different screen. Pete

66420 is the best choice as this is the same as assigning in FSX itself. UNLESS you are also calibrating in FSUIPC. Try turning the calibration off (press the RESET button on the relevant Calibration tab). Calibrating in FSUIPC means it has to intercept the control (via SimConnect) at its normal level, process the value, then send it back to SmConnect at a lower level. It cannot send it back at the normal level because that would cause an infinite loop. Some aircraft, like the PMDG Boeings, also grab the value at the higher level, not from withing FSX. Probably the Airbus you are using does the same. Pete

Yes, that is quite likely. with PMDG aircraft if you calibrateyou get conflicting values so the throttles jitter. With some other add-on aircraft they just don't process the controls at all at the level FSUIPC has to inject them after calibration. Calibrate in PFCcom64.dll, the PFC entry in the Addons menu. Pete

The 0 in your event call isn’t valid. Does the log show an error? Minimum time for scanning is 100. Use something like 250. Sorry I didn’t spot that before. Use the Log Lvars Lua plug-in to check whether your Lvar is changing. Pete

You called the function "QW_AP_MASTER_I", which is okay. but then your event.Lvar calls it "AP_MASTER_I". You missed off the "QW_" bit! Additionally your function definition: function QW_AP_MASTER_I (66C0, 0) contains actual values as parameters. They need to be names of values you might then use. For example: function QW_AP_MASTER_I (offset, val) what then happens is that the "Offset" parameter will becone 0x66C0 (or whatever other offset you might call the function for), and, more importantly, the val parameter will be the value you want to use. Then these next lines: ap_master_l = ipc.readLvar("L:QW_ap_master_l") ipc.writeUB(0x66C0, ap_master_l) simplify down to just: ipc.writeUB(0x66C0, val) Oh, and you don't need the return either. The return will occur at the end. So, the fully corrected Lua looks like: function QW_AP_MASTER_I (offs, val) ipc.writeUB(0x66C0, val) end event.Lvar("L:QW_ap_master_l",0, "QW_AP_MASTER_I") One last thing. When a Lua plug-in doesn't work, do look at the reports in the FSUIPC LOG file, in your Modules folder. Any errors like these will be logged including the line number in your Lua file. Pete

Though your FSUIPC settings and logged details might be useful, so please do send (add or paste) those files, you should understand that there is really no way, uninstructed, that FSUIPC can make windows disappear. It doesn't get involved with graphics at all. Whilst we'll look at your files I think you should post the problem on the PMDG support forum. Pete

Let me get this right. Merely installing the 737NGXu has messed up your rudder control on all aircraft? Or only PMDG aircraft? And you've mad no changes, only installed an aircraft? The rudder is just another flight control axis along with aileron and elevator. FSUIPC treats them all the same. And you go on to say: With no settings -- no assignments, no calibrations, nothing -- FSUIPC isn't doing anything, at least not for you. At most it will be obeying requests from other applications designed to work with FSUIPC, or Lua plug-ins. It sounds rather like you may have questions for PMDG, doesn't it? If you want furrther help here you'll need to supply the FSUIPC5.LOG and the FSUIPC5.INI files from the Modules folder, and also describe exactly what the rudder problems are, and which aircraft they do and don't affect. Also, if you are attempting assignment in FSUIPC, whether buttons or axes, please be sure to turn controllers off in P3D altogether. Pete

Sorry, the only way currently to remove an aircraft profile assignment is to edit the settings file. Go to the P3D or FSX Modules folder and find the FSUIPC4.INI (or FSUIPC5.INI for P3D5). Open it in notepad and look for a section [Profile.xxxx] where xxxx is the name of the profile it is wrongly assigned to. There's be a list of aircraft names after that.Jjust delete the one you want to re-assign the profile for. Save the changed file then load up the Sim, load the aircraft, and create or assign a profile. Pete

Well, It would actually be a lot easier to do in the Options for Key assignments, but perhaps editing files is easier for you? So, here's an example: 64=90,24,x0D0066C0,x01 -{tab+Z: Press=offset byte setbits, offset 66C0 }- Here 64 is just the entry nmuber in the list, 90 is the Key Code for Z, 24 is the sum of the two "shift code" values for "Press" and "Tab" x0D0066C0 is the hexadecimal representation of 0D00 is the top part, for the control "Offset byte setbits" and the lower part, 66C0 is the offset being changed. 01 is the parameter giving the bit (or several bits -- it's a hexadecimal value too) to be set. Sorry, I don't understand you mean here by "this". If you mean something you read from an offset then all vlaues are binary, whether code, strings or numbers. It's how their interpreted that matters. An application written to interface to FSUIPC using the mthods defined in the SDK do not need to be talking with a registered version. You'd need a registered version to assign the keys though. The keys section of the INI file won't be used otherwise. You'd need another program to detect the keys and set the offset. So to that extent you might as well have the program which is reading the altitude simply act on the keypresses itself. Why have FSUIPC detect the keypresses? Pete

Yes. There is a range of three user offsets, from 66C0 to 66FF (64 bytes altogether). There are special FSUIPC controls you can assign.to any keypress or joystick device button If 64 different actions are enough then you can use the Offset Byte Set contro, with the chosen offset aspecified and a parater on 1 or 0 as needed to turn something on or on. It it is to trigger an action only, like playing a sound, then maybe Offset Byte ToggleBits would be better. This just toggles the specified bit 9or more, bits) in the offset specified,. you'd use parater 1 for bit 0, 2 for bit 1, 2 for bit 2, up to 128 for bit 7. This gives you up to 512 different actions (8 x 64), but I doubt you'd find enough buttons or keypresses to handle all those. Sounds good. Your "app" would need to handle a "toggle" of a bit differently to a Set (goes non-zero) or Clear (goes zero) change. Sounds to me as if you need to use Toggle commands. The offsets are as I've said, 66C0 to 66FF -- 64 bytes. Setting up is just by assignment. Let us know if you need more help with setting this up. Pete

I think the calibration selection in P3D does the same thing. Good! Happy flying! Pete

Well unfortunately you'll find "best-rated" equates with best hardware too. Currently you can apparently try the FSX-SE "Beta" on Steam for free. FSX-SE was cheap in any case. It was basically a recompiled improved (a bit) version of FSX. I think they've re-enabled real-time weather in the Beta, but you'd need to check. FSX originates from 2006, so not that distant from your FS2002. Otherwise the best there is at present, in my opinion, is Prepar3D version 4. For real-time weather you need an add-on though -- ActiveSky is excellent, but there are others. And there's a lot of support for the latest X-Plane flight simulator, competing with Prepar3D. Prepar3D was originally based on Microsoft's "ESP", which was a commercial/professional version of FSX. However, much of that has been substantially revised for Preare3D version 4, which is a 64-bit program too. Note that for more general and thorough advice you'll be better off askng such questions in a more general flight sim community Forum. Here it is really only support for a very specific, very FS oriented, set of products. Pete

FSUIPC uses the standard DirectX joystick input facilities to read the values. What it shows is exactly what is received. P3D uses the same methods UNLESS you select "raw mode" instead of "DirectInput" in the "Other" section. In its raw mode it bypasses DirectX and reads the USB stream directly. This is not the normal way. If the DirectInput method gives "wrong values" (whatever that means -- you really need to be more specifc) it will because that's what DirectInput provides, and that is affected by Registry settings. Those Registry settings, unless set properly by the installation procedure which takes place in Windows when it detects and recognises devices, are normally set by the Windows calibration, done by Game Controllers. You can get to that easily in P3D's "Calibration" section, clicking the "Calibrate Device" button. You go on to say: Now what do you mean by "correct values"? If you've assigned them in the Axis assignments (and NOT in P3D) then the IN values ill match the values you see in the axis assignments, which you say are "wrong" (whatever that means). They ARE the same values! So you are not making sense there. As for Rudder. How have you assigned that? I think you need to start afresh. delete (or rename) your FSUIPC5.INI file (in the Modules folder) so that when P3D starts a new default on is produced. Then decide where you are going to assign devices -- P3D or FSUIPC. Do not use both for assignment, you MUST choose one or the other. The calibration in FSUIPC is separate from this. FSUIPC calibration can be used for axes assigned in either place. For the possible Registry mess the best thing to do would be to unplug your joystick device(s), use Windows Device Manager to uninstall them software/driver as well, then re-boot, plugging them back in for fresh recognition. That should re-write the Registry entries for them. Pete

Support for the offset mapping for the PMDG 737NGXu data has been added in the interim FSUIPC update FSUIPC 5.152e, now available (as 5.152e3) in the Download Links subforum. The offsets are mapped to the same offsets as the PMDG NGX, so should be compatible with existing hardware using these. Pete

Hi Roman, Please see the PM I've just sent. Pete

As well as what Thomas says, calibration in FSUIPC matches ANY input range (whether limited or not) to the full range acceptable to P3D. So you can calibrate in FSUIPC. But the calibration in Game Controllers should be done first because that will ensure you have the best precision with the incoming readings. Game Controllers calibration is stored in the Windows Registry and limits what FSUIPC can read. Pete

No, you can install it into P3D4. You will get full FSUIPC application support and full documrentation installed. If you want any of the User facilities, then, yes, of course you must purchase and register it. Pete

Sounds like they don't need much in the way of calibration. Pressing "RESET" just removes any existing calibration! To then calibrate you must press the SET button above the IN/OUT values on the left. Please do read the Chapter on Joystick Calibration in the User Guide! If you click the max button at any point with the IN value above that MIN of -16384 then the OUT will read 16383 when you've done. If your axes are inverted when you come to use them you need to press RESET again, then press SET again but check the REV button before proceeding to set MIN, CENTRE if applicable (twice to set a range for a little null zone to allow for slight variations) aand MAX. The User Guide does explain these things clearly. Pete

FSUIPC3 wnet on a long history of developments for FS2004 all the way up to version 3.999z9b im 2016 and no backward compatibility for FS2002 and before would have happened. it just wasn't worth it by a bout 5 years after FS2004 was released. You've really only got a chance if you can find someone with a much older version, probably pre-2004 or maybe 2006. The earliest I have is 3.957, from 2010, but that is still part of the 3.9 series and 7 years after FS2004 was released. Sorry, but I am certainly no longer in a position to support FS2002. In fact support for FSUIPC3 has pretty much ceased even for FS2004. We do keep supporting our products far longer than most, but there is a limit. Pete