John Dowson

I am not sure how the throttle works on this aircraft as I do not have it, but if there are issues when assigning direct to FSUIPC calibration, try switching to using 'Send to FS as normal axis' instead. Also check which throttle control you need to use - you can do this by activating Axis control logging and moving the throttle in the cockpit UI yo see what control is logged - maybe it is using the THROTTLE1 AXIS SET EX1 control, which I have seen with other users with this aircraft, so you could try that. There are also several presets available for the throttle on the Hawk: HT1_FWD_LEFT_ThrottleTransmit_Press HT1_FWD_LEFT_ThrottleTransmit_Release HT1_FWD_LEFT_ThrottleRelight_Press HT1_FWD_LEFT_ThrottleRelight_Release HT1_FWD_THROTTLE_Idle_Stop_Toggle I am not sure what these are supposed to do, but maybe they also need to be used? Maybe some other users of this aircraft can help? @Shorty01 has indicated that he has this aircraft configured with FSUIPC, and so may know how to assign the throttle with this aircraft... John

This indicates that, when selecting to install the "add-on.xml" component, there is an issue writing to your Documents\Prepar3D v5 Add-ons folder. The documents for FSUIPC6 should be installed under a Documents\FSUIPC6 - do you have them installed there? John

The log files you attached stop after 3 seconds... can you run MSFS with FSUIPC7, select an aircraft and get ready-to-fly, then check the WASM menu options. If they are not available, exit FSUIPC7 and then attach your FSUIPC7.log and FSUIPC7.ini files. Thanks, John

Where are you trying to install FSUIPC6? Check that you are not trying to install into a windows protected folder. Also, check your VC++ redistributables are up-to-date. If you get the same issue, try installing again without selecting the 'add-on.xml' component.

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