John Dowson

If you look at your log files, the error is obvious: This is happening after the left light has been set (i.e. turned on or off) and will stop the processing, so the function to control the right light will not be called. The error is because you are using the function DspShow which is not defined anywhere. Note also that your lua scripts are writing numeric lvars as strings, e.g. ipc.writeLvar(lvar, '0') This should be ipc.writeLvar(lvar, 0) This happens in various places. Can you please try looking at the log files yourself and at least attempt to diagnose the issue before asking for support. I don't mind helping, but such obcious errors should be detected by the user really and not require support. Always at least look at your own log files before posting and the error may be obvious. John

No. This is quite an old post. The lua COM library is working in all versions of FSUIPC. The 'LUACOM' library that you are using is different - it is a library to support the windows COM object library, not to read data from COM ports/sockets, which is what this thread is about. As I said in the other thread, I have no idea why/how WideClient can load this library but not FSUIPC. As I said (in the other thread), I will take another look at this when time permits. John

Ok. But this topic is about 'No ASSIGNMENT button shown FSUIPC7', which you have now solved (by registering). You cannot use the same topic for all your issues, If you have another issue, please create another topic. I am closing/locking this topic now as it is solved. John

No, it is not possible to have mouse macros with MSF2020, and there are no plans to add this as the functionality is not provided by the MSFS SDK. There are alternative methods that replace the need for mouse macros - hvars (HTML variables), Input Events (also known as B vars) and calculator code (usually executed via presets). It really shouldn't be an issue. For example, check the presets availalble for each aircraft here: https://hubhop.mobiflight.com/presets/. All MobiFlight presets are available for assignment in FSUIPC7. John

Ok, thanks for checking. I will provide full details later today, but auto-tuning will only kick in if the default value of the DetectToConnectDelayAuto ini parameter hasn't been changed, or if it is forced. To test the auto-tuning, just remove the DetectToConnectDelayAuto parameter from your ini. If auto-tuning increases the DetectToConnectDelayAuto parameter, it will not run again. If it decreases this parameter, it will run again on the next auto-start unless the parameter has been decreased to 30 (minimum value for this parameter). I also noticed a minor issue in the above attachment - this has been corrected and the attachment replaced (no change in version number though). So please download this again if you want to try the auto-tuning. John

Events are logged to the FSUIPC6.log file. You also activated Log Lua Separately. Please do not set this - I prefer to see the lua log embedded in the FSUIPC6.log file. Only activate the logging I request please, no other logging needed. And no-need to rename your lua files with a txt extension. Also never start a new log file when generating logs for support, and always exit FSUIPC/P3D before attaching logs. I will look at your files tomorrow - just finishing for the day... John

Sorry to have to revisit this, but I need to make further changes to the way FSUIPC7 starts, and I would like users who have this issue with key presses not being received to try this before I release publicly. Therefore could all people with this issue, especially @Cuantreau please test this version. Please attach logs if you have issues. This version contains an auto-tune feature for the connection issues, but I will publish details on this once I have verified that this version doesn't re-introduce the problem with keys/hot keys reported by so many of you. Thanks, John Attachment removed, now available from here:

What issue is that? If it is the same as reported. follow the advise I have already posted. Otherwise please explain your issue and attach the relevant files - the InstallFSUIPC7.log file if having issues with installation, otherwise your FSUIPC7.log file. If unsure, attach both. As a new user to these forums you will have a restricted upload limit - zip/compress the files if too large. John

With your current [Auto] section, both lua scripts will be ran for every aircraft that you use. If you replace this with the above, only the relevant script will be ran in each profile. I can't help if you don't show me/attach your updated script. You can also try logging (for Lua Plugins and maybe also Events) and work out what the script is doing and why it isn't working as intended. John

They do not indicate the current com frequency setting, they indicate if the avionics in the current aircraft support 8.33 or 25 KHz, and will be set when the aircraft is loaded. John

