John Dowson

@frankj76021 Did you manage to register your license? What was the issue?

First, if you re-installed windows, make sure you download and install the combined VC++ Redistibutable packages from Microsoft. You can download them from the following site: https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist. Download and install both the x64 and x86 packages. Did you run MSFS2020 before installing FSUIPC? You need to run MSFS at least once before installing, otherwise the installer won't find the necessary files under your AppData folder. So first try re-installing FSUIPC after running MSFS. If you get the same issue, please see the following FAQ entry: John P.S. Please give your posts an appropriate title for your issue. Just saying 'fsuipc' means nothing - every single post in this forum is about FSUIPC!. I have updated it for you this time.

That is nothing to do with FSUIPC - that will be a false-positive and due to a update to Secutity intelligence (anti-virus definitions). What version of Security intelligence are you using? I am on 1.433.192, updated this morning, and I don't get that here. You can restore the file from Windows Security, under Protection History. This keeps happening recently - when it happens here, I report to Microsoft and they are pretty quick to update the definitions to allow it, but for now you will need to restore it. John

These are the FSUIPC support forums and are not really the place for such questions - uoi should try the MSFS / Asobo forums. They should. See the following: https://steamcommunity.com/app/2537590/discussions/0/4839770694276165539/ https://forums.flightsimulator.com/t/msfs-2020-premium-deluxe-content-not-shown-in-2024/666813/8 https://www.avsim.com/forums/topic/649281-is-premium-deluxe-for-2024-worth-it-if-i-own-it-for-2020/ if you google you will find plenty of threads on this, e.g. https://www.avsim.com/forums/topic/663902-cant-decide-whether-i-should-upgrade-to-msfs-2024-or-not/. Personally, if not using the new features or aircraft, then I would stick with MSFS2020. You may get better performance from MSFS2024 though, if that is an issue, as long as you have a fast and stable internet connection. I don't want to promote discussions on this topic in these forums, so I am closing this thread. John

There are many ways to send multiple commands on a single button 1. Use macros - see the Macro Controls section in the Advanced User guide. 2. Overload your assignments. You do this by making the first assignment, commenting this out in the ini file, reload the updated ini file, then make the second assignment, then uncomment the first assignment and reload the ini. 3. Define your own preset to send multiple commands (FSUIPC7 only). I have explained how to do this in detail many times before. See one of the following:

Ah, sorry - forgot to check the poster...!

This is quite a big change and a lot of work, and I certainly won't have time this year, Did you try the Input Event for this? As I said, there are work-arounds you can use for the time being. John

👍

@AlMassimo Having looked further into this, the only current way that I can see to get the value of a scoped lvar is via a response from executing a calculator code string. I presume this is how you can see the value in MobiFlight. Unfortunately, the current FSUUIPC WASM doesn't allow a response from executing a calc. code string. However, I could provide such functionality in an updated WASM module (and integrate this functionality into FSUIPC). I will add this to my ToDo list to investigate, when time permits. However, I do have a lot on my plate at the moment (and the ToDo list is always quite large!) so it will certainly take quite a while before I can get around to looking into this. In the mean-time, as suggested, you should look at other ways to get this information. As I said, for this particular scoped lvar (1:EHSI_1_HDG) you can use the matching Input Event (INSTRUMENT_HEADING_BUG_LEFT). In the cases where there is no matching input event, you can use a lua script to copy the scoped lvar to a standard lvar at regular intervals, and then just use the standard lvar. Hope this helps - let me know if you need any further assistance with this, John

Looks like a static buffer was used to build the text string (for some unknown reason!), so this could cause that issue when using multiple quickly updating wnd windows. I have corrected this in the attached version if you would like to try it. Note that this version contains some technical/non-functional updates that have not been fully tested yet, so if you get any other issues please let me know. John FSUIPC7.exe

Sure, I can add thst. I could also add save flight as a control, so that you can assign to a button or key press (combination). John

I have checked your details here and they validate without issues. Did you download and install both the x86 and x64 combined (i.e. for 2015, 2017, 2019 & 2022) redistibutables? Are you sure all 3 parts of the license (name, address & key) are exactly as specified in your purchase email/simmarket account?

I will take a look tomorrow....

Yes, they look to be the same. 0x0798 was added in v7.2.15, and 0x0818 in v7.2.0. Looks like I forgot to cross it off mu todo list and added it again. Unfortunately, now its there I am reluctant to remove one of those, as it may be being used by someone. I will mark 0x0798 as duplicate in the next update of the offset documentation. Well spotted! John

Ah - MSFS2024 - I was looking in MSFS2020...so, the Viking Air CL-415 then? Searching for 'Canadair' returns nothing... These are the new 'scoped lvars' - from the MSFS2024 documentation: II do now remember hearing about these when they were introduced, but don't know how you can directly read scoped lvars at the moment or if this is even possible. You can use calculator code to set them e.g. '270 (>L:1:EHSI_1_HDG) ' will set the heading bug to 270. To read a scoped lvar, you could just write it to a standard lvar and read that, e.g. execute the calculator code 'L:1:EHSI_1_HDG (>L:EHSI_1_HDG )' will copy the value to the lvar EHSI_1_HDG (and also create that lvar if it doesn't already exist). However, in this instance, you can just use the input event INSTRUMENT_HEADING_BUG_LEFT which holds the same value as the scoped lvar. Just add that to an offset - and you can also set that (via an offset if required) to change the heading bug. I will investigate to see if these can be made visible. However, if I do this, this will break compatibility with MSFS2020 as I will have to switch to the MSFS2024 SDK, which means a new version of FSUIPC.... John Later: I've looked at the MSFS2024 SDK and done some googling and its still not clear on how to access such variables. In this SDK, there is a new Vars API, but there isn't even a way to enumerate existing lvars (i.e. to discover them) and you need to know the name of an lvar before you can do anything with it. The functions the FSUPC WASM uses (from the old Gauges API) are deprecated with no replacement functions available (e.g. not even a function to execute a calculator code string).

