John Dowson

Ok, thanks for the update. And thanks for the kind words. Also, please note that these forums are now closed for new support requests, and will be removed at the end of the year. For any further issues, support id available on the FSUIPC website (fsuipc.com). Please see Regards, John

First, please not that these forums are soon closing and will be unavailable by the end of the year. Please use the new support forums - see This has been reported many, many times... As I tell everyone, for any and all installation and registration issues you should read the provided documentation before posting, namely the Installation and Registration guide. For all new installations, you will need to install the latest combined VC++ redistributables (for both x86 and x64) from Microsoft. Please see the documentation. If you had read this topic you would have also found the same advice, and also in one of the hundreds of others reporting this issue. I am closing this topic now, For any other issue, please use the new support forums. John

The usual value range for an axis is -16384 to +16383. The value range for the axis you are using (as show in the log is -16306 to 3000. So the minimum value (-16306) is ok, resulting in a max thrust (as your axis is reversed) of 88,76%. But the max value (3000) will only result in a minimum thrust value if around 41%. You can try two things: 1. Try calibrating your axis in windows game controllers to see if you can get the full range for the axis values. 2. If you cannot get the full range of values, just calibrate the script to the range of values your axis produces. So with a range of 16306 to 3000., in the lua script change: newValue = (16384 - value) / 327.6 to newValue = (3000 - value) / 193.06

Your log shows only one value being logged from your axis. I have no idea why your axis is not updating offset 66D0 when it is being moved. We need to determine why your axis is not writing its value to that offset. For the time being, can you stop that lua from running - just remove it from you [Auto] or profilw-specific [Auto..Bell UH-1C] section, whichever one you are using. then add offset monitoring to offset 66D0 using the right-hand side of FSUIPC's logging tab, as S32. Then load your aircraft and movr your throttle slowly from idle to full throttle and then back again, exit and attach both your log and ini files. Strange that this was previously working correctly, but just reversed. They are probably fine and look to be using FSUIPC-added controls or custom controls. They looked strange to me as there was no comment generated, but maybe FSUIPC4 does not auto-generate comments for such controls, like it does in other versions. I have not used FSUIPC5 / FSX for many years now and forget the differences in this compared to later versions. John

Offset logging is done via the right-hand side of the FSUIPC logging tab. However, you don't actually need that as the lua script logging is sufficient, as that will log any offsetchanges. Please also remove the comment characters from the other ipc.log statement:

No, you did not set the correct logging., You have activated lua debug logging - I did not request this and it is not needed, please remove this. As I said, you just need to uncomment the 'ipc.log' line entry in the BellUH1Throttle.lua file. You also did not add the offset logging, and the log file shows no movement in the throttle (or the lua debug logging is not showing this). You also forcibly closed the log and started a new one. Please don't do this. Please set the logging as requested and show me those files again. Please exit FSX/FSUIPC before attaching logs, and do not request a new log file.. John

Activate the logging in the lua script (remove comment characters from 'ipc.log' line) and add offset logging for offset 66D0, then test and show me your FSUIPC4.log & FSUIPC4.ini files. For the test, first move the throttle from idle to full and back again, and then exit FSX/FSUIPC4 before attaching the files. John

.Ok, thats interesting. So they are not 'scoped lvars' then.. Thanks for the update. I will make a note of this and take a look at the ProSimSDK.dll when I get time. Thats good to know, thanks. I also saw this on using ProSim with MobiFlight and FSUIPC (which may be useful): https://www.mobiflight.com/en/tutorials/aircraft-guides/prosim737.html John

Please do this. You need to: 1. Correct your aircraft profile names, as advised 2. You have a lot of general button assignments to your Macro Bell_UH1C - shouldn't these be in your .Bell UH1c profile? 3. You seemed to have assigned your axis to update offset 66D0 twice: Why is this? 4. You are starting your BellUH1Throttle lua script in the [Auto] section, so it will run with all aircraft. As this is specific to the Bell UH1, you should start it in a profile specific [Auto.Bell UH1c] section. 5. You seem to have assignments to non-exisiing macros: But it looks like the lua isn't running for some reason. Are you sure it is in your FSUIPC4 installation / modules folder?

These forums will soon be closing, and are already closed for new topics. Please see the following announcement: John / FSUIPC

These forums will soon be closing, and are already closed for new topics. Please see the following announcement: John / FSUIPC

This depends on how you select the key to copy it. If you just double-click it, it may not select the entire key due to the mix of letters and numbers. It is up to you to make sure that you are copying the entire key string - I am not going to provide details on how to copy and paste correctly...! However, I will add a comment to make sure that the entire 12 characters of the key are copied/pasted. Anyway, glad its working and thanks for responding with what your issue actually was. Regards, John

There is no 'password' - your FSUIPC7 license contains 3 parts: name, email/address & key. If you have already registered your license, the details will be in your FSUIPC7.key file. Otherwise, the license details can be retrieved from: 1. the purchase email you received from SimMarket 2. Your SimMarket account If you have issues accessing your SimMarket account, you need to resolve this with SimMarket, not here. I am just a vendor on SimMarket and cannot assist with SimMarket issues. John

I don't think this can be due to the fact that FSUIPC7 is auto-started via the EXE.xml. Don't you get the same issue when FSUIPC7 is started manually? What I suspect is happening is that FSUIPC (post) calibration is affecting the controls. If you have a general calibration section, this will apply by default even when the axis is assigned in MSFS or elsewhere. You can do one of two things: 1. Create a profile-specific calibration section for the CowanSim and remove/reset all calibration controls - you should do this even if you are not currently using a profile for this aircraft. To do this, just click the 'Profile Specific' checkbox in the calibration tab of the axis assignment panel. Then on each calibration page where the button says 'Reset' (as opposed to 'Set'), click that. 2. You can disable all post-calibration (i.e. to not calibrate at all unless an axis is assigned in FSUIPC using 'send direct to FSUIPC calibration') by setting AllowSendToFSCalibration=No in the [General] section of your FSUIPC7.ini file. Note that setting this will affect all axes assignments not assigned in FSUIPC with 'send direct to FSUIPC calibration'. Please do! John

You did not activate the requested logging option for IPC Reads. However, your log file does show some connection issues: It also looks like you disconnected and reconnect before FSUIPC had established a connection with MSFS2020...I didn't think this was even possible! And I do not understand why the connection attempt at 84078 didn't time out after 15 seconds. For this connection issue, you need to increase the DetectToConnectDelayAuto ini parameter (in your FSUIPC7.ini file). I am not sure wht value you should use - you need to time the period between when you see the FSUIPC7 splash screen to when MSFS2020 arrives at the main menu, and then set the value for that ini parameter to this. Please see the following FAQ entry on this connection issue: Note that this parameter will also be used when running MSFS2024 if you are using the same FSUIPC7 installation for both simulators. Once you have configured this parameter correctly (and for use with both MSFS2020 and MSFS2024 if using the same FSUIPC7 installation for both), you should set the ini parameter StartUpTuningDoneVersion to -1, which will disable the auto-tuning of this parameter by FSUIPC7 itself. John

But which redistributables? As it says in the documentation, you need to install the latest combined (i.e. for 2015-2022) redistibutables for both x86 and x64. Did you install these? If so, please let me know your order number and I will check your details here. Do not post your key details. Please note that EVERY report I get on this is down to user error, usually either by not entering the correct details (all 3 parts, name, email/address, key) must match exactly, or due to not having the required redistribtable packages installed. You can also try manually creating your key file (as shown in the Installing and Registering FSUIPC document) and then running FSUIPC7 to see if the license is recognised. If it is recognised by FSUIPC7 but not validated by the installer, it will be due to either your VC++ redistributables or anti-virus software. John

Can you activate logging for IPC Reads and show me a log file for this. Start everything as normal, and when the client programs cannot connect, disconnect and re-connect so that they connect, then exit FSUIPC7 and show me / attach your FSUIPC7.log file. John

A new trial license is now available (from first post in this topic), valid until 1st December 2025. Note that this is the last time I will provide a trial license in this topic/via these forums. These forums will be closing at the end of the year and all support will be moving to the FSUIPC7 home website (fsuipc.com) and Discord. I will post more information about this in the coming days once the update/new website has been released.. John

Not sure why that would be - is the value of the lvar decreasing when you do this? You can verify by re-enabling that log line and check the log file (or open the logging console so you can see the messages in real time when you move your assigned axis. Also set logging for Events/Controls, and maybe also axes controls, yo see if any other event is registered that could be preventing this. If it is decreasing, then it could be due to assignments in FSX - check you have disabled controllers in FSX if assigning everything in FSUIPC. John

You will only have profile sections in your ini file if you are actually using profiles. Also, if you are using profiles-in-separate files, the profile-specific sections will be in a separate file (named after the profile) and will not contain the profile-name extension. So it really depends on how you are using FSUIPC. If you fly multiple aircraft, you should be using profiles. The only reason to not use profiles is if you only fly a specific aircraft. See the section on profiles is the User guide for details. John

The additional '.FENIX A320' indicates that this is a profile-specific calibration section - FENIX A320 is the name of the profile. If you are not using a profile for the Fenix, then you would use the general calibration section [JoystickCalibration], which will apply to all aircraft that don't have a profile specific calibration section, even when the aircraft is in a profile and has its own profile specific [Axes.xxx] section. John

Note the license is still valid today - it expires at the end of the day. I will update later today (if I get time) or tomorrow.... John

You can attach your FSUIPC7.log file, or copy the relevant text from there. But why are you using an 8-byte floating point number? Even though input events (and lvars) are always stored internally as 8-byte floats, they are often used as just integers, Booleans, etc. As this one has a fixed set of discrete values within the rang 0-255, you should add it as an unsigned byte (UB) and use the Offset UByte Increment/Decrement controls (or Offset Byte Cyclic Increment/Decrement). Always use the the type relating to how input events/lvars are used when adding to offsets, which is rarely a 64-bit float. Note also you have an extra 0 - its A000 and not A0000. Any further issues, please attach your log and ini files. John

You can do this easily in two ways: 1. use a preset to increment using '++'. Also use min/max so it stays within range 2. Add the lvar to an FSUIPC offset, then use the FSUIPC-added controls to inc/dec/cycle the offset. Changing the offset value in this way, when the offste holds an lvar, will send the new value to the FS. Well, many standard events don't work for many add-on aircraft in MSFS, both MSFS2020 and MSFS2024. That is why you need to look into lvars, hvars, bvars, etc Usually you can use FSUIPC logging - either events or input events. For lvars its more complicated - you have to find the lvars you want to monitor first (list them in FSUIPC), and then you can log the lvar changes to the lvars by adding a section to the FSUIPC7.ini file. This is documented in the WASM section of the Advanced User guide. B-events are Input Events, just via a different root - in FSUIPC, you can use input events directly via the Simconnect interface. B-events are only for use in gauge code, i.e. via valculator code or a preset. There is a mapping from B-events to input events, but not 1-1. For ecample, there may be just one input event which has a value (which you can change/set), but there may be several b-events associated to this input event, such as *_set, *_inc, *_dec. You won;t see these in the input event interface, just a variable with a value that you can control. No problem! Cheers, John

Did you try the MAGNETO_INCR k-event instead of the MAGNETO1 one? But I don't think that will work either... If the BS Bonanza G36 uses an lvar, I would have thought the Pro would use something similar. Have you tried listing the lvars to see if anything looks appropriate? Also maybe try looking at the Input Events - you can list these, and also log any changes. Set logging for Input Events, (Log->Input Events) open the logging console (Log->Open Console) and turn the magneto in the virtual cockpit (VC) to see if anything is logged. You can also examine the behavior of the switch using the MSFS dev tools to see how it is controlled - see this MF documentation: https://docs.mobiflight.com/guides/input-events-2024/ You can assign to input events in FSUIPC in two ways: 1. Using Input Event assignments directly 2. via calculator code and using them as B events (MSFS2024 only - doesn't work in MSFS2020) John