Pete Dowson

The logging feature you are referring to is a TRACE. Between execution of each statement in the script, the Lua interpreter calls external functions to gather the log data (result and line number principally) and sends it to the Log via the main FSUIPC thread. So between each statement there's effectively a change in thread executions with the interpreter held up until its thread is allowed to continue. So, like tracing things in a compiler development system, the tool is not meant to be used in normal circumstances, but only to debug a problem where the reason is difficult to determine by inspection and very specific logging (via ipc.log). Pete

Well I can reproduce your problem here. I could see what was going on but I didn't manage to figure out why it was going on. I'm still puzzling over that. However, I've implemented a work-around ( extra code) and I've got it working. Please re-download the ZIP which now contains version 5.061 dated today, the 14th January 2021. Pete

Yes, I use VS C++ in VS 2017 or VS 2019, according to project. But I don't think any updates to that are relevant. It's more likely something else I overlooked when doing the 32- to 64-bit conversion. Pete

Oh, blast. Yes, forgot to change that. So, in that case the problem you have is NOT the one I fixed, but only related to trying to set a keystroke. I'll have another look tomorrow. A bit drastic, especially as it isn't P3D5 if it affects MSFS too. Apologies for not testing sufficiently today. I'll be on it tomorrow. Pete

Still same typo? Did you mean PFC? No, the date is 13th January 2021 and version is 6.06. I think you must have downloaded a cached version of the old file. Please clear your cache first. I think it's by F5 or something like that. It's the same for MSFS as it is for PdD4 or 5. The change was 32- to 64- bit. Pete

Please try version 5.0.6, now in the PFCDLL.ZIP file in Download Links and on FSUIPC.com. I fixed a serious problem with all of the button assignments pages. They were attempting to use the older 32-bit events list in FSUIPC. I've fixed this so that now they use the proper 64-bit version of that list. I'm still not sure what exactly you get as a result, but here any attempt to make any changes on those pages causes P3d to crash. This would have been the case ever since the 64 bit version was released for P3D4.0 back in 2017 (?). I would have thought it cause P3D to crash for you too. Please confirm that this does also fix your problem. Pete

But did you not look? There are offsets for the values and, separately the mode switches/buttons. Here: 07BC Autopilot Master switch 07C0 Autopilot wing leveller 07C4 Autopilot NAV1 lock 07C8 Autopilot heading lock 07D0 Autopilot altitude lock 07D8 Autopilot attitude hold 07DC Autopilot airspeed hold 07E4 Autopilot mach hold 07EC Autopilot vertical speed hold 07F4 Autopilot RPM (N1) hold 07FC Autopilot GlideSlope hold 0800 Autopilot Approach hold. 0804 Autopilot Back course hold. Pete

Me too. (What is PCF?) Have you no idea what change happened mid last week? That might be key to understanding the problem. Anyway, you appear to be saying that the problem in PFCcom64 is one you've not encountered before because you never tried to use the Key press assignments facility before. Is that right? I'll try it later today anyway. Pete

MSFS isn't relevant. the only change for that was to let FSUIPC7 load it. Test in P3D for now. So, considering you are 100% sure it worked before, for 5 years, why are you not using your existing settings? Are you starting again? Seems odd that you are re-cnifuring. Do you have your working settings to compare with your revised attempts? Pete

In that case it is a problem in your specific settings or Lua plug-ins (if you use them). The LOG shows it fails while checking your attached joystick devices. I think you have a device or driver which is hanging during FSUIPC's scanning, which it does to allow you to assign buttons and axes. Try: 1. Running HIDSCANNER -- see and show me the resulting HIDscanner log file. 2. Try with all devices disconnected BEFORE next re-booting the PC. Pete

Can you describe exactly what you are doing to assign this keystroke? And what the result looks like? Possibly, it doesn't support the "DEL" key, so test with a normal graphic character (A-Z pr 0-9) please. When you say it used to work till 'recently', is that with the DEL key or others? Do you have example assignments which used to work and don't now? With no relevant changes in the DLL for the last 3 yrs it is difficult to work out why it has suddenly stopped working for you. I do still have some serial port PFC hardware, but I won't be able to try things till late tomorrow at the earliest. Pete

Just thought. This may also requite MSFS be run in admin mode. Not sure -- it might depend on how it tries to load FSUIPC.

The FSX.EXE program file in your "c:\games\microsoft flight simulator x - steam edition\" folder says it is version 1.0.0.0. This must be wrong. Have you put some sort of dummy EXE in that folder? The very first version of FSX was 10.0.60905.0, and FSX-SE was 10.0.60905.0. Check the FSX.EXE file. Right-click and select Properties. Pete

