John Dowson

To send key presses via offsets, you can either use the keysend offset at 0x3200, or the general control offset at 0x3110 using the FSUIPC keysend control 1070 (press and release). See the offset status document for offset use, and the Advanced User guide for details on using the key send controls and the parameters (virtual key codes) needed. John

No - the counter value is appended to the string 'myvar' and the result written to the lvar. The lvar change is then picked-up (in event.Lvar handling function) and written to an offset (as a string - note that you cannot use the value passed to the handling function as that is a number, you have to read the lvar value to get the string), and this offset update then triggers the event.offset handling function and the offset, which holds the lvar value as a string, is then logged. This is just an example to show you how to handle string lvars, and how to add them to an offset as a string. Bur that is not what your script is doing. Your script is creating and setting lvars based upon the values held in some PMDG-specific offsets. The example I provided shows you how to add data/lvars to offsets in lua - see the lvarUpdated function, which reads the value of an lvar and adds it to an offset. You can also use the lvars-to-offsets functionality provided by editing the FSUIPC7..ini file (see the Advanced User guide). But I don't really understand what you are trying to achieve... as you have the PMDG data on the offsets, why fo you want to use this to create lvars? And what data do you want to write to offsets? And what has this got to do with this topic, which I thought was about using lvars that were strings. John Later: if your issue is that the value received in the event.offset handling function (for strings) is a number and not a string, then you have to read the offset as a string in the handling function, and not use the value provided by the function, as this will always be a number. I will clarify this in the documentation - as well as the same for event.lvar when the lvar value is a string, and I will mention the 8 character limit for lvar string handling,

👍 Sounds good! Glad it all fell into place. John

The WAPI debug library is correct and up-to-date. I have updated the WASMClient to use the WAPI debug library when built in the debug configuration. There is a problem in the WASMClient in that that an invalid simConnection is used when running in debug mode. I have corrected this now. If you have a problem connecting in your code, you can try specifically setting this before you start the connection - once you have your WAPI instance, and before calling start(), do this: wasmPtr->setSimConfigConnection(SIMCONNECT_OPEN_CONFIGINDEX_LOCAL); But really this shouldn't be necessary, as that should be the default value anyway... I have attached the latest WAPI libs, so maybe try with them. John FSUIPC_WAPI-libs.zip

I think you also need to add data to offsets respecting the offset boundaries for the types you are adding. What this means is the words (e.g. UW, SW) should be added on 2-byte boundaries, dwords (e.g. SD, UD) on 4-nyte boundaries, etc. I am not 100% sure on this without checking the code, but probably a good idea to allocate your offsets with this in mind. John

All lvars are handled internally as 8 byte doubles, so the maximum string length of an lvar is always 8 characters. I am not going to go through your lua file, but please see the example script I have attached. This creates an lvar, and sets a timer to update this to a different string value every second. There is an event set to pick up the lvar change, and then write the lvar value to an offset. The event on this offset then picks up the new string value for the lvar and just logs it. John stringTest.lua

I don't know...this is probably more a question for the developers/support of the VAC software you are using. I do not know this software - do you have a link to where this is available? I can take a look (if you provide a link to the software you are using), but maybe also try asking this on the support forum for that software. John

No, sorry. Only the application/exe is provided - no source, so I have no idea why it isn't working with MSFS2020. The developer would need to look into this, or make the source available for others. John

Yes - the lua interface is only available with registered versions. as is the auto-start. John

First check with the windows Event Viewer, under Windows Logs -> Applications. Actual full dump logs won't be generated unless activated via a registry update. Crash/exception event logs are the first things to check and report. John

👍

No, still no external access to the new nosewheel steering axis, sorry. John

