John Dowson

That is a load of rubbish...just read the documentation and try it - it will be a simple script (that you also need to auto-start) using event.offsetmask and in the handling function ipc.writeUB. Yoiu can use logging (ipc.log) and FSUIPC's lua debug log facilitiies to help you. Start with the lua plugin documentation and lua library documentation look at a few of the provided examples. The Advanced User guide shows you how to auto-start the lua. John

You cannot set them - the PMDG offsets are read only. To control PMDG aircraft, use custom controls - see the following FAQ entry:

That doesn't tell me anything I'm afraid...I would need to see the full log - you can try zipping and attaching... You have quite a few simconnect connections running: 322, 323, 324, 325, 326, 334, 335, 336 & 337 - at least, according to that short log extract, and all of them just giving errors... What are all those connections (a full log file would tell me....)? Search for Open: strings - that will tell you the connection name and thus the programs using them... Your SimConnect is certainly having issues before the I/O error with all those exceptions reported... John

I see offsets 65F3/65F4 alternating between 0/1 when the AP annunciator is flashing orange, and 65F1/65F2 alternating between 9/1 when flashing red (and the alarm sounding), so those offset certainly seem to be working. And also offsets 65F5/65F6 alternating between 1/0 when the A/T annunciator is flashing orange. So all seems ok to me - haven't checked 65F3/65F4, but presume those are also ok. So, the annunciator offsets for A/P P/RST, A/T P/RST, FMC P/RST all seem to be correct. John

Did you do as I advised? i.e. do not use your client to request lvar updates, use the WASM...that is what you should try first... Need to see the logging around this, and the full log would be interesting.... John

Well, the SDK has been published so you can raise a ticket on this issue now if needed - or I guess I could do this... Are 65F1/65F2 (MAIN_annunAP) and 65F5/65F6 (MAIN_annunAT) still not populated correctly (it was commented that 65F9 holding MAIN_annunFMC was)? Please try first with the latest 737-700 version (3.0.56) and let me know if those are working or not. John

You can use a lua script that monitors an offset and when it changes the handling function can write the required value to another offset, using event.offset - or, if it is a bit change as in your case, use event.offsetmask. See the FSUI{C Lua Library document on using this function. Presumably you just want to monitor the bits 0 and/or 1 values of offset 0x7390, and write those to a free byte offset for the BFF program to read. John

Yes. It is a consequence of the throttle axis that you have assigned to, which accepts that value range. This is what calibration does - calibrates your devices axis range to that accepted by the axis you have assigned to: So what is your 'axis calibration issue' then? If it is just a question, please say that it is a question in the topic title, not issue. I wouldn't worry about this. I don't fully understand all aspects of the calibration, and a lot of the stuff is there for historic purposes and for support of older controls, some of which probably aren't that relevant to MSFS. John

As I said, if you have a boxed version you need to update and install the service packs before you can use FSUIPC4.

There is no access to lvars via simconnect - they are only accessible via the gauges API and are handled by the FSUIPC WASM module. And in the WASM I can scan for lvars programmatically, and so can get the names of all the ones available. There is no such method to scan for a:vars (or hvars, or any other variable type). And all lvars are a fixed size, so there is no added complication determining their size - they are all treated as doubles. That seems to be the way most add-ons are going anyway, and a:vars cannot be added by an add-on, only used. All a:vars are provided by the FS and documented in the SDK. John

Oh - and you could also enable a simconnect log to see if that shows anything...if needed, try what I have already advised first...

Then why is there no logging for that call? Maybe you need to set the logging level to Trace for this - can you do this please. You also have your client application requesting lvar updates. It is better to have the WASM push the updates instead - which it does by default anyway. Try setting the lvar update frequency to 0 (wasmPtr->setLvarUpdateFrequency(0)) and use the WASM ini parameter LvarUpdateFrequency to set the required frequency for updates. Could it be a threading issue? There are no critical sections around the executeCalaculatorCode calls as I didn't think these were needed as the the SimConnect_SetClientData calls should be thread-safe. If you are using multiple threads, you could try adding a CS around your executeCalaculatorCode calls to see if that improves things. Anyway, for now just update your logging to Trace, use the WASM for the lvar updates, and show me (attach please, not paste the contents) the log file if it happens with that change. See https://devblogs.microsoft.com/visualstudio/debugging-external-sources-with-visual-studio/. Note that there is a debug enabled library available for the WAPI, no pdb file though but the source for the WAPI is available on github. And I am not suggesting you debug the WAPI (this shouldn't be necessary anyway!), but to use the debugger to try and determine what is occurring when you get the first error. But try without the client requesting lvar updates for now - this has caused some issues in the past for some developers using the WAPI, but I don't understand why, This was the default method that FSUIPC used before I decided to switch to updating via the WASM, and I never saw any issues (and none were reported in FSUIPC). John

