John Dowson

👍

Hi Al, you have asked for support so many times now, I don't understand why I still have to ask to see your FSUIPC7.ini and FSUIPC7.log files for such questions... Please show them to me, the latter with logging for Buttons & Keys as well as Events activated, and where you have pressed such an assigned button. It certainly is working, as that is how my POV is assigned and I certainly would have noticed if that wasn't working... John

I don't think the MSFS sensitivity settings have any affect if not assigned in MSFS, but you can try it... You should usually calibrate in FSUIPC, but I don't think its possible with the *_EX1 axis controls at the moment. I did look into allowing this when the *_EX1 axis controls were introduced (I have a code branch somewhere that allows this), but there were issues (can't remember what now!) and I never got around to completing this - it is on my ToDo list, but not sure when I will get around to looking at this again at the moment. John

👍😎

This wasn't so difficult... Please try the attached version. You should add the following line to the end of your script: ipc.control(1156) -- set focus to FSUIPC This will prevent MSFS from receiving and acting upon the key presses. You should also add the following line before your ipc.exit() calls: ipc.control(1125) -- restore focus to MSFS The other changes you should make, as explained earlier, is to register for release and repeat events by setting the downup parameter to 7, and modify your handling function to ignore releases and repeats. This will then prevent any FSUIPC assignments being triggered while your plugin is active. John FSUIPC7.exe

I have tried this and it doesn't work - this only stops keys going to other lower priority applications that have requested the keys, and doesn't prevent MSFS acting upon them. I have also implemented this, but it is of no use. Key input is currently only being received from MSFS, so if MSFS does not have the focus, no key input is received. I may look into keyboard input when FSUIPC has the focus, but this may take a while.

Yes, I don't update that section very often. If you want to read away from your PC, just copy the latest manuals from your FSUIPC documents folder to the device you will be using. Then use lua, as I have advised. Everything I have said is still applicable. A simvar is a simulator A-type variable. An offset is an FSUIPC memory location. Some FSUIPC memory locations/offsets hold the value of simvars (not all), and some allow you to write to them which will trigger FSUIPC to tell the sim to update the simvar either directly or by sending an event/control. That link says that it is using the simvar. So, if you are using the cockpit UI, you need a lua script to monitor the lvar value (using event.lvar() - no need to add the lvar to an offset), and in the event handling function you could try to write the value received directly to offset 0x341D, If that doesn't work (i.e. writing to the offset doesn't update its value), then you can use the ipc.execCalcCode("<code>") function instead to set the simvar using the <code> 0 (>A:CABIN SEATBELTS ALERT SWITCH,bool) or 1 (>A:CABIN SEATBELTS ALERT SWITCH,bool) depending upon the value received (i.e. of the lvar). John

To see what control are being used, you can activate logging for Axes Controls, open the logging console (Log->Open Console...), and then move the throttle in the cockpit UI to see what controls (if any) are logged, and then use them. However, for the Fenix, it has been reported that you first need to calibrate your throttle in the Fenix MCDU, and then assign as 'Send to FS as normal axis' using the Throttle 1/2 Axis Set Ex1 controls. See John

FSUIPC does not forget settings. This is just not possible. Why, don't you still have P3D and the FSUIPC version that goes with it? If so, just fire it up and take a look at your assignments, or look at the FSUIPC ini file that you use/used with P3D - this will hold your assignments. Yes - this is usually the Throttle Decr control which you send on repeat to reverse once the throttle is in idle, and then you send a Throttle Cut control to stop the reversers. Please see the following thread for further discussions and details on how to configure reversers for the PMDG 737 in MSFS: John

Simvars are created by the FS, and can be used by the aircraft or not. It is the aircraft (model) that creates the lvars. Is PACX reading that simvar, or accessing its value via the FSUIPC offset? Either way, the first thing to try is updating that simvar. Doing this will NOT have the desired affect (i.e. will not set or toggle the seatbelt switch) - you need to use the preset/calculator code for that, but you need to cgeckif the simvar is updated upon request. You may find that this I not the case if the simvar isn't being used, but a simple test of writing to the offset and then reading it back should tell you this. If it isn't being updated, and PACX is reading the FSUIPC offset for this value, you will need to 'spoof' the value of this offset with the value of the lvar. The latest documentation is always included with the latest FSUIPC release. The latest Advanced User Guide is dated May 2022 and was last updated for FSUIPC7 v7.3.5. The latest FSUIPC7 version is v7.3.6. Uf the manual you are looking at is dated Jan 2021, that is extremely old now. Please download and install the latest version of FSUIPC7. I recommend that you always check you are using the latest version of FSUIPC before asking/posting in the support forums. Only the latest version of each major FSUIPC version is ever supported. John

Increasing the LvarScanDelay IS the way you solve this. Listing lvars is NOT a solution, as this would still not add any lvars to offsets - this is only done on the first scan, as I said. I cannot change the fact that lvars are created such a long time after aircraft load, only provide facilities to allow for this, which I have done. But why list lvars? Just perform a rescan/reload. You can do this in lua using ipc.reloadWASM(). You can even create a small lua script that calls this on a timer (event.timer) periodically (say, every 10seconds). The script can also exit itself once all the lvars you are using are loaded and available (and it is no longer needed). You can check if an lvar is available by using ipc.getLvarId(“name”) - the returned value would be nil if the lvar doesn't exist. Alternatively, you could have a section in your script that checks the availability of the lvars you are using before it starts to use them, and if not available then perform a ipc.reloadWASM() until they are.

You control the [Auto] section, and the format of that line is not correct - if the file is called master_caut.lua, then the [Auto] section entry to start that lua would be: 3=Lua master_caut Please see the Advanced User guide, section Automatic running of Macros and Lua plugins on page 41 if the Advanced User Guide. If you don't specify Lua, it us assumed you are trying to auto-start a macro file. Not sure what this means - I do not use MobiFlight and cannot help with this. You could always take a look at LINDA, which comes with a support module (i.e. lua scripts) for the Maddog X - see https://www.avsim.com/forums/topic/532362-leonardo-maddogx-module-13/. Even if you don't use LINDA, it may be worth taking a look at the scripts they provide to see how things work for that aircraft. But not that you cannot use the LINDA scripts without installing/using LINDA (due to dependencies). See https://www.avsim.com/forums/forum/424-linda/ for more information on LINDA. ¡Saludos desde Galicia! John

You need to use a lua script, with event.offset (on 0xA000 ) that calls a handling function that writes the offset value (0x341D) when the lvar offset (0xA000) changes. However, this is probably not what you want, as writing to that offset may not actually change the offset value if the simvar is not being used by the aircraft. It may work, you need to try this. Alternatively, what you may need is to 'spoof' the offset 0x341D to the value of offset 0xA000, so when anything external tries to read offset 0x341D, it actually gets the value stored in offset 0xA000. The spoofing facility is in offset 0x0024 - if you search the forums, there are various examples on how to use this facility, most recently for spoofing the Parking Brake for the A320. I would recommend that you use presets rather than MobiFlight events. The MF preset for that calculator code is called ASCRJ_OVHD_SEAT_BELTS_SWITCH, and is directly assignable in FSUIPC7 with the control Preset:ASCRJ Ovhd Seat Belts Switch. All MobiFlight events are available using presets, and you do not need to install the MobiFlight WASM module to use them (as you would if you used the actual events). Please see the section on the WASM module in the Advanced User guide to understand presets and how to use them. Also take a look at the MF Hub Hop preset list (https://hubhop.mobiflight.com/presets/). That is a good resource for finding presets available for any aircraft. You can also download the latest events.txt file from that site (you need to create an account first) which you can do if there is a preset mentioned there that is not currently available in FSUIPC7. The MF events.txt file included with FSUIPC7 is only updated when I release a new version of FSUIPC7. John

As I keep saying, you need to increase the LvarScanDelay further. To see the actual lvars currently available, assign a button or key to the control List local panel vars. If you use that, no rescan will be performed and you will see that the lvars you are using are not available, due to your LvarScanDelay parameter being too low. There is nothing that FSUIPC7 can use that tells it when ALL lvars are available, and indeed, some lvars are created quite some time after aircraft load. Also, take a look at the index numbers of the lvars you are using - the higher the number, the later they are created. I suspect the ones you are using are created after some time. Yes - lvars are only added to offsets on initial load, after the first scan. They are not added to offsets on a rescan. This is why you should increase the LvarScanDelay to an appropriate value, when ALL the lvars you are using are available. I am spending a lot of time on this and just repeating myself. It is obvious, to me at least, what your issue is, and I am telling you how to solve this. PLEASE just follow my advice, it would save us both a lot of time... John

This is because a rescan is performed when you list the lvars... I don't like this really but was implemented upon a request from LINDA. I think I'll remove this automatic re-scan and make it dependent on an ini parameter.

See my previous comment...

This indicates that the lvar was not found on the initial scan. When you list the lvars, a re-scan is performed, and so the lvar becomes available. You need to increase the LvarScanDelay WASM ini parameter so that the scan is performed after the lvars gave been created. I suggest you change/set this to between 45 and 60 (seconds) if/when using complex aircraft. And don't do this in your Community folder WASM ini as that will be overwritten - use the WASM permanent storage area (see the Advanced User Guide, WASM section, for details).

I cannot see those errors in the log file you attached. Please attach a log file showing the errors - and always exit FSUIPC7 before attaching an FSUIPC7.log file. You can also set Debuf level logging in the WAPI - add the following line to the [WAPI] section of your FSUIPC7.ini file: LogLevel=Debug John

This sounds like it could be an AutoSave issue - complex planes can take a long time to save. This is compounded if the folder where flights are saved is being scanned/protected by an anti-virus program. So, first exclude your saved flights folder from any antivirus that you are using, or disable Autosave if you are not using that facility. Any further issues, please attach your FSUIPC7.log file.

@auroraisluna This is not a crash - FSUIPC7 is exiting, as the log message says. I do nor know why new users do not look at the documentation...there is a README.txt file (the clue is in the name) which tells you what you need to do for this issue: There are also many many support requests about the same problem - most recently Please check the forum for exiting posts on the same issue before posting - and ALWAYS check the documentation. This would save us both time. John

One other thing I will add and test is a new ini parameter TrapMSFSKeys - when set to Yes, this will request that all single key press events to not trigger MSFS assignments. This was not working in earlier versions of MSFS but I haven't tested this in a while. I will add and test tomorrow and post a new version for you to try if working. If not working, I will add a new FSUIPC control that will attempt to set the focus to FSUIPC (away from MSFS) so that key assignments are not triggered.

Click the Ignore Axis button. That will ignore a jittering axis so that other axes can be recognised and assigned. John

Ok, I think I understand what is happening a lot better now. First, the LuaTrapKeyEvent ini parameter is working, but this prevents the FSUIPC assignments on the key not the MSFS assignments. However, the default value is Yes, which is why setting it to this value has no affect. You can set to No if/when you don't want these keys trapped. MSFS key assignments will always be acted upon when MSFS has the focus, but not when the focus is elsewhere (including FSUIPC). So your key down assignment wasn't being acted upon (or logged) as it was being trapped by your lua event.key functions. However, as you are only trapping the key press, the ley release isn't being trapped and your assignments are being called. If you want to prevent this, trap the press and release event (which you can then ignore in your handling function if you so wish). I think (but haven't tested) that this also applies to repeat key press events - if you don't trap the repeat, any assignments to a repeated key will take affect. So, to stop all FSUIPC assignments, you need to trap the press, repeats and release. As with releases, you can ignore repeats (or not, as you wish) in your handling function. The shift flags are also incorrectly documented for the event.key function - they are the same values as documented in the Advanced User manual, page 25. I have also added 1 additional flag: +512 - trap key events This can be used when LuaTrapKeyEvent is set to No and you want fine-grain control got each event.key assignment. I have also added a bit more logging in the attached version (mainly for when keys are trapped) if you would like to try. It should be clearer what is going on using this. John FSUIPC7.exe

I have tested your script here and it works as expected here... Your issue, from your log, is that the keydown events aren't being sent from MSFS - I do not know why this is. Could you maybe check your script using a different aircraft, to see if its the Fenix that is interfering. I can't do much about it if the event is being sent... There does also seem to be an issue with your key down assignment not being triggered when no repeat is set as the first keydown has the repeat flag set - I will check this further here.

You have to assign the axes before you can calibrate - did you do that? That is where your controllers axes are bound to the relevant functions. And if you previously calibrated with a different controller, then the calibration page will show the previous calibration settings. Calibration settings are either general or bound to a profile, not to a controller. You should just re-calibrate - click Reset to remove the calibration and re-calibrate, or just calibrate again... John