John Dowson

Of course - that is the whole point of this topic...and it is available/downloadable from the first post in this topic. John

These are known as Add-on Custom Events - see the Advanced User guide, page 38. To use them, create an event file in your FSUIPC7 installation folder, e.g. PilotEdge.evt, and add the following content: [Events] 0=PILOTEDGE.PTT_ON 1=PILOTEDGE.PTT_RELEASE then restart FSUIPC7, and you should see and be able to assign to those events as you would any other FS events. John

This will be corrected in the next release.

PMDG specific offsets are always (and will always be) read-only. To control, you need to use the provided Rotor Brake controls or presets. You can send these using the facility to send any control at offset 0x3110, or if using presets then offset 0x7C50 may be easier to use, as you can use the preset name directly rather than havung to calculate the control number. John

Are you sure that the drift is due to your controller, and not for other reasons (e.g. wind, trim, etc)? You can ret activating logging for axis controls and maybe also events. If you then fly with the logging console open (Log->Open console) you will see what controls are being sent to the sim. Are you using FSUIPC for your assignments, and if so do you have controllers disabled in P3Dv5? Also, your title suggests that you are using FSUIPC7 with P3Dv5. FSUIPC7 is for MSFS2020 only, it is FSUIPC6 that is compatible with P3Dv5. John

Ok. Also check that you have controllers disabled in P3D. John

No, you should only need to enable WideFS just the once. This setting should then be saved to your FSUIPC7.in. However, I have just checked this and it does seem that this setting can sometimes get reverted. Noy sure why this is happening all of a sudden - #i will check this and get back to you. John

You have plenty of button assignments in your ini file, so I don't understand this. Can you add your offset assignments again, and once you have assigned them and pressed 'Ok' to close the assignment panel, take a look at your ini file to see if they are there. Also check that you haven't installed FSUIPC7 into a windows protected folder, such as under Documents or Program Files. Once you have your assignment in your ini file, generate a log showing your issue, with logging for Buttons & Keys activated as well as Events, and show me your FSUIPC7.log file as well as your updated FSUIPC7.ini file. John

Can you go back to your original assignments (i.e. Trim Up/Down), set logging for Buttons & Keys as well as events (non-axis controls) and produce a log file showing your issue. Also, maybe try controlling the trim from the cockpit UI (if possible) to see what happens and what is logged then. Attach your FSUIPC .log and .ini files and I will take a look. John

Note you can also log IPC Reads and Writes using FSUIPCs logging functionality. This will log all offsets read/written-to by external programs (IPC = Inter Process Communication). However, the log may be large and difficult to understand when using these options, but you can give it a try... Of course, as this is a facility in FSUIPC, you would need FSUIPC (and also the FS) running. John

I will check the updates on my windows 10 system the next time I fire it up, but I am pretty sure that is on the latest updates as of a few days ago, and I have not experienced any issues. And if there was an issue with the latest updates, I would have expected this to be reported by many other users... You should always use the latest FSUIPC version for your FS - only the latest release is supported. John

Those offset that you are using are in the offset area 6200 - 62FF which I have documented as: 6200-62FF = PMDG projects (Lefteris Kalamaras) fixed [PT1] So those offsets were allocated to a PMDG project many years ago, but they are NOT the official PMDG offsets that we populate - those are in offset areas 0x6420 (512 bytes) and 0x6C00 (256 bytes). See the FSX document Offset Mapping for PMDG 737NGX.pdf for a description of those offsets for FSX. For MSFS, those offsets have changed and are now documented in Offset Mapping for PMDG 737-700.pdf, which is available in the latest FSUIPC7 beta where the PMDG offsets are enabled and working. There is no secret, big or otherwise. The offsets were allocated, but we have no idea what they contain, They must be populated from some software by Lefteris Kalamaras, so you must be using some other software with FSX that is populating those offsets. You need to determine what those offsets contain and have two choices: 1. See if the software that populates those offsets is working with MSFS, and if so use that 2. See what those offsets contain/were used for in FSX, and try to determine if there are corresponding offsets in the PMDG data area that you can use instead, and update your SIOC code to use the new offsets. Lefteris Kalamaras is the owner/founder of FSLabs, although he previously worked with PMDG. I could possibly contact him about this offset area allocation, to find out what this data is and what populates/uses it. John

Well, I think WideClient accepts client connections without the FS running, so I guess you can debug, but no offset date would be available if the FS isn't running, so you would probably just get 0/null values. If you just want to know what data an offset contains, why don't you just run FSUIPC and use the offset logging facilities? But you (obviously?) need the FS running if you want to read the value of a simvar held in an FDUIPC offset.... John

This is very strange... If FSUIPC doesn't start manually, it is usually due to the correct VC++ redistributables not being installed. However, if it was previously working then those should be ok. Does a log file get created? If so, please show me that (although I suspect not...). Did you try rebooting your system? Check the windows event viewer to see if anything has been logged there. Also maybe try starting FSUIPC7 from a command prompt, and see if you get any errors starting this way. Something must have changed on your system, you need to find out what... That is needed for Windows 11 only.

