John Dowson

There is now also a later beta version, 7.3.18c, available here: John

No - also for the current release.

These have nothing to do with your issue but indicates a possible issue with your P3D installation. Try re-installing the P3D client. I have now finished for the weekend - I will take a further look on Monday if this doesn't fix your issue. John

What is not clear in the documentation that I referenced: ?

Yes, unless UseKeyboardHook=Yes is used, in which case a global windows hook is used and the key presses/releases are received from Windows. I can't comment on how HidMacros gets its input (haven't looked at the code), but FSUIPC will fet it direct from windows before any processing by other applications when UseKeyboardHook=Yes is used. Ok, doesn't surprise me really. I'm not sure how this works when using multiple keyboards...I don'r know how windows handles multiple keyboards as they are not Hid joystick type devices, which is what I am familar with. I know very little about other types of Hid devices, sorry. I think this is the issue.... I think someone needs to update HidMacros to be compatible with MSFS - would seem to be the obvious solution. Unfortunately I am not in a position to look into this. You could maybe ask about this on the Asobo forums, or maybe over on avsim. Sorry I can't be of more help. Regards, John

Can you please try the latest FSUIPC7 beta (which includes a WASM and WAPI update), v7.3.18c, with the SU12 beta, available with a full installer from here: Any issues with the SU12beta can be reported here or in the Announcements post. Thanks, John

Could you please try the latest beta release, available here: Not 100% sure this will fix your issue though...please let me know! You should be able to remove this now as well, but test with this if you get the same issue. Thanks, John

I have no idea as you provide no supporting information - why can't you register? No - you only need to purchase a license once. I suggest you read the provided Installing and Registering FSUIPC7 document. I provide documentation so that I do not continually have to respond to such requests. The usual issue is that you need to update your VC++ redistributables, as the documentation says. Please consult the documentation and search this forum for similar issues before posting a new topic. John

Correct. I can look into this at some point I guess (i.e. add it to my to-do list), but unfortunately I think it would be many years before I had time to look into such an issue. There are many things I need to look into that would be far more useful to a far larger audience, and my developmet time is limited due to the amount of time I am spending on support... I don't think that would be a possibility, especially without changing the HidMacros code, which I am not prepared to do. Looking at HiDMacros, it does say: so doesn't it work if you just turn-off (i.e. remove) UseKeyboardHook=Yes? If you use HidMacros to send the keyboard shortcut to the FS window, that should then send the "z" key (on numpad1) to the FS, which would then be picked up as the "z" key by FSUIPC where it can be assigned. Is that not the case? Otherwise, you could try using numlock on on one keyboard and off on the other, which would allow you to distinguish between the numpad keys on the different keyboards, but not the other keys. John

Not sure what you mean by this - the list of controls (and presets) is the same for all aircraft. The only aircraft-specific controls are custom controls, such as those provided by PMDG. If the king air 350 provides custom controls, then you can use them by selecting the <custom control> option and give the custom control number. Just checked - there are 37 presets available for the Asobo King Air 350i all starting with KA_ John

I have moved your post to the FSUIPC7 support forum - please take care to post in the correct forum for support. I have lost count of how many times this has now been raised... Please see the provided document Installing and Registering FSUIPC7 - this should contain all the information you need. If you cannot see the Assignments drop-down menu, then you have not registered your license, You do this at the end of the installation process - enter your license details EXACTLY as given, and click the Register button. If you get an error for any reason, please see the documentation - your VC++ redistributables probably need updating if the license details are entered correctly but do not validate. John

Ok. Not sure what happened - the log you posted stopped after 17 seconds and the lvars still hadn't been received. Auto lua scripts are not started until lvars are available if you have the WASM module installed and activated. Cheers, John

Which you didn't follow...no new thread! Presume you mean they didn't work... Ok. But it seems you already have a macro for this, so just assign that to a button or key to test if its working. Ok. John