Not really as I don't see how this can work. How would you read/set them if not from offsets? Or are you talking about using lua? But even with that, you would need to read them from somewhere... Currently I am reading lvars using simconnect. It is not a straightforward process - you don't just ask for the value of a simvar, you have to add it to a data definition and then request that data definition on some sort of interval (basically, although it is more complicated than that). You then receive the values asynchronously. these then need to be put somewhere so that they can be accessed somehow. It is now possible to access a:vars via calculator code in a WASM, but accessing this way would also present the same issues - if not more.... It would be a request/response (again, asynchronous), and allowing this via WASM communication (which is via Client Data Areas, again using SimConnect) would mean that you would basically have to implement a simconnect-style a:var access system using CDAs, and do this in a way to make the interface easy to use/understandable to a non-programmer. I really can't see how this can be done. It is a lot more work for me (if even possible - would be a lot of work to even think about how this could be implemented) for minimal benefit (if any) for a small user subset. You would still need to know the names, sizes and units of the simvars - or do you expect me to make these all available somehow and continually update these as well? And currently there is no work for me, as I am no longer adding simvars to offsets on request - this is why I have provided the current mechanism for (advanced) users to be able to add any simvar to an offset, so that I no longer have to do this. I could possibly add a UI instead of using the myOffsets.txt file, but if this UI was to present all available a:vars with there default units/size and the possible conversions available 9and maybe a descriptive text, this would basically mean that I would have to incorporate the MSFS simvar documentation into FSUIPC7 and keep this updated...again, a lot of work for little benefit - and no real cost benefit as I don't think this would improve my sales, which I also have to consider. My time is actually quite limited for updates/improvements, as most (if not all) of my time is taken up on support issues and keeping up with MSFS/P3D and SDK updates. Regards, John

It doesn't...that just adds the aircraft with the new livery to the profile section. As I said, you only have assignments to keys and buttons in the profile. To see these in the buttons and keys windows, you have to then manually check the profile specific checkbox before you press the button/key- this is not checked by default in buttons and keys, only in axes, as it is possible to add general button/key assignments even when using a profile for the loaded aircraft (as general assignments to buttons and keys are inherited, if not overwritten). This does cause some confusion. I will look into updating so that the buttons/keys will register a profile-specific assignment when a button/key is pressed even if the profile-specific checkbox isn't ticked - and automatically tick the checkbox to show that it is a profile specific assignment. John

Most probably the lua wasn't running initially as the [LuaFiles] section would only have been created the first time you ran FSUIPC and so the [Auto[ section would have not started the lua, and the 2nd time everything is correctly in place and so the lua was started. Anyway, glad its working - hope it solves your issue... John

Ok. But better if you could catch/trace in a debugger.

First, you are using an old and unsupported version of FSUIPC7 (7.3.12) - only the latest version is supported, which is version 7.3.16. Please update. What is it 'wiping'? I cannot see how this can occur, but if you think this is happening then I need to see your ini both before this wipe and after. together with the log from the session where this occurred. So, make a backup/copy of your ini file before you make any changes. Your current ini only shows one key assignment and 3 button assignments, all profile specific. Note that as they are profile specific, you need to check the profile specific checkbox to see these assignments. Change your [Profile.PMDG 737] section to the following: John

