Gypsy Baron

In answer to question 1, yes, you can program buttons and switches to be conditional upon the state of other buttons and switches. I suggest that you read the following two sections of the "FSUIPC4 for Advanced Users.pdf" Page 19 COMPOUND BUTTON CONDITIONS Page 47 Appendix 1 The mode switch you refer to is reported to FSUIPC4 as buttons 8, 9 and 10, depending upon the position of the switch. To implement the compound button programming you will need to edit the FSUIPC4.ini file by hand. It is a text file and can be opened in Notepad. (ALWAYS make a backup copy before edits) There are other methods to achieve what you want to do, depending upon how many 'modes' you want to have. I have a rather comples arrangement for my A2A aircraft that gives me up to 8 functions for each of the switches on my Saitek dual throttle quadrants, That is effectively 8 modes. I use the technique described on Page 22 "ADDING OFFSET CONDITIONS", where I use one of the three-position switches on the throttle quad as my 'mode up and mode down' switch. This increments/decrements the value in user-defined offset 0x66C0 between 0 and 7. That value is the mode selected. In the ini file the programming for such an implementation would look similar to this: 31=P174,10,Cx510066C0,x00030001 <---- Mode switch 32=B66C0=0 P117,6,C1030,0 33=B66C0=1 P117,6,C1034,0 34=B66C0=2 P117,6,C1038,0 35=B66C0=3 P117,6,C1042,0 The above would equate to 4 'modes' for the referenced button (see Page 23) The problem with using the three positions of the mode switch on the yoke is you are limited to 3 modes which I find to be too few for any advanced aircraft. My A2A B-17G, with it's 8 modes means that I have 80 functions available for the 5 three-position switches on my throttle quads. The 6th is the 'mode switch up/down' functions. Question 2....I don't use the throttle detente switches often but when I do it is usually to 'trigger' a Lua script. One case in point is the prop reverse function in the A2A B-377 aircraft. To achieve reverse pitch in this aircraft you must send an 'F1' keystroke to set throttle to idle and then send a series of 'F2" keystrokes to pull the VC throttles back into the reverse range. Then to exit this condition you need to send a series of "F3" keystrokes to advance the VC throttles out of the reverse range. At that point you can then resume normal throttle action. When one of the 4 throttles goes into detente, the F1 and F2's are sent. When that throttle moves out of the detente position, the F3's are sent. Using the compound button procedures you can program those detente switches to be 'mode dependent' just like any other button or switch. I use Lua scripts for their power in implementing event-driven functions...a change in some offset value, a timed event, etc. One use is to briefly display the current mode assignments for my 10 switches when I change modes. This appears in a small Lua display window for, in my case, 3 seconds and shows me what the 10 functions are that are set for that mode. With 80 functions I need the 'reminder' :) So, read the pdf file mentioned above and keep a shortcut to its location handy. Also read the "FSUIPC Lua Library.pdf" and the "Revised_List_of_FSX_Controls.pdf" that come with FSUIPC4. Also, I suggest that you use the "Aircraft specific" feature of FSUIPC4 or "profiles" so that you can have different setups of your various aircraft that get loaded automatically when you select that aircraft to fly. Paul

Just as a side note to this thread, I have all the A2A Accu-sim aircraft and I use "short aircraft names" and assign my settings using "aircraft specific" and not "profiles". On some of thos aircraft I do use the A2A configurator for some axis but most of my assignments are done in FSUIPC4. I have had NO issues with assignments not 'sticking'. Many of my assignments use compound button programming and the ini file entries are quite extensive. There aren't any problems with the A2A aircraft names. They are recognized when I load them and the correct set of aircraft-specific controls are loaded. Paul

Hummm...I missed that point. Sounds like a problem with the particular aircraft modeling unless, of course, he sees this on all aircraft. The aircraft.cfg file has separate entries for max trim and max rudder, AIR. There is also an effectiveness entry. The aircraft I fly have limited trim relative to control surface inputs, be it rudder, aileron , or elevator. Paul