Hmm, strange...but glad this is now resolved. This is also strange - the current release of FSUIPC7 is still using the WAPI v1.0.0 seemingly without issues. No problem!

All axis settings are profile specific, but the general calibration settings are applied in a profile unless you also check the Profile Specific checkbox in the calibration tab, in which case the general calibration settings are then copied to the profile from where they can then also be edited to suite the profile. Button and key assignments are always automatically inherited in any profile unless they are specifically overridden in the profile itself. Don't worry about it - a lot of people are confused by this. I will see if I can update the User guide to make this more clear - although not that many people seem to refer to this! Cheers, John

What version of VS are you using and which toolset? This seems to occur when using libraries built with a different VS toolset - see https://learn.microsoft.com/en-us/answers/questions/1130957/link-fatal-error-c1007-unrecognized-flag-zc-nrvo-i If not using VS2022 then try with that using windows SDK 10.0. 19041,0, which is what the FSUIPC_WAPI.lib is built with. Not sure what exceptions you are referring to, but there should have only been an issue/crash when calling SimConnectEnd(). There was an issue in this function in v1.0.0, corrected in v1.0.1, due to trying to drop/clear the lvar/hvar name CDA definitions which are now dropped/cleared directly after being read. Regards, John Later: it may be the MSVC toolset, not the SDK, which is v143 for VS2022. I have noticed that there is also a later SDK, v10.0.20348.0, although I am not using this yet. I may update for the next release, but I will add a README.txt and specify the toolset and SDK versions used om the next release.

Why delete it, and just not run it...or exit FSUIPC7 if it is running. Also, if your throttles are working perfectly without FSUIPC7 running, then they must be assigned in MSFS, not in FSUIPC. If this is the case, and the behavior changes when you run FSUIPC, then this implies that you have the throttles calibrated in FSUIPC7. To stop this behavior, just remove/reset the throttle calibration for these aircraft (i.e. in their FSUIPC profile). Please also attach your FSUIPC7.ini file if you have any further questions on this - I cannot tell what FSUIPC is actually doing unless you show me this file. Can you please explain further what you mean by this? Is this again just in both the FBW A320 and the PMDG 737? How are you loading your flight plan? Where do you get the dashed line? And again you say delete which I find confusing, as this implies the problem exists if FSUIPC is just installed on your system and not even running... John

I am not familiar with HidMacros, but if you are using UseKeyboardHook=Yes then FSUIPC will grab all keyboard input (when an aircraft is loaded in MSFS) and so the focus window, and also HidMacros I assume, will not see the key press. If you want to remap the "1" key to the "z" key (to be sent to MSFS), then you can do this in FSUIPC's key assignment dialog, where you can assign the "1" key press to the control Key Press & Release with a parameter of 90 (the "z" key). It may be better to assign the press to Key Press/hold and the release to Key Release, both with parameter 90, but you can try both and use whatever works best for you. John

