John Dowson

It won't be "recognized" by FSUIPC as a device, as it is a keyboard device. FSUIPC just receives the keyboard input from such devices from windows, and if it is sending keys then they should be picked-up in FSUIPC's keyboard assignment panel. Is this device actually sending any keys? Is there some configuration software that you use to determine what keys this is sending? If you open another app (e.g. notepad or notepad++) does that receive input/key strokes from this devices? Did you check the other button assignment (as I mentioned) on this device? If that has the same problem, it will be a problem with the device. If not, it will be an issue only with that button,

You did - it was the log file that was missing.

Yes - LINDA is a lua interface built on top of FSUIPC's lua facilities. Not necessarily - only if LINDA has a module/lua script that supports that hardware, otherwise you would have to write your own. You should ask about this on the LINDA support forum. The VRInsight MCP works with FSUIPC as we provide support for this device within FSUIPC (see appendix 3 in the Advanced User guide). Why do you want to send me that - it is of no use to me. I will not be adding any special support for this device. No. It is really up to the hardware provider to provide the software for this device. If this is not available, then you would have to see if it can be controlled using the lua com interface, and write your own lua script to handle this. Or maybe check if MobiFlight support this device. No, sorry. John

I will take a look and get back to you. John

Could you please also attach your FSUIPC6.ini file the next time you show me your files. Have you installed any saitek drivers? If so, please remove them and let windows install the default windows drivers. There is certainly something strange going on.... first, the joyscan file shows only 3 HID devices, and all showing the same GUID: And in your registry, there are multiple entries for the yoke with one using the same id as one of your throttle quadrants: And your ini file shows only one throttle quadrant and the yoke detected, missing your pedals and 2nd throttle quadrant: The first thing to do is to switch to using JoyLetters - this helps prevent issues and aids recovery when ids and guids change in the registry. To do this, change the AutoAssignLetters ini parameter in your [JoyNames] section (shown above) from No to Yes. Then run P3D/FSUIPC and exit. This will update your ini to use JoyLetters. After that, you need to clean the registry entries. To do this, first run regedit and take a back-up of your registry, then exit regedit. Disconnect your yoke and throttles, and download and run (i.e. double-click it in windows explorer) the attached regedit script: removeDevices.reg Then reboot your PC, and then reconnect your yoke and throttle. Run P3D with FSUIPC6 - just load an aircraft and then exit. Then show me/attach your updated 3 files - FSUIPC6.log, FSUIPC6.ini and FSUIPC6.JoyScan.csv, John

I don't think the version is the problem, and updating to v6 probably won't fix this, whatever the issue is. I could provide you with a trial/time-limited license if you would like to try it. No - you just need to rename your FSUIPC5.ini to FSUIPC6.ini and your settings will be preserved. John

I've also just tried the GFLeds-G58.lua with the Cessna 172 and it also works for this aircraft, so no need to resort to using lvars. The latest script should work for most aircraft, and for the ones it doesn't you will need to adjust and provide a separate script for that aircraft. For now, I suggest that you just install the script and add it to your general [Auto] section, i.e. [Auto] 1=Lua GFLeds-G58 It will than be started for all aircraft. If it doesn't work for a specific aircraft, you can then look at that on a case-by-case basis. Probably also better to change the name of that script to just GFLeds.lua, as it is not G58 specific (and change the name to match in your [Auto] section). John

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.