John Dowson

Also, note other users may have an issue with the axis range, not just the reversing. As I said, the script expects each axis to be in the -16383 - +16383 range. Quite a few axes, especially those home-made using potentiometers, can have a different range. If this is the case, you would also need to calibrate the pot's range input to the script to -16383 - +16383. John

Great! It is not an issue if an axis is/needs reversing - many axes work in this manner. To handle this nicely in the script, you can add add two boolean variables - rudderAxisReversed, brakeAxisReversed, and then use those to determine whether to reverse or not. Then it is a simple matter of setting those to true or false. If you can attach the script you are using, I can make those changes for you. John

FSUIPC3 is now free - you can find a registration code on www.fsuipc.com. Here are the details: John

You should not uninstall default aircraft, as they will get re-installed the next time that you restart. There is no need to do this.. The problem with lvars, especially with default aircraft, is that the lvars from the previously loaded aircraft are still available. If I load the A310, I get the max of 3066 lvars, and this is with the Aerosoft CRJ, FBW A320, PMDG 737, JF PA28, Flying Iron Spitfire and several more aircraft in my Community folder. If I then switch to the C171, I still get 3066 lvars. However, if I then exit and restart MSFS, use the same C172, I only get 150 lvars. So, the solution at the moment would, when switching planes, first switch planes in MSFS, then exit and restart, and you should see the number of lvars reduce substantially. Can you try this as well to see if you see the same behavior? Cheers, John

You didn't offend me - sorry if it came across that way. I was just puzzled by your reply... Anyway, there are still quite a few MSFS key input strings I am not requesting, and it could be one of them, although it is strange that the key is registered as #~ by FSUIPC. Could you run FSUIPC7 without MSFS running. activating logging for Buttons & Keys, press the Ö, Ü & Ä keys (in that order), then close FSUIPC7 and show me what was logged - either paste the lines logged for each key or attach your FSUIPC7.log file. I will also see if I get emulate using a virtual keyboard (as I don't have a German layout keyboard!).

Just move the entire fsuipc-lvar-module module folder out if your Community folder. However, thinkin about this a bit more, that also cannot/should not caise MSFS to CTD, as WASM modules are sandboxed (that is the whole point if them!) and so if they crash, they should stop working and MSFS should continue. I really think your problem lies else where... John

Did you read my original comment? Did you look at the valid key input strings I referenced? If they are there, I can add them - I can't see them, but then neither can I see Ö and Ü... And there is something I have already done about this - allowing ALL keys to be recognised by switching to the keyboard hook method, as I said. There is no way that I can add key input strings via SimConnect that are not recognised by MSFS - surely you must understand that. So, in effect. I do not understand your last comment. and I have already provided an alternative solution. John

Keyboard input in FSUIPC7 is (usually) received from MSFS via SimConnect. The only keys supported by SimConnect are shown here: https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimConnect/API_Reference/Events_And_Data/SimConnect_MapInputEventToClientEvent.htm - see the section Valid Input Strings. Unfortunately it does not look like these keys are available. You can raise this with Asobo - if they add input events for these, I can make them available to FSUIPC7. There is one possible way to get these keys in FSUIPC7, which is to switch from using SimConnect for key input events, and enable a global keyboard hook to be used instead. To do this, set the following in the [General] section of your FSUIPC7.ini file: UseKeyboardHook=Yes See the Advanced User guide for details on this parameter. John

Good news indeed...and good luck! Let me know how it goes... John

👍

That should work, but you also need to change the assignment index number (the first number), and make sure you do this either when FSUIPC is not running, ot if it is then the button assignments window must be open, and once you have saved the file you must press the Reload button to reload the assignments from the file. If it is just two controls that you want to send, and it is a button and not a switch, then you could also assign one control to the press and one control for the release. Another method of doing this would be to create your own preset, using the myevents.txt file. If you are not familiar with presets, if you show me the assignment line that you want to duplicate, and let me know the additional rotor brake value you want to add, I can show you what the calculator code for the preset would be. There may already be a preset available for this - you can check on HubHob. John

This is certainly not an issue with FSUIPC or the installer, and so there is nothing I can do. It is either something you are doing or system settings (permissions). You are not even running the FSUIPC7 installer! As I said before, make sure you unzip the downloaded file before running the installer, and I recommend just unzipping from your Downloads folder (not in your desktop). And check any anti-virus software which may be blocking or removing the installer. Have you actually checked it is there? Did you try what I suggested in my previous response? I am closing this thread now as thee i really nothing more I can say or do on this issue. Try google (as this is nothing to do with FSUIPC). John

It is for technical reasons in how the lvar names and values are passed from the WASM to FSUIPC (via the WAPI). I could increase this (would involve an update of the WASM and WAPI), and have already done this once (from 2044 to 3066) quite recently, in version 7.3.5 released 29th May. I may consider increasing the maximum limit again, but not at the moment. I don't want to be increasing this every 6 months if the number of available lvars keeps increasing like this. MSFS should only provide the lvars for the aircraft currently loaded - the rest are just noise. John

