John Dowson

Yes, please do that - I think that is the easy solution for this... It seems that in MSFS (2020 & 2024) aircraft developers are implementing things in their own way and don't consider at least using or updating the standard simvars available. It is a bit of a pain - means that you have to figure out how everything works for each aircraft. And, as FSUIPC is aircaft agnostic, you have to determine these things for yourself and assign/use the offsets in aircraft-specific ways. These type of values are stored in that wat as they are then integer values, and you then make the appropriate adjustment to get the floating point value. When you do things as you are, you will only get the integer component. Thats fine, if you are not interested in the decimal part, but means that a heading of 135.95 will be read as 135, which can cause issues if this is not taken into account. John

Ok. I will look into this when I have time.

I have also checked the license in that order here and it validates just fine. Are you sure that you installed the combined (2015, 2017, 2018 and 2022) redistibutables for both x64 and x86? Pleae double check that. I have also pm'ed you your key file. Save this to your FSUIPC7 installation folder and try again - the key details will be populated from this file. Try and validate it. If it doesn't validate, I can't think of anything else it could be other than the redistibutables or antivirus (please check that as well). You should also be able to run FSUIPC7 with that key file without it being validated by the installer. So, even if validation fails, try running DSUIPC7 and see if its registered. John

Please don't do this...this makes this post now difficult to understand. If you have found out what the issue was, just add another comment saying what the issue was and how you corrected it. This is then useful for anyone else who has the same issue and comes across this post. I have removed your edit. This parameter can be auto-tuned - if it is, then this is logged. If you don't want to use the auto-tuning of this parameter, you can set StartUpTuningDoneVersion=-1 This is all explained in the Advanced User guide, section Auto-tuning of initial start-up ini parameters on [ag 11. Please read that section. John

If the WASM menu isn't there, then this implies that FSUIPC could not find it under your InstalledPackagesPath (from your UserCfg.opt file). Could you please show me / attach your FSUIPC7.log file, and tell me what the value of the InstalledPackagesPath is - or, better still, attach your UserCfg.opt file as well. The location of that file should be logged in the log file, like this: John

@Daveo There is already a control available to save a flight: Trigger Auto-save. Given this, is there really a need to add an option to the file menu for this?

@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