John Dowson

Can you clarify what you mean by this? What does this mean? Do you have a reference? I'm not exactly sure what you are after, but maybe try logging the camera state offset, 0x026D. This will go through various values and then back to 2 (cockpit) (or maybe 3 - external/chase). If you log this offset, you can probably determine the value changes you need.

Yes - that is strange - maybe they are just events that are continually being sent. Many aircraft do this, and such events can be ignored using the DontLogThese ini parameter (see the documentation on using this). However, I do see that you have an axis assigned to Flaps using 'direct to FSUIPC calibration' but have not calibrated the flaps. Does this work? Usually such flaps assignment with PMDG aircraft can cause issues (especially loss of power on climb). The usual method to assign flaps for PMDG aircraft is to use the custom controls (or also preset in MSFS) to be sent on entering/leaving an axis range (i.e. using the right hand side of the axis assignment panel) - see the following topics: As for your reverser 2 issue, there is nothing I can see in the logs. One thing that can prevent the reverser activating is if the throttle is not at 0 (can be changed by setting the MaxThrottleForReverser ini parameter). So it may be worth logging the throttle values to check these are 0 - to do this, add logging for both offsets 0x088C and 0x0924 as S16. Your throttle1 and throttle2 calibrations are also different around the null zone: It is strange that the lower number is positive and not negative...although these values shouldn't really be used when calibrating throttles with no reverse zone - but maybe just set them to be the same values in the ini, just to be sure. You can also check that the out value of your throttle axes are both 0 (when no throttle is applied) in the axes joystick calibration page 3. Can you also check your assignments in MSFS are empty, just to make sure. Other than that, I will need to investigate here further as I am not familiar with the Reverser axes or how they are implemented, I won't have time today (finishing now for the weekend), but I will look into this further on Monday. John

I don't think this can have anything to do with anything in the last update, but I have attached the previous version below so that you can test with this to make sure. Just temporarily rename your current FSUIPC7.exe, download the attached to your FSUIPC7 installation folder and test with this version: FSUIPC7.exe The attached log file is of no use as there is no additional logging. Could you set logging for Events and Axes Controls and generate another log file showing your issue, and attach that together with your FSUIPC7.ini file and I will take a look. Use both Reversers 1 and 2 so that I can see any differences. Use the latest version for this! John

Note that you can do such things using calculator code (or by defining a preset for the calculator code), e.g. (A:PLANE HEADING DEGREES MAGNETIC, Degrees) near (>K:HEADING_BUG_SET)

There is no need to purchase twice... If your registration details won't validate correctly and you are sure that you have entered them correctly (using cut and paste), then it will most probably be due to not having the correct/required VC++ redistributables installed. Please see the Installation and Registration guide, section Invalid Key Details. This issue has been reported many many times and my answer is always the same. PLEASE read the documentation before posting, and also please check for similar issues. I have also moved your post to the FSUIPC7 support sub-forum. John ...etc

What aircraft are you using? Look for available presets - either using the Find Preset button in FSUIPC, or search on the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/). You can also try listing available lvars (Add-ons->WASM->List Lvars) to see if any look applicable and if so try them. You can also use logging: set logging for Events, open the logging console (Log->Open Console) and then open the doors using the virtual cockpit and see if anything is logged, and if so, you can use that. John

👍

It shows the input events that can be used for assignments, to buttons/switches & key presses natively, or via lua for axes. The same as listing available lvars (via Add-Ons->WASM->List lvats). You can also log lnput event value changes by setting Log->Input Events. This is needed to determine the values (discrete or ramge) that the input event accepts and how they relate to the function (e.g. the value for each position in a switch).

What do you mean by 'hook' in this context? You assign to input events as you would any other event type, but by checking 'Select for Input Event' (but not for axes due to calibaration issues).. Ah, no - there is no event handling function for Input Events. You can add the input event to an FSUIPC offset (via the ini file) and use the event.offset function. See the Advanced User guide on adding Input Events to offsets - basically works in the same way as adding lvars to offsets, but using a different ini section. I will look into adding an event.InputEvent lua function in a fuuture release. John

For all auto-start issues, please see

From the first post: i.e. the current trial license is valid until (and including) the 1st September. I will update/replace this license on the 3rd or 4th September. John

👍 No bother!

The size/position coordinates are only used the first time a window is created. After that, its size/position is stored in your FSUIPC ini file, under the [ExtWindow] section. To use the new coordinates, delete the entry from that ini section. You can also move/resize the window using the arrow keys and the ctrl key to toggle between move and resize. You need to give the window the focus first. John

I have no idea. There is only one version of FSUIPC, and it can either be used with or without a license. You can also download from https://fsuipc.com/. If your key is not validating, it is most likely because you do not have the required VC++ redistributables installed. Please download and install the combined (ie. for 2015, 2017, 2019 and 2022) VC++ redistibutables, both x86 and x64, from https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 John