You log and ini files don't match - the log is from 7.5.4 and the ini from 7.5.3... I have tried to update anyway. Your ini is a bit of a mess as it looks like your GUIDs previously changed and rather than correcting for this you re-assigned. If you find that your assignments no longer work, it is usually because windows has assigned a new GUID and so FSUIPC cannot match this new GUID to the one in the ini file. Rather than re-assigning, you just need to update the GUID string of the device entry letter to which your assignments are attached. Anyway, I have cleaned-up your ini and update the GUIDs and have removed many duplicate assignments. There are a couple of assignments that need clarifying. 1. On your yoke, buttons 18 and 19 had different key assignments - I have left the later one, but kept the earlier one commented out: You can edit this to keep the ones you want and remove the others, 2. On your throttle quadrant, button 4, you have an assignment to both Gear Down and to send keypress lshift+C: I have commented-out the sending of the key press. You can either re-activate this or remove it. Let me know how it goes with this. Any issues, please re-attach both the updated ini and the latest log file. John FSUIPC7.ini

Do you mean the DHC-3 Beaver? I can create an lvar with this name and this is then picked-up by FSUIPC: So if such an lvar existed, it would be listed. So I am confused about this issue... Maybe ask on the MobiFlight Discord server about this... Please report back, or provide further details. John

Please show me / attach your FSUIPC7.ini, FSUIPC7.log and FSUIPC7.JoyScan.csv files nd I will take a look. Most probably your joystick GUIDs have changed and these will need updating, but this should not affect key assignments. Finishing now for the day, will take a look tomorrow. John

It did look like a USB hub power issue and the cable re-organisation is important information that wasn't included in your original posts. Anyway, no problem - and thanks for the update, John

It is not possible to read the location of the aircraft.cfg file in MSFS2020/2024 if the file is encrypted, which is usually the case for paid add-ons. In MSFS2024, aircraft are 'streamed' - I haven't checked if the aircraft.cfg is readable for such aircraft. I will take a look on Monday, or possibly later today if I have time. John Later: Looks like it doesn't work either for streamed aircraft (i.e. all aircraft in MSFS2024) - see https://devsupport.flightsimulator.com/t/simconnect-requestsystemstate-aircraftloaded-returns-partial-path-of-aircraft-cfg/9041/7 I will still check this though and report back.

No - lvars can only hold numeric data. From the Adobo documentation: IMPORTANT! "L:" vars can only hold numeric data and nothing else, eg: no strings, no binary values, no structs, etc... Are you sure there is an lvar with this name? Are you sure it isn't just 'EHSI_1_HDG' and the '1:' is some MobiFlight syntax? How do you read this in MobiFlight? And what do you mean by 'the default Canadair'? Which aircraft is this - there is no such default aircraft as far as I am aware... Nothing is written as no such lvar exists. I am pretty sure FSUIPC would pick it up, even with a name like '1:EHSI_1_HDG' - it is only a string after all...

Please don't attach the events.txt file (I have removed those) - that is the file that holds the presets, is installed by the installer and doesn't change. It was the FSUIPC7.log file that you should also attach. Did you change the USB port for the USB pad? Or is it in the same hub as another device, or was the logitech joystick connected to the same hub as the UDB pad? If using hubs, are they powered? Your joyscan csv shows the device is detected twice, with the same GUID, but with different vendor and product ids: Not sure why its doing this - looks to be a strange usb issue - especially as this was previously the problem with your logitech joystick but now its with the UDB pad. You could try ignoring that dodgy entry with the empty name by adding: IgnoreDevice=0x28DE,0x11FF to the [JoyNames] section of your FSUIPC7.ini file. If that doesn't work, please show me the files again, but include the FSUIPC7.log and no the events.txt file (if you cannot see the log file, it is because you have windows explorer set to hide the extensions of known log files - change this setting). John

The log file you attached is from 7.4.17, where you say everything is working. Although that log file does contain errors. 7.4.17 is also quite old now - there have been 6 release since that version. You should update more often.... One change that was introduced in 7.5.0 that could affect some third-part add-ons is the offset that holds the sim version (0x3308), Some add-ons expect a value here on start-up, and prior to version 7.5 this was always set to 13. With the introduction of MSFS2024, this offset is now only populated once FSUIPC has a connection to the FS so that it can determine the version being used. For add-ons that need this offset populated earlier, you can add the following ini parameter to the [General] section of your FSUIPC7.ini file: init3308=13 So please try that. Any issues, please set logging for IPC Reads and IPC Writes and show me / attach your FSUIPC7.log file. Also, please always exit FSUIPC7 before attaching logs. Many people use SIOC with FSUIPC - I would have expected a lot more support requests if there was an issue here. If you still get issues with that change, after saving the log file from 7.5.4, can you also please try the attached version below, which is 7.5.3 (just rename your current FSUIPC7.exe and save the attached to your FSUIPC7 installation folder). Also show me / attach the log file from this version. John FSUIPC7.exe

Hi Luke, Could you be more specific -seems like there were several issues in this thread. Also, be aware that MSFS2024 is a different beast and I think that for many aircraft it is not possible to read the aircraft.cfg file. But I will check further tomorrow. John

Peter retire > 5 years ago now. It looks like the name has disappeared from the registry entry for your Saitek X-56 stick. Can you please attach your files - your ini, log and JoyScan.csv files and I will take a look. John