No point installing it if you don't need it...and (almost) certainly not on the same PC as the FSs. Ok, so if its a registered version and they aren't showing in the log, then they aren't HID joystick type devices - that is what FSUIPC recognises. Ok, so the flaps are assigned in ProSim, and they work fine except when you connect your Sismo hardware. Strange - I would ask both ProSim and Sismo about this. As FSUIPC isn't involved, I don't think I can help with this... I was just suggesting that you try FSUIPC's control/event logging, but I don't think this will help. I suspect it will just show the flaps control logged when working, and not when not working, which isn't going to help much!

Are you using a registered or unregistered version of FSUIPC? If unregistered, your devices won't be scanned or listed. Sorry, should have mentioned that... However, I was suggesting logging to see if there is any difference in the flaps events logged, not for the device ids. As you aren't using FSUIPC for assignments, it won't have anything to do with your issue, but logging may help identify what is happening (or maybe not!). What FS are you using? Do you have assignments in the FS, or do you have controllers disabled in the FS (P3D/FSX) or for MSFS2020, are using an empty assignment profile? I think you probably need support from Sismo for this issue.

The assigned Joystick Ids shouldn't change (as they should be fixed by the registry), but you can check this by looking at your FSUIPC log file that will shown the joystick ids assigned to your devices. You can check this file to see if the same ids are assigned with and without your Sismo hardware. FSUIPC has a feature called joyletters that allows you to assign to a fixed letter for your devices, which prevents issues when joystick ids do change, but this isn't relevant if not assigning in FSUIPC.

I don't know - do you have your assignments in FSUIPC or ProSim? You could try using FSUIPC's logging features to see if you can spot what is different in the logs when you connect the sismo modules. Or, as the problem only occurs with the sismo modules running, maybe ask on the sismo support forums about this. I have no knowledge or experience with Sismo, sorry. Maybe some other Sismo users can assist... John

Why is this a problem? If you have used this program for the PMDG 737 with FSX or P3D with FSUIPC4/5 or 6. then you should be able to update it to work with FSUIPC7 / MSFS. The specific PMDG offsets have always been read-only. The change with the PMDG 737 from the FSX/P3D versions is switching from using distinct custom controls to using the Rotor Brake control to implement custom controls. John

No. WideClient requires a connection to FSUIPC, which is only running when the FS/P3D is running. John

Really - where? Controlling anything other than pushback? Most of the ground services functions can only be controlled through the menu system or via ATC. But what service were you looking for? For which aircraft? Such things in MSFS are controlled in a very different manner from other FSs and can be very aircraft dependent. Pushback controls were previously reported as working - see For other services, if you see an MSFS control that can be used (that is not available in FSUIPC7), then you can assign a keypress to that control in MSFS, and then use that keypress in FSUIPC/lua. MSFS currently doesn't provide an API to control the ground services, apart from the standard aircraft pushback controls (which work with mixed results). Also no SODE for MSFS for these reasons. John

This sounds like you have installed FSUIPC7 into a windows-protected folder, such as under Documents or Program Files. If that is the case, re-run the installer and select a different non windows-protected installation folder. Did you have an aircraft loaded and ready-to-fly? The WideServer interface is only started once ready-to-fly. However, when FSUIPC7 is started with MSFS (or while MSFS is loading), it receives many different events, some indicating 'ready-to-fly', and so the WideServer interface is started prematurely (i.e. when MSFS is still loading or in the menu system). This is not an issue (and something I can't do anything about),it is on;y a problem if the WideServer interface isn't running once you have an aircraft loaded and ready-to-fly. So, if you start FSUIPC7 when MSFS is already running and in the menu system, the WideServer interface may not be started, but will be enabled. The interface will start once you have an aircraft loaded and are ready-to-fly. For any further issues or questions, please attach your FSUIPC7.ini and FSUIPC7.log files (and maybe your InstallFSUIPC7.log file as well). John

Yes - the 'D' was a typo. There should also be a .log file in the same folder - if you cannot see it, change your Explorer settings to show the extensions of known file types. Your ini file shows that you only have one lua file: There is no master_caut.lua file - you have called it master_caut.lua.txt (as the file you attached in your last comment). So your issue is that you are using the wrong file type, most probably due to your Explorer settings - change those so that you can see the actual extension type. John

Hi @Solito I have just been looking at this, and get the same as you - error 740 when trying to start TrackIR5 from the windows. However, I can start it ok when using the following: i.e. When running using a command shell. However, when doing this, TrackIR5 will not exit with FSUIPC/MSFS, even if you use the CLOSE or KILL options, as these affect the command shell and not the TrackIR5 instance. I have also investigated this before - please see John

What is there to respond to? I thought it was now working for you and the issue was that you did not enable the WAPI, which you have now done. When you first enable, you may need to disconnect and reconnect FSUIPC7 from MSFS (or restart FSUIPC7 which has the same affect). If you are still having issues, please show me your FSUIPC7.log and FSUIPC7.ino files again.