John Dowson

Ah, ok. Interesting.... John

Strange...can you try the attached (haven't changed the version): FSUIPC7.exe

There was a correction to what I assumed was dodgy code when offsets not in the internal FSUIPC offset table (such as the ones allocated to Linda) were written to, which is most probably the cause. Can you try the attached. John FSUIPC7.exe

Maybe its using the same virtual flags? You can change the offset/flags used in one of the scripts so that they don't clash. However, you don't need to use the hidBravoButtons lua script any more, nor the Alpha script. These scripts were needed to recognise the buttons with ids > 31. However, FSUIPC7 now recognises up to 128 buttons natively, and has done now for a long time (since v7.2.0 I think). I suggest you remove the hidBravo/Alpha scripts, and update your assignments to use the actual button numbers rather then the virtual buttons/flags that those scripts use. John

Not sure what you mean by this, but there is a change in this version with the ipcReady.lua. In this version, the ipcReady.lua is not started until lvars/hvars have been received by FSUIPC. I made this change as lua scripts that depend on hvars/lvars wouldn't have them available when starting. The ipcInit.lua is started earlier, as soon as the simconnect connection is obtained, but the lvars/hvars will not be available at this time. I will make this clear in the documentation. As for those strange lvars, they are the same in the FSUIPC log file as you get when scanning via lua, so they seem to be valid lvars. Maybe they are related to that plugin you mentioned... John

Also, please try with the latest build, attached. This is the next version I will be releasing, hopefully over the weekend. Just need to do a bit more testing and update the documentation. This version is built against the latest MSFS SDK, v0.17.0.0. John FSUIPC7.exe

What do you see when you list the lvars from the FSUIPC Add-ons->WASM->List Lvars menu item? What ids are you using when using that function? Maybe they are out of range? Of course, if out of range then nil should be returned... Maybe you can log the id with the name, and compare to the list from FSUIPC.

That is just a warning, you should be ok. I think that is because the FSUIPC_WAPID.dll (in your FSUIPC7 Utils folder) is not up-to-date. I will update this in the next release, but for now try replacing that with the attached version. John FSUIPC_WAPID.dll

That depends on what values you are talking about...If you mean lua variables, I am not sure how they are initialised - check the lua documentation. For FSUIPC flags/offsets, they are initially 0 but will be populated as data is received, or button presses, etc. Not necessarily. nil in lua means 'no object' or an uninitialised object reference. See https://findanyanswer.com/what-is-a-nil-value-in-lua. Toggle controls toggle the value as known by the FS, so if they start visible and you toggle the visibility then they become hidden - the value is irrelevant. If you are talking about FSUIPC toggle controls (e.g. offset toggle controls), they will toggle the value found in the offset. Anyway, why don't you just try it....

The STARTER1/2/3/4 SET controls were previously not recognised by simconnect and were commented-out/not available. I have just checked and they are now available so I will enable in the next FSUIPC7 release. This is now ready for release, just need to update the documentation, so I will probably release this sometime over the weekend. In the mean-time, you could try the Magento controls Magneto Set or Magneto1 Set. John

Please see the README.txt file included in the FSUIPC zip file that you downloaded. This is due to a lua crash: Unfortunately there is no information given about what lua file is causing that. Maybe that is related to linda? Maybe ask on the linda support forum to see if any one else has reported issues when closing down. Otherwise, try disabling the luas you are using one at a time to see which lua is causing this issue.

I have an offset to allow you to set lvars, activate hvars, call a preset or execute calculator code in the attached version, if you would like to try. The offset is at 0x7C50 (64 bytes), and the parameter value is at 0x780 (8 bytes). Always write the parameter first (or write both offsets together), as it is the write at offset 0x7C50 that triggers this. For lvars, the first characters must be 'L:', and the parameter value is an 8 byte string (including terminator). For hvars, the first characters must be 'H:', and the hvar must be known to FSUIPC (if it isn't known to FSUIPC, write as calc. code, e.g. '(>H:hvarName)'). For presets, the first characters must be 'P:', and the parameter is a 4-byte (dword) number (not a string!). Anything not starting 'L:', 'H:' or 'P:' is considered to be calculator code and will be executed as such. Let me know if you have any issues. Note this version has also been built against the latest MSFS SimConnect SDK (v0.17.0.0) and contains additional controls/events. I will publish details when officially released. John FSUIPC7.exe

FSUIPC should now recognise up to 128 buttons. And the encoder buttons are recognised in the assignments, so I don't think that is the issue. What are the button numbers (not assignment indexes) for the unrecognised encoder buttons (i.e. the numbers you see in the assignment panel)? Your FSUIPC7.ini would tell me - still waiting to see that... You could try an assignment to your button numbers 63 and 64 to check that there is not a limit somewhere that makes it fail after button number 63 (which will be your 64th button). Unfortunately I don't have any devices with so many buttons so difficult for me to test. i will look into this in more detail, probably at the weekend - I need to finalise and release the next FSUIPC version (v7.2.17 or possibly v7.3.0) in the next day or two, and I will look into this in more detail once that is released. John Later: you could try activating all of your buttons with numbers > 57 to se which ones are logged (open the logging console and see if recognised when pressed, although you will only get the joystick values logged if not assigned. I'll test with a virtual device at the weekend.

👍 If you have not yet updated to 7.2.16, please do as this includes direct access to the Mobiflight presets (i.e. you can assign to them directly). These are probably easier to use than using lvars/hvars in macros, and you can use the MobiFlight HubHob site to search for existing presets by aircraft and subsystem (as well as key words). You can also create your own presets using lvars, hvars, etc. John

The additional lua libraries/functions provided by FSUIPC are defined in the document FSUIPC Lua Library, which should be available in pdf format in your FSUIPC documentation folder. John

Glad you found the problem! Good to hear! Regards, John

If you had checked your ini file you would find that your key assignments to control 1070 are invalid and have been ignored: The 'C' character is not needed in key assignments. Remove those and try again. Attach your ini and log file (keyboard keys) again if any issues. John

I've tested here and cannot see any issues. Try setting the ServerName parameter in your WideClient.ini file rather than using the address (maybe this has changed?). Also, if you still can't connect, try disabling any firewalls on both the client and slave PCs.

Sorry, it is buttons 157 and 156, for assignments with indexes 82 and 80. I understand your issue but do not understand why the other encoders aren't being logged - at least the button numbers should be logged when triggered. It is normal for the encoder button numbers to be n and n+1. The assignment indexes don't matter really - they will only be logged if there is an assignment to the button. I'm not sure why nothing is being logged for some of your encoders - i will take a look at the code to see if there is any further logging I can activate or add. John

There should be no change to WideFS between those versions. Can you attach your WideServer.log and WideClient.log files, as well as your FSUIPC7.log file.

That won't work and I don't understand why you would even do that. There is no such section as [L:vars]. Please read the documentation and not invent your own syntax. To assign to an lvar, you need to create a macro file (*.mcro), or add it to an offset and assign your button to one of the offset controls. John

Your code doesn't make much sense. To define the table you should use: TableA = { ... } Why are you using the io library? For logging, use ipc.log. Your readTableA function also makes no sense - I am surprised that doesn't give an error as the for loop syntax is not correct... Try an on-line lua tutorial to understand the basics, and take a look at some of the example lua scripts provided.

Can you please attach your FSUIPC7.ini so that I can see your assignments. Your log shows the AP_VS_VAR_INC and AP_VS_VAR_DEC being sent on buttons 82 and 80. There are no AP_MACH_VAR_DEC or AP_MACH_VAR_INC controls sent from your "working" encoder.

Sounds like Asobo haven't connected the simvar to the visuals. I don't think there is much that can be done about this at the moment, except maybe to raise a bug report to Asobo to get this fixed. John

Try searching for relevant key words... For the A32NX (Asobo and FBW - the latter is more functional....) try the MobiFlight HubHob site to see what presets are available (https://hubhop.mobiflight.com/). MobiFlight presets are directly assignable in the latest FSUIPC7 release, v7.2.16. The PMDG 737 for MSFS has still not been released, as far as I am aware... See Appendix 3 in the Advanced User Guide 'Handling VRInsight serial devices in FSUIPC' and the document Lua Plugins for VRInsight Devices.pdf if you want to use FSUIPC for this device. John