[Questions about Setup for Saitek ProFlight Yoke & Throttles]

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

[Problem w/ Not Being Allowed To Assign Planes To Profile]

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

[rudder trim and rudder problem]

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 and rudder problem]

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

[Fuel Cutoff]

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

[Solved: ipcparam, Should this work???]

happens to me every day :razz:

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

paul

[How do you read the parameter value of a joy/button in a lua script?]

Thanks Very Much for the explanation and sample scripts!

I've got a long way to go on the lua learning curve, but you've certainly given me another push in the write direction. As of this morning I have many of the functions in my Carenado King Air C90 working thanks to your help. I'm still having trouble with a few they have that use timers, but thats not so much lua related as it is how Carenado has the application coded.

Again Thanks!

Tom G..

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

[How do you read the parameter value of a joy/button in a lua script?]

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

[How do you read the parameter value of a joy/button in a lua script?]

Paul,

Thanks again for your help, I now have it working!!!

Tom G.

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

[How do you read the parameter value of a joy/button in a lua script?]

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

[dll.xml changes by itself?]

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

[Four engine props.]

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

[NGX Trimwheel]

Got it working with a Lua to reset at value 0 followed by ipc.control.

0 is the forward most position and close to where takeoff trim is as well, but that's fine I can just set my trim wheel near the top before pushing the button.

I just have to remember not to push that button in flight, or I'll be pointing at the ground!

Cheers and thanks for the Lua help

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

[reverse axis in LUA script]

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

[OK Pete, Here is one for you!]

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.

[Registration key]

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

[FS9.exe with another name]

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.

[FSX white text instead of red]

Hmmm. Interesting. I can't see any reason for a difference between XP and Win7 though -- the code for all the graphics involved in local to FS. I don't think it is dependent on driver behaviour at all.

Pete

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

[FSX white text instead of red]

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

[MCRO L:Var=SET when "0" broken]

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

[MCRO L:Var=SET when "0" broken]

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

[LUA: repeated evemt.key action and plane recognition]

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

[MCRO L:Var=SET when "0" broken]

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

[MCRO L:Var=SET when "0" broken]

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

[MCRO L:Var=SET when "0" broken]

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