John Dowson

I have tested your script here and it works as expected here... Your issue, from your log, is that the keydown events aren't being sent from MSFS - I do not know why this is. Could you maybe check your script using a different aircraft, to see if its the Fenix that is interfering. I can't do much about it if the event is being sent... There does also seem to be an issue with your key down assignment not being triggered when no repeat is set as the first keydown has the repeat flag set - I will check this further here.

You have to assign the axes before you can calibrate - did you do that? That is where your controllers axes are bound to the relevant functions. And if you previously calibrated with a different controller, then the calibration page will show the previous calibration settings. Calibration settings are either general or bound to a profile, not to a controller. You should just re-calibrate - click Reset to remove the calibration and re-calibrate, or just calibrate again... John

Btw, you are using v7.3.5 - the latest and only supported version is v7.3.6 - please update. John

I've checked these and the event.mouse* functions don't seem to be working at the moment. I'm not sure why - I will look into this, but it will be low priority I'm afraid so it may take me a week or so before I get time to look into this. I will continue looking into the other issues you have raised...

The event.lvar function is working as expected here, with or without adding the lvar to an offset, and adding an lvar to an offset should not affect the event.lvar function in any way. Something else must be going on. Can you turn on logging for lua plugins (turn off all other logging) and generate an FUIPC7.log file showing your issue (i.e. without adding the lvar to an offset) and attach that, together with your FSUIPC7.ini file and the lua plugin/file you are using. List the lvars before and after you test - so I can verify that the lvar you re using exists and that the value has also changed.

Not by me...I will check those functions here.

I will check this here. That should be ok. But I should update that function really and remove the interval - this shouldn't be needed anymore. You can declare with or without the "L:". This is what I don't understand - it should make no difference, I will check this here. John

It is an FSUIPC client program - but you must have installed and set that up to run. Whatever it is, it hasn't set its application name correctly!

The program is obviously trying to communicate with FSUIPC7 even though it has exited. Thats a problem with the program, not FSUIPC7. You can check your FSUIPC7.log file to make sure that FSUIPC7 is exiting correctly and not crashing, If the program is started from FSUIPC's [Program] section, then you try adding the KILL option. If the program is not started that way, you could try that if its something you always use - see the Advanced User Guide for details on how to do this, section Programs: facilities to load and run additional programs on page 43. I have no idea why you didn't have this issue with the earlier version you had installed, but you also don't sat what that version is/was.

You should use either the MSFS EXE.xml file (which also starts FSUIPC) or FSUIPC's facilities to load and run additional programs, not the MSFS.bat file. To use FSUIPC's facilities, see the section Programs: facilities to load and run additional programs on page 43 of the Advanced User guide. To use MSFS's EXE.xml file, open it in an editor (the location can be found in your InstallFSUIPC7.log file) and add a new<Launch.Addon>..</Launch.Addon> section as detailed below, directly before the closing </SimBase.Document> element (NB your FSUIPC entry will be on one line - I have added line breaks below to make more readable): <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>EXE.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>FSUIPC7</Name> <Path><yout path>\FSUIPC7.exe</Path> <CommandLine>-auto</CommandLine> <NewConsole>False</NewConsole> </Launch.Addon> <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>TrackIR5</Name> <Path>C:\Program Files (x86)\NaturalPoint\TrackIR5\TrackIR5.exe</Path> </Launch.Addon> </SimBase.Document> If you really want to use the MSFS.bat file, add the line: start "" "C:\Program Files (x86)\NaturalPoint\TrackIR5\TrackIR5.exe" before the exit command.

Hmm, ok - but the crash report you uploaded says it was version 7.3.4. Yes - I cannot start to investigate without this.

Ok, this makes sense. The wnd window has no key event handler - that comes from FSUIPC. When you create the window/run the lua, the focus stays with MSFS. MSFS forwards the keys to FSUIPC which then acts upon them, feeding them to your lua scripts (event.key I presume) and anything else that needs them, such as assignments. When FSUIPC has the focus, FSUIPC picks up the keys directly and does the same. So the only difference is that MSFS assignments are not triggered. There is not much I can do about this. The only thing I can think of would be to add a new control that gives the focus to FSUIPC7. You could then call this at the beginning of the lua, and call the restore focus when done. This would prevent MSFS assignments being triggered, but not FSUIPC ones. To prevent FSUIPC assignments being triggered, you should have them on modifier/shifts keys (e.g. ctrl+x+, shift+x etc), and use standard keys in your lua key events. By the way, I'm not sure the shifts values in the lua documentation are valid anymore, and even if they are they should probably be updated. I recently updated the other key handling functions to distinguish between left/right modifier keys (as well as removing the windows key, as that shouldn't be used) and I should do the same for these. I will look into this. So no keydown is being received. Strange. I will check that here, but if its not being received from MSFS, I'm not sure there is much I can do (except maybe ignore the key up if no down had been received. Presumably your assignment is on the keydown and not the keyup, no? The assignment should be performed on the first key press though, if that is the case. It would be helpful if you could attach your FSUIPC7.log and FSUIPC7.ini files so that I can take a look. Ok. although I don't need this at the moment. Your log and ini files are more useful.

I've taken a look and it still isn't possible to implement this are there is no way provided by the SDK, and the hack used to achieve this in P3D/FSX is not possible in MSFS2020.

It will be a problem with the Fenix - or the Asob/MSFS SDK. FSUIPC just calls the provided SDK save/load functions, it has no control over what data is actually saved/loaded. Regards, John

@PSantos To summarise my previous posts, please do the following which should help us get to the bottom of this: 1. Start MSFS and FSUIPC7. 2. Open the FSUIPC7 main window 3. Remove/uncheck all logging 4. Open the offset logging window and log the following offsets: 0x3103 U8 0x3364 U16 0x3300 U16 hex 0x034E U16 hex Click Ok when done to close the offset logging window. 5. Load the Fenix A320, and press the ready-to-fly button. 7. Wait a minute or two to make sure everything is loaded - you can open the logging console if you like, and wait until you see this message: Lvars/Hvars received - checking aircraft autos.... Once that message is received and any luas/macros are started, everything is ready. 8. Power up the aircraft and the aircraft avionics and wait a few seconds. 9. Exit FSUIPC7. 10. Start FSUIPC7 again. Wait a minute or two (i.e. as step 7). 11. Exit FSUIPC7 again. Then show me both your FSUIPC7.log and FSUIPC7_prev.log files as well as your FSUIPC7.ini file. You can also repeat but log the following offsets instead: 0x281C U32 0x0350 U16 hex 0x0352 U16 hex 0x311A U16 hex John

I'm pretty sure that offset must be set, as I've just checked the log @PSantos posted and can see this line: That flag should be set then...but please check. You also posted a continuation log - please only post full log files when requested (zip them if too big). Your log shows several errors - these are from trying to use presets before everything is ready (you need to be more patient): You can use presets (or lvars/hvars) until you see this line logged (nearly 3.5 minutes later than when you executed the first preset): This one is interesting: but looking at the code I think this is normal when using the PFCcom64.DLL to prevent the axes getting registered with FSUIPC. Please attach a full log next time, and don't attempt to do anything until the plane is fully loaded and FSUIPC has received the config data to be able to communicate with the WASM. Also, can you please check the bits in offset 0x3300, and also that the com/nav frequencies are being populated in the following offsets: And it is offset 0x3103 that is used for the avionics switch status (not 0x2E80) - so please double-check that one. The PFC driver doesn't listen for events, it only reads offsets, so there must be an offset that is not being set correctly with the Fenix... John

Can one of you check if the ready-to-fly flag is being set for the Fenix in offset 0x3364? This is the offset/flag that activates the driver when set to 0 (non-zero indicates still loading).

That is 0x1530 or binary 0001 0101 0011 0000 in decimal... Yes. But it is far easier to ignore the binary and use hexadecimal as it is far more obvious. To convert BCD 0x1530 to a decimal equivalent (i.e. NOT the decimal value of the hex number), you drop the 0x and convert the string "1530" to the int value 1530, then divide by 100 to ger the decimal value 15.30, then add 100 (as the leading 1 is always dropped when frequencies are held in BCD format) to get 115.30. If you have the frequency in decimal, you cannot just convert that to hex - you do the same in reverse, i.e. subtract 100 to get 15.30, multiply by 100 to get 1530, convert to a string to get "1530", prepend 0x to get the string "0x1530", then you can convert that to an integer/hex number to get 5424/0x1530. But we are going in circles here...google can show you all you need to know about BCD format. You multiplied the lvar by 100, to get a lua number 10994.0. The writeSW funcrion would convert that to an C/C++ integer. No! The offset area is just a memory address range. You can read/write whatever type you like, including floats (4 bytes), doubles (8 bytes) and strings (any length). That is why there are ipc.writeDBL and ipc.writeFLT (and read equivalents), as well as the various offset logging types - see page 14 of the Advanced user guide to see the types supported. Some simvars that are floats are converted and stored as integers, but this is for historical reasons. The offset documentation should say if any conversion is necessary - although it doesn't specify the type (only the size). Usually the type is obvious, but in some cases not, when you should refer to the FS documentation for clarity. I will update the offset documentation to specify the actual type at some point... when I get time - I have been meaning yo do this for a while but get very little time for such things due to the amount of support requests.... Just remember that offsets are just memory addresses, and must be read as the same type and/or size as they were written.

Please see the README.txt file, included in the zip file you downloaded: This has also been reported many, many times already... Please check the documentation and existing forum posts before starting a new post. I waste a lot of time answering the same questions again and again... I will look into making this the default option now Windows 11 is being used more and more... John

No! That is certainly not the case... Yes - 108.00 is 0x800 in BCD, which when read as an integer is 2048. So this is obviously not a straight conversion from hex to decimal. Yes, exactly! But, a simply a conversion from hex to decimal of 0x800 would be 2048, which is not the frequency... But you seem to understand...but your initial statement certainly isn't true! Ok - glad you found the function, that should make things easier. John

I am puzzled by this though - could you check by explicitly giving your lua Wnd window the focus by clicking on it - or maybe giving FSUIPC the focus. Really, the LuaTrapKeyEvent should be redundant now that FSUIPC is a separate application. The only way MSFS should see key presses when FSUIPC (or one of its lua processes) has the focus is if this is done explicitly via a keysend control... I don't think opening a Wnd window (and setting it topmost) will give the window the focus, as the focus should remain with the FS. I don't think there is an easy way to give a wnd window the focus. Best to just try this. I also suggest you activate logging for Buttons & Keys and open the logging console window. This will show you what keys are being received from the FS (meaning the FS has the focus) and which, if any, are being sent to the FS. I suspect that the keys are being received from the FS, but lets see... John

Maybe take a look at the MaxSteerSpeed ini parameter (and maybe also RudderBlendLowest) which allows you to control the amount of tiller/rudder blending for different groundspeeds. Also make sure both axes are calibrated properly. If using/assigning rudder in MSFS, assigning to FSUIPC's 'Steering Tiller' will cause issues -you should assign to Steering Set (under Send to FS as normal axis). This is the documentation section on the steering tiller (in case you missed it) from the FSUIPC7 User Guide (page 30): John

That is strange - I will look into it... Yes, please do - it will help me to see what is happening. Do that and I will take a look and get back to you, although it may take a few days. John

You can scale the axis values - add ,*0.5 to the end of the axis assignment line in your FSUIPC7.ini. You can adjust the scaling value as needed - see the section Additional parameters to scale input axis values on page 41 of the Advanced User guide. John

Ok, thats good to know, thanks. No - for future reference, always upload a full/complete log file, and zip it if too large. I need to see the beginning, the end, and most of the stuff un-between...! And in this case, the log was missing the lines that would have told me that you were using an incompatible WASM version. John