Rudder trim isn't well simulated in FSX, to the best of my knowledge. I wouldn't expect it to cause a full rudder deflection. You may be asking too much of it :) Paul

You might try one of these: Toggle Fuel Valve All 66493 Toggle Fuel Valve Eng1 66494 Toggle Fuel Valve Eng2 66495 Toggle Fuel Valve Eng3 66496 Toggle Fuel Valve Eng4 66497 Paul

Now THAT explains a lot, Günter ! :razz: paul

I don't have that aircraft so I can't give you any specifics but you may want to use the FSUIPC4 control to "List Local Panel Variables" or words to that effect. This will show you the internal L:Vars used in the code and if the coders used a naming convention that relates to actual functions you may be able to do whatever you need done by acting on those L:Vars directly. I assign that control temporarily to a button and activate it once I load the aircraft in question. The list goes out into the FSUIPC4.log file. That is how I interface to the A2A Accusim aircraft in many instances since much of that simulation is 'outside' of the 'normal' FSX realm. Paul

Tom, that is one feature I don't use and do not have a complete understanding of the methodology involved. Gunter (guenseli) who is involved with the LINDA world uses that feature in his script implementations. I THINK what is done is to assign that 'control' (ipcparam) to a joystick button or switch in the FSUIPC4 Buttons + Switches menu system just the same as you would assign any other FSX control. The assigned parameter is then passed to the Lua script that uses the event.param("function-name") trigger instead of say, the event.offset trigger. In one of Gunter's scripts I have he looks at the passed parameter to determine which switch/button was activated and then does whatever is dictated by that action. Here is a partial list of one of his scripts: -- A2A Spitfire accusim -- LUA Script V 1.0 -- updated: Sunday, 24th Oct -- -- (C) Guenter Steiner/guenseli -- List of parameters -- -- 1 Generator on -- 2 Generator off -- 3 Generator Toggle -- -- 4 Primerstate open -- 5 Primerstate closed -- 6 Primerstate toggle -- 7 Priming -- 8 Primer releasing and priming -- -- 9 open Lid and starter ON -- 10 starter OFF and close Lid -- -- 15 Boost cut out off -- 16 Boost cut out on -- 17 Boost cut out toggle -- -- 20 Mixture ratio lever weak -- 21 Mixture ratio lever rich -- 22 Mixture ratio lever toggle -- -- 23 Top (Left) Fuel Selector ON -- 24 Top (Left) Fuel Selector OFF -- 25 Top (Left) Fuel Selector toggle -- -- 26 Bottom (right) Fuel Selector ON -- 27 Bottom (right) Fuel Selector Off -- 28 Bottom (right) Fuel Selector toggle -- -- 30 Ventral recog light "Beacon" steady -- 31 Ventral recog light "Beacon" OFF -- 32 Ventral recog light "Beacon" morse -- -- 33 dorsal recog light steady -- 34 dorsal recog light OFF -- 35 dorsal recog light morse -- -- 36 morse key -- -- 40 Landing light extending -- 41 Landing light retracting -- 42 Landing light ext/retr toggle -- -- 43 Left Landing light ON -- 44 Left Landing light OFF -- 45 Right Landing light ON -- 46 Right Landing light OFF -- -- 50 Left Landing light extend and ON -- 51 Left Landing light retract and OFF -- 52 right Landing light extend and ON -- 53 right Landing light retract and OFF -- -- 55 LL Beam up -- 56 LL Beam down -- -- 60 Defroster inc -- 61 Defroster dec -- -- 70 Oxy Alt Valve set inc -- 71 Oxy Alt Valve set dec -------------------------------------------------------------- GEN -- Generator ON if ipcPARAM == 1 then LVarSet = "L:Eng1_GeneratorSwitch" ipc.writeLvar(LVarSet, 1) end -- Generator off if ipcPARAM == 2 then LVarSet = "L:Eng1_GeneratorSwitch" ipc.writeLvar(LVarSet, 0) end -- Generator toggle if ipcPARAM == 3 then LVarSet = "L:Eng1_GeneratorSwitch" val = 0 if ipc.readLvar(LVarSet) == 0 then val = 1 end ipc.writeLvar(LVarSet, val) end [/CODE] It seems that each switch is assigned the same control, ipcparam, and a unique parameter to ID the function of the switch as noted in his list of parameters vs functions. I think the same results can be achieved with the method I noted earlier, using the event.offset to pass a parameter to a given processing function in the lua script. Here is a script I use for various actions for the A2A P-51D. Some functions interact with the aircraft code via L:Var's while I use others to display data as a control is changed that may be interacting with the code directly via association with normal FSX controls. =============================================================== -- Script for the A2A Accu-Sim P-51D (Military) -- Last modified on 09/21/2012 P.D. Strogen function dispP51_CS(offs, val) conset=val+1 ipc.setdisplay(650, 200, 500, 100) if val == 0 then ipc.display("INS LIGHTS ON _ BATTERY _ RECOG _ NAV LIGHTS _ LAND LIGHTS\nINS LIGHTS OFF _ AV MASTER _ GEN _ APU _ PANEL LIGHTS\nControl Set = "..conset, 10) end if val == 1 then ipc.display("FUSELAGE _ LEFT MAIN _ RIGHT MAIN _ REL L DT _ REL R DT\nFUEL OFF _ LEFT AUX _ RIGHT AUX _ SPARE _ SPARE\nControl Set = "..conset, 10) end if val == 2 then ipc.display("PRIME _ MAG INC _ START _ GUN SIGHT _ GUNS \nFUEL PUMP _ MAG DEC _ PITOT HEAT _ SIGHT GYRO _ SIGHT MODE\nControl Set = "..conset, 10) end if val == 3 then ipc.display("GPS _ AP CHART _ TAGS _ WING LEVEL _ CANOPY\nRADAR _ MAP _ HEADPHONES _ SPARE _ OXYGEN\nControl Set = "..conset, 10) end if val == 4 then ipc.display("COOLANT AUTO _ COOLANT OPEN _ OIL AUTO _ OIL OPEN _ AIL TRM RT\nCOOLANT MAN _ COOLANT CLOSE _ OIL MAN _ OIL CLOSE _ AIL TRM LT\nControl Set = "..conset, 10) end end function dispFUEL_TANK(offs, dummy) TANK =ipc.readLvar("L:FSelP51State") if TANK == 2 then x = "R MAIN" end if TANK == 1 then x = "L MAIN" end if TANK == 0 then x = "FUSELAGE" end if TANK == 4 then x = "R DROP" end if TANK == 3 then x = "L DROP" end ipc.display("FUEL TANK = "..x, 2) -- ipc.display("L:FSelP51State = "..TANK, 2) end function dispFUEL_VALVE(offs, dummy) STATE =ipc.readLvar("L:Eng1_FuelCutOffSwitch") if STATE == 0 then y = "CUTOFF" end if STATE == 1 then y = "CLOSED" end ipc.display("FUEL VALVE = "..y, 2) end function Vent(offset, val) Vent_Set =ipc.readLvar("L:CabinVent") ipc.display("Vent = "..Vent_Set, 1) end function Headphones(control, on_off) ipc.writeLvar("L:Headphones", on_off) ipc.writeLvar("L:SystemCondSelectFSX", 57) ipc.writeLvar("L:SystemCondValueFSX", on_off) end function Oxygen_Mask(control, Mask_on_off) ipc.writeLvar("L:OxyMaskOn", Mask_on_off) ipc.writeLvar("L:SystemCondValueFSX", Mask_on_off) ipc.writeLvar("L:SystemCondSelectFSX", 58) end function GPU(control, GPU_on_off) ipc.writeLvar("L:APUSwitch", GPU_on_off) ipc.writeLvar("L:SystemCondSelectFSX", 53) ipc.writeLvar("L:SystemCondValueFSX", GPU_on_off) end function Disp_El_Trim(control, Dummy) Trim_in = ipc.readSW(0x0BC0) if Trim_in > 0 then Trim_Out = (round(Trim_in/65.532))/10 else Trim_Out = (round(Trim_in/65.525))/10 end ipc.display("El Trim = "..Trim_Out, 1) end function Disp_Rud_Trim(control,Dummy) RTrim_in = ipc.readSW(0x0C04) Rud_Trim = (round(RTrim_in/163.83))/10 ipc.display("Rud Trim = "..Rud_Trim, 1) end function Disp_Ail_Trim(control,Dummy) ATrim_in = ipc.readSW(0x0C02) Ail_Trim = (round(ATrim_in/163.83))/10 ipc.display("Ail Trim = "..Ail_Trim, 1) end -- rounds the integer function round(num) num = tonumber(num) if num == nil then return 0 end if num >= 0 then return math.floor(num+.5) else return math.ceil(num-.5) end end event.offset(0x66C0,"UB","dispP51_CS") event.offset(0x66C6,"UB","dispFUEL_TANK") event.offset(0x66C5,"UB","dispFUEL_VALVE") event.offset(0x66C4,"UB","Vent") event.offset(0x66C7,"UB","Headphones") event.offset(0x66C8,"UB","Oxygen_Mask") event.offset(0x66C9,"UB","GPU") event.control(65607,"Disp_El_Trim") event.control(65615,"Disp_El_Trim") event.offset(0x0C04,"SW","Disp_Rud_Trim") event.control(66276,"Disp_Ail_Trim") event.control(66277,"Disp_Ail_Trim") =============================================== I also use one offset, 0x66CO, as a "Mode" indicator whereby I can have any number of "Modes" as the aircraft interface dictates. I have dual Saitek throttles and use 2 switches of the 12 to change the mode up or down. The other 10 switches have mode-dependent assignments. In the case of the P-51D I have 5 modes. The "dispP51_CS(offs, val)" function in my script simply displays a message in the Lua display for 10 seconds, showing me what controls are assigned to each switch for that mode. The actual assignments are made in the FSUIPC4.ini file using the "Offset Conditions" of FSUIPC as show in the FSUIPC4 for Advanced Users.pdf...see pages 22 & 23. This type of arrangement requires 'hand editing' of the ini file as the menu assignment feature can only assign 1 control to each button when pressed and one when it is released. Here is an example of my technique, showing 2 of my 5 mode settings for the P-51D. [CODE] !=3=//CONTROL SET 3 30=B66C0=2 PD,14,CM10:1,1 ;// PRIMER 31=B66C0=2 UD,14,CM10:1,0 ;// PRIMER RELEASE 32=B66C0=2 PD,18,CM10:2,1 ;// START 33=B66C0=2 UD,18,CM10:2,0 ;// START RELEASE 34=B66C0=2 PD,16,C65635,0 ;// MAG INC 35=B66C0=2 PD,17,C65634,0 ;// MAG DEC 36=B66C0=2 PD,15,C66237,0 ;// FUEL PUMP TOGGLE 37=B66C0=2 PD,19,C65858,0 ;// PITOT HEAT 38=B66C0=2 PA,0,CM10:16,2 ;// GUN SIGHT 39=B66C0=2 PA,1,CM10:18,0 ;// GUN SIGHT GYRO SWITCH 40=B66C0=2 PA,2,CM10:29,1 ;// FIRE GUNS 41=B66C0=2 UA,2,CM10:29,0 ;// CEASE FIRE 42=B66C0=2 PA,3,CM10:17,2 ;// GUN SIGHT MODE !=4=//CONTROL SET 4 50=B66C0=3 PD,14,C65908,0 ;// GPS 51=B66C0=3 PD,15,C66506,440 ;// RADAR 52=B66C0=3 PD,16,C66506,14992 ;// AP CHART 53=B66C0=3 PD,17,C66506,14 ;// MAP 54=B66C0=3 PD,18,C66199,0 ;// TAGS 55=B66C0=3 PD,19,Cx0D0066C7,x01 ;//Headphones Toggle via Lua Event 56=B66C0=3 PA,0,C65727,0 ;// WING LEVEL 57=B66C0=3 PA,2,C66389,0 ;// CANOPY 58=B66C0=3 PA,3,Cx0D0066C8,x01 ;// Oxygen via Lua Event [/CODE] I use a mix of standard FSX controls "C65xxx", Macro file assignments (CM10:xx) and Lua event triggers (Cx0D0066C8,x01) So, as you can see, there are 'many ways to skin a cat' :) Hope this answers more questions than it creates! Paul

