John Dowson

First, please try just using a simple script to test if it is a problem with the sound., i.e. just sound.path("F:\\FSUIPC") sound.play("bong",2) Also try the other things mentioned, i.e. sound.path("F:\\FSUIPC\\") ipc.log("Playing sound on device 0...") sound.play("bong",0, 100) sleep(1000) ipc.log("Playing sound on device 1...") sound.play("bong",1, 100) sleep(1000) ipc.log("Playing sound on device 2...") sound.play("bong",2, 100) ... etc You don't need to read the lvar as you can use the value variable, or change to function MOUSE_NOSMK_SWITCH(varname, smkNEW, userParameter)

Which A2A aircraft are you using? I have looked at the A2A Cherokee and in this aircraft the L:NotesPage lvar doesn't seem to do anything. Assigning to the Kneeboard View control with a parameter of 5 will display the (kneeboard) checklist, and sending the same again will remove the display (i.e. it acts like a toggle). But the checklist it displays is empty... For the A2A pre-flight checklist, I can assign to the control Panel 8 to toggle this on/off. and use the Next Sub View and Prev Sub View controls to move through the checklist pages. You can also try listing the values of the lvars (using the List Local Panel Variables control). See what the value is before you try and in/dec it, and then check the value again after you have sent an inc and dec control. For me, this lvar always has a value of 0, indicating that is is (probably) not writeable, i.e. read-only.

Are you sure the lua file is actually running? I have tested here and everything seems to be working as expected. Try logging Lua Plugins to make sure the script is being executed, with the logging console open (Log -> Open Console). Also try those tests as mentioned by @ark1320. Note you can also exclude the .wav extension (i.e. sound.play("bong",2)), but that shouldn't make any difference... John

All logged events come from the simulator. Many MSFS aircraft continually emit certain events, and such events emitted vary by aircraft. You can ignore these by using the DontLogThese ini parameter, best used in a profile section - see the Advanced User guide for details. That is strange - you don't usually get aircraft events shown when in the main menu. What aircraft do you have loaded? The events shown will not depend upon any devices, unless it is that device (usually a joystick type device) that is programmed/assigned to send the events. However, FSUIPC will not send any assigned controls/events when the FS is in the main menu.. I don't think the logging of these events can be related to the stuttering, You can try with logging disabled. You can also try in dev mode and open the MSFS (logging) console to see what messages are logged there. You can also post/attach your full FSUIPC7.log file here and I will take a look - can't tell much from a snapshot of a log extract. John

As the \ is a lua escape character, you need to use \\, so try: sound.path("F:\\MSFS Backup\\Mobiflight") sound.play("bong.wav",2) If the script is exiting after the play instruction, you may also need to add a delay, e.g. ipc.sleep(2000) John

The license has been updated.

Please do this with the com data logged,, and with a simple script that shows this issue. Also set Log -> Extras.

I will update tomorrow....

Note your issue seems to be similar to this one, for which the ComWriteLoopTime ini parameter was added, and when the defaults were changed from 20 to 10ms: Try playing around with different values for those parameters to see if this improves things.

You have an event registered on offset 0x652C, which is an offset in the PMDG offset area: If you are not using PMDG aircraft, how is that offset populated? Ok, then this is the event.com one: There was a change in com read/write loops in 7.3.18: You can try reverting to the previous values by setting:; ComReadLoopTime=20 ComWriteLoopTime=20 in the [General] section of your FSUIPC7.ini file. As I have said, the lua interface in FSUIPPC7 is exactly the same as that in FSUIPC5. If it is slower, I have no idea why and cannot do anything about this. Can't say it's PMDG cuz those happening before sending or receiving events/offsets, also as i said even print("hello world") is slower, it can't be about PMDG 🙂 I just tested print("hello world") again; sent around 40-60 trigger string around in 3 seconds to both of them, i couldnt count FSUIPC5 hello world prints but can easily count for FSUIPC7 and its just 13 times. But I need to see the actual script running to make any sense of the log - there is no point sending me a different script than the one running, so if you are going to remove parts of it then I need to see the log generated with that script, not the original So can I assume that your issue is with the lua com interface only? I am not in a position to be able to test the com interface here. Try with those parameters I mentioned above to see if that makes a difference. I will go through any other com interfaces changes to see if they could possibly cause this, and maybe provide you with an older version to test. You can also try logging com data to see if that reveals anything. Suggest you initially do this with a minimal lua script that shows your issue, like your Hello World example. To log com data, in FSUIPC7, enter a Log -> Custom value of x40. in FSUIPC5, add the following to the [General] section of your FSUIPC5.ini file: Debug=Please LogExtras=0x40 That is basically what those ini parameters do. However, they are set to 10 in FSUIPC7 and 20 in FSUIPC5, so FSUIPC7 should be faster...

Its thee FSUIPC6 documentation, under your windows Documents\FSUIPC6 folder. There is an offset status document, and a separate document for the PMDG offsets.

Your log files do not show the exaamplecode.lua running. If you want me to spend time looking into this. I need to see the actual scripts that are running, and the log files showing these scripts running., and also a description of where in the log file you think that there is a performance issue. Also, if waiting for an event on an offset change, you should add FSUIPC logging for that offset. Note also the examplecode.lua you provided is waiting for am offset change in the PMDG offset area. This is updated on reception of the client data from PMDG. The PMDG aircraft for P3D and MSFS are very different, and I suspect the performance issue relates to the delivery & reception of the PMDG data, not the performance of the event waiting for this data change. Try logging the offset that you are waiting for the event on. This will show you when the offset value has changed, and when the event should be triggered. If FSUIPC7 is seeing less PMDG offset changes than FSUIPC5, then the PMDG aircraft is sending less client data packets, and you should ask about this on the PMDG forums. I think the differences in performance you are seeing are due to the PMDG aircraft, not FSUIPC.

