ark1320

I understand John, and in fact have a number of scripts that do just that. This was a particular situation where as an experiment I did not want to use an event driven script. Thanks, Al

A flash happens when a window is opened, and since the "other" script is called numerous times, the window is opened and flashes each time. I don't think there is a good solution for this kind of situation. Thanks, Al

What is a good way to keep a Lua script from terminating? One way I found is to put a "dummy" (empty) do while true at the end of the script like this: WIndow Script code here do while true end In the particular case I have, the script above simply opens a window for display that I want another script to be able to use. So I don't want the window to close. I pass the window's handle to the other script, and this seems to work OK. The other script is called frequently as data is entered, and if I put the window definition code in that script, then each time the script runs the window flashes. If the window stays open there is no flashing. I just wonder if there is a better way to keep the window script from terminating then using the empty do while true? Thanks, Al

That's interesting because I've never run into this before. Is the preference not to open on startup saved somewhere and so passed on to new FSUIPC7 installs? I looked at the top of the FSUIPC7.ini file but didn't see anything I recognized related to this. Thanks, Al

Found the "problem"... apparently me. Somehow the option to Open on Start was selected under the FSUJIPC7 Options drop-down menu. I don't know how that happened, it has been so long since I've looked at that menu I didn't recall there was an option to open the window on startup. 🙁 Al

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?