That's great, Tom. Glad I could help. Just keep those FSUIPC4 user documents handy! I refer to them frequently when I am setting up my controllers for a new aircraft or tweaking the settings of 'old ones'. :) Paul

I would program the switches/buttons to send the parameter to one of the user-defined offsets (0x66C0 to 0x66FF) and then use the Lua "event.offset(offset, "type", "function name") structure to launch your processing. This passes the parameter that was placed in the offset to the processing function. event.offset(0x66C0, "UB", My_Processing) would be the 'trigger' to launch the processing function when the data in the offset changed. So function My_Processing(offset,value) would receive "0x66C0" as the passed offset and the parameter, in this case an unsigned byte, as the value. You can use multiple offsets to launch the same processing function and differentiate the source by looking at the passed offset to determine 'who' triggered the event. I use this feature to launch most of my Lua processing functions. Another approach: You could also send the parameter to an offset and trigger the processing using the event.button(joynum, button, "processing function") You would then read the offset that you are using to receive the parameter using the ipc.readUB(offset) statement in your function. The joy number and button number will be will be passed to your processing function as well so you can determine 'who' sent the parameter to the offset. Paul

Hummm....my dll.xml has FSUIPC4 as the last entry and it has been that way forever. I suspect that perhaps the TacPac app might be manipulating the dll.xml to place itself last. FSUIPC4 certainly would not be doing that. Paul

