John Dowson

Should be reasonably straight-forward with a lua script. When you say 'a linear increase in P3D from 70% to 100% throttle' what sort of increase do you mean? How long would you want this increase to take to get from 70% to 100%? Presumably a 1% increment delta over this period would be sufficiently 'linear', no? I can take a look at this for you when I get time - maybe on Sunday if I get a chance... John

So the throttle input values are the same, conditions are the same (i.e. wind speed and direction), but you cannot achieve the same airspeed? This does sound strange... The title says 'Until FSUIPC is Disconnected' - does this mean that if you assign the throttle in MSFS and have FSUIPC7 running but not controlling the throttle, you still get the same issue? And if you stop FSUIPC7, you then get increased power? What if you run FSIOPC7 with no assignments (i.e. temporarily rename your FSUIPC7.ini file)? Please clarify. Maybe you could also verify the input throttle values are the same when assigned in MSFS as when assigned in FSUIPC7. To do this, activate logging for Axis Controls in FSUIPC, open the logging console and monitor the parameters to the "Throttle Axis Set Ex1" event. Do this when throttle assigned in MSFS and when throttle assigned in FSUIPC7 and see if the parameter values for those controls look roughly the same.

Yes - didn't we discuss this before? Or maybe that was someone else...anyway, its fixed (in next release) and attached below, John A32NX FBW.hvar

You shouldn't have done this as all your previous assignments are still available. This occurs if your GUIDs change. Rather than re-assigning everything, you can just update the [JoyNames] section to match the new GUID. I can help with this. Looks like something strange is going on - your xbox 360 controller os being given the same GUID of your CH Eclipse Yoke for some reason. Don't you have an xbox 360 controller as well? Can you please respond to this question (may help): What changed from when it was working until now? I will take a look in detail tomorrow and get back to you. John

This is not quire correct. A variable (simvar or A:var) is a variable, that can be read-only or read-write. A control is an event, an action that changes something. An event can update one or more simvars, but there is no direct translation (in many cases) between an event and the simvars that it can change, although this can sometimes be determined. If you look at the FSUIPC offset document for FSUIPC 4/5/6, in the write column you will see something like Ok-SimC and Ok-SimE. The former implies that the simvar is updated directly (the simvar must be writeable) while the latter indicates that an event/control is sent for the write operation. I have an idea to allow the user to add any simvar (including a specific simvar index) to a free offset, and maybe also allow already allocated offsets to be re-purposed to hold different simvars. This will be for reading, but I could also allow writing/updating if the simvar is writeable. This functionality is the next piece on my list to look into. Depending on how busy support keeps me, I should be able to start looking into this in detail in a couple of weeks. John

Ah....logging in FSUIPC should have indicated this... Glad you finally fixed this issue. John

Only your CH Pedals are now recognised correctly: The name for the yoke cannot be read correctly - it is blank for some reason. This is the second time this week I have seen this issue, no idea what is causing this at the moment. What changed from when it was working until now? How many devices do you have? Id it just the CH yoke and pedals, or do you have another device? I ask as you have assignments to devices B, C, D and E which all look like they are assigned to the yoke, and you have no assignments at all to your pedals. Did you previously lose your assignments to the yoke and then re-assign for some reason? Can you show me your FSUIPC7.log and FSUIPC7.JoyScan.csv files please. John