Yes, as far as I understand it... you could ask about the NAV SIGNAL simulator variable (simvar) in the P3D support forums (presuming you are using P3D -you don't say which sim...) as to why it is not 0 (when no VOR) where you may get further information. Seems to be the same since FSX and probably earlier. Cheers, John

Sorry, but I don't understand this - FSUIPC does nothing with objectives or voices... This sounds like its coming from MSFS's assistance options - you should check there. Does this only happen in one of the training sessions, and if so in which one? FSUIPC doesn't know if you are in a training session, and activity or a free flight - they are all the same as far as FSUIPC is concerned. The only way I can think of that FSUIPC could be involved in this is if something is assigned that sends something (a keypress I would have thought...) that activates this somehow. I would check MSFS's Assistance Options (probably Notification settings) and compare them to then FSUIPC is running and when not running to see if they change - or just turn those off if on. I can't see how FSUIPC can be changing this, but you can attach your FSUIPC7.ini and FSUIPC7.log files and I can take a look. For the latter, activating logging for Buttons & Keys and Events first, and exit FSUIPC7 when you see the issue. And let me know the training session or sessions where you observe this behavior so I can check this here.... John

It should contain 0, but as that comment indicates this is not always the case. FSUIPC only stores the value in the offset as received from the NAV SIGNAL:1 simulator variable.

It comes from the simulator variable NAV SIGNAL:1. As the offset status document says: Maybe best to just ignore this value when no VOR. John

That log shows nothing...I need to see the complete log file. Compress/zip it. But I don't want to see this until you have removed the FSUIPC calibration.... This doesn't make sense...you are sending the controls direct to MSFS (i.e. you have assigned using Send to FS as normal axis and not Send direct to FSUIPC calibration). But you do then have the throttle calibrated in FSUIPC (in your general calibration section) so the controls are going to MSFS, then coming back to FSUIPC and being masked (i.e. not applied in MSFS), then calibrated and sent back to MSFS. You cannot assign with Send direct to FSUIPC calibration with aircraft using the *_EX1 controls. What you need to do (and this is now the third time I have said this...) is to remove FSUIPC's calibration in your DC6 profile. To do this. load the aircraft, go into FSUIPC's calibration tab and check the Profile specific checkbox. Then Reset the calibration of the throttle on page 1 of the calibration tab, and then go to page 3 of the calibration tab and Reset the calibration of the 4 individual throttles. This will remove FSUIPC calibration. If you need to reverse your throttle axes, use FSUIPC's axes scaling feature with a value of -1 (i.e. add ,*-1 to the axes assignment lines in your FSUIPC7.ini - see section Additional parameters to scale input axis values of the Advanced user guide for more details.). Did you see this: There are known issues with calibration, but if you set this up correctly you should be fine. PMDG provided me with a license for the MSFS 737 so that I can help with this, but I don'y have the DC-6. Otherwise, if it works better for you, assign your throttles for the DC-6 in MSFS, and make sure that you don't have them assigned OR calibrated in FSUIPC7. John

Hi Emile, the update in 7.3.17 was only to give the initial 'lvars ready' callback when the lvars are first loaded, which is now delayed until the initial values are received. When new lvars are found, the current lvar list is dropped and the update lvars are given a default value of 0. I can look into locking read-access to lvars on an update until the new values are received. In the mean-time, you can prevent the automatic scanning and updating of the list of available lvars by setting the following parameter in your FSUIPC_WASM.ini: LvarScanFrequency=0 Note that it is better to do this in the FSUIPC_WASM.ini under your AppData folder, not the one under the WASM Community folder, as this would get overwritten on updates - see the Advanced User guide for details on the locations of this ini file. John

Your ini file shows that you do not have any profile-specific calibration for the DC6, and so the general calibration section is applied. As I said in my previous post, please make the DC6 calibration profile-specific, and then remove (i.e. reset) the calibration settings for throttles 1-4. As I don't have the DC6, I am not sure how to calibrate that - does it come with any in-aircraft calibration settings? If so, you should use that. The log file you attached is of no use as you did not activate logging for axes controls as advised. If works ok without FSUIPC, this implies that you have also assigned your throttle in MSFS. You should only assign in one place - if you are assigning your throttles in MSFS, remove the assignments in FSUIPC, as well as the calibration. Your general calibration for throttle2 is also rather strange: You should correct that. Well, if you have the AFE running then this can also affect the throttle and throttle position. But again, as your DC-6 throttle is being calibrated in FSUIPC, this may be the same issue. Remove the throttle calibration for the DC-6 - but make sure that you make the DC-6 calibration profile-specific first or this will affect other aircraft that use this. Also see https://forum.pmdg.com/forum/main-forum/general-discussion-news-and-announcements/127235-msfs-dc-6-throttle-position-and-automatic-flight-engineer John Later: your Throttle4 calibration in your Superconny profile is also rather strange: