John Dowson

You could also register for an event but do nothing in the event handling function- just registering for the event will keep your script running/window open. You could even use a timer event if you wanted to close the window after a number of seconds/minutes. The lua script that updates the window could run the lua that creates the window if the window isn't available/created yet, or use the handle if the window was available. If using an endless loop to keep the window open, maybe add a sleep call in the loop body. John

👍

Thanks for the update. No need to feel like an idiot - this has been a problem for quite a few folks and it wasn't clear what the issue was. Did you assign to the discrete position presets using the right-hand side of the axis assignment panel, or did you try the axis preset I gave above? Maybe if you could post/share your assignments, this will help others. Cheers, John

This is the calculator code for that preset: @ 20 - 10.03 / near 0 max 100 min s0 l0 5 < if{ 714101 (>K:ROTOR_BRAKE) quit } l0 15 < if{ 714201 (>K:ROTOR_BRAKE) quit } l0 35 < if{ 714301 (>K:ROTOR_BRAKE) quit } l0 50 < if{ 714401 (>K:ROTOR_BRAKE) quit } l0 64 < if{ 714501 (>K:ROTOR_BRAKE) quit } l0 75 < if{ 714601 (>K:ROTOR_BRAKE) quit } l0 85 < if{ 714701 (>K:ROTOR_BRAKE) quit } l0 98 < if{ 714801 (>K:ROTOR_BRAKE) quit } 714901 (>K:ROTOR_BRAKE) This looks to be written for an axis/potentiometer range of 20 - 1023. To change to a standard range of -16383 to +16383, you can use the following (i.e. add this to your myevents.txt file and then assign your axis to it): My_PMDG_B737_Flaps_Set#@ 16383 + 327.68 / near 0 max 100 min s0 l0 5 < if{ 714101 (>K:ROTOR_BRAKE) quit } l0 15 < if{ 714201 (>K:ROTOR_BRAKE) quit } l0 35 < if{ 714301 (>K:ROTOR_BRAKE) quit } l0 50 < if{ 714401 (>K:ROTOR_BRAKE) quit } l0 64 < if{ 714501 (>K:ROTOR_BRAKE) quit } l0 75 < if{ 714601 (>K:ROTOR_BRAKE) quit } l0 85 < if{ 714701 (>K:ROTOR_BRAKE) quit } l0 98 < if{ 714801 (>K:ROTOR_BRAKE) quit } 714901 (>K:ROTOR_BRAKE) John

Then you need support from PACX / TFDI Design - cannot help with 3rd party programs from other developers. Be aware that if running FSUIPC7 as admin, all 3rd party programs must also be ran as admin, as well as MSFS2020 itself. Everything that communicates needs to be ran at the same privilege level. John

If you want the window to be always open, then you should have one script that creates the window and then waits for events to update the windows contents. The events could be anything - an offset change, a flag change, a button or key press/release, an event, etc. You do not need two scripts, or to create the window each time.

Another user has reported a similar issue and has determined that it is the flaps calibration that is causing this issue. So maybe try with just the flaps calibration removed, and maybe re-assign your flaps differently if you cannot use them without calibration. See John

How are/were your flaps assigned? Rather than assigning a flaps lever to an axis, for the PMDG you can assign to the presets that move the flaps between the discrete positions, using the PMDG B737 Set Flaps n presets (where n is 1,2,5,10,15,25,30,40 or Up - 9 discrete positions). You can do this on the right-hand side of the axes assignment panel. Alternatively, you can define a preset that does this (in a myevents.txt file) on an axis, similar to the PMDG B737 Flaps Set (Potentiometer) preset but adjusted for your axis range, and then assign your axis to this preset.

You can do that but I would not recommend it - a script should run and exit when finished. There is no other way to keep a lua thread running as this should not be necessary. Create the window in the other script and try to eliminate whatever is causing the "flashing".

Hi @Jackiie. If you are still having this issue, now that you can assign directly to Input Events you could try assigning to the input event AUTOPILOT_KAP140_1_ALT with a parameter of 1. This will simulate the actual button press and toggle between VS and ALT modes, and should give the same behavior as pressing the button. John

After looking into this further, I don't think i will be implementing this. Issues arise when there is a long press but only an event on a short press - should the short press function still be called? Presumably so, otherwise this would effect existing behavior, but this then means the function called depends on the events registered which is a pain to handle...This is also problematic with switches which are like buttons but are 'always on' or 'always off', which can also give issues (as FSUIPC doesn't know the difference between a button and a switch, it just sees the change events. Note there are already lua scripts that you can use to handle long and double button presses - see John

👍

This issue is specific to PMDG and I think it is due to FSUIPC's calibration facilities which work well with PMDG aircraft. Try assigning your elevator and trim axes with Send to FS as normal axis and remove/reset any calibration.

I think this may be due to the calibration of the elevator, or maybe the flaps. PMDG aircraft in P3D don't play well with FSUIPC calibration due to priority levels, so maybe this is also the issue with PMDG aircraft in MSFS. Try calibrating the elevator again and see id the problem returns. If so, switch to assigning with Send to FS as normal axis and remove/reset the calibration.

Thanks for reporting back. John

If you would just read the comment where the key file is available, it would save us both some time: As the installer is showing the trial license details, the key file is already in the correct place, i.e. your FSUIPC7 installation folder. John

This change is already implemented in the latest beta if you would like to try it, available here:

If there are no controls logged, you could also try listing the available lvars to see if any look appropriate, and if so try those. Otherwise, you can try using mouse macros.

It is valid. However, trial licenses are NOT validated by the installer. as it says in the comment where the license is available....

If using FSX/FSUIPC4, please use the main support forum. You posted in the FSUIPC7 / MSFS sub-forum. I have moved your post. Try activating logging for events, open the logging console and switch of an engine using the VC. See what control/parameter is logged and try using/assigning to that.

What aircraft are you using? If this is the PMDG 737, then there is already a thread om this topic: Otherwise I need to see your FSUIPC7.ini and FSUIPC7log files, the latter with logging for Events and Axis Controls set, and also add monitoring for the elevator trim offset 0x0BC0 as S16.

For which aircraft? You can try with the standard controls/offsets to see if they work, but for some aircraft you will need to use lvars or presets. It sounds like you just need to assign your key press to the FS control Toggle Taxi Lights - have you tried that? Otherwise, try searching for a preset for the aircraft you are using. If there are only separate on/off controls, you can assign your key press to both controls, and add an offset condition to determine which control to send depending on the current state of the lights. You can check if offset 0x0D0C bit 3 is set or not to determine the current state of the lights. You can also assign to set/clear/toggle bits on that offset to control various lights.

What offset are you using to drive the LED? Sorry but this doesn't mean anything to me. You may have better luck asking about this on the MobiFlight Discord channel, or on Dash support.

You can use event.cancel to remove all event tracking on the same function. This seems overly complicated. Why not just use one script that has a flag (or two) which determine if the brakes should fail or not. You can then set/clear these flags by using an ipcParam variable, and using an event.param function in your script, and assigning with LuaValue to tell the script when to set and clear the brakes failure flags. John

Did you check and try everything in the documentation? i.e. setting the workgroup, checking your firewalls (client, server and router - test with all disabled), Please see the Configure your Network section of the WideFS user guide. Try with the server name specified in the WideClient.ini rather than the IP address, and you should also specify the protocol (try with TCP). Also check that WideServer is activated and running in FSUIPC7. Note that you will need to have an aircraft loaded and ready-to-fly before wideserver is activated and wideclient can connect. I am not sure what those pm log files are or why you attached them. Please also attach your FSUIPC7.log and .ini files.