I have the B-377 and dual Saitek quadrants. I assign four axis to the throttle functions...1 for each engine. Another axis is assigned for the turbo lever. The last axis is assigned to rpm, which applies to all 4 engines. Before COTS I managed the Tubos with the assigned axis but now with COTS, the virtual FE takes care of that but I keep the assignment in case I want to take full control again at some point. I manage the mixture with switches to set the basic settings, auto rich, auto lean, etc. If I wist to 'tweak' the individual mixtures I just use the mouse to drag the levers. I find it most useful to have one throttle for each engine as that makes taxiing much easier and as the engines age, you will need to adjust each engines' throttle settings keep the mp's and torque matched. Paul

FYI, there is an offset (0x0366) that will tell you if the sim is on the ground or not. You could test this to prevent any unwanted actions while in flight. On the ground = 1. Paul

Günter, Just off the top of my head, how about this: Rev_Axis = abs(var - 100) Just subtract 100 from the 0 to 100 "var" and then take the absolute value. or using your equation above: var = abs(round((ipcPARAM+16384)/32768*100) - 100) Paul

It might be possible to add the fx to the [smokesystem] section of the aircraft.cfg file and give it a number other than smoke.0, say smoke.3. Then send the SMOKE_ON or SMOKE_OFF commands with a parameter of 4 (1 higher than the smoke.3 entry). I don't have that aircraft so I do not know what use is made of the SMOKE section. If the aircraft code uses a global SMOKE_ON/OFF command for some event(s) this method may not work. I've used this method to control individual effects with a XML gauge but you can easily assign those commands to buttons via the FSUIPC4 menu system. The commands are "Smoke On" and "Smoke Off" in the Buttons + Switches section menu. One caveat for this is that at least 1 engine must be running for the smokesystem to be active.

