John Dowson

Yes. There are other interfaces - WebAssembly (for WASM development) and JavaScript - see the MSFS SDK documentation. FSUIPC also uses a WASM module, which runs in the sim itself, and communicates to FSUIPC (an external application in MSFS) using SimConnect Client Data Areas. To develop anything that runs in the sim itself, you need to use the WebAssembly API. You can also use SimConnect in WebAssembly, and you also have access to the Gauge API, as well as other APIs (Network, MapView, NanoVG).

I think the problem is the parameter you are using with the macro control assignment. For the inc and dec controls, the parameter is used to determine the max and min values respectively. You are using a parameter value of 0 for both the inc and dec controls, and so the dec control is working as expected and decrementing to 0. However, as the max value for the inc control is also 0, it will not increment this value past 0. To correct for this, you need to set the parameter for the inc control to the max value this lvar accepts, which will be the number of pages -1 (as page numbers in the lvar start from 0 not 1). For the cherokee, this is 5 as there are 6 pages. You can also use the Panel 2 control to show/hide this checklist. John

Then I have no idea why its slower, and I'm not sure if there is anything I can do about this either. I will do some general lua performance tests here at some point, but not sure when I will have time to do this.

The SimCommect API has changed but is basically the same, although some functions have been deprecated and are no longer available. You should just try building your application against the MSFS SDK. You can download this from MSFS itself - you need to be in dev mode to do this. You will probably find that more changes are needed due to the PMDG aircraft, rather than the simconnect API. The Simconnect API documentation is available here: https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/SimConnect_SDK.htm John

You should fist check the provided FSUIPC documentation, the User Guide and the Advanced User guide. The documentation on adding lvars to offsets is in the WASM section of the Advanced User guide, starting on page 46. However: Those are hvars, not lvars, and you cannot add them to FSUIPC offsets as they do not have a value. How to use hvars is also described in the documentation. However, the easiest way to use a hvar is to create a preset to use it (again, see Advanced User guide). What you need to do is to add the following to a file called myevents.txt (create this if it doesn't exist) located in your FSUIPC7 installation folder: My_Scroll_Up#(>H:checklist_scroll_up) My_Scroll_Down#(>H:checklist_scroll_down) My_Select#(>H:checklist_checklist_select) Restart FSUIPC7 (if it is running) to reload the events, and then you can use the Key assignment panel to assign to the presets My Scroll Up, etc by checking the Select for Preset checkbox.

There have been various minor changes but none that could affect the performance so much. There was one change to locking which could affect performance with event-based lua scripts, but the change was made so that events would not be lost (i.e. previously an event would be lost if a required resource was being used, but with this change the lua thread waits for the resource). I have reversed this update in the attached version (7.3.21c) if you could try it, to see if it is this change that is making the difference: FSUIPC7.exe If its not this, I really have no idea why the general lua performance has changed, and am also at a loss as to how to investigate this. Is more PC more heavily loaded when running MSFS compared to P3D?

It looks to be that bomg.wav file. I tried using that file here and get the same issue. I have added extra logging and it looks like it cannot read (or convert) the format of that wav file. Looking at that wav file, it could be one or all of the following: - is using a bits_per_sample value of 24, the ones I am using use 16 - is using 2 channels, the ones I am using use 1 - the bit rate is 2304000, the ones I am using use 705600 - sample rate is 48000, the ones I am using use 44100 ...or something else. I could look into adding code to handle/convert this format, but I am no expert on wav file formats so this may take a while. I converted that bong.wav using this online tool and this plays as expected, so please try this: bong.wav John Later: I think its the bits_per_sample value of 24 that is the issue....

The error indicates that the bong.wav couldn't be found/opened. Are you sure its called bong.wav? The ones you attached were called: bong.wav.0645ec9f6c9d603625c03bbececf9f2f.wav bong.wav.6131c136275a2d1df950f9af7a19cf17.wav Have you tried with a different .wav file? Did you update the sound.path call in your test script for this as well? Looks like its still referencing the old folder name: 19766 Sound: Id 1, PlayNow("F:\FSUIPC\bong") 19766 Sound: Id 1, PlayTheSound("F:\FSUIPC\bong.wav") That is probably the cause if the current "mmioOpen Failed" error.

It would have been better to NOT Log Lua Separately, so that the lua log and sound logging can be seen together, but looking at your files it looks as though it is trying to play the sound file, but something strange is going on,... This is my lof extract from a similar test: Note that the id is changing (yours is always 1) and the DeActivate and EndPlay messages, which are missing from your log. Apart from this issue, is your audio working ok? Could you check the windows Event viewer, to see if there are any events logged relating to audio. You could try updating your VC++ redistributables to see if this is an issue (see the Installation and Registration guide for details). Other than that, I don't understand why this isn't working. I will look at the code tomorrow to see what could be causing the id not to increment and why those log messages are missing. Could you also attach the bong.wav file so I can test with that to exclude that being the issue - and maybe try with another sound file.

You can also try without the sound.path call, and have the .wav sound file in your FSUIPC7 installation folder.

No. Also please add logging for sound by setting a Log->Custom value of x20.

Thanks Al, also tried that as well with no luck. Can you please do this with Log -> Lua Plugins set, and show me both the lua script and your FSUIPC7.log file after the test. Also try with other devices (0,1,3,4,5,6,7,8) and with also setting the volume parameter to 100.

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'?