Extensive documentation for FSUIPC7 is installed in your Documents folder when you install FSUIPC7. Also available from the Documents section of this forum, although that will be slightly out-of-date. There is no such file. FSUIPC7 stores is user-settings in a file called FSUIPC7.ini, located in the FSUIPC7 installation folder. This file is created when you first run FSUIPC7, if not already present. John

Sorry for the delay - I will look into this further in the next few days... John

No problem - and me too!

Can you please turn off logging for both Lua Plugins and Log Lua Separately. If you want to show me a log file, I just want to see your FSUIPC7.log file, and also your FSUIPC7.ini file if you have issues. And, as I said, you should open the logging console (Log->Open Console) and monitor the output in real-time. I also suggest you re-read my previous posts to make sure that you have set everything up correctly. You are also using an extremely old and unsupported version of FSUIPC7 - 7.0.0-Beta from 19/8/2020. This is a very early version - please update to the latest (and ONLY supported) version which is 7.3.15. John

There are many posts from users saying the FSUIPC is causing MSFS to CTD (with different MSFS versions) and my answer is always the same. I am not going to repeat myself on this topic again - please search for the similar posts where I have replied to this accusation at length. I will also create a FAQ entry on this issue in the next few days and will post a link in this topic when done. No. FSUIPC7 is a separate application and in no way should cause MSFS to CTD. If MSFS CTDs, it is a problem for Asobo, even if this only occurs with FSUIPC, as it will be a SimConnect issue on the server side if MSFS is crashing. However, I doubt very much if this is the issue. Many many users are using FSUIPC7 with SU11 without suffering CTDs. I suggest you check the Asobo forums and report to Asobo if MSFS is crashing. Check your windows event log and submit the crash report to Asobo. The only possible way that FSUIPC7 could cause MSFS to CTD was if this was caused by the FSUIPC WASM module. If this did cause such issues, it would certainly have been reported by many other users, so I really don't think this is the cause - but you can always test with the WASM removed from your Community folder. John

👍

Don't do this! Just let the luas be logged to the standard log file (FSUIPC7.log) - you can then see the messages in real-time if you open the console window. Yes, of course you do, as I previously said: Please see the section Automatic running of Macros and Lua plugins on page 39 of the Advanced User guide for further details. John

Why are you installing the WASM manually? Are you a developer? The WASM module for users is included in the FSUIPC7 installer, you only need to download/use the WASM/WAPI package if you are not using FSUIPC7, or if you are a developer and want to use the WAPI (the WASM Application Programming Interface). Please attach your full InstallFSUIPC7.log file, not paste extracts. The folder $LOCALAPPDATA\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache is the first one checked for the UserCfg.opt file for an MS Store installation. If the installer could not fund that file, then either your LOCALAPPDATA environment variable is not set correctly, or you have permissions issues somewhere that are preventing the installer from seeing this file. Please check that environment variable first. Anyway, there is no problem manually installing the WASM into your Community folder. You may also have issues with auto-start installation if your MSFS EXE.xml file cannot be found, but you can also set this up manually (see the FAQ entry on auto-start for details). I will correct the spelling mistake, thanks. None of this is of any importance. The WAPI is NOT installed by the installer - as I said, you only need this for developing WASM clients. The WASM is also not installed by the installer, but you do not need this either - everything that that provides is also provided by FSUIPC. The WASMClient is provided as an example client using the WAPI, and standard FSUIPC users don't need this, or need to know anything about this really... Yes it is correct. It is for developers. The WASM is installed by the FSUIPC7 installer (which I know you are having issues with - we can sort that out). Please see the provided document Installing and Registering FSUIPC7. That should tell you all you need to know about installation. It doesn't seem to matter what documentation I provide, as many users don't seem to use or refer to it anyway.... You should read the Installing and Registering FSUIPC7 document, as well as the User Guide. You should take a look at the Advanced User guide to be familiar with what's available, and read the WASM section there. The FAQ questions are available here. and this forum is the knowledge base. Please use it to search for any issues BEFORE posting (and after having checked the provided documentation). John

Sure, no problem, Once you have tested this, and maybe tuned the script, I can also create a post un the User Contributions sub-forum and make the script available there. Cheers, John

Auto-start is working fine here (Steam install)- always has. I don't know why so many people are having issues with this, but id you have checked everything mentioned in the FAQ entry on this topic and it still doesn't work, you should raise a bug report with Asobo, as it is MSFS that should do the auto-start via the EXE.xml. If that file is correctly formatted, and all your permissions and privileges are correct, then it is an MSFS issue.

Ok, thanks for the update. John

That is probably because you asked about an FSUIPC offset - you should just ask about the SDK variable. As I said, FSUIPC just populates the offset with the value received. That is also an option! Cheers, John