If you have previously installed FSUIPC4 (registered) and have not deleted the entire contents of your Modules folder, you should find a file in there with the extension of .key AIR it is a text file and you should be able to get your information from it. Actually, when installing/updating I believe there is an option to 'use the previous key' or something like that. Selecting that option should cause the installer to get the information from the key file automatically. Paul

You need to also rename a copy of your FSUIPC.ini file and if this is a registered version, you also nee to rename a copy of your key file. I have multiple named copies of my FSX.exe file so that I have multiple CFG files tailored for the particular types of aircraft I wish to fly or the region I am flying in or whether I am going to fly on one of two different MP servers. As long as the ini and key file names match the exe file name, it should work with no problems.

Update: You are correct Pete. There isn't a difference. I just double-checked my Xp FSUIPC4.ini file and the "WhiteMessages=" entry was back to "No". I reset it to "Yes" and the Lua display and the ATIS messages were white. For the ATIS, both the scrolling or non-scrolling text was white when selecting either "Continuous" or "Single Line" in the "Informational Text" area of the FSX "Graphics" settings. Not sure how/when the setting go changed and since I fly in Win7 now almost exclusively I didn't bother to check further. Paul

I have this option set and it does work for the messages it was intended for. I mainly have Lua scripts sending messages to the Lua window when I access various functions and these cone out in white text. This is on my Win7 dual-boot install of FSX. I seem to recall that in my Xp boot, the option did not appear to take effect. Paul