There are no standard controls for EFIS commands. Which aircraft are you using? The A320 or FBW A320? You most probably need to look at the available lvars and hvars for the aircraft you are using. You can use the MobiFlight hubhop resource (https://hubhop.mobiflight.com/#/list) to see that the MobiFLight preset uses and try to use that, or you can install the MF WASM module, use the provided MF event files (in your FSUIPC7 EventFiles folder) and use the MF presets directly. I could help you set-up one button/function if you like and you can take it from there. I am currently looking at adding additional functionality to FSUIPC7 to make calculator code (such as that provided by the MF preset list) easier to use. John

Is FSUIPC7 still running when you attached that log or did it crash? If the latter, can you temporarily unplug/disconnect the Fanetic device to see if it is the empty name causing this. If FSUIPC7 is running ok, do you have any more issues? John

Yes, you could try that if all the information you need is available in the MakeRunways output files. Be aware that these are large as they contain all airports/runways, so you might find that this will take a while processing such a large amount of data... Good luck if you try this! Cheers, John

FYI, he condition lever controls/events are now recognised in the latest MSFS / SDK release and will be available in the next FSUIPC7 release, v7.2.16, hopefully to be released by the end of the week or possibly early next week. John

FYI, he condition lever controls/events are now recognised in the latest MSFS / SDK release and will be available in the next FSUIPC7 release, v7.2.16, hopefully to be released by the end of the week or possibly early next week. John

Sorry, but I have no idea what the MSFS control txt file you are referring to is - can you please explain? The Documents/FSUIPC7 folder should contain the FSUIPC7 documentation. One of the file in there will be the Controls List for MSFS Build 999.txt file if that is what you are referring to. However, note that this is created on-the-fly, once you have an aircraft loaded and ready-to-fly (or maybe once an active simconnect connection is established, which maybe earlier). John

Those files you posted are useless to me as they are from an unregistered version. You need to copy the FSUIPC7.exe downloaded to your FSUIPC7 installation folder, replacing the existing one (and where your FSUIPC7.key file is located), and run it from there. So you won't be assigning these via FSUIPC then? If not, you should be ok with the latest version i posted. However, I would still like to understand why the FSUIPC7 can't get the Fanetic device name, so please post those files again when you have ran it correctly. John

I haven't checked this since the last time over a year ago (October 2020). I will take another look when time permits, although there isn't much I can do if the data returned from the SimConnect_RequestFacilitiesList call doesn't actually contain the closest airports, which was previously the case. It is FSUIPC that determines which are the 6 closest from the complete list received. If the closest airports aren't being returned, I don't think there is much else that can be done in FSUIPC. John

Except that you can't start MSFS from FSUIPC7....! The provided desktop link (which calls the MSFS.bat file) simply displays a splash screen and then starts MSFS. It is MSFS that then starts FSUIPC7, if you have installed the auto-start component. The only other difference from using the FSUIPC-provided MSFS desktop icon to start MSFS is that if it is an MS Store installed version, it will be started with the FastLaunch option - for Steam installs, you have to configure this in the Steam client. John

Do you mean the splash screen? That should appear for a dew seconds and then disappear. FSUIPC7 always starts iconised to your system tray. No idea, but I doubt very much this is related to FSUIPC7. When it starts, it does not even connect to MSFS until a minute or two later (when MSFS is ready). I have no idea what your issue is... are you sure that it is just not taking time to load? Takes a few minutes here, depending upon what is in your Community folder, and what the current/previous aircraft loaded is/was. You can verify that this has nothing to do with FSUIPC7 by just temporarily renaming the FSUIPC7.exe (e.g. FSUIPC7.exe.unused). You will get a dialog saying that FSUIPC7 cannot be found/started, but the loading process will continue. For any issues with MSFS, you should use the Asobo forums. John

This is normal. When MSFS crashes, this causes a fault (but not fatal) in FSIOPC as the connection to the simulator is lost. FSUIPC will detect this and then close down gracefully, as indicated by your log: It is MSFS. FSUIPC7 is a separate executable and in no way should it cause MSFS to crash. Try checking the Asobo / MSFS forums for any possible causes (there are many!), and report your issue to Asobo if you cannot find anything that looks relevant to your situation. John

There is a version available, v7/2/16c, including an updated WASM, that has a 1k limit for the calculator code if you would like to try it. It can be found here: http://www.fsuipc.com/download/Install_FSUIPC7v7.2.16c.zip John

Did you get any further with your issue? I just updated my original SPAD to the 64-bit version from that post you kindly shared, and when I run this version the gear lever works without issues in the JF arrow with the default profile, no configuration needed at all. I really don't understand why this is not working for you. John

What is that file? Never heard of it... To use hvars, you have to make them known to FSUIPC7 by adding a *.hvar file, where the name of the file is a substring match to the aircraft name. The file MUST be in one of two locations. Please see the Advanced User guide for details. Also note that I haver no idea what hvars are available for any particular aircraft. It is up to you to discover these. I have provided some *.hvar files (in the HvarFiles sub-folder). To use any of these, they must be copied (and renamed to match the aircraft that you want to use them for) to one of the two locations where hvar files are active. John

This issue could be caused by the OEMName string being returned in unicode format, although I don't understand how this can be. Could you please try the attached version, where I have changed to explicitly call the ansi version. Please keep the current log settings active - again, just run this (without MSFS) and show me the log file produced. Also, please let me know what devices/controllers you are actually using. I do not understand the different devices you previously had in the FSUIPC7.ini file you posted. Please also attached the latest version of that file, and also the latest FSUIPC7.JoyScan.csv file. John FSUIPC7.exe

Hi Detlef, Thanks. FSUIPC4, 5 and 6 use a similar windows hook to get the keyboard input, but as an embedded dll it only gets the input when the FS has the focus. As I previously said, I do not like the idea of grabbing all keyboard input regardless of focus, as this would cause issue for mot (i.e. the majority) of FSUIPC users. However, this does seems to be an issue when using additional 'keyboard type' devices. But, the issue with these is that they are not recognised by MSFS, and so the keyboard input is not forwarded to FSUIPC7 via SimConnect input events. I can look into adding a global hook for keyboard input. If I do this, it will be activated on a new ini parameter (i.e. not active by default), and if/when activated, I will disable the keyboard input from SimConnect (to prevent multiple inputs). However, as I am very busy on other things at the moment, I am not sure when I will have time to look into this fully - maybe in 2-3 months or so, but earlier if I get a chance... Thanks for the kind offer, but this shouldn't be necessary. I should be able to implement and test sufficiently using a standard keyboard (or two!). I can also post here for you to try once implemented. Thanks and regards, John

They are just the index numbers for those items, All section item that are not parameters (i.e. parameter=value) will have an automatically assigned index number that increment by 1 each time. You have "2" and "6" as assignment lines 1, 3, 4 & 5 have been removed. Please see the Advanced User guide for a description on the format of the various ini file sections. John

Yes, this is a known issue with MSFA and has been present since launch. It is even worse that what you describe - If you load the Aerosoft CRJ directly without even loading the FBW A320, you will still see the FBW A320 lvars by just having that aircraft in your Community folder. This is why many folks clear there Community folder to just include the add0ins they are going to use for the current flight, and restart MSFS in between flights, changing the contents of the add-ons folder as needed. Many people use the MSFS add-on manager to help with this. Current maximum is 2044 lvars. Your file only contains 1547 so you are no where near the maximum. If all lvars are not loaded, give it more time before the lvar scan is performed (see LvarScanDelay WASM ini parameter, as I gave already mentioned) or perform a WASM-> Reload. Yes, known issue since inception. Nothing to be done, except restart and start with a 'clean' Community folder if this bothers you. There is nothing I can do about this as far as I am aware. The FSUIPC WASM just iterates the known lvars for the currently loaded aircraft, and this is what is returned. John