You need to install the GoFlight driver, most probably the 64-bit version (although you don't say what version of FSUIPC or simulator you are using). The GoFlight drivers are available from https://fsuipc.com/, together with a list of supported Go Flight devices. John

FSUIPC7 is not crashing - it is MSFS that is crashing, and FSUIPC7 was then exiting as MSFS was no longer available. You will also see an exception for FSUIPC7 when the MSFS SimConnect drops, but this is nothing to worry about. So your issue is that MSFS is crashing. I cannot help with this - please see the Asobo support forums for MSFS crashes. By the way, you seem to be running FSUIPC7 from your Desktop. This is generally not a good idea - you should at least create a folder and run FSUIPC7 from a sub-folder (and preferably not on Desktop or under Documents, i.e. not in a OneDrive folder). John

As I said, once you have assigned your axes to a profile, the only way of changing this is by editing the ini, either removing the aircraft from the profile, or deleting the profile-specific axis section.

Did you read the documentation? Please see the Installation and Registration guide, section Invalid Key Issues (or the provided READme.txt). In ALL cases, this issue is ue to one of three reasons, which are: 1. You do not have the required VC++ redistributables installed 2. You aare NOT entering the details exactly as given/provided (all 3 parts must match: name, address/email and key) 3. You are using an overly-aggressive anti-virus that is blocking the validation There is absolutely nothing wrong with the validation method. You need to read the documentation. Or see one of the many many support requests, e.g. I am continually asking people what the problem was once they have validated correctly but don't get any response, and i can only assume it is due to the fact that they have either not read or nor understood the documentation. Note I have also updated the topic of this support request. Please always give an appropriate topic for your issue - 'FSUIPC7' means nothing as it applies to every single post in this forum. And please look for similar topics before posting - this one has now been reported hundreds (if not thousands) of times. John

As I have said, I would like people to upgrade when a new version is available. You should download when you see the pop-up message, and then install once you have finished the flight session, or before you start the next session. Installation of a new version takes less than a minute and should not give any issues. If you do not update to the latest version, your version of FSUIPC is no longer supported. I also release beta versions for any important changes that could cause issues, so if there are any issues, most are fixed before release. However, i cannot check everything here - for example, I have no PFC devices, there are many add-ons that use FSUIPC that I don't have, etc. So if there are any issues with a release, I would like to pick these up (and fix them) asap, not when someone has found an issue after upgrading from a version that is 5 or 6 versions old. I may consider adding an option to completely disable new version notification. However, if i do this, it will be under the condition that you no longer require support if using this option. I am closing this thread now as I have nothing further to say on this issue. John

It should still close when using the Last option - and also when using Kill - it is for this that these options are provided! So are you saying that it works when using Run/Close but not when using RunReady/CloseReady? If so, that is very strange asthere is no realdifference, apart from the time when the program is started. Also, if WideClient can't close a started program, it will not shut down automatically itself. I will look into this further in September anyway and try to work out what is happening. I don't think there is much I can do about this though, except maybe clarify things in the documentation. I will report back sometime in September. Regards, John

It may be an issue if its starting other programs, but if its working in FSUIPC it should really work in WideClient. Is it the same program, starting the same programs as on FSUIPC? If not, you could try that as a test, to make sure. I;m pretty sure that would work - WideClient hasn't changed for many years and this would have been reported earlier (many time!) if this wasn't working. But I will double check this, but, as I said, I cannot do anything now until I am back from mu holidays, in September. Ok - let me know how that goes. However, if you use kill, I don't see how your program could run the the 2nd batch job on closing.... Why don't you use FSUIPC / WideClient to start the ProSim modules? Or are you doing it this way to run the 2nd batch script on close? John

Can you check what the actual process name of the prosim process on your client PC is called (using TaskManager) - runprosim.exe may start an exe with a different name. If that is the case, you need to put the actual process name in the CloseReady1 entry, e.g. CloseReady1=Yes,"<processName>.exe" From the technical guide: Also, please try using the Last and Kill keywords (instead off Yes). John N.B. Note I am an holiday now and away from my flight PCs so cannot look into this in more detail at the moment (and I don't use or have prosim!).

Yes - I saw that when I made the second script and corrected it! As reading the value of an lvar by name is quite time consuming (as it has to go through the list of available lvars) , the script cant also be more efficient: id = ipc.getLvarId("L:Lear_LDG_Weight") if id == nil then ipc.createLvar("L:Lear_LDG_Weight",10361) while (id == nil) do ipc.sleep(50) id = ipc.getLvarId("L:Lear_LDG_Weight") end end ipc.execCalcCode(" (A:TOTAL WEIGHT, pounds) (>L:Lear_LDG_Weight) ") -- get current total weight ipc.sleep(200) ldg_wt = ipc.readLvarById(id) ldg_wt = math.floor(ldg_wt + 0.5) Basically if you are accessing an lvar by name more than once, it is better to get the id of the lvar and use the id functions. John

Even better: if ipc.getLvarId("L:Lear_LDG_Weight") == nil then ipc.createLvar("L:Lear_LDG_Weight",10361) while (ipc.getLvarId("L:Lear_LDG_Weight") == nil) do ipc.sleep(50) end end ipc.execCalcCode(" (A:TOTAL WEIGHT, pounds) (>L:Lear_LDG_Weight) ") -- get current total weight ipc.sleep(200) ldg_wt = ipc.readLvar("L:Lear_LDG_Weight") ldg_wt = math.floor(ldg_wt + 0.5)

I don't have the fenix, but if you engage vnav by pressing the altitude button, you could try the preset FNX320_FCU_ALTITUDE_KNOB_PUSH. See https://hubhop.mobiflight.com/presets/?vendor=FenixSim&aircraft=A320 for a list of the available presets for the Fenix - all MobiFlight presets are available for assignment in FSUIPC. You can also see these by using the Find Preset button in the assignments panel, after checking Select for Preset: