John Dowson

Really? You installed FSUIPC6 in your top-level LM folder? I would advise against that... Did you check your FSUIPC6.ini file? Please attach both your FSUIPC6.log and FSUIPC6.ini files and I will take a look. John

Please see the FSUIPC User Guide for the additional features provided by the payware version. The FSUIPC SDK applies to the free as well as the payware version. FSUIPC's Lua interface is only available in the payware version. As for MobiFlight, I'm not a MobiFlight user and so will leave to others to respond, or ask on the MobiFlight forums. If you are just using the MobiFlight WASM module, you should be able to use the MobiFlight added events via code as custom controls. But you cannot assign directly unless using the registered version/ John

First, you posted in the User Contributions sub-forum where it explicitly states NOT for support requests. I have moved your post for you, but please take care in future to post in the correct forum. Are you sure that is you FSUIPC installation folder? You can verify this by using the 'Open Folder' button in FSUIPC's Logging tab, which will open a windows explorer window on your FSUIPC installation folder. Try that and see if you can see your macro file in that folder. I suspect not! Also, when FSUIPC6 detects a macro file it will add it to the [MacroFiles] section of your FSUIPC6.ini file. Do you see anything there? If not, you will not be able to assign to it. Note that it does this automatically - do not manually edit that section. John

If you mean ProvideAIData=No, then that goes in the [General] section of your FSUIPC7.ini. Please see the Advanced User guide. John

The mouse macro should emulate the mouse click, so it is very strange that they give different results. And also weird that assigning to keys doesn't work, as that was reported as a possible solution in that thread on the PMDG forums. Sorry, but I'm out of ideas on this one. Maybe try posting on the PMDG forums to see if any one else has had this issue and has found a workaround. John

The latter. But if you can always do the other option - rename your linda.lua to linda.lua.unused (or whatever new name you want to give it). I just want to know that Linda isn't doing anything behind the scenes. Its probably not related to your issue, but always better to eliminate (at least temporarily) when investigating an issue. I'll look at your new log tomorrow.

I don't think this will make a difference. You can try it, but make sure MSFS is set to run as administrator. I didn't try this though, but should work...

Sure, I can also add that. Ok, but rather strange. I can do that before the offset is populated. Ok, I can look into that as well, but may take a few days. I'll do it for the 3 slot index offsets (altitude, heading and speed), but not the APU switch offset. John

Further info: both your second yoke and your wingman have been assigned the same joystick id (2), which is why you have issues. Also, as both your yokes have the same product and vendor ids, they can get confused if you disconnect and re-connect. But, once set-up it should be ok if you leave them connected. Your assignments are slightly confused due to this and will need modifying. You have assignments to a device with id 3 that doesn't exist - do you know which device you made these assignments to: Once I've seen your updated files with the joyletters assigned. I can change these to the correct device if you let me know which that is! From you Joyscan.csv file, it should be the wingman. If thats the case, you could also try changing this line in your ini: 2.GUID={4D285480-3B07-11EA-800D-444553540000} to 3.GUID={4D285480-3B07-11EA-800D-444553540000} at the same time as you make the AutoAssignLetters update, then restart FSX, try your yoke and post the update files if still not recognised. If you do that, you may need to revise your current assignments to device 2: If they are to the Wingman, they will also need to be changed to 3. Otherwise they will be assigned to your 2nd yoke, which should be recognised (with the above changes) as device 2. If in doubt, remove them and re-assign. John

Looks like the yoke is being assigned the same joystick id as your Wingman for some reason. Can you do the following please: change AutoAssignLetters=No to AutoAssignLetters=Yes in your FSUIPC4.ini, start FSX, close it, then attach you new FSUIPC4.log and FSUIPC4.ini files. John

This should be the one that works, with both flightsimulator.exe set and FSUIPC7.exe set to run as admin. I don't know why you get a CTD with this config. Maybe try that again? If it crashes again, check for a crash event in the windows event viewer. You can post that here but I'm not sure I can do much with it... John

Sounds strange. Did you try sending the control on the release only? Then this seems correct - only one control being sent. If that is incrementing by 5 rather than 1, I think you need to ask PMDG why... What is logged when you increment by 1 with the mouse? Have you trued using a mouse macro for this instead? And lookin art the PMDG website, someone also posted the issue there: https://forum.pmdg.com/forum/main-forum/pmdg-737-ngxu-for-prepar3d-v4/57103-mcp-heading-selector-event-evt_mcp_heading_selector-event-70022-jumping-in-steps-of-value-of-5 The proposed solution is to assign keys for this in the PMDG setup, and then assign to those keys in FSUIPC. Maybe try that? John

As with all CTDs, they should be reported to Asobo with the relevant crash logs, not here. John

But why do you think that? Its the same issue for both systems. No point in investigating both, if you solve it in one then you will have solved it in the other....

He means the date on the www.fsuipc.com web page - which still says July 20th 2020. I will update that shortly. Not sure where he's getting the 5.0.5.1 version number from though! John