Ok, so probably related to the timing, i.e. what Steam/MSFS is doing when FSUIPC is scanning the registry. I will report this to both Steam and MSFS and see what they say... Thanks for the files. Cheers, John

As I said, using the facilities provided (Log->Offsets). Please read the user manual! John

I have responded in the other topic you created on this same issue: In summary, FSUIPC7 is holding the correct 8.33KHz frequency, so the problem must be elsewhere. Maybe @sdlc can comment if he has resolved this issue? John

What offset are you using for the COM frequency? For COM1, there are two offsets (for the active frequency): 0x034E: COM1 frequency, 4 digits in BCD format. A frequency of 123.45 is represented by 0x2345. The leading 1 is assumed. 0x05C4: Active COM1 frequency in Hz (32 bit int) For 8.33KHz frequencies, you need to use offset 0x05C4, not 0x034E (as that does not support 8.33KHz spacing). Check which offset you are using. You can also use FSUIPC's offset logging facilities to check what these offsets hold. You can also check offset 0x0B47 which will tell you which frequency spacing mode is being used (25KHz or 8.33KHz). There are similar offsets for COM2 and standby - see the Offset Status document for details Yes, the same issue - but that user was already using offset 0x05C4. What A320 model are you using? Check what frequency spacing mode is supported. In the Asobo A320, I see this: 5469 Monitor IPC:034E (U16) = 0x1870 5469 Monitor IPC:05C4 (U32) = 118705000 5469 Monitor IPC:0B47 (U8) = 1 and in the FBW A320 (Development branch) this: 185610 Monitor IPC:034E (U16) = 0x1870 185625 Monitor IPC:05C4 (U32) = 118705000 And when I change to 122.805, this: 450344 Monitor IPC:034E (U16) = 0x2280 450344 Monitor IPC:05C4 (U32) = 122805000 So FSUIPC is holding the correct values for these aircraft. Please check those offsets for your aircraft model. If they are holding the correct values, then you need to go back to OpenCockpits. If they are not holding the correct values, then maybe the aircraft isn't setting the COM ACTIVE FREQUENCY simvar correctly. You can either report this to the aircraft developer, or check to see if they use an lvar to hold the correct 8.33KHz spacing - if so, you can add this lvar to an offset and use that. Cheers, John

Mine is set to Use default settings and I don't have this issue. I have experienced this issue before, but I can't remember what I did, if anything, to stop this. I also think this is caused by Steam - I will raise a support request with them. Ok, that's good as at least your controllers are recognised and acquired correctly. Could you attach a joyscan.csv file for this please. It would also be useful to see a joyscan.csv file from when you start FSUIPC7 without MSFS running, when these phantom entries do not appear. I can then use this to show the difference to Steam support. Thanks, John

Ctrl+F2 is assigned to LuaToggle My789functions with flag 2. Flag 2 calls the QW_OH_LT_Both_RWYTF_toggle function: event.flag(2,"QW_OH_LT_Both_RWYTF_toggle") This is the function called: function QW_OH_LT_Both_RWYTF_toggle () QW_OH_LT_L_RWYTF_toggle () QW_OH_LT_R_RWYTF_toggle () end The functions QW_OH_LT_L_RWYTF_toggle and QW_OH_LT_R_RWYTF_toggle do not exist (and neither QW_OH_LT_L_RWYTF_on, QW_OH_LT_R_RWYTF_on, QW_OH_LT_L_RWYTF_off, QW_OH_LT_R_RWYTF_off and QW_OH_LT_R_RWYTF_offQW_OH_LT_R_RWYTF_off). So looks like your lua is missing some functions, although I don't know why this error isn't logged. Note that you arer starting two lua dunctions in your [Auto] section, one for each profile. Better to use profile Auto sections (e.g. [Auto.B789]) to only start the luas needed for that profile. Also, consider using substrings for your aircraft profile names. i.e. change to which will then match the aircraft when using a different livery. John

