John Dowson

Ok, but I find this rather confusing as you previously posted some code (presumably from SIOC) that was trying to use the custom control numbers for presets. If you are using lua, why not just send these commands (either via presets or the Rotor Brake control) from the lua script? You can also add logging statements (using ipc.log) to check/test the performance, although I would not actually set Lua Plugins logging as this can slow things down even further. You can also use offset monitoring to see when offset A001 changes and get the timestamp of that, which could help see where the delay is coming from. Events and controls re the same thing... I think you mean preset (or calculator code), which will translate to the same event anyway - it will just go via the gauge execute_calculator_code function rather than via SimConnect. Yes. You can try that to see if the performance improves. You can also try moving the lua execution thread off of core 0/1 by setting an affinity mask - this may improve performance if the first cores re highly loaded. You can do this using the ini parameter LuaAffinityMask - see Ok.

If these reconnects are not causing any issues, it is nothing to worry about, just an observation from your log. Properly powered hubs are generally always better/more reliable than unpowered hubs, but it really depends on the devices you are using. If the disconnect/reconnect messages are just due to the iPad losing its connection/reconnecting, then this is nothing to worry about anyway as FSUIPC does nothing with that - it is just re-acting to a windows 'new HID device connected' message. John

This is generally not necessary, also in FSX, but can depend on the aircraft. For aircraft that use an axes/trim wheel, it is always better to assign to offset 0x0BC0 as this gives better control over the increments/decrements. For aircraft that use up/down for trim (as opposed to a wheel) or a switch with discrete positions, then bettor to assign to the inc/dec controls/events. There is no need to assign to the (default) key presses for this, unless the events aren't working via external applications (which can happen for some events/aircraft). For some aircraft in MSFS2020/2024, the standard controls don't work (neither the axes or inc/dec controls) and you need to use lvars/hvars/bvars/Input Events or calc code/presets, e.g. for the Cows DA42 you would need to use the lvar L:INPUT_TRIM_AXIS, or the MF preset 'Elevator Trim DN' (which uses that lvar). John

Yes - I should really load the myevents.txt file first and start the numbering from there. But, as I say, using the numbers is not recommended as these can change. The presets you saw in the log are the ones NOT loaded (and hence not available) due to some sort of errors. Loaded presets are NOT logged anywhere (there are usually far too many for this!). If you set WAPI Debug level logging (Log->WAPI->Debug), this will log the calculator code from a preset when it is sent the the WASM to be applied to the aircraft. Lua does seem to run rather slower in MSFS 2020/2024 than in other flight simulators (there are already several support topics on this), but it should not be that slow. They are a lot faster if they are already running and re-act to events, rather than being started on a button/key press (as they need to be compiled each time before being ran if/when assigned to run on a button or key press). Lua scripts may also run faster when FSUIPC is manually started, rather than being auto-started by the FS (although YMMV). Sorry but I can't really help much if using SIOC as I have never used this. Does FSUIPC not see your buttons? If so, you can try assigning directly in FSUIPC rather than assigning in SIOC.

Double check this and maybe also try running with standard privileges to see if that helps. As I said, the main reason for 3rd-party connection issues IS the privilege level. Nothing related to your issue. You do have a lot of USB device reconnection messages, which are strange, This could indicate either a USB power or connection issue unless you are disconnecting and reconnecting your Yawman Arrow. John

I've checked this here now and offset 0x0BC0 seems to work fine to control the elevator trim in both the C172 and JF Turbo Arrow III, I found your fast settings too low though, so changed the fast delta from 96 to 128 and also added fast assignments to the button release as well as the press. At one point I did noticed the trim starting to behave abnormally (wouldn't go below 0), but this rectified itself and I haven't been able to reproduce this since. So, please show me your ini & log files with the appropriate logging (mentioned above) activated. Also please add logging for offset 0BC0 (as S16). You an also use the version attached below which has some additional (temporary) logging added around offset 0BC) changes. John FSUIPC7.exe P.S. Once change from 7.5.1 to 7.5.2 that could cause this issue for you is the following: i.e. the ELEVATOR_TRIM_SET axes is now calibrated from 7.5.2 onwards, So, check your elevator trim calibration (on page 6 of the calibration pages) and remove/reset if you have this calibrated.

