John Dowson

First, note that the gauges display the temperature in Fahrenheit, but the offset holds the temperature in Celsius. However, there does seem to be an issue. When I start the PMDG 737 I see the offset increase in value from 0 up to around 80, and if I adjust the temperature this can go above 100C! This is obviously not correct, and should be reported to PMDG. John

FSUIPC just populates the PMDG offsets with the data received from the aircraft. If it is not holding the correct value, then this can be due to one of two things: 1. The PMDG data format has changed. I can check this. 2. The data PMDG is sending is not correct. I cannot do anything about this and this should be reported to PMDG. I will take a look at 1 and get back to you. John

Ah, ok... This depends. Some add-on aircraft don't work well when assigned using Send to FS as normal control and are then also calibrated in FSUIPC7, due to the priority levels. The aircraft will intercept the initial axis control, pre-calibration, rather than the calibrated axis control. Anyway, glad your issue is fixed. John

Can you show me the InstallFSUIPC7.log please, from when you re-installed after renaming the UserCfg.opt file. Also please attach your FSUIPC7.log file, which will be in your FSUIPC7 installation folder. The auto-start issue is not fixed - you started FSUIPC7 manually. You can continue to do this to use FSUIPC7, but if you want this to be automatically started then this issue will need to be fixed. There is a FAQ entry on auto-start issues - see John

Yes, I can see this now after virus definitions update. I have allowed an exception and downloaded and checked the file, and it is the same one as uploaded and so this will be a false-positive. I will report this to windows, and also see if I can fix here. I think the problem is that the installer runs an embedded program to check the registration details and it is this that is being flagged. This program was recently updated (recompiled only) so I will try with the older version. If that also fails, I will have to remove the registration validation until this issue is fixed. Sorry about this - I will try and fix this asap....for now, please add an exception for the installer to allow it to be downloaded and ran. John

See: https://www.bitdefender.com/consumer/support/answer/13427/ https://www.bitdefender.com/consumer/support/answer/2393/

Whatever you want - User.cfg.opt.notUsed for example. Just give it a different name so it is not detected.

What is confusing about this? If that file is present, the installer will assume you are using a Steam installation. If that file is not found, then an MS Store installation is assumed. Renaming that file will therefore tell the installer to install for MS Store, not Steam. John

No, it is a false positive. I have no viruses, and SimMarket also scans all files for viruses and they have not reported anything. As the virus is reported in the RegistrationChecker program, can you not install and skip registration? Are you using BitDefender? What is it saying, and why is this different from other users reporting this issue - others users could download but had problems running it due to the issue with the RegistrationChecker program. If it is your browser blocking the download, you can tell the browser to download anyway. What workaround did they post? Can you please provide a reference. It must be possible to either disable BitDefender when downloading/installing, or adding an exception to allow the program to run. Can this not be done?

But you shouldn't install FSUIPC7 when running MSFS. But try re-launching MSFS after you have finished your flight and see if FSUIPC7 starts. If not, can you at least try starting it manually, by double-clicking the FSUIPC7.exe in windows Explorer - does it then work? Then I would expect that you are using an MS Store installation, but your log file indicates that FSUIPC7 is installing for Steam. Did you previously have a steam version installed but are now using the xbox version? If so, please remove or rename this file: C:\Users\jaked\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt and re-install. Do you know where your Community folder is - is it at that location I mentioned? John

Do you mean that FSUIPC7 is not running? Do you not see the FSUIPC7 splash-screen when MSFS is started and loading? Did you install FSUIPC7 firectly from within the zip file rather than extracting the installer from the zip file first? It looks like it: Please try extracting the installer before running it. The Community folder for your Steam installation also looks rather strange: Is this correct? Anyway, please try installing again and extract the installer before running it. Then run MSFS. Do you see the FSUIPC7 splash screen? If so, FSUIPC7 is running. If not, there may be an issue with your EXE.xml file. Please show me/attach this file, as well as your new InstallFSUIPC7.log file: C:\Users\jaked\AppData\Roaming\Microsoft Flight Simulator\EXE.xml Are you running MSFS as admin or as a standard user? If running as admin, you may need to set the FSUIPC7.exe to also be ran as admin (and also all FSUIPC7 clients). John

Again, what aircraft are you using? I don't see how FSUIPC's aileron calibration can change the display in the attitude indicator. What the calibration will do is adjust the values sent to the FS when you move the aileron axis, so axis positions below the centre will send the negative parameter range (-16384 to 0) and axis positions above the centre will send the positive range (0 - 16384). Are you sure that you weren't doing something else to configure the attitude indicator? It should be with those settings - have you tried it? There has been absolutely no change in this area for a very long time.

Sorry, but what do you mean by this? Do you see the In/Out numbers changing when you move the axis? Are the numbers registered when you press the Set button? What aircraft are you using, and which aileron axis? Can you also attach your FSUIPC7.ini file please. John

This all sounds very strange! Re-installing MSFS sounds rather drastic though, especially if your issue is only with the PMDG 737. Not sure what else you can do though, except maybe try Simstaller (freeware) to check for add-on conflicts - see https://parallel42.com/products/simstaller/. John

Just to close this issue, when using XINPUT devices, such as the xbox one and xbox 360 controllers, input is only recognised by FSUIPC when FSUIPC has the focus. In versions of FSUIPC before FSUIPC7, this will be when the FS has the focus (as FSUIPC is an embedded dll in the FS), but as FSUIPC7 is an external application it will only receive the controller input when it has the focus. The only way around this is to use an additional program: XInput Plus. This is noted in the README,txt: John