Just had a look at this in more detail. TrackIR is not set to run in administrator mode, but it requests this when ran, so it does run in administrator mode. You therefore need to set FSUIPC7 to run in administrator mode if starting trackIR from FSUIPC7. Then, as MSFS stars FSUIPC7 from the EXE.xml, you need to run MSFS in administrator mode for it to be able to launch FSUIPC7, which will then be able to launch trackIR. I did this by setting this option on my FlightSimulator.exe file. After doing that, all start ok. Alternatively, you can remove the start-up of FSUIPC7 from the EXE.xml, and re-enable the start of FSUIPC7 from the MSFS.bat file.To do this, change to and replace INSTDIR with the full path to the FSUIPC7.exe John

I wonder how this happened. Currently, uninstalling removes the entry, and installing ALWAYS adds the entry, but does not check for existing entries. When I get time, I'll update the installer to check for an existing FSUIPC7 entry first, before adding the new entry. This should prevent mutile entries occuring. Yes, that's fine. But note that you can also use either the FSUIPC ini file ([Programs] section) or the MSFS EXE.xml file to also start other programs.

Is trackIR set to run with admin privileges then? If so, try turning that off and running everything as non-admin. John

Can you try the attached version, v7.0.4b, where I have added the following offsets: 0x0290 4Bytes AUTOPILOT ALTITUDE SLOT INDEX 0x0294 4Bytes AUTOPILOT HEADING SLOT INDEX 0x0298 1 Byte APU SWITCH Thanks, John FSUIPC7.exe

Hi Stephane, someone else has also reported something similar here: I have found a sim variable APU SWITCH (read-only), that may be useful to you. Its available in the version posted in that topic. John

Can you try the attached version, v7.0.4b, where I have added the following offsets: 0x0290 4Bytes AUTOPILOT ALTITUDE SLOT INDEX 0x0294 4Bytes AUTOPILOT HEADING SLOT INDEX 0x0298 1 Byte APU SWITCH Thanks, John FSUIPC7.exe P.S. The offsets are read-only. I could make the slot index ones writeable by using the associated controls when written to if needed.

The SDK also lists the following sim variable: APU SWITCH Boolean, whether or not the APU is switched on. UNITS_BOOL However, this is not documented as being exposed vi SimConnect. I will try adding it anyway, to see if it is recognised, and will let you know. If not, I can raise a zendesk issue to get this exposed via SimConnect. John

If you keep the console open, you will see the entries logged (or not!) when you use the mouse. Doo you see anything doing this? Ok, but why not just disable controllers in P3D then? This will prevent them from being automatically re-assigned by P3D, which can happen. It can go in the [General] section or in a a [Profile.xxxx] section. You want it in the latter, i.e. add this to your [Profile.B738U] section (and maybe your other PMDG profile sections): DontLogThese=66587 Yes, as this is used internally by your PMDG aircraft. Also, please don't start a new log file - I need to see the complete log file. You have also assigned to send the control on both press and release: 242=P257,17,C70022,-2147483648 -{Custom control: <70022>}- 243=U257,17,C70022,-2147483648 -{Custom control: <70022>}- So this will send to controls (one on press, one on release), so maybe remove one of those - this will half the change rate. Your last log is also quite strange, as it shows several button presses per second: If you press this button once, do you see multiple press entries in your log? What is your 257 device (some type of VRI device?)? Is that sending repeated button press/releases when 'on'? John P.S. Please keep your console open when testing, so you can see what is logged on each individual button press/release. Other than that, your assignments look fine according to the header file.

Just rename your linda.lua script, or, better, remove the call to that script from your ipcReady.lua script. There is no FSUIPC7 log file included, only you installation log which is not relevant. Please disable Linda, activate the logging requested (event and button & keys) then produce a short log where you press one of you assigned buttons (i.e. not keys - we'll check your issue for buttons first) Could you update to FSUIPC6 v6.0.12 first though please - this was released yesterday. Your ini file also shows that you are not using the JoyLetters facility. This means that you joystick IDs could have changed, which would invalidate your assignments. You should activate the JoyLetters facility by setting the AutoAssignLetters ini parameter (in the [JoyNames] section) to Yes. You also have one assignment to a non-existent device (with id=0) that you can delete: 0=0X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- Maybe also check your FSUIPC6.ini to see if you can determine if your assignments (buttons and axes) are assigned to the correct devices (with 1=T.16000M, 2=TWCS Throttle, 3=Yoke).

Its obviously a permissions issue but I've no idea what is causing this, you need to play around. I have TrackIR as well, but I never run anything in admin mode.... I always start TrackIR manually (as I only use it occasionally and for tests), but I'll try starting in via both FSUIPC and the MSFS EXE.xml to see if there are any permission issues for me (but I doubt it!). You could also try running TrackIR from the EXE.xml, rather than from FSUIPC?