Your elevator trim assignments are the same for all aircraft: And I can't see how this can be related to the FSUIPC version, as you say: i.e. you see the same behavior when assigned in MSFS, no? Can you check that you do not have the trim buttons assigned in MSFS as well as in FSUIPC - they should be assigned in only one place. Can you set logging for Buttons & Keys and Events, and show me / attach your FSUIPC7.log file showing this issue, as well as attaching your full FSUIPC7.ini file and I will take a look. I will check the elevator trim here in the default 172 and in the JF Turbo Arrow (I don't have the Comanche). John

Your log file shows that you are using the events.txt file, as you have 18994 presets loaded: The control numbers for the presets in your myevents.txt file will certainly not start at 4194304 (which will be the number for the first preset in the events.txt file). If you want to use control numbers for the presets in the myevents.txt file, you should not use (i.e. delete and do nor install when you re-install). However, it is far better to use the preset name to send a preset, as I suggested, or just use the Rotor Brake control (with the appropriate parameter). You cannot see the presets being logged as you have disabled logging in the WAPI. To see the preset/calc code being sent, you need to set Debug level logging in the WAPI. The myOffsets.tct and myevents.txt are completely different.

The value will be different. You need to check the PMDG header file for the aircraft (PMDG_747QOTSII_SDK.h) to see what values to use. Otherwise, the technique for using custom controls is the same. See and also, to use custom controls via the Rotor Brake control, see John

Then why not contact support for the PIREP application? The ecceptions/errors you posted are from that application, not FSUIPC - that doesn't mean anything top me. It does look like this program has an issue connecting to FSUIPC, but it should handle that gracefully an not crash. This is an issue for the app developers, not FSUIPC. Note that the usual reasons for a third-party FSUIPC not being able to connect are: - the application is being ran at a different privilege level to FSUIPC. FSUIPC and all connecting programs must be ran at the same level. - firewall or antivurus software blocking the connection - not having an aircraft loaded and ready-to-fly You can post / attach your FSUIPC6.log file here if you like and I can check that for errors, but you should really contact the support of the app developers. John