But there is no need to do this - the email address is never used. And once you have generated the FSUIPC key file you don't need to use it again, and the registration details are always available in your SimMarket account. It is just not necessary. John

Yes of course - I should have realized that, sorry. You can use the MSFS.bat file for this. This was the old way that FSUIPC7 was started, and there shou;d still be lines in that file to start FSUIPC7 although they will be commented-out. You can uncomment them and move them to before the start of MSFS. Maybe this is a Steam issue... Could you check your Steam Controller settings - what does that look like? All my settings are off, except for Guide button focuses Steam, and I do not have the Xbox Extended feature Support Driver installed. Please check that, and I will review your files and check the other posts on this issue to refresh my memory. Quite busy at the moment so it may take a few days before I get a chance to look into this again. John

You only need to do this if running FSUIPC7 as admin - all clients must be ran at the same privilege level as FSUIPC7. John

The log file attached stops after 3 seconds and was attached when FSUIPC7 was still running - MSFS was detected but FSUIPC7 hadn't even tried to connect yet. Please see this post: And please hijack unrelated posts - this post is about virus protection blocking the installer. There are several posts on start-up issues but not this one - and this one is badly named - I will update. John Later: sorry, look like you have already adjusted that. Please create a new post and attach a fill log, where you get to the main menu, wait a short time and then exit FSUIPC. FSUIPC should not affect the start-up time much though. Try disabling FSUIPC7 (just rename the FSUIPC7.exe) and see what start-up times you get then.

This lvar holds the correct value, but if you manually change the value of this lvar it does not change the lighting. Therefore you cannot use this to control the lighting, but you can use it to get the current value of the lighting, then increment/decrement this and send the new value via an Input Event. You would need to write a lua script to do this. The script should wait for a button press on your rotary buttons (event.button), and in the button press handling function it can read the current lvar value (ipc.readLvar), inc/dec the value to the new value and then send this on using ipc.execInputEvent.

Does it also validate? If it works, then why didn't the one you created manually work (it should be exactly the same)? If it validates, why doesn't it validate when you entered the key (the details will be the same)? I would like to know what your issue was... John

The key details for that order work fine here. I have PM'ed you a key file - please save that to your FSUIPC7 installation folder and run FSUIPC7 and see if you have access to the Assignments menu to confirm it works. If so, then re-run the installer and see if that validates.

You need to add them - use a value of 185. John

Some events take a parameter (e.g. all *_SET events), others not. If you do not know, check the documentation: https://docs.flightsimulator.com/flighting/html/Programming_Tools/Event_IDs/Event_IDs.htm Those presets are incorrect as those events do not take a parameter. They will work, but the parameter is not necessary and is ignored. If you want different/alternating commands to be sent on successive keypresses, you would need to overload the key press assignment (i.e. have both assignments on the same keypress) and then use an offset condition to only send one of these at a time, depending on the state of the offset. So, for the ignition switches, for example, you can use offset 0x02C0 (TURB ENG IGNITION SWITCH EX1:1) for the left switch, and 0x02C1 for the right switch. These offsets will hold 1 when the switch is off/NORM, and 2 when on. You cannot currently read the value of an Input Event- this is something I would like to add. You need to determine if there is something else that also holds the value (a simvar or lvar) and use that - as I showed above with the ignition switch. It is easier to use an axis for such controls, and you would assign the axis value to an offset and use a lua script to pick-up changes to the offset value, calibrate this to the required range and then send the input event with the calibrated parameter. If using a rotary, this will use buttons and you need to use button assignments, and you will need to know the current value so that it can be incremented/decremented. Note that LIGHTING_PANEL_1 is also available as an lvar, so it would be easier to use this. Just add that to a free/spare FSUIPC offset (using the facilities provided), and then you can just assign your rotary buttons assigned to the offset inc/dec controls.