ark1320

Thanks for the reply. Ver 7.4.3a is an experimental version John gave me to try to fix a bug. Al

I don't know what I did, but now when FSUPC7 loads, along with the flash screen, the FSUIPC7 assignment window shown below also opens. Does someone know if there is a setting somewhere that controls this? I looked but couldn't find anything. I never had this happen before. I am using 7.4.3a. Thanks, Al

Hi John, ver 7.4.3a has fixed the "unsaved" parameter problem for Lua scripts with an index greater than or equal to 32 (tested with script index of 59). Best to your wife for a speedy recovery, Al

John, did some more investigating and read back through this thread and saw your comment that "There was a problem with the flags that indicated lua/preset/input event as the same bits are used when the lua file index number is 32 or higher" and realized my problem Lua script had an index of 36. When I changed the Lua script index to 28, the problem went away. Attached is a simplified version of the script, but exhibits the same problem behavior when I give it an index of 58, but works correctly when I change the index to 28. Note the script makes use of calculator code. Thanks, Al LJet35CtrlsTest.lua

Hi John -- I am having this problem again. I was defining new presets in myevents.txt, and subsequently noticed saved parameters associated with new key assignments were being reset to 0 when FSUIPC7 restarted. I am using FSUIPC7 ver 7.4.2. I tried reinstalling FSJUIPC7 but the problem persists. Al

I have entered a version of NpC for MSFS in the FSUIPC User Contributions subforum. See Numberpad Control for MSFS 2020 (NpC4MSFS2020): Al

NpC4MSFS2020 is an updated version of a similar application I developed years ago for FSX and P3D. Using the NpC4MSFS2020 Lua Script you can assign (bind) keys, key combinations, or buttons to different functions to allow entering data such as aircraft radio frequencies (COM, NAV, ADF), altitudes, courses, headings, and transponder codes, as well as accessing other aircraft functions, just by entering the data using your keyboard numberpad instead of a mouse. Although modifications can be made, the base version of NpC4MSFS2020 assumes the aircraft is using standard MSFS variables which can be manipulated by FSUIPC7, and uses the FSUIPC Window (Wnd) library for display purposes. Attached below is the NpC4MSFS2020 Lua Script and a document that describes how to install and setup the application. Using Lua scripts requires a registered copy of FSUIPC7. NpC4MSFS2020.lua NpC4MSFS2020 Setup.docx

I just wanted to confirm I updated PilotsDeck correctly. Al

Hi, How can I check to see what version of PilotsDeck I have installed? Thanks very much for the update, Al

Hi John, This latest FSUIPC7.exe version has fixed the problem for me. Thank you! Al

I finally went back to FSUIPC7 ver 7.3.21 and now everything is working again. On my system both FSUIPC7 versions 7.4 and 7.4.1 have the button Param problem discussed above. Used the same FSUIPC7.ini file in all cases. I don't know where the problem is when using the newer versions -- FSUIPC7 or my system. I wonder if using the new assign buttons to input events functionality in versions 7.4 and 7.4.1 introduced a strange bug -- just a thought. Al

As a test, I renamed my FSUIPC7.ini file to back it up, and let FSUIPC7 create a new one. Then button Param assignments worked. So there is something about my existing FSUIPC7.ini file -- maybe some kind of a limit has been reached. I noticed I can make button Param assignments to older Lua scripts, but not to new ones although I can make Param assignments when assigning keys. So perhaps some kind of a button related limit? Will continue to experiment. Al

I have just run into the same problem -- button Param values are reset to 0, but key assignment Param values are not, all with the same LuaToggle script. I tried turning off FSUIPC7 and editing the FSUIPC7.ini file directly (put in the Param values) and saving it. When FSUIPC7 restarted the Params had been reset back to 0. Another user, using an exact copy of the same Lua script, and the same version of FSUIPC7 (7.4.1), does not have this problem. Tried reinstalling FSUIPC7, didn't help. Very strange. Al

There is a Simvar Watcher tool provided by Asobo that looks like this. See https://docs.flightsimulator.com/html/Samples_And_Tutorials/Samples/VisualStudio/SimvarWatcher.htm and the zip file below. Al SimvarWatcher.zip

Sorry for any confusion on my part, that is what I thought was the intention from the start. Al

In general yes (see the FSUIPC Lua Event library), but it depends on if the special condition can be detected with code; that is, are the necessary simvars (variables) associated with the special condition available? I think it would help John give you the best answer if you would provide him with some information on the nature of the special condition you are talking about. Al

I took a look at your Lua script and think you have the following syntax errors: 1. On Notepad++ lines 62, 66, 83, and 87 the ipc.writeLvar statements like this: ipc.writeLvar(“FSUIPC_C510_Ignition_1", 1) apparently have the wrong type of opening quote character ( a curly quote instead of a straight quote? ) before FSUIPC_. Use the same type of straight quote character as you use for the closing quote after the _1. The similar writeLvar statements on lines 156, 161, 179 and 183 seem to be OK. 2. Line 250: Lua file path syntax requires the statement ipc.runlua("C:\FSUIPC7\2-loglvars.lua") needs to use double back slashes ( \\ ) like this: ipc.runlua("C:\\FSUIPC7\\2-loglvars.lua"). I think a single back slash in Lua is reserved for escape characters. 3. Your local function Check_N1_S1() is missing an end statement. You need one end to close the function, one for the while do , and one for the if statement. Good luck, Al

Thanks John. Al

John, If you removed FSUIPC7 from the EXE.xml and just created a FSUIPC7.exe shortcut and launched it by hand after MSFS loaded, are there any inherent unintentional consequences of doing that? For example, would all the Lua script entries under [auto.xyz] get launched as expected? Asked another way, in your view is having FSUIPC7 in the EXE.xml just a convenience for the user, or is there more to it than that? Thanks, Al Edit: As I think more about it, launching FSUIPC7 by hand could lead to problems if you launched it to early, such as before the plane you will use has been completely loaded by the sim. In that case related FSUIPC7 profile assignments may not work?

Yes, that is exactly the approach I was trying to suggest above. Glad you got it working. Al

Another thing you could try just for testing is to pick a different key for PTT -- maybe K or F1, etc., just to see if that makes any difference. As a test, using the method I described above I was able to setup buttons on two different joysticks to send the keystroke I had assigned in VPilot for PTT . Al

OK. And just to confirm, after making the first button assignment (Joy# A, Btn# 8), you click OK and close the FSUIPC7 window, then reopen the button window and try to make the second button assignment. When you reopen the button window all the FSUIPC7 fields should be blank, nothing in the Joy# or Btn# fields until you press the button on the second joystick. And what you are saying is when you press that second button all the FSUIPC7 fields stay blank, nothing shows up in the Joy# , Btn # fields. Is this correct? Al

I suppose there could be a problem with that particular button on the second joystick. For example, it could be that button is being "trapped" (used by) some other app and prevented from "getting to " FSUIPC7. As a test, if you just open the FSUIPC7 button window and push that button does FSUIPC7 see it?

After making the first assignment for Btn 8 on Joystick A did you click OK and close the window? And then open the window again and push the button on the other joystick? Both joysticks have to be connected and recognized by FSUIPC7. If you just open the FSUIPC7 button window and push the button on your second joystick, does FSUIPC7 see it? Al