John Dowson

As I said, that script uses offsets, so should be valid with all aircraft that use the simvars associated to those offsets. You should just try it. For the aircraft that don't use the simvars associated to those offsets, you will need to look at the lvars instead and adjust the script accordingly, and as I showed in the first lua script I posted (for the Cessna 172). For the yaw damper, try offset 0x0808. Then find the appropriate offset or lvar that holds the state/position of the fuel pumps/alternator, and add the appropriate code to the lua script. I have shown you how to do this now for both when offsets (bits or otherwise) and lvars hold the state of the function that is needed to control the light state, so you should be able to use and adapt those for your needs. I cannot write everything for you - just take a look at the scripts I have provided, as well as the FSUIPC documentation, and you should be able to use and adapt those scripts for any use case / aircraft. John

Please see the attached script. This works for the G58 for all your switches in the order you specified (Landing lights, taxi lights, nav, panel, beacon, strobe, yaw, pitot) except yaw, as I am not sure what that is. Note that this script used the general lights offset at 0x0D0C, and the pitot heat offset at 0x029C. As it uses the general offsets, it should work with all aircraft that use these offsets. For those that don't, you need to find what holds the state to control the light, such as an lvar. The script for the Cessna 172 I posted earlier uses lvars instead of offsets. John GFLeds-G58.lua I have also noticed a difference in the way GF device are detected (I think!). I have two each of the GFP8, GFT8 & GFRP48. These used to be detected as separate devices, i.e. each with a unique joy#. However, now only the GFRP48s are recognised as two separate devices with unique joy ids (or device numbers). Only 1 device number is given to both of the GFP8s and GFT8s, with the button/switch numbers on one going from 0-7, and from 8-15 on the other. Not sure when or how this happened...

Then rename it to be a .lya file... Which "other"? What do you mean by "yaw"? Just create a text document then rename it to a lua file. Then you will most probably have to write a script for each aircraft, although some may be compatible with each other, Alternatively, you could just write a simpler script that switches the leds on when in the up position and off in the down position, but I think that is a lor less useful. I can look at the G58 and give you an updated script for that, or maybe a general script if you prefer that. John

But doing it that way means you need two macro files. Better to leave the parameter out of the macro file, and add it to the button assignment to the macro, and this will then be passed-in, As the Advanced User guide says: John

These were the references I was using - no comma before the checksum: http://receiverhelp.trimble.com/oem-gnss/NMEA-0183messages_PASHR.html https://docs.novatel.com/OEM7/Content/SPAN_Logs/PASHR.htm Are you sure you want this added?

Yes, that seems strange - no other sentences have this additional comma. I have added in the attached: FSUIPC6.dll John

Parameter d is the GPS Quality flag, and e the IMU state flag. You said: Which is why they are always 1 and 4. Do you want me to just change e ( IMU state flag) from 4 to 1? As I previously said, I do not know how to calculate these values so have just hard-coded the values that you asked for.

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.