Error 740 can only occur when the program being loaded needs elevation and the program loading it doesn't have it. So there must be a problem in your setting of 7.0.4 to run in "admin mode". Set that in the FSUIPC7.EXE Properties-Compatibility. Note that the 7.0.4 installer sets MSFS to load FSUIPC7 automatically, rather than via the Batch file. Pete

You have a serial port Cirrus II? I thought they were all HID devices! Before what? What have you changed? That'll be the clue to working out what happened. PFCcom64 hasn't been changed for a while now -- not since 2017 except for changes last year to allow FSUIPC7 to load it too. Pete

I need to see the Installation log file. Pete

Does it continue okay if you allow it to run (ie select Yes in the above question)? If not, try a couple more times. If no luck, we will need more information: 1 The version of Windows. (Note that FSUIPC4 is not supported on any version of Windows before Windows 7, and will probably not work on such versions in any case). 2 The log (FSUIPC4.LOG) from the FSX modules folder 3 The windows crash details for FSX, from the Windows Event Viewer. Pete

Did you miss the above in my previous reply? If this is from an assignment in FSUIPC, and the axis is not assigned in the P3D, then this surely indicates a bad registry entry for that device. Please re-read my previous reply! You response gave no further usseful information at all. Pete

The INPUT value defined is definitely a direct copy of what is being received -- either directly from your Axis assignment when assigned "direct to calibration", or from the Sim otherwise. There is no way FSUIPC's calibration can change that unless it is affecting what does to the Sim and it is the Sim value you are using. So without knowing anything about how you assigning nor to which controls I can't really advise. As usual you do need to supply information -- maybe in this case your FSUIPC5.INI file. But you refer to a particular add-on aircraft. Please always test your controls first on a default aircraft in case the add-on is doing its own odd things. The other consideration if the whole range of your axis is not being used is a bad install of your control device. The entries in the Registry may be wrong. It has happened quite frequently with Saitek devices (as an example) that the registry data for the device is limiting the range to only half that available, or even treating the analogue axis as a digital on/off input. If the latter is a factor, first try calibrating in Windows. If the problem persists then a complete uninstall of the device via Windows device manager (including any drivers), followed by a re-boot so the device gets re-installed afresh, may work. Pete

Neither of those are AGL values, but ground altitudes. Please do refer to the provided offsets list for details of what they contain. Your 12719 is 12719/256 = 49.68 metres. The 0B4C offset is just metres with no fractional part. So at least you are getting consistent results. Try flyng over some hills, or the ocean, and see those values change! For AGL (which means "ABOVE ground level" you need to read your own altitude and do a subtraction. Pete

What language are you using to manipulate offset data? If you've not started on your program yet, it would probably be best to use a .Net language and Paul Henty's .Net DLL -- please see the dedicated subforum above. If you are a C or C++ programmer then you should be able to work with the documentation and examples in the FSUIPC SDK. Other lanugages, like Python, are also supported in that SDK. Pete

The Sismo aft overhead I have is an Ethernet device and needs a driver. I use ProsimB738, which comes with a built-in Sismo driver. But I'm sure Sismo provide drivers. Whether they require FSUIPC or not I'm afraid I don't know. You need to ask them. Pete

That is definitely a Windows problem. It should never be possible to have two objects or devices with the same GUID. That's the point of GUIDs -- to be guaranteed unique! Roman's idea is good. Otherwise, if there's only one you are ever unplugging then you may get away with swapping them over. But it's always been dodgy to unplug and re-plug devices with all versions of Windows. Best not to unplug devices at all, and certainly not when there are two or more identical ones. There are always better ways, like using Profiles, or just ensuring there are stable null zones so that an untouched lever doesn't interfere with another (buttons and switches won't in any case unless pressed or operated). Pete

So that lever is faulty, constantly sending button press/release notifications? Is Honeycomb going to fix that? And why are you assigning to a Key press (G) instead of the more efficient GEAR TOGGLE control? Or, better, GEAR UP / GEAR DOWN? Do these controls not yet work in MSFS? If you are referring to FSUIPC3 and FSUIPC4. I think what you refer to was actually a Sim code hack which will not be done in the 64-bit FSUIPC5/6 not can it be with FSUIPC7 being a separate process altogether. And "Fix control acceleration" wasn't a "flood" prevention -- there was never any such thing. If a button is continually signally a change FSUIPC must obey its assignments. The facility you refer to just changed the time value in the sim which was being used to determine whether to accelerate or not. And it operated on controls (events) not keypresses. I think the fix has to be in the Honeycomb device. Have they explained why they have it repeating like that? I can only assume it is a production bug. Pete

Nevertheless, it is still code being executed, ready to obey your commands. Pete