John Dowson

No problem - but your issue should be resolved. I hope - especially if you have turned off lvar update requests from the client. Cheers, John

Ok, I will add a comment with more info to that....

I gave up registering bug reports...I raised many in the early days and got nowhere with them (no response except something like 'issue closed'), and no way to track or see any progress. Although most (if not all - difficult to track) now seem to be resolved. Things may have improved, but I will ask about this on the developers channel - I seem to get more response from Asobo through that. I will also try with unregister_var_by_name, but the documentation for that one says "...unregisters a named variable from another gauge..." so I don't think that will do the trick anyway. But I will have a play around and raise this issue with Asobo - although I may have already done this but not sure. Seen your PM - will look into this early next week - need to do/check a couple of things first...suggest you start by looking at the WAPI source if interested in updating this as that will give you an idea of what needs updating on the client side. Will PM you on Monday or Tuesday once I have given you access to the WASM. Weekend off for me this weekend! Cheers, John

This would involve a huge amount of work, on FSUIPC, the WASM and the WAPI. And as I don't see any value in this for me (i.e. more sales), it is not going to happen. There are many other more useful things I could be doing that would provide far more value to the vast majority if users. However, the WAPI is open source, and I will also open source the WASM, so you are welcome to implement yourself...if you did this, I would consider using this in FSUIPC. However, I am not sure how I could implement two different lvar access methods in FSUIPC - I would have to think about that.... I will consider making the current method more flexible in the future (no guarantees when), i.e. allow the user to define how many lvars they want to support via WASM (and possibly WAPI) ini parameters. Strange question....me! Well, I disagree here. The Gauges API even provides a function for this - unregister_all_named_vars, although the documentation for that references token variables,, not named variables (i.e. local variables or lvars) - the other 'named variable' functions reference lvars (e.g. get_name_of_named_variable). I have tried using this but to no avail. There is also unregister_var_by_name but I haven't looked into this. I don't see a problem with this, and I think most advanced users, especially those with home cockpits, tend to concentrate on one aircraft, or maybe a small subset, and don't have any issues restarting if/when occasionally changing aircraft. You can do that, or you can update the FSUIPC WASM / WAPI for your needs if you like and use that (I cannot guarantee that I will use such updates in FSUIPC). I have nothing more to say on this and do not want a prolonged debate on the issue - I consider this closed. If you want access to the WASM code before I open source it (make it public), you can PM me your email and I will send you a github invite. John

No, there are no plans to implement another method or to increase the number of lvars available. What you suggest may be ok for you, but not for the vast majority of FSUIPC users. How would you even know what lvars are available if FSUIPC couldn't list them? I would receive a lot of support requests if this was the case... As I keep saying, the problem here lies with Microsoft / Asobo. I suggest you raise a ticket/bug report with them, saying that all lvars from a previous aircraft should be cleared before loading the lvars for a new aircraft, and the ids re-used. This would solve the issue. FSUIPC doesn't get confused, and you don't need to restart FSUIPC. It is the WASM module that asks/scans for lvars by id using the Gauges API, and it is this scan that is returning the lvars from the previous aircraft. Note also that lvars don't have to be known by FSUIPC to use/write to them - you can use calculator code for that. However, they do have to know by FSUIPC if you want to read them (including adding them to offsets), John

This should be WasmPtr->setLvarUpdateFrequency(0); The default WASM update frequency is 6Hz, so you shouldn't need to change anything, but you can check. Of course it is defined - you have to register your own function, and before you start the WAPI, i.e. WasmPtr->registerUpdateCallback(&LvarsChanged); WasmPtr->registerLvarUpdateCallback(lvarsUpdatedById); // if needed WasmPtr->Start(); and then supply two functions: void LvarsChanged(void) // Called when lvar names have been received and are available { ... // use registerLvarsForCallbck here if needed } void lvarsUpdatedById(int id[], double newValue[]) // Called when an lvar value has changed { ... }

Ah yes, sorry - that should be fine. You can treat an offset area as any size that you like, as log as toy understand what the data holdd. John

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