John Dowson

Those logs are from 3rd Feb and 8th March, and the ini's are probably just as old. So it looks likeyou have installed in another folder to your original installation folder. You need to determine where you have actually installed v6.1.1. The best way to do this is to use the Open Folder button in the logging tab. But, probably the best thing to do is to just re-install again. This will uninstall your current version, and allow you to select the installation folder. Make sure that you select your old installation folder - the one where your .mcro files are located. A re-install into the correct folder should fix his issues, but you can certainly continue with this if the OP has more issues, thanks.

Sorry, but could you also attach your FSUIPC6.log and InstallFSUIPC6.log files please.

Did you read the Installation and Registration guide? Did you check the forums, as this question has been asked hundreds of times already? Did you click the Register button during registration? 95% id uses are due to this not being done. If you did do this, what did the pop-up say? Have you installed in a non-windows protected folder?

Lvars are, by default, 8 bytes (64 bits). If the strings aren't null terminated, ipc.writeSTR will write 8 bytes. There are two things you could try - specifying the length of the string in the ipc.writeSTR function call, e.g. ipc.writeSTR (0x6950, value, 4) You could also try logging the value, to see what is actually being received and written to the offsets, e.g. function md_ipc_fuelleft (varname, value) ipc.log("md_ipc_fuelleft: received value '" .. value .. "' for lvar " .. varname) ipc.writeSTR (0x6950, value, 4) end Later: and this: should probably be: event.Lvar ("md_ipc_fueltotal", lvps, "md_ipc_fueltotal") - (string) | offset = 0x695C | type = string | size = STR, 5 | substring 0 - 5 BUT, you are also using an offset area that is not documented as free for general use - it is Reserved. Try with offsets free for general use, e.g. try from 66C0 or A000.

In your FSUIPC7 installation folder, along with your FSUIPC7.log and FSUIPC7.ini files, which I would also like to see. Have you 'enabled' wide server (using the WideFS -> Enable menu option) from FSUIPC7? You only need to do this only once.

Please also show me your WideServer.log & FSUIPC7.ini files, and I will take a look (tomorrow now). Also, try removing the Protocol from your WideClient.ini and and use ProtocolPreferred ini parameter in your FSUIPC7.ini ([WideServer] section). And try using ServerName rather than ServerIPAddr, if not done already. However, these issues are usually always caused by firewall or workgroup settings, so please double-check.

Have you checked your windows workgroups and firewall settings, as indicated in the WideFS user Guide?

Ah, the trim wheel uses buttons! Sorry, I had assumed that was an axis... Have you tried adjusting the PollInterval (to read the button states faster) or the ButtonRepeat ini parameters (to control the repeat rate)? You can usually achieve acceptable results adjusting these together with the timings in your lua. See the Advanced User guide for details on these ini parameters. Yes, its the same SDK for the various FSUIPC versions. Note that this is also installed (if selected) in an SDK folder under your FSUIPC7 installation folder. But I would persist with lua for the time being and try those ini parameters if not done already, before looking at the SDK.

Do you have a steam or MS Store version? The installer thinks you have a steam version, but cannot open this file: The strange thing is that that file is detected as being present, but cannot be opened for reading. Maybe check the permissions on that file. Do you run MSFS using admin privileges? Alternatively, you can use the following - just unzip in your MSFS Community folder and it should be picked-ip the next time you run FSUIPC7: fsuipc-lvar-module.zip

One of the rotaries is the mode selector which has 5 different buttons/positions, so I guess you just need to control the 2-button inc/dec rotary, no? You can usually achieve acceptable performance using both methods, especially if you assign to the offset increment/decrement controls and tune the inc/dec amount. However, being a two button rotary, its performance will be limited. I don't know that library so can't really comment (although it seems more of a multi-media library than for device handling), but not sure how you would interface that to FSUIPC. The FSUIPC lua library is not available to external lua programs, i.e those not ran by FSUIPC. You would have to use the FSUIPC SDK to feed the input back to FSUIPC. You use the FSUIPC SDK (available for various languages) in an external program to write/read to/from FSUIPC offsets. As indicated in that post you referenced (and was what the OP did), you could using another button (or key) as a type of latching switch, so when pressed/active the rotary would be performing fast in/dec, and when not the in/dec would be slow. You could even have different increments for different keys/buttons. You acieve this via compound button assignments (see the Advanced User guide). John

