John Dowson

Please try the attached (with Extras logging): FSUIPC7.exe Not had time to test but should be ok...will review tomorrow, Please attach log or confirm ok if you can test, Regards, John

Yes - this is the exact issue in that bug report I have referenced several times - here are the first few lines: As FSUIPC can be started when the AircraftLoaded system event has already past, it also uses the RequestSystemState call. However, you log does show an issue: The request done at 2nd bold timestamp 87578 should not really occur, but is happening as a flag is being set at timestamp 58110, but not being cleared at 1st bold timestamp 87578, so that request is unnecessary. I will correct this. That is because it cannot open the aircraft.cfg file as the path is relative, so it resets the offsets read from this file. Relative paths may be useful (and these may also get corrected at some point) so I will still add them if that is all that is available, but what I can do is add a check so that when a relative path is received, I can compare it (case-independent) to the end characters held in offset 0x3C00 and only update if they differ. This should preserve the full path when available, and only update to a partial path if that is all that is available. I have to take the dogs out now - will make these changes either later this evening or tomorrow and provide you with an updated version to test.

You could try the ATC TYPE offset 0x3160,

But there is no functional difference in that build - the only difference is that the AircraftLoaded events (both on specific request and via a sim state change) will be logged with the parameter received. There should be no difference in the values received and/or held in offsets. Note, as documented in that link, there is a difference in the value when specifically requested and when received from a sim state update. So I am confused now. Compare both versions with the exact same test (i.e. don't just exit one version of FSUIPC and start the other - exit MSFS and repeat the test). Then compare the values in the offsets - they should be exactly the same if the test was the same. The only difference should be in the log, where the log for the patched version will show the full values received from the AitcradtLoaded events, You can also attach both log files here.

I already did...complete description: C - indicates a compound condition R - indicates repeat while button pressed (+1,11) - this is the compound condition, and indicates that button 11 on device 1 must be pressed (+). This is true when the selection rotary is in the IAS/MACH position C66587 - is the standard ROTOR_BRAKE control 38408 - is the control parameter, where 384 is this custom control: #define EVT_MCP_SPEED_SELECTOR (THIRD_PARTY_EVENT_ID_MIN + 384) and 08 indicates a 'mouse wheel down' operation on the control, which is the speed selector and so will decrement the speed No problem. If you understand those assignments, it should make it easier for you to add your own when you need to... Regards, John

@kingm56 I have looked into this further, and there is an issue with offset 0x0640. That holds 6 *6 character idents, i.e. needs 36 bytes. However, offset 0x0658 is only 24 bytes away, so the full idents for airports 5 & 6 are overwriting 0x0658. The offset are for the full 6 character idents should start at 0x0630, not 0x0640, to prevent this. I have corrected this in the attached version. John FSUIPC7.exe

Delete those settings in bold and try these: Those use the rotor brake custom controls to control the IAS/HDG/ALT using the mouse-wheel down/up codes (on repeat) for inc/dec, (on buttons 15 & 14) with a compound conditional on the position of the selector switch (buttons 11, 12 & 13) Not sure why the previous assignments were for the Microsoft SideWinder Precision Pro....

Did you remove the custom controls being sent in ranges then? Ok, glad its working. Could you attach your working ini file here please.

In the ini you just posted in the other open topic you have, you have the flaps lever axis assigned to Flaps Set, AND are assigning to the custom controls in ranges - that will always be problematic. For now, please assign the axis to Unused, and just use the custom controls. Do you get the same issue? If so, try what I said above, i.e. assign to Flaps (direct) and calibrate with detents.

Ok, although that is strange - I would expect the EVT_CONTROL_STAND_FLAPS_LEVER and Axis Flaps Set controls to do something... You can also try assigning to Flaps Decr when entering the lower range, and Flaps Incr when entering the upper range (may be vica-versa). Does assigning the flaps lever directly to the Flaps control (Send direct to FSUIPC calibration), Flaps Set or Axis Flaps Set controls (both 'Send to FS as normal axis) work? If so, and your flaps lever has detents, then toy can use one of those and then set the detents as shown in the user guide (section CALIBRATING FLAPS WITH SPECIFIC DÉTENTES). It was reported that assigning to Flaps (direct) and calibrating with detents works fine for the PMDG737 in this post (although this is with FSUIPC6 and the Bravi, that should make no difference): It is certainly an issue with the controls, and not the thrustmaster, but this should certainly be possible... Seems like you had this issue before and got it working in September 2023: ? Why did you not report this in the same topic? Is this a new throttle quadrant - were the flaps previously working correctly (as it says in that post), and if so, how did you assign then?

@simnutzer1962 Did you manage to get the selection knob working yet in the PMDG 737? If not, if you attach your latest FSUIPC5.ini I can take a look. I don't have this aircraft for P3D, but I can look into setting this up in MSFS (on a different controller) then it should be possible to map this to P3D and your thrustmaster throttle quadrant.

The latest trial license, valid until 01/02/2025, is now available from the first post in this topic.

I did look at it. I didn't know "Path of Flight Simulator installation" == "InstalledPackegesPath". I meant look at the value in the offset, i.e. log its value. I will update the offset status document to make this clear. Cheers, John

As part of the process to find out what is causing this issue, you need to remove add-ons and add them back one at a time. But it is not possible for FSUIPC yo cause MSFS to CTD. FSUIPC is a separate application and only communicates with MSFS via the SimConnect API.; I have had hundreds of reports claiming that FSUIPC is causing MSFS to CTD, all false/incorrect. There are already quite a few similar reports on the Asobo forums, so you should check those out. For example: https://forums.flightsimulator.com/t/sim-still-crashes-ctd-when-changing-checking-control-options/653525 https://forums.flightsimulator.com/t/ctd-when-saving-control-profiles/679884 https://forums.flightsimulator.com/t/changing-control-presets-causes-ctd/678112 https://forums.flightsimulator.com/t/ctd-by-adding-controller-or-other-device/487164/3 If you find what is causing this issue, please update here - it may help others and save me some time.... John

Hi Luke, I don't have any aircraft that use the [VARIATION] section (with a relative path), so cannot really check this. As you have done this, maybe you could add this information to this bug report: https://devsupport.flightsimulator.com/t/simconnect-requestsystemstate-aircraftloaded-returns-partial-path-of-aircraft-cfg/9041/6 Better to not mention offsets or FSUIPC - just refer to this as the data returned from the AircraftLoaded event. You can use the attached version (and enable logging for Extras) which will log the actual parameter received. Or you can attach the log file here. John FSUIPC7.exe

How do you know that this was due to a WASM crash? And if you think that this is a WASM crash, you should attach your FSUIPC_WASM.log file, preferably generated with Debug logging enabled. There really isn't any point posting to complain about something if you are not going to back this up with information so that I can investigate. Have you disabled continual scanning for lvars, as this is the cause of the WASM crash as documented in the FAQ entry for this. If you have not read that entry, please do so now and disable lvar scanning. If you have already done that, then I need to see your FSUIPC_WASM.log file. And if you don't know where that is, consult the documentation.

Just checked this and I see the same in those offsets with 7.4.17 and 7.5.1: i.e. there is no change, I don't understand why the first airport at offset 0x0640 is EGLL though and not EGTF, the first airport at offset 0x0658 (the plane was in a runway at EGLL). Have you tried monitoring those offsets to see what has changed? Also check that you have the GetNearestAirports ini parameter set to Yes,

7.5.1 is 7.5.0.1 - I combine the last 2 digits for the text version (so 7.4.18 is 7.4.1.8) %USERPROFILE%\Document But what is the value of the Personal key under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders? That is what FSUIPC uses, and if that is not set correctly it will not install correctly.

Your log shows the flaps lever is sending the correct controls when you move it through its range: So FSUIPC is sending the controls as expected, but if it is not going into the 0 or 40 position, then it looks like those controls are not working as expected (although they are being sent and applied in the FS). I am not sure why. To test this, can you assign a spare button or key (or key combination) to the flaps 0 and flaps 40 custom controls (76773 and 76781) to see if they actually work. If not, then it should be reported to PMDG, You could also try assigning the flaps 0 and flaps 40 range positions to the EVT_CONTROL_STAND_FLAPS_LEVER custom control instead (70346). I am unsure of the parameter needed though - try either 0 or -16384 for flaps 0, and either 16383 or 32767 for flaps 40. And you could also try assigning the 0 and 40 ranges to the Axis Flaps Set control, with a parameter of -16384 for flaps 0 and +16383 for flaps 40.

You should consult the user manual for such basic information... The FSUIPC6.log file will be located in your FSUIPC6 installation folder. Did you try FSLabs support? As the issues started after an update to this aircraft, you should really be talking to them, not me. John

No. For MSFS CTDs, please use the Asobo forums - this is nothing to do with FSUIPC and I can't really help with this, sorry You could start here: https://forums.flightsimulator.com/t/how-to-troubleshoot-ctds-on-pc/591659 John

I only support the latest version of each product. 7.5.x is not just an update for MSFS2024 - it also contains changes for MSFS2020. You can continue to use 7.4.18 if you like, but it is unsupported and I will not look into anything reported with old versions. John

There have been no changes to FSUIPC in this area, but I will take a look when I get a chance - this may take a couple of days as I am quite busy,,. In the mean-time, could you try the attached version, 7.4.17, to see if they still function in this version, FSUIPC7.exe

You are using an old version of FSUIPC (7.4.18), Only the latest version, currently 7.5.1, is supported. Please update., John

No Pete retired over 5 years ago and no longer provides support. Sorry but I cannot understand this... I do not support SIOC, so cannot help with that. Is WideClient connecting to WideServer? From your logs, I suspect not. If WideClient is not connecting, please see the documentation and follow the 'Configure your Network' section in the User guide. Check your WorkGroup name is the same in both PCs, try with firewalls disabled (client, server and router)m and try adding the ServerName (or ServerIPAddr) and Protocol WideClinet ini parameters, See the documentation. I get hundreds of reports of wideclient connection issues after a windows update. All such issues are due to the update causing changes to the network configuration which you need to identify and correct. All issues that can cause such issues are documented, so please check the documentation, and maybe one of the many threads here from others who have the same issue.