Sorry, but I can't help if assigning in SIOC - I have never used and know very little about this. But you should be able to use FSUIPC's logging facilities to work out what is happening. Why do you think it is doing this? What does your log file show? You should see a line indicating the number of presets loaded, e.g. Can you show me / attach your FSUI{C7.log file. There can be many reasons why a preset is not working, you need to narrow it down why (is the preset actually being sent on the button press/release? Is it being received in the WASM? Is the WASM even installed? etc). Yes - that is the only location where this file is read from. Not sure what this means, but using the presets/calculator code is exactly the same as using the Rotor Brake control directly, and if you are having issues with those then you will have the same issues when using the presets.

@kaha In MSFS2024, the SU2 release contained two new simvars that may be useful in determining the type of the user aircraft: Unfortunately these are only available in MSFS2024 though and not in MSFS2020.

Rather than using presets, you can just use the Rotor Brake control directly, e.g. var 0171, name E_SPD, Link IOCARD_ENCODER, Input 0, Aceleration 2, Type 2 { IF &E_SPD = 1 { &FS_PAR = 38407 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_SPD = -1 { &FS_PAR = 38408 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } } } i.e. use control number 66587, for the Rotor Brake control, with the parameter (38407, 38408, etc) indicating the actual custom control to be used. John

From your log file, it looks like the Rotaries.lua is not starting as it can no longer be found: As that script is not running, it will not be converting the button presses to the virtual ones needed to trigger the assignments. Check that that file exists/put it back. But turning that 'wheel' just triggers a different button press in each direction, which is why it is assigned under FSUIPC's button assignment dialog box. All joysticks are just a collection of buttons and axes as far as FSUIPC is concerned. That is strange - I am surprised its working there if the lua script is not running.... Also I am not sure why you have these profile-specific button assignments for the A2A Comanche when they are exactly the same as the general assignments: You can just remove them and use the (same) general assignments for those buttons. John

Why are you creating your own presets rather than using the one provided (by MobiFlight), e.g.: PMDG_B737_MCP_HDG_DEC#39008 (>K:ROTOR_BRAKE) PMDG_B737_MCP_HDG_INC#39007 (>K:ROTOR_BRAKE) PMDG_B737_MCP_IAS_MACH_DEC#38408 (>K:ROTOR_BRAKE) PMDG_B737_MCP_IAS_MACH_INC#38407 (>K:ROTOR_BRAKE) I am not sure what that code is (is it from SIOB?), but it looks like that will be (eventually) using offset 0x3110 to send the preset control using a control number. Control numbers for presets are difficult to calculate and you shouldn't use them really. To send a preset via an offset, use the preset name and offset 0x7C50. Otherwise, check that you are using the correct control number. You can use FSUIPC's logging facilities to see what is being sent. Do you have the events.txt file installed? If so, control numbers 4194304 and 4194305 will trigger the 1st and 2nd preset in the events.txt file (not in the myevents.txt file). You should use the preset name via offset 0x7C50, not the control numbers which can change, It is the aircraft developers (PMDG in this case) that have re-purposed the Rotor Brake event to implement custom controls. This is done by several aircraft developers that re-use the Rotor Brake control. It is deprecated but can still be used - and must be used for the custom controls to work, not K:ROTOR_BRAKE_ON . This FAQ entry shows how to to use the PMDG custom controls via the Rotor Brake control: Yes - use logging to see what is being sent. If using presets, set Debug level logging in the WAPI to see the calculator code/preset being used. John

Your log file shows a few issues: - there are several reconnection attempts at start-up, as your DetectToConnectDelayAuto ini parameter is set to low. Change the value of that ini parameter from 50 to 110. - the lvars are not being received from the WASM for some reason. I do not know why this is at the moment and would need to see your FSUIPC_WASM.log file, generated with Debug level logging set in the WASM (FSUIPC_WASM.ini). See the Advanced user guide on where to find these files. You can also try adding Init3308=13 to the [Genera;] section of your FSUIPC7.ini file. This will pre-populate offset 0x3308 with the version number for MSFS2020 (13) which is needed by some add-ons. Note that FSUIPC7 must also be ran at the same privilege level as any 3rd party add-ons that use it, so check they are running at the same privilege level. Also please exit FSUIPC7 before attaching files. The log file you attached shows FSUIPC7 was still running. This issue is continually getting reported. See and John

If a particular button isn't working, please set logging for Buttons & Keys and show me / attach a log file showing the button press not working, as well as your FSUIPC7.ini file.

You have installed under the Program Files folder: Please uninstall and re-install in a non-windows protected folder, e.g. C:\Prepar3D Add-ons\FSUIPC6. The lua files are not running as nothing is starting them. You need to start a lua script, either by assigning it to be started on a button or key press, or having it auto-started by using the [Auto] section. See the documentation on how to have lua files started automatically.

I don't know - what are you doing? You said: But you don't put the 'license info' anywhere. You save the FSUIPC7.key file (which you download from the 1st comment in this topic) to your FSUIPC7 installation folder and that is all.

I have noticed that there is a bug report for MSFS2024 that stops multiple K and B events from being processed correctly when using the 'execute calculator code' function. Maybe this also effects setting multiple lvars? This will be fixed in the SU3 beta 1.5.4.0 version - see https://devsupport.flightsimulator.com/t/unable-to-post-multiple-k-events-in-one-go/12621/10. John

What license info? Have you purchased a license, or are you using the trial license? This topic is for the trial license, and (as it says) the trial license is not validated by the installer. If you have purchased a license and it doesn't validate, see the README.txt and/or the Registration and Installation manual, section Invalid Key Problems. The usual reason for a license not validating is that the required VC++ redistibutables are not installed and need to be installed. John

Did you follow the instructions in the la script when assigning to these? Maybe it is @Glen McMillen? Last time he posted was in 2007 so I don't know if he is still monitoring these forums - he should receive a message now I have tagged him and he may respond here. I cannot give out emails, sorry, but you could also try sending him a (personal/direct) message via these forums. John

Clear your browser cache or try a different browser. There is nothing wring with the website as far as I can tell - looks fine in both Chrome and Edge.

What has this got to do with FSUIPC? This is the forums for the support of FSUIPC and related products ONLY. For any issues with the flight sim (simmarket?), you need to raise a ticket with them (https://secure.simmarket.com/customerservice.php). John

You need to install the latest combined distributables, i.e. for 2015, 2017, 2019, and 2022, not necessarily the most recent. And please install both x86 and x64 versions. The only reason I know of for this error is due to the account being used being unable to be elevated to full admin rights, so please double check this. Also make sure that - you are not running the installer from within the zip file - it needs to be extracted first - your windows environment variables are set-up correctly, especially APPDIR and TMPDIR - you are not trying to install into a protected folder John