Ok, thanks for reporting back.

Yes, that is correct. I have explained this in a few posts, but yes, you are right - I should add this to the documentation. See or

I don't know what this means. but it needs to be saved as a .mcro file, as I have said...if its not saving with the correct extension, change by using 'save as...' or simply rename the file (right clickin windows explorer and select Rename). Then you cannot use direct assignments. You will have to use either the lua com library or MobiFlight.

Before we do that, try the macro first. However, neither route will work if your arduino switches aren't recognised by FSUIPC. That is the first thing to try. Are they? Recognised or not, the lvar should appear in your assignments drop-down if the macro file has the correct extemsion (.mcro), is in the correct place (your FSUIPC installation folder) and has the correct content (as previously posted). So, you need to check: - if your arduino buttons are recognised - if the lua macro you created is accessible/visible in the assignments drop down menu

Yes... One is for P3D, and one for MSFS, and one a dll and the other an exe. So yes, they are coded differently. They are different products. However, the functionality is the same, wherever possible... Most offsets should be the same, apart from those not available (or not working). Please see the included offset status spreadsheet (in the downloadable zip) for the latest status of the FSUIPC offsets for MSFS. Check the status of the offsets you re using in the aforementioned spreadsheet. If in doubt as to whether they are working correctly or not, try logging the values (via the Log -> Offsets... facility).

Ah, ok. I haven't used live traffic in quite a while. I've heard about the CTD issue with AI traffic but not experienced it. May be worth trying AI traffic in the latest MSFS version to see if this issue has been fixed, or check the Asobo forums to see the status or availability of any work arounds (e.g. replacement BGLs).

Check your MSFS traffic settings.

Yes, the sensitivity settings on MSFS take effect regardless of where your assignments are. If calibrating in FSUIPC, better to leave them at their defaults (or RESET) and calibrate only in FSUIPC.

Then check where Prosim is getting this data from. If the On Ground flag is received correctly via SimConnect in FSUIPC, it should be ok via other clients.

But where is your display getting this data from? Looking at the FSUIPC traffic tables (using TrafficLook), all aircraft seem properly categorized as on-ground or airborne, so it looks to me that the AI data in FSUIPC is correct.

No. But it doesn't matter, I don't use Prosim (or MF) and so can't advise, sorry.

Disabling controllers will not affect the keyboard (or mouse). If the numeric keypad changes thhe views then you must have assignments for that somewhere, most probably in chase plane. Also check the status of you num-lock, as that will effect the functionality of the numpad keys. Most folks seem to use GSX and FSUIPC (and also chaseplane) without having to do this.

They only conflict if you have conflicting assignments, i.e an axes or button assigned both in FSUIPC and in P3D, either to the same or different controls. When this occurs, this is when things seem to "go crazy" as you say, as the FS is receiving different conflicting commands from the same joystick button press or axis movement. You can have controllers enabled as long as your assignments in P3D do not "conflict" with those in FSUIPC. However, the problem with having controllers enabled in P3D, is that P3D will sometimes recognize your attached device and automatically create new assignments to it, which can (and will) conflict with FSUIPCs assignments. To prevent this, we recommend disabling controllers completely if assigning in FSUIPC.

No, thats the same log file as last time, with the same issues. Please do as previously advised. Note that this is now nothing to do with the original support request and title of this topic. I am going to close this topic. Please raise a separate topic if you still have issues, providing the needed information. Before you do this, please check your assignments in MSFS. Make sure that you have created (and assigned) a new empty profile to your yoke in MSFS if assigning in FSUIPC.

What does the pop-up message say when you register (i.e. click the Register button at the end of the installation process)?