Then either download the latest events.txt file from the MF hub-hob website (https://hubhop.mobiflight.com/presets/) or create your own preset. The hub-hop site only lists an output preset for this lvar (and it is quite recent), so maybe it isn't writeable: I only update the preset lists (i.e. the events.txt file) when I release a new version of FSUIPC. You can always update yourself if you want to use new presets, or create your own via the myevents.txt file. But, if you just want to assign to update an lvar (assuming the lvar is writeable), then you can also use the add-lvars-to-offsets functionality, define a macro, or just define your own preset. Please see the Advanced User guide for further details. John

All updates to each product version are free, and do not require a new purchase, However, different versions of FSUIPC are for specific FS;s and require a specific license. This has been the case for over 20 years, and has been asked and commented on continually over this period. Maybe I should name them differently to avoid this waste of time..... John

I already did - it is this: Maybe the exact location is determined by the installer API I am using, which is NSIS. I don't know how that resolves the input to the exact registry location, but, as O said, just use what you find and that should be sufficient. I suspect that the location I am using will be resolved to the WOW6432Node location dor all installs (as they are all 64-bit), so just use that, Otherwise, fig into the NSIS registry facilities, but I don't see why you just don't use what you see.... John

That is strange... the installer writes and reads from that path... I have just checked my registry and I also have the entries under the WOW6432Node, as you say. However, the installer still reads/writes to that location I specified. Strange. I suspect this is some sort of voodoo that windows uses to split registry entries for 32 and 64-bit applications. Just use whatever works for you. John

This seems very strange...WideClient (and FSUIPC) knows nothing about what type of connection you are using - that is at a much lower level controlled by Windows. Are you using TCP or UDP as the transport protocol? Whatever you are using, maybe try switching to the other protocol to see if that makes a difference. I will look into this further and get back to you, although I doubt there is much I can do about this, except maybe note this strange behavior in the documentation. I have noticed that the Wnd library isn't even mentioned as being available in the current (yet very old!) WideFS documentation... Regards, John

I have not looked at (or used) the WAPI debug lib for a long time. Not even sure its up-to-date. Maybe try checking out the WAPI from github, and build your own debug library and use that - if you have your own local copy of the source, oy may also help in determining what is causing this issue. If you want me to look into this further, let me know and I can maybe take a look next week. John

The installer just writes (and reads) the key as I specified. This is for FSUIPC6 and FSUIPC7 only, which are both 64-bit, so 32-bit OS (Win7) is not supported. Any translation to the registry path must be done by windows. I suggest you just try reading the key as specified. John

Each major version of FSUIPC (FSUIPC3, FSUIPC4, FSUIPC5 & FSUIPC6) requires its own license. This is stated in many places and should be obvious as each product is available to purchase separately. I really don't understand why I have to reply to this same question several times a week - and this is the 2nd time today... John

First, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. I have moved your post to the correct sub-forum - the one for FSUIPC7 support. Please take care to post in the correct place for support. Have you read the provided Installing and Registering FSUIPC7 document, section Invalid Key Problems? I suspect not....please consult the documentation before requesting support - you will usually find your answer there... So, please consult that document. 99% of all registration issues are due to either the registration details being entered incorrectly or the VC++ redistibutables needing an update. John

For FS9, you used FSUIPC3. FSUIPC4 is a different product and requires a new key, available from SimMarket. If you have already purchased a key for FSUIPC4, your key details will be available from your SimMarket account. John

This seems strange as the throttle axis values look ok.... Do you notice this through actual control? I only compared the VC throttle movement to my actual throttle movement, and that looks okay, i.e. throttle positions match between my physical throttle (saitek X52) and the throttle in the VC. If there is a mismatch between throttle position and amount of throttle actually used, then this would be a question for asobo, so you could ask there... There does seem to be some issues since SU10, see here for example: https://forums.flightsimulator.com/t/problem-throttle-after-last-update-of-the-msfs2020/477252/23 Otherwise, maybe try one of the available mods to see if they make a difference. There are a couple of mods available, but I'm not sure which are now valid an useful since SU10 - see https://forums.flightsimulator.com/t/best-bonanza-mod/451819 https://forums.flightsimulator.com/t/bonanza-g36-turbo-mod-available/298769/164 https://github.com/TheFrett/msfs_g36_project/tree/development - note this hasn't been updated since SU7) For the sensitivity, you could try adding a sensitivity slope (available in the FSUIPC calibration settings), but the slopes we provide are more for increasing/decreasing sensitivity around the initial and extreme ranges, but maybe worth taking a look. Sorry I can't be of more help, John

You can always compress/zip files that are too large to attach directly. Your log shows that the throttle axis is moving through its full range. I have also tested here and it works fine in the G36 with the same assignments, so I don't understand why you are not seeing the full range in the axis movement. Do you have any mods installed for this aircraft, or have you modified any config files? You could try assigning with Send to FS as normal axis and try both Axis Throttle1 Set and Throttle1 Set controls and calibrate in the 3 page (and with No reverse zone checked). Note also that you are using 7.3.12. You cannot calibrate when assigned with Send to FS as normal axis in that version. Please update to the latest version - 7.3.14. John

You can read the installation location from the registry, from InstallDir under HKLM Software\Microsoft\Windows\CurrentVersion\Uninstall\FSUIPC7 But note that lua files don't necessarily go in the installation folder. If the LuaPath ini parameter is set (under [LuaFiles]), that will be used instead, so you would also need to read that. LuaPath can contain a relative or full path specification. John