John Dowson

I know what an .ODS file is, and use OpenOffice myself. But the file you posted is junk - it contains the following: Of what use is that? And it is NOT a .ods file. It is a .ods# file, and the name starts with '.lock'.... so, as I said, useless.

What do you mean? And what does that mean? Any elevator value coming from the joystick axis will also change the elevator position. if you want to know what is happening, activating logging for axis values, open the logging console and look at the elevator axi controls logged - this should tell you what is happening. John

What lua file? You haven't mentioned lua before, and I have not seen any lua files from you. Can we please stick to one problem at a time. I am not going to look at those, as I have no idea what you are doing with lua... That looks ok (except it should be 'Lua' not 'lua', but that shouldn't matter, but change just in case). I presume you didn't insert the [LuaFiles] entry, and this was created by FSUIPC, no? If so, then I don't know why your lua isn't running - there are no lua scripts being started according to your log. As for your 'keyboard keys' log, what exactly am I looking for? Why have you attached such a large log? Have you looked at this yourself to try and work out what is happening? I am certainly not going to go through a log file containing over 4000 lines with no indication from you what the problem is (i.e. what key press do you think is not performing as expected?) You can see the key presses registered, and the actions taken on that key press. What is incorrect? Why don't you try keeping the log open and see what messages are logged when you press your buttons or keys. This should tell you what is happening, and if it is not as expected, then show me (i.e. a concrete example of an individual key press that is not behaving as you expect).

You can try assigning to the Axis Elevator Set or the Elevator Set control with a parameter of 0 (both of these controls use the range (-16383 - +16383). John

Not sure what that file you attached is - looks to be an editor lock file, completely useless.... What are you assigning to? If it is the inc and dec controls, they do not accept any parameters. First, activate logging for events and axis controls, open the logging console (Log -> Open Console) and see what events are logged when you move the flaps lever in the UI. This should indicate what controls you can use. You can also try assigning to the flaps offset at 0x0BDC. First, monitor this offset (using FSUIPC's offset monitoring facilities) and check the values logged when you move the flaps lever in the UI. If they are changing as expected, you can assign your buttons to the Offset UDword Increment/Decrement controls. Doing this will use the Flaps Set control when you press one of the assignment buttons to inc/dec the value in that control. Alternatively, you can check what lvars are available for the aircraft (Add-ons -> WASM -> List Lvars). Maybe there is an lvar that you can use? If you see one that looks like it might control the flaps, you can try changing its value (using the provided facilities) to see if updating it has any affect. If so, you can add that lvar to and FSUIPC offset and control by assigning your buttons to change the value in that offset. As I don't have this add-on aircraft, I cannot really advise any further. You need to investigate and try the various options. John

Yes to all. You can also add comments to your myevents.txt with the control number to be used for offset 0x3110. Yes, this file will be installed and overwrite the existing file each time you update, which is why its better to use the myevents.txt file. You can also uncheck the option to install that file (in the installer). Yes, you can also do that.

Please read the manual more carefully...it does first say: That is the one that is installed. If you change the settings there, they will be over-written the next time you install FSUIPC7 (i.e. on the next release/update). To prevent this, you should use the second location. Also, as the manual states: That is because you have not created one, or made a copy of the original in that location. You only need to do this if changing any settings that you want to stay on an update. This should be clear from the documentation... John

Confirmed that buttons 64-95 aren't working correctly, although 96-127 are (as well as 0-63). This is an issue both in FSUIPC6 and FSUIPC7. I will look into this next week. John

I have released FSUIPCv7.3.0 now, so please download and re-install to get the updated documentation. John

Sorry, the control number is wrong. The first control will be 0x400000 and not 0x40000, so the first one will be 4194304 (and not 262144). Of course, if you also install the events.txt file then that control will be the first preset in that file, and it will be difficult to determine the control number for your own presets (which is why I suggest you don't use that file!). John

I will be updating the documentation today. I did provide instructions in a post earlier in this thread, where I attached the beta for this functionality - check that. Not sure how you would write strings to that offset from SIOC though... Checked writing a preset control number to 0x3110 and this is no longer working. I will look into it. John

Ok, so it looks like button numbers > 63 aren't working. I will look into this tomorrow. Thanks for the update. John

That looks strange - it is trying to send as a normal control than as calculator code. I will look into this. Why not try the new offset 0x7C50, where you can use the preset name directly? I've attached the latest FSUIPC7 version that i will be releasing later today. John FSUIPC7.exe

👍 Thanks!

Can you verify the attached please. This is the version I will release tomorrow, v7.3.0 John FSUIPC7.exe

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