Then send it by DM/PM... What exactly "triggers" faster/slower? And what do you mean by 'does more triggers'?

As I said, I want to see your script and log files, not a video...there is no way I can tell what is happening from a video of the console log.....

There should be no difference in the actual execution of lua scripts, as the lua engine in FSUIPC7 is identical to the one in FSUIPC5. Any difference will be due to the simulator being used, and also, as FSUIPC5 is an embedded dll in P3D, and FSUIPC7 is a separate application, there will be a slight overhead with the communication to the FS (via SimConnect). What exactly is much slower? Can you show me the script, and both an FSUIPC7.log file and FSUIPC5.log file showing this performance issue.

You can log any offset - see the right-hand side of the Logging tab, and the User Guide, starting from page 17. You need to look/search the Offset status document for general offsets, and the PMDG offset document for PMDG specific ones. For the general offsets, see: And for the PMDG 737 specific ones, I can only see the following offset specific to the NGXu : Although there are others for annunciators relating to the auto-throttle state, e.g.: John

As I said, that is not needed in the latest version as that is now the default. You need to set this to the appropriate number if you want the pump offsets populated - see the Offset status document for details. No problem. Glad you isolated the issue - and maybe you should report this to GSX. Regards, John

But you still need to use the latest version, which includes the changes in that older beta version. As i said previously, please try with the console log open, and see what, if anything, is logged just before this pause, during and after - and using the latest released version. Did you install the WASM? Can you try with that installed, but without any other software (e.g. your Java Simulations glare fcu panel) to see if you get this pause/stutter then. Also try with the MSFS console window open (you need to be in dev mode), and see if MSFS is reporting anything.

But why are you doing this? That thread is old and the version there is older than the released version, which is also why you are getting those warnings. Please try the latest released version.

What version of FSUIPC7 are you using? You say you are using the latest as-of today, but 7.3.20 is the latest and should be using WAPI 1.0.2. Check the version logged at the top of your FSUIPC7.log file. Those warnings indicate a mismatch between the installed version of FSUIPC7 and the FSUIPC WASM module, but should not cause any issues. To resolve, make sure you are running the latest version of FSUIPC7, which I don't think you can be... John

First, please do not post continuation logs for support, i.e. do NOT use the New Log feature. I always need to see the full log file. Looking at your log file, you can see: 751343 LUA: Could not open HID This is most probably due to the fact that the device is a keyboard device. Are the keys not recognised by FSUIPC7 in the key assignments panel? If not, you could try setting UseKeyboardHook=Yes in the [General] section of your FSUIPC7.ini file. This will tell FSUIPC7 to receive its keyboard input directly from Windows rather than from MSFS. and can help when using additional keyboard controllers. See the Advanced User guide for details. For this issue, your logs show that FSUIPC is behaving as expected. The problem is that FSUIPC is continually seeing button press and release events, and so is acting on these press/release events and setting/clearing the parking brake. Is the same happening for your other button assignments on your Saitek Pro Flight Quadrant? e.g. what about these assignments: If the same thing is happening with the other buttons, then you need to try and determine what update caused this. Did you install any Saitek drivers or software? If so, try removing that - you should only use the windows default drivers with Saitek controllers if using FSUIPC. Otherwise, if it is only happening for this button, I suspect that there is a hardware issue with that button... John

That is the default and not needed. Every time? Do you have auto-save enabled? FSUIPC doesn't do anything special on touchdown. Do you see anything in your FSUIPC7.log file? You can post/attach it here, but it would be better if you could try landing with the FSUIPC logging console open (Log -> Open Console...) and see what, if anything, is logged when this occurs.

Yes, of course. John

You can use event.terminate to get a callback in a lua script before it is stopped. You can also try with event.sim to get notification of certain sim events, including aircraft change, although I am not sure how reliable these events are in MSFS.

No - this file is from 24/03/2023 and from FSUIPC7 version 7.3.19, whereas your FSUIPC7.ini file is from version 7.3.20 (the latest version). If you cannot see the FSUIPC7.log file, you probably have windows explorer set to hide the extension of known file types. Then, if you have set the logging as I have asked, then either the extension is hidden, as with the FSUIPC7.log file, or the lua script is not running. How are you starting the HidDemo.lua script? I see no [Auto] section in your FSUIPC7.ini that starts this. So, please check that the lua script is actually running. Then, once you have confirmed that it is running, please provide the files I asked for with the logging asked for (and no other logging). For your parking brake issue, please also attach the ini file for the aircraft/profile that you are using, and please keep the test as short as possible, i.e. load your aircraft, press the button to activate the parking brake, then release. Then exit FSUIPC7 and show me the files requested. Note that you have two issues, and I expect to see two sets of files, one for each issue, as they are not related. In future, please create a separate topic for each issue. Looking at the in you attached. it looks like you are trying to comment out lines by using the double back-slash '//'. Those characters do NOT designate a comment in an ini file. Use the semicolon ';' instead. Also, change to i.e. use substrings for your aircraft profile names John