John Dowson

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:

What part? And what part don't you understand? In which panel? as I said, you cannot change this in the axis panel. In button & key assignments, you can assign a button to either a profile or not, and should be able to check/uncheck the profile-specific checkbox accordingly. If this is not clear, please provide more information - what arte you trying to do? Which panels are you using - axis, button or key assignments?

For PMDG aircraft, you can use the provided custom controls. See For the NG3, the custom controls are: #define EVT_MCP_VNAV_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 386) #define EVT_MCP_LNAV_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 397) You can also use FSUIPC's logging facilities to determine what is being used: set logging for Events, open the logging console and see what is logged when you press the switch in the virtual cockpit. This will be a custom control using the Rotor Brake control, which is an alternative method of using PMDG custom controls, also described here: (N.B. when logging events in many add-on aircraft you will see many events being continually logged - you should ignore such events using the DontLogThese ini parameter) For the Fenix, you can also use logging to determine what is being used. If no events are logged, try listing the available lvars (Add-ons ->WASM->List Lvars) to see if any look applicable.

There are a few things that could be improved in the script: 1. You only need to create the lvar once, do you should handle this if the script is being called multiple times. 2. If you create an lvar using ipc.creatLvar, you don't need to reload the WASM afterwards - this is done automatically. As for the timing issue, lvar values are, by default, updated and send out from the WASM at a frequency of 6Hz, so roughly every 166ms.Therefore a delay of 100ms is not going to be enough most of the time, although this depends on the timings. Taking into account the time needed to send and process the request, you would need a delay of 200ms to make sure the new value had been received. if you want faster updates, you can set the WASM ini parameter LvarUpdateFrequency to VisualFrame. if ipc.getLvarId("L:Lear_LDG_Weight") == nil then ipc.createLvar("L:Lear_LDG_Weight",10361) ipc.sleep(600) 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)

Thanks for this - I will move it to the User Contributions section. Also note that another way to use the mode switch to have different assignments to the same button/switch depending on the mode switch positiin is to use compound assignments. You need to manually edit the FSUIPC7.ini file to do this, and the method is documented in the Advanced User guide. However, this is only applicable to button (and key) assignments, not for axis assignments. John

Your license information is available in your SimMarket account. John

Yes, you need a radar.bmp file for any of this to work. This was provided by ActiveSky, but that functionality isnt available for MSFS. Once you have the radar.bmp file then sharing/displaying shouldnt be a problem. But I do not know how you can generate such a file with MSFS. Note I am on holiday now until September. John

👍

You just add it to your ini and it akways applies. But dont switch it off (i.e.set to yes), try setting it to Enum first. This will still monitor, but using a different method.

Just caught me in time... Currently lua is the only possible way to do this. I will look into allowing 2 parameters for events at some point, but I have a few more urgent things that I need to do before I can look into this. Note I am now on holiday until September, although I will be checking for support issues occasionally. John

Please also note that I am now on holiday until September, although I will check for support issues occasionally. I am now out-of-contact until Monday though. John

As with all other users who report this, your key validates just fine. I will pm you a key file and try this. Save the key file to your FSUIPC installation folder, then re-run the installer and validate the key by clicking the Register button at the end of the installation process, If it validates, then the only possible reason that you are unable to register is that you did not enter the details correctly. If it does not validate, and you have installed the required VC++ redistibutables, then it can only be your anti-virus software blocking the validation - please check that.. Can you PLEASE respond once you have done this. I would like to understand why so many people are having this issue so that I can update the documentation accordingly, but nobody is responding. John

Do NOT manually edit the [LuaFiles] section. This section is maintained by FSUIPC. Your script is never running, so the offset will not get updated. Before you write the axis value to an offset, check if you can use either offset 0x3416 / 0x3418. If you just want notification that the brakes are being used, you could also try the 'brake being used' flag in offset 0x32F9. So check these offsets first. If none of those offsets are working, then maybe consider using a lua script. If those offsets don't work and you want help with a lua script for this, it would help me if you could provide a log, with logging set as previously advised. Note that I am now on holiday until September, but I should have time to look at this again on Monday if you need help with a lua script (so please provide the log file before then). John

👍

You can do that but I wouldn't recommend it, especially if the app connects to MSFS or FSUIPC. The batch file will also be overwritten/replaced whenever you update FSUIPC7 as well, and you would lose any changes. FSUIPC provides facilities to start other programs (registered/licensed version only) - you should use that. These facilities provide options to delay the start of the program until MSFS has started or until an aircraft is ready to fly, can also close or kill the program when MSFS exits, as well as other options. See the section Programs: facilities to load and run additional programs on page 44 of the Advanced User guide. John

The log looks good! I think the lesson from this thread is that if you want to calibrate any axis in FSUIPC for the iFly 737, then you also need to have the axis assigned in FSUiPC using the send direct to FSUIPC calibration option, and not the send to FS as normal axis one. I consider this topic closed now (unless you have any more issues). You can remove the logging now, including removing the [Auto] section to start the lvar logging lua script. Regards, John

By "switching off", do you mean that FSUIPC exited? You log file shows that FSUIPC was running for just under 6 hours and then exited as MSFS was no longer running. If MSFS was still running, you can try setting the DisableMSFSMonitor ini parameter to Enum or Yes. From the Advanced User guide: John

Thats good news! I will check your logs tomorrow, but I would suspect it was the change in assigning the toe brakes using 'direct to FSUIPC calibration', instead of 'send to FS as normal axis'. I cant see how the other axes assigned in P3D could cause this, especially as it was working without the toe brake axes being calibrated in FSUIPC, and you only get the issue when the Toe brakes were calibrated. Some (complex) aircraft dont play well when using FSUIPCs axes calibration facilities when an axis is assigned in P3D or in FSUIPC using 'send to FS as normal axis'. For such axes, you should assign using 'send direct to FSUIPC calibration' and calibrate. This is also the better/preferred/recommended method anyway. The underlying issue is complex but due to conflicting priority levels used to trap and mask events in FSUIPC and the actual aircraft. John

Is FSUIPC7 running? Is it connected to MSFS? Check your FSUIPC7.log file... You can also try adding Init3308=13 to the [General] section of your FSUIPC7.ini file. This will pre-populate offset 0x3308 with the version number for MSFS2020 (13) which is needed by some add-ons. If using MSFS2024, set this to 14 - although some add-ons not yet updated for MSFS2024 may still require this to be 13. Your add-ons must also be running at the same privilege level as FSUIPC7, so check they are either all running with standard privileges or all with admin privileges. There are also many other posts on connection issues with VAMSYS - check those. And if you still have issues, when FSUIPC7 IS running and IS connected to MSFS, AND you have added the init3308 parameter to your ini file, then show me / attach your FSUIPC7.log file and I will take a look. John

To log the lvars, please save the attached script to your FSUIPC6 installation folder: logLvars.lua Then add the following to your FSUIPC6.ini file: Before take-off, please again rotate the autobrake switch through the settings so that I can see the values associated with each setting. You can also now remove the assignment to list the lvars as it is no longer needed. John Later: I have also now added logging for the lvars when the OnGround flag changes,