Good day Pete, I just ran through my tests of 'test3' and everything looks good now. That 'anything but 0' issue sure was a strange one. Glad you tracked it done. Thanks for your time if squashing these couple of problems. Paul

Ok, I finally got to test 4839test2 a bit more....first, the good news. The blank window is gone and my lua.displays seem to be working fine. Now the bad news. In both 4389test and 4389test2 all my switch assignments that use a TOGGLE function via the LVar entry is a MCRO file are now 'uni-directional'. That is, they toggle OFF but not ON. I didn't see this earlier as I entered the cockpit of my test aircraft with the major functions already on. Just a bit ago I went back to test everything again and saw this behavior. I tested on 3 different aircraft and the common element was the controls assigned via the MCRO entries with 'TOGGLE' as the action. If the function is ON I can hit my switch and the function goes OFF but I can not then turn it back ON. The standard FSX commands assigned directly Cxxxxxx, work OK but not those as noted above. I also tested with 4387 and the TOGGLE functions worked in that version, but that was the version where the "SET" with a '0' parameter failed. So, something got introduced in the 4839test and test2 versions that messed up the 'xx=LVar=TOGGLE' actions. I also loaded 4827 to make sure that nothing else on my system was involved and 4827 worked fine. Paul

Poster Peter, Pete's memory is spot on. 0x3D00. Here is a snippet of a Lua script I wrote some time ago that uses that offset and another related offset. Perhaps it will help you. -- Offsets 0x3D00 and 0x11D4 are used to chech to see if -- the correct aircraft is selected and the flight is loaded -- Offset 0x3D00 contains the ASCII name of the current aircraft -- Offset 0x11D4 will be 0 when the flight is not loaded or a MENU -- is opened, otherwise it will be 0x0000FADE function Do_Spit(offset, PFlag) -- Initialize a variable for use in sending the "ACTIVE" message if x == nil then x = 0 end -- The next section of code will check to see if the aircaft is a Spitfire Mk I or II -- We check the first 13 ASCII characters of the variable holding the current aircraft name -- bypass the read and write sections if the plane has changed -- NOTE: Make sure FSUIPC.ini has "ShortAircraftNameOk=Yes" declared if ipc.readSTR(0x3D00, 13) == "Spitfire Mk I" then -- Also check to see that the flight is loaded and we are not PAUSED -- If either condition is not met, bypass the read/write sections of the code if ipc.readUD(0x11D4) > 0 and ipc.readSW(0x0264) == 0 then -- If This is a Spit and the flight is loaded and we are not paused, Read the L:Variables RPM = ipc.readLvar("L:Eng1_RPMGauge") OIL_PRESS = ipc.readLvar("L:Eng1_OilPressureGauge") OIL_TEMP = ipc.readLvar("L:Eng1_OilTempGauge") BOOST = ipc.readLvar("L:Eng1_MPGauge") RAD_TEMP = ipc.readLvar("L:Eng1_WaterTempGauge") FUEL_PRESS = ipc.readLvar("L:Eng1_FuelPressureGauge") LEFT_BRAKE = ipc.readLvar("L:LeftBrakePressureGauge") RIGHT_BRAKE = ipc.readLvar("L:RightBrakePressureGauge") Top_Needle = ipc.readLvar("L:FuelGauge1") Bot_Needle = ipc.readLvar("L:FuelGauge2") -- Scale a few to get the tenths portion into the integer variable RPM = RPM * 10 OIL_PRESS = OIL_PRESS * 10 OIL_TEMP = OIL_TEMP * 10 BOOST = BOOST * 10 RAD_TEMP = RAD_TEMP * 10 FUEL_PRESS = FUEL_PRESS * 10 Top_Needle = Top_Needle * 10 Bot_Needle = Bot_Needle * 10 -- Write the data out to chosen user-defined offsets ipc.writeUW(0x66C0,RPM) ipc.writeUW(0x66C2,OIL_PRESS) ipc.writeSW(0x66C4,OIL_TEMP) ipc.writeSB(0x66C6,BOOST) ipc.writeUB(0x66C7,FUEL_PRESS) ipc.writeSW(0x66C8,RAD_TEMP) ipc.writeUB(0x66CA,LEFT_BRAKE) ipc.writeUB(0x66CB,RIGHT_BRAKE) ipc.writeSW(0x66EC,Top_Needle) ipc.writeSW(0x66EE,Bot_Needle) -- Output a "feel good" message for test purposes periodically if x == 20 then ipc.setdisplay(1000, 25, 100, 50) ipc.display("ACTIVE", 1) -- Reset the test counter after the message is diplayed x = 1 -- Or increment the counter if it hasn't reached 20 yet else x = x + 1 end else -- If the conditions for doing the reading/writing are not satisfied -- wait 1 second and check again ipc.sleep(1000) end end end [/CODE] Paul

Hello Pete, First, yes, the fluctuating window position seems to be resolved however since I was not able to reproduce that action 'on demand'...it was rather random, I will keep any eye on the windows, so to speak :) Thanks for digging into the phantom window issue. I'll be testing the updated 4839 within the hour. And thanks again for the quick fix. You didn't 'waste' any of my time. I'm a 'tweaker' and 'troubleshooter' by nature and training (retired electronic engineer). :) Paul

Pete, If I close that blank window then my ipc.display routines no longer function. The problem with it is if I minimize FSX to get to shortcuts on my desktop, if they are under that blank window I can't get to them. As you can see, I tend to accumulate a good many shortcuts :) Paul

Hello Pete, I just d/l'd 4839 and will test in in a few hours, once I get through my morning online chores :) Thanks for the quick find and fix! Paul EDIT: OK, I checked the L:var=SET condition and that does appear to be fixed. Thanks. With regards to the Lua display window, what I see now is a blank, tan window that opens and remains open as long as FSX is running. It minimizes as soon as I put the focus on the main FSX window. Does this need to be opened to insure the operation of the lua.display positioning? Here is what I am seeing: Paul