When it shows this SkyDemon must be connected to the simulator, or at least connect to FSUIPC7. I cannot help with 3rd party apps, you need to ask on the SkyDemon support forum (presuming there is one). All I can tell you is that most connection issues with 3rd party apps (to FSUIPC7) are due to permissions issues. All applications that connect to FSUIPC7 must be ran at the same privilege level as FSUIPC7. So, if running FSUIPC7 with admin privileges, you must also run SkyDemon with admin privileges, and if running with standard user privileges then SkyDemon must also be ran with standard user privileges and not admin privileges. Please check this, and if you still have issues then report to SkyDemon - I cannot help with this, sorry. John

@Fess_ter It seems that lua scripts (and probably also FSUIPC7) are running approx 13x slower when FSUIPC7 is auto-started by MSFS compared to when it is manually started. This doesn't explain the difference between event.offset for PMDG offsets vs non-PMDG offsets (which is probably due to the data rate, but I will investigate when time permits), but worth knowing if you are having performance issue in your lua scripts. John

The changes in 7.4.11 were minimal - the only change was to change the default value of the InitialStallTime ini parameter that was reduced by too much in 7.4.10 and was causing issues. The MobiFlight events.txt (that holds the preset definitions) was also updated, but I doubt very much that these presets were changed. The PMDG presets mainly use the PMDG custom control numbers, which also will not have changed. So I have no idea what could cause this. It is also difficult for me to diagnose without seeing your original ini and a log file. So I cannot check what has changed, only if you have any issues with your current configuration. Do you? Do you get issues every time you use the PMDG 737? If so, please activate logging for Buttons & Keys as well as Events, and show me a log file, together with your ini file again and a description of what you did and what went wrong, and I will take a look. John

That is interesting. Thanks for the update. John

BTW, I have moved your post to the FSUIPC7 sub-forum - please use this sub-forum for all issues with FSUIPC7, not the main support forum. Thanks, John

There seems to be an issue with the speed of lua scripts when FSUIPC7 is auto-started by MSFS. Can you try manually starting FSUIPC7 - just exit it and restart manually, then try recording again to see if you get a faster rate. If I run this lua when FSUIPC7 is auto-started, I also see data logged at approx. 800ms intervals, as you do: If I exit FSUIPC7, and restart it manually, I see data logged at roughly 63ms intervals: You can also speed things up further by reducing the delay in the sleep statement on line 58: ipc.sleep(48) Note that this was reported previously in the following topic, but I have only just realized that this is related to how FSUIPC7 is started: John

@naizo I have looked at this again and it seems that lua scripts run a lot slower when FSUIPC7 is auto-started by MSFS. if it is started manually, it runs a lot faster. Are you auto-starting FSUIPC7 via the EXE.xml (i.e. using the auto-start component)? If so, can you try manually starting FSUIPC7 - just exit it when it starts and then restart it manually., Do you see a performance improvement? I noticed this when running the example record to csv.lua script. If I run this when FSUIPC7 is auto-started, the data is logged at roughly 800ms intervals, but if I exit and start FSUIPC7 manually, the rate goes up to around 63ms intervals, more than 10 times faster. I will update the documentation with this information, and report this to Asobo to see what, if anything, can be done. John

LINDA is quite a complex system - you cannot just extract one lua file an expect it to work asit may have many dependencies. If you want to do this, then you need to have some knowledge of lua to be able to modify the files so they work stand-alone. You cannot assume that. You need to extract all dependencies, and then all functions that those depend on, etc etc. No. That lua script will work withing the LINDA environment, where all dependencies will be available. The use of a string rather than a number is minor - that will still work (due to lua's lax type specification - the string will be converted to a number), but it is always a good idea to correct such mistakes as they can cause issues - especially if blindly copied. This error: 1040344 *** LUA Error: C:\FSUIPC6\My789functions.lua:66: attempt to call global 'DspShow' (a nil value) is telling you that he function DspShow, called on line 66 of the My789functions.lua script, does not exist. Just remove that line (and also remove it if it appears elsewhere in your script) and then try again. When you try again, look at the log file to see if any errors, correct them, and repeat. However, I think if you remove those calls to DspShow, the script should work. If you want to use lua, you should really at least learn the basics of the lua language, If you don't want to do this, then you should use LINDA. But if you want to use lua, you need to at least understand the basics, And the log files are there for a reason - to help you. If you get any issues, at least try looking at the logs. If there are basic errors, e.g. syntax errors or missing dependencies/functions, then this should be pretty obvious, as in this example. I don't mind helping people with these sorts of issues, but I prefer to help people understand what the issue is and to help them diagnose and fix these type of issues for themselves. This then reduces the support I have to provide and gives me more time to develop and improve FSUIPC. I have a huge backlog at the moment but have hardly any time to work on improving my products as nearly all my time is spent on support. John

@DaveSCUSA Have you managed to set this up yet (and I can consider this closed) or are you still having issues? If so, please let me know and I can provide further details on how to configure assignments for the C510. I will soon be looking into updating the Input Event functionality to store the current values of the Input Events, and this will make incrementing/decrementing these far easier. But until then, work-arounds are necessary for this. John

The next release of FSUIPC7 (which will be 7.4.12) will auto-tune these connection parameters. This release is currently available as a beta release here: John