Yes, so you can assign the RTO preset (PMDG_B737-7_ANTISKID_RTO_POS_SW) to the release, and the off preset (PMDG_B737-7_ANTISKID_OFF_POS_SW) to the press. It is just a window showing the log output in real time. But it is very useful to diagnose issues and what is occuring in real-time- if more people used this before requesting support they would most probably be able to solve the issue themselves! Cheers, John

👍

Please stop posting links (sharing?) to other comments in the same topic - use the "quote" mechanism to reference previous comments, i.e. select the text that you want to reference and then a 'Quote selection' box will appear which will quote the text in your new comment. Alternatively, you can copy/paste the text, and then format as a quote in the menu bar directly above the area where you enter your comment. This will make your messages far easier to understand (take a look above!). Please activate logging for Buttons and key operations and Debug/Trace Lua plugins (assuming you are using FSX or P3D). Then generate a short log file showing your issue, i.e. load an aircraft and press the F3 / F3 keys a few times, then exit FSUIPC and show me/attach (not paste contents!) your FSUIPC ini and log files. I still don't even know what FS or version of FSUIPC you are using, but your files will tell me this...presume it is either FSX or P3D - if you are using MSFS (2020) then this lua script may not work (and you are also posting in the wrong forum...) You can also take a look at the log file as well, or, better, open the logging console (check Send to console window in logging tab) when you do this to see the log in real-time - first check the lua is started and running without issues, and then that the key presses are triggering the lua moveThrottle function, and check if any throttle events are also sent. This should give you a clue as to why it isn't working, and if you post/attach those files here I can also take a look. John

No, you do NOT edit the lua script. just leave that as it is and place it in your FSUIPC installation folder and add the [Auto] section to your FSUIPC ini file (see below). Then, start the FS, open up FSUIPC and assign the keys you want to use to LuaSet Throttle as I said....if you do not know how to assign keys, please see the provided User guide. No, add the following: [Auto] 1=Lua Throttle Please re-read that section, this is not that hard to understand, and it is clearly explained....I do not understand how you could think it would be "[Auto.throttle.lua]".... Note that you need a registered/licensed version of FSUIPC to use lua and the assignment facilities.

As I said, you cannot assign to the mouse using FSUIPC, so I cannot help you with the mouse/throttle issue. You can use the script available in this topic for the F2 and F3 keys. To do this, you need to save the Throttle.lua to your FSUIPC installation folder, and then assign the F2 and F3 keys to the control/event LuaSet Throttle with a parameter of 2 for inc and 3 for dec (and 1 for cut if you want to assign for that). You should also have the lua auto-started by adding it to the [Auto] section of your FSUIPC ini file - see the Advanced User guide if you don't know or are not sure on how to do this. You should also remove the key bindings in P3D/FSX if doing this. You can also select other keys instead, but whatever keys you use make sure they are not also assigned in the FS. John

How have you assigned the throttle to your mouse? Are you using FSUIPC for this - if so, how? Could you please show me/attach your FSUIPC ini file. Lua files go in the FSUIPC installation folder (or in the LuaFiles folder, if that is set). But I am not sure if you can use that lua if you are using the mouse for throttle, and I am not sure how this works. Could you explain further - or do you mean that you are just using the mouse to control the throttle in the VC? The lua uses flags to control the throttle : flag 1 for cut, 2 for increment and 3 for decrement. FSUIPC doesn't handle mouse assignments (except for specific purposes such as mousewheel trim/move/look), so you cannot assign your mouse to set those flags... John

It won't be an issue with the WASM then. You could try and see if you can reproduce in a debugger to see what the issue is? Otherwise a debug (or maybe even a trace) log from the WAPI for when this issue occurs would be helpful. You shouldn't need to do this - you can use registerLvarUpdateCallback to get a callback when an lvar value changes, which would be better than polling. John

That is strange in itself - FSUIPC starts the numbering at 0 whereas windows ar 1, so usually #25 in windows would be #24 in FSUIPC. That does sound strange...you could try activating logging for Buttons & Keys and see if anything is logged on that change - open the logging console (Log -> Open Console) and check in real-time. If there is no button press event registered, there may be a release event for the previous position that you can use.... John