['Next / Prev View' controls don't work?]

Hi there,

I'm trying to map 'Next View' / 'Prev View' ('S' and 'Shift + S' keys in FSX) controls on my Saitek X52 Pro POV1 hat-key using FSUIPC combined buttons. But for some reason they don't work. I've checked the INI entries (see below), but I can't find anything wrong with them. These combinations for buttons 32-38 are used for views only and I've specifically checked that they aren't mapped on other buttons. Interestingly, 'Next Sub View' and 'Prev Sub View' ('A' and 'Shift + A' keys in FSX) controls work OK.

Maybe someone has better eyes than mine? Kindly appreciated!

48=CR(-0,0)(-0,14)(-0,15)0,34,C65672,0 	-{PAN_RIGHT}-
49=CR(-0,0)(-0,14)(-0,15)0,38,C65671,0 	-{PAN_LEFT}-
51=CR(-0,0)(-0,14)(-0,15)0,32,C65734,0 	-{PAN_UP}-
52=CR(-0,0)(-0,14)(-0,15)0,33,C65856,0 	-{PAN_RIGHT_UP}-
53=CR(-0,0)(-0,14)(-0,15)0,35,C65857,0 	-{PAN_RIGHT_DOWN}-
54=CR(-0,0)(-0,14)(-0,15)0,36,C65735,0 	-{PAN_DOWN}-
55=CR(-0,0)(-0,14)(-0,15)0,37,C65855,0 	-{PAN_LEFT_DOWN}-
56=CR(-0,0)(-0,14)(-0,15)0,39,C65854,0 	-{PAN_LEFT_UP}-
57=CP(+0,0)(+0,14)(-0,15)0,32,C65875,0 	-{PAN_RESET}-
58=CP(+0,0)(-0,14)(-0,15)0,34,C66153,0 	-{NEXT_SUB_VIEW}-
59=CP(+0,0)(-0,14)(-0,15)0,38,C66154,0 	-{PREV_SUB_VIEW}-
60=CP(+0,0)(+0,14)(-0,15)0,34,C65827,0 	-{NEXT_VIEW}-
61=CP(+0,0)(+0,14)(-0,15)0,38,C65828,0 	-{PREV_VIEW}-
62=CR(-0,0)(-0,14)(+0,15)0,34,C66526,0 	-{EYEPOINT_RIGHT}-
63=CR(-0,0)(-0,14)(+0,15)0,38,C66527,0 	-{EYEPOINT_LEFT}-
64=CR(-0,0)(-0,14)(+0,15)0,32,C66528,0 	-{EYEPOINT_FORWARD}-
65=CR(-0,0)(-0,14)(+0,15)0,36,C66529,0 	-{EYEPOINT_BACK}-
66=CR(+0,0)(-0,14)(+0,15)0,32,C66524,0 	-{EYEPOINT_UP}-
67=CR(+0,0)(-0,14)(+0,15)0,36,C66525,0 	-{EYEPOINT_DOWN}-
68=CP(+0,0)(+0,14)(+0,15)0,32,C66530,0 	-{EYEPOINT_RESET}-

 

[problem with getting the right RPM value for some aircrafts!]

Hi there,

I know, it's an old topic but I'm putting it here not to spoil the forum with yet another similar topic. Please feel free to relocate it as appropriate.

Anyway, I'm trying to get the values for Prop RPM percentage (%) and Torque pressure (psi) for Aerosoft Twin Otter DHC-6-300 and to display them on the screen via a LUA script. The script works OK but I'm not sure if the offsets I'm working with are correct - the values match with the aircraft's gauge indicators only if divided with certain 'guesstimated' scalars , as shown below (e.g., 386.45 and 327.66).

So, is there any elegant solution to get correct values for the above parameters?

PS: FSX Acceleration with FSUIPC v4.972a

    propRPM1 = round (ipc.readDBL(0x2400) / 386.45)
    propRPM2 = round (ipc.readDBL(0x2500) / 386.45)
    torque1 = round (ipc.readUD(0x08F4) / 327.66)
    torque2 = round (ipc.readUD(0x098C) / 327.66)

Thanks!

[Offsets for HSI heading and course values]

Thank you, Thomas! That's exactly what I was looking for. It works! :)

[Offsets for HSI heading and course values]

Hello everybody,

I'd like to display heading and course degrees on Horizontal Situation Indicator (HSI) through FSUIPC. I can see the tool-tips regular way (mouse hovering) but it's inconvenient during flight. E.g., I've tried to use the offset 0x0580 further converted to magnetic heading and displayed at each inc/dec of the heading bug but what I've got is aircraft's positional heading, not the one selected on HSI. Basically, what I want to achieve is a sort of 'tool-tip display using FSUIPC'.

So, I wonder if one can successfully retrieve these values using FSUIPC on each turn/press of the HSI rotary button?

Thanks!

[LUA error: attempt to call global 'function_name' (a nil value)]

OMG, it was so obvious... This one works finally:

function Armrest_Toggle()
    ipc.writeLvar("L:Twot_Armrest", nToggleVal(ipc.readLvar("L:Twot_Armrest"), 0, 1))
end

Thank you VERY much for the hint, Thomas!!!

[LUA error: attempt to call global 'function_name' (a nil value)]

I tried this to no avail yet...

function nToggleVal(nCurrVal, nVal1, nVal2)
	if nCurrVal == nVal1 then
		return nVal2
	else
		return nVal1
	end
end

function Armrest_Toggle()
    ipc.writeLvar(nToggleVal(ipc.readLvar("L:Twot_Armrest"), 0, 1))
end

if ipcPARAM == 0 then

	Armrest_Toggle()
	
end

FSUIPC.ini is unchanged - FSUIPC recognizes the button OK. The problem is associated with function call I think. But I don't know why the above syntax doesn't work... :(

[LUA error: attempt to call global 'function_name' (a nil value)]

Thank you, Thomas!!! Strange, I thought calling functions was just a matter of proper environment definition (local or global), but direction of declaration is smth new for me...

I'll try your suggestion and return to this thread.

And Happy New Year!!!

[LUA error: attempt to call global 'function_name' (a nil value)]

Hi there,

I'm trying to call the function 'Armrest_Toggle' with a button assigned through FSUIPC as follows:

if ipcPARAM == 0 then

	Armrest_Toggle()

end

local function Armrest_Toggle()
    ipc.writeLvar(nToggleVal(ipc.readLvar("L:Twot_Armrest"), 0, 1))
end

local function nToggleVal(nCurrVal, nVal1, nVal2)
	if nCurrVal == nVal1 then
		return nVal2
	else
		return nVal1
	end
end

I'm tracing the changes in LVars and when I press the assigned button, I get this error:

273111 *** LUA Error: ...Games\Microsoft Flight Simulator X\Modules\dhc-6.lua:26: attempt to call global 'Armrest_Toggle' (a nil value)

And here is the content of FSUIPC.ini, as relates to the particular aircraft I've loaded into the sim:

[JoyNames]
AutoAssignLetters=No
0=X52 Pro Flight Controller
0.GUID={A1946F60-C51A-11E6-8005-444553540000}

[Profile.DHC-6]
1=Aerosoft DHC-6

[Buttons.DHC-6]
0=P0,1,CL1:R,0 ; armrest toggle 	-{Lua dhc-6}-

[General]
ShortAircraftNameOk=Substring

[LuaFiles]
1=dhc-6
2=ipcReady
3=linda

 

I wonder what can cause this error? Thanks in advance!!!

FSUIPC4.log

[RealAir Beech Duke Turbine]

Thank you VERY much, Sir!!!

 

I took the liberty to translate your LINDA script to "basic" Lua language since I don't use Linda with FSX. And it works pretty well!

 

I hope you don't mind... :)

 

Cheers,

 

Rustam

[Displaying ADF frequency (offsets 02D4 and 02D6)]

The power of C libraries... :) Amazing solution, thanks a million!!!
 
I took the liberty to slightly modify your code - otherwise I see a blank spot instead of a zero:

adf2_main = string.format("%03X", adf2_main) 

Thanks again, Roman!!!

[Log only specific L:Vars in a display window for gauge debugging]

Simply brilliant! Thank you!!!

[Displaying ADF frequency (offsets 02D4 and 02D6)]

Since on aircraft I'm flying the ADF frequency is barely visible, especially the fractions part, I've written this piece of "dirty" code to display it on the screen:
 

-- Converts decimal values stored at offsets 02D4 & 02D6 to hex
function dec2hex(num)

    local a = {}
    local b = {}
    local i = 0
	
    num = tonumber(num)
	
    while num > 0 do
         local q = math.floor(num / 16)  -->> find quotient
	 local r = num - q * 16          -->> find remainder

	 if r == 10 then r = "A"                -->> this IF part is not required anyway due to offset limits but it makes the converter sort of complete!
	    elseif r == 11 then r = "B"
	    elseif r == 12 then r = "C"
	    elseif r == 13 then r = "D"
	    elseif r == 14 then r = "E"
	    elseif r == 15 then r = "F"
         end

         num = q
         i = i + 1
         a[i] = r
   end

   -- reverse the array elements
   for j = 1,i do
      b[j] = a[i]
      i = i - 1
   end

   -- join the array elements to a string
   return table.concat(b,"")

end

adf = ipc.readUW(0x02D4)
adf_f = ipc.readUW(0x02D6)

if adf_f == 0 then                             -->> Do I need to modify this IF part?!
   adf = dec2hex(adf)
elseif adf_f == 256 then
   adf = dec2hex(adf) + 1000
elseif adf_f > 256 then
   adf = dec2hex(adf) + 1000 + (adf_f - 256)/10
elseif adf_f > 0 and adf_f < 256 then
   adf = dec2hex(adf) + adf_f/10
end

ipc.display("ADF = "..adf.." kHz")
ipc.sleep(50)

The code goes into a WHILE loop and so far works ok. What I really wonder is how I can modify the IF section indicated above to read hi / low bytes at offset 02D6 properly (instead of doing this "dirty" hex / decimal addition) and amend to the value of offset 02D4 converted to hex?

 

I'm sure the answer is really simple but I can't figure the better approach yet...

Thanks!

[Elevation trim offset (xBC0): Min / Max values]

As far as I can trace in the event log, by default the controls 65607 and 65615 has max step of 31. Therefore, I'm trying to implement the following code to bypass default values with step 256/16384:

-- Elevator Trim -------------------------------------------------------------------------

if ipcPARAM == 890 then				--	Up

	local val = ipc.readSW(0x0BC0)
	local newval = val + 256
	
	if newval > 16383 then
		ipc.writeSW(0x0BC0,16383)
		ipc.writeLvar(soundSet,0)
	else 
		ipc.writeSW(0x0BC0,newval)
		ipc.writeLvar(soundSet,10)
	end
	
end

if ipcPARAM == 891 then				--	Down

	local val = ipc.readSW(0x0BC0)
	local newval = val - 256
	
	if newval < -16383 then
		ipc.writeSW(0x0BC0,-16383)
		ipc.writeLvar(soundSet,0)
	else 
		ipc.writeSW(0x0BC0,newval)
		ipc.writeLvar(soundSet,10)
	end
	
end

But it seems strange that when I reach 0 (zero) trimming down the elevator, instead of switching to negative values, the offset values start counting down from 65536, as shown in the image below, whereas in the List of Offsets it's clearly stated that elevator trim control input at offset xBC0 ranges from –16383 to +16383 being of type signed word (SW). Or, am I getting smth wrong?! :)

 

 

Thanks!

 

Rustam

 

[Adding Sounds to Your Cockpit (LUA)]

Thank you, Michael!!!

 

Very helpful and generous of you indeed...

[[SOLVED] Compound buttons & LUA script]

Roman,

 

Thanks a lot! I followed your tips and guess what - it works, although a bit unexpectedly! :D

 

 

Basically you have to tell FSUIPC to get the state of all the buttons when 1 action button has a compound. They are not assumed as unpressed. Edit - Another way of thinking about it is - an action button can be either a press or a compound, but not both.

 

 

I see your point... The lesson learnt: the key, as you have also mentioned, is the state of all buttons involved in compound button programming, not what one expects them to do even if the syntax I posted in OP is pretty much logical...

 

Have a nice day!

 

Rustam

[[SOLVED] Compound buttons & LUA script]

Thanks, Roman!

 

I double checked the contents of the INI file, nothing suspicious or similar to what you have described... But a 2nd set of eyes is better anyway:

 

[JoyNames]
AutoAssignLetters=No
0=Saitek X52 Pro Flight Controller
0.GUID={355F3F90-50DC-11E5-8001-444553540000}
 

[LuaFiles]
1=SW_AN2
2=ipcReady
3=linda

 
[Profile.SW_AN2]
1=Antonov
 
[Buttons.SW_AN2]
0=CP(+0,28)0,4,CL1:R,1125 ; adf near-far switch
1=R0,6,CL1:R,780 ; mixture lean
2=R0,7,CL1:R,781 ; mixture enrich
3=CR(+0,18)0,6,CL1:R,812 ; prop pitch decr
4=CR(+0,18)0,7,CL1:R,813 ; prop pitch incr
5=R0,2,CL1:R,891 ; elevator trim down
6=R0,3,CL1:R,890 ; elevator trim up
7=P0,12,CL1:R,88 ; flaps up incr
8=P0,13,CL1:R,79 ; flaps down incr
9=P0,4,CL1:R,751 ; emerg flaps switch
10=P0,5,CL1:R,131 ; brakes
11=CP(+0,15)0,5,CL1:R,133 ; parking brakes
12=P0,1,CL1:R,1 ; cold & dark + autostart
13=U0,14,CL1:R,59 ; landing light left
14=P0,14,CL1:R,58 ; landing light right
15=P0,8,CL1:R,60 ; navigation light
16=P0,9,CL1:R,62 ; strobe light
17=P0,10,CL1:R,61 ; taxi light
18=P0,19,CL1:R,300 ; cockpit door
19=P0,21,CL1:R,301 ; pax door
20=CP(+0,15)0,21,CL1:R,302 ; cargo door
21=R0,20,CL1:R,900 ; aileron trim left
22=R0,22,CL1:R,901 ; aileron trim right
23=P0,31,CL1:R,132 ; manual pump
24=CP(+0,18)0,31,CL1:R,107 ; manual primer
25=CP(+0,15)0,31,CL1:R,57 ; tailwheel lock
26=CP(+0,15)0,25,CL1:R,1264 ; fuel tanks
27=CP(+0,15)0,8,CL1:R,65 ; battery
28=CP(+0,15)0,9,CL1:R,64 ; generator
29=CP(+0,15)0,23,CL1:R,804 ; magnetos
30=P0,23,CL1:R,920 ; cowl flaps incr
31=P0,25,CL1:R,921 ; cowl flaps decr
 
[Axes.SW_AN2]
RangeRepeatRate=10
0=0X,256,D,1,0,0,0
1=0Y,256,D,2,0,0,0
2=0Z,256,D,4,25,0,0
3=0R,256,D,3,0,0,0
 
[JoystickCalibration.SW_AN2]
Aileron=-16384,-512,512,16384
AileronTrimControl=0
AllowSuppressForPFCquad=Yes
ApplyHeloTrim=No
BrakeReleaseThreshold=0
CowlFlaps1Control=0
CowlFlaps2Control=0
CowlFlaps3Control=0
CowlFlaps4Control=0
Elevator=-16384,-512,512,16384
ExcludeMixtureSet=Yes
ExcludePropPitchSet=Yes
ExcludeThrottleSet=Yes
FlapDetents=No
FlapsSetControl=0
MaxSteerSpeed=60
MaxThrottleForReverser=256
Reverser1Control=66422
Reverser2Control=66425
Reverser3Control=66428
Reverser4Control=66431
Reverser=-16384,-11000
ReverserControl=66292
Rudder=-16384,-512,512,16384
RudderTrimControl=0
SepRevsJetsOnly=No
SlopeAileron=-2
SlopeElevator=-2
SlopeRudder=-3
SlopeThrottle=-4
SteeringTillerControl=0
Throttle=-9000,16384
UseAxisControlsForNRZ=No
 
[General]
AdvDisplayHotKey=65,11
AileronSpikeRemoval=Yes
AutoScanDevices=Yes
AutoTuneADF=No
AxesWrongRange=No
AxisCalibration=No
AxisIntercepts=No
BlankDisplays=No
BrakeReleaseThreshold=75
ClearWeatherDynamics=No
ClockSync=Yes
ClockSyncMins=1
CloudIcing=No
CloudTurbulence=No
Console=No
CustomWeatherModify=No
DelayedMouseLookZoom=No
DeleteVehiclesForAES=Yes
DirectAxesToCalibs=No
DisconnTrimForAP=Yes
DontResetAxes=No
ElevatorSpikeRemoval=Yes
EnableMouseLook=No
EventsViaCommands=Yes
FixControlAccel=Yes
FixMachSpeedBug=Yes
GenerateCirrus=No
GetNearestAirports=Yes
History=5A32BD8JRGOS3PH71NH2N
InitDelay=0
InitDelayDevicesToo=No
LoadFlightMenu=No
LoadPlanMenu=No
LuaRerunDelay=66
MagicBattery=No
MaxIce=-4
MaxSurfaceWind=0
MinIce=-4
MouseWheelMove=No
MouseWheelTrim=No
MouseWheelTrimSpeed=1
NewInterceptTextMenu=No
OneCloudLayer=No
OOMcheck=Yes
OOMcheckInterval=10
OwnWeatherChanges=No
PatchSIM1friction=Yes
PauseAfterCrash=Yes
PollGFTQ6=No
PressureSmoothness=0
ReversedElevatorTrim=No
RudderSpikeRemoval=Yes
SaveDataWithFlights=No
SavePreviousFlight=No
ShortAircraftNameOk=Substring
ShowMultilineWindow=Yes
ShowPMcontrols=No
SimConnectStallTime=1
SmoothBySimTime=No
SpoilerIncrement=512
SuppressAllGusts=No
SuppressCloudTurbulence=No
SuppressMultilineFS=No
SuppressSingleline=No
SuppressWindTurbulence=No
SuppressWindVariance=No
TCASid=Flight
TCASrange=40
TemperatureSmoothness=0
ThrottleSyncAll=No
TimeForSelect=4
TurbulenceDivisor=20,20,40,40
TurbulenceRate=1.0,5.0
UpdatedByVersion=4945
UpperWindGusts=No
UseMidMouseBtn=No
UseProfiles=Yes
UseSystemTime=No
VisibilityOptions=No
WeatherReadFactor=2
WeatherRewriteSeconds=1
WhiteMessages=Yes
WindAjustAltitude=No
WindAjustAltitudeBy=2000
WindDiscardLevel=400
WindLimitLevel=200
WindSmoothAirborneOnly=Yes
WindSmoothing=No
WindSmoothness=2
WindTurbulence=No
ZapSound=firework
ZeroElevForAPAlt=Yes
JoystickTimeout=20
ConsoleWindow=0,0,0,0
LogEvents=Yes
FSVersionUsed="Microsoft Flight Simulator X",10.0.61637.0
SimConnectUsed=10.0.61259.0
 
[Axes]
PollInterval=10
RangeRepeatRate=10
 
[Buttons]
PollInterval=25
ButtonRepeat=20,10
 
[JoystickCalibration]
Aileron=-16384,-512,512,16384
AileronTrimControl=0
AllowSuppressForPFCquad=Yes
ApplyHeloTrim=No
CowlFlaps1Control=0
CowlFlaps2Control=0
CowlFlaps3Control=0
CowlFlaps4Control=0
Elevator=-16384,-512,512,16384
ExcludeMixtureSet=Yes
ExcludePropPitchSet=Yes
ExcludeThrottleSet=Yes
FlapDetents=No
FlapsSetControl=0
MaxSteerSpeed=60
MaxThrottleForReverser=256
Reverser1Control=66422
Reverser2Control=66425
Reverser3Control=66428
Reverser4Control=66431
Reverser=-16384,-11000
ReverserControl=66292
Rudder=-16384,-512,512,16384
RudderTrimControl=0
SepRevsJetsOnly=No
SteeringTillerControl=0
Throttle=-16384,16384
UseAxisControlsForNRZ=No
 
[AutoSave]
AutoSaveEnabled=No
Files=10
Interval=60
Next=1
SaveOnGround=No
 
[GPSout]
GPSoutEnabled=No
Port=COM0
Speed=4800
Interval=2000
PosTo6Decimal=No
SimModeIndicator=No
Sentences=
 
[GPSout2]
GPSoutEnabled=No
Port=<none set>
Speed=4800
Interval=2000
PosTo6Decimal=No
SimModeIndicator=No
Sentences=
 
[WideServer]
WideFSenabled=Yes
 
[Window.LUA display]
Docked=7354, 2828, 3545, 2459

 

Thanks!

 

Rustam

[[SOLVED] Compound buttons & LUA script]

Can you please check the following syntax?
 
I have tried to integrate both programming methods since I couldn't find a proper example showing the usage of combined buttons and LUA parameters in the FSUIPC Advanced User manual. This one doesn't work - FSUIPC recognizes only the action button and the LUA parameter but skips the trigger (+0,28) button.

Is it possible to combine the two at all?!

...
27=CP(+0,28)0,8,CL1:R,65 ; battery              {ipcPARAM = 65 in the 1st LUA file is activated with button 8 on joy 0 while button 28 on joy 0 is pressed}
28=CP(+0,28)0,9,CL1:R,64 ; generator            {ipcPARAM = 64 in the 1st LUA file is activated with button 9 on joy 0 while button 28 on joy 0 is pressed}
...

Thanks!

Rustam

[SibWIngs AN-2: LVars associated with inertial clutch switch]

 

 

Does the switch respond and annimate to the parameters of 0 and 1?

 

Yes, the assigned button activates both positions (0 for neutral and 1 for charging) well. But smth gets wrong at charging stage unless I switch to position 1 with mouse. The L:Var "AN2_inertia" should increase gradually adding ~0.15 at each charging step, whereas with LUA script switching from 0 to 1 sky-rockets the value to >1000... Switching to position -1 with LUA is... impossible at all!

 

 

When debugging issues like this I assign a button/switch temporarily to the L:Var in question (You may need to create

an MCRO file with an entry to define the L:Var and use SET as the function) The L:Var should then be present

in the FSX Commands list of the Buttons & Switches menu.

 

I simply set/change the parameter via the menu then 'Reload all..' and press the assigned switch or burron and observe

the results.

 

Roger that... If I understood you correctly I can achieve the same with LINDA Tracer - it has a facility where you can change a value of the L:Var in question "on the fly". Will try that again to debug.

 

 

Although 3 position switches with a center 'off' are most frequently coded to us 1, 0, -1 parameters this may

be an oddball. Try 0, 1 and 2 to see if that works.

 

Thanks for a tip!!!

 

 

 

Anyhow, unless there is some other dependancy in the code for that switch position to function...

 

That's my nightmare... I expressed the same concern about the code at SibiWings forum, so I strongly hope to get a reasonable answer from the developers.

 

Paul, thanks again for your time and understanding!!!

[SibWIngs AN-2: LVars associated with inertial clutch switch]

Captains,

 

I'm close to finish my first ever LUA script which is dedicated to beautiful but grumpy "Annushka". :)

 

It was made possible thanks to precious advices I got from Pete, Paul (Gypsy Baron), LINDA Tracer and already covers almost ALL buttons, knobs, and switches found in the cockpit. But it can do more, particularly put the aircraft in a complete Cold & Dark situation and initiate the auto-start procedure (for lazy guys like me!).

 

There is only one problem though and I would like to hear your advice again. The final stage of auto-start procedure requires inertial clutch switch put to charging (LMB click), then wait until the charger noise stabilizes and ampermeter shows not less than 8 amps, and switch it to the right (RMB click) with magneto set to 1+2 mode immediately after engine is started. The following piece of code tries to accomplish this task:

 

local i = 0

local clutch = "L:AN2_inertial_clutch"

local soundSet = "L:play_sound"

local magneto = 0x0892

 

if ipc.readLvar(clutch) == 0  then 

   ipc.writeLvar(clutch,1)             -- inertial clutch switch CHARGE (LMB click)

   ipc.writeLvar(soundSet,10)

 

   i = 3

 

   while i > 0 do

      ipc.control(66740,1)             -- manual pump switch x3 times

      ipc.writeLvar(soundSet,52)

      ipc.sleep(1500)

      i = i - 1

   end

 

   if ipc.readUD(0x08F8) > 0 then             -- while fuel pressure is OK...

      ipc.control(66300)

      ipc.writeLvar(clutch,-1)             -- put inertial clutch switch to ON (RMB click)

      ipc.sleep(500)

   end

 

   if ipc.readUW(magneto) == 0 then 

      ipc.control(66400,3)             -- set magneto to 1+2

      ipc.writeLvar(soundSet,13)

      ipc.display("Magneto: SET TO 1+2")

      ipc.sleep(1000)

   end

 

end

 

Here is the photo of the switch:

 

 

But in fact changing L:Var "AN2_inertial_clutch" to -1 (note the minus sign!) yields nothing... :( When I do this with mouse, the engine starts OK but programmatically it's not possible... yet! The switch doesn't animate, nor it returns the requested value (-1).

 

I have tried to trace the L:Vars associated with the clutch switch but I cannot see them in event log. So, I thought maybe you can advice what other variables might be initiated during the startup so that the script can do everything without any user (mouse) interaction?

 

Thanks!

 

Rustam

[Read value of FSX control?]

Thanks a lot, Pete!!! It works finally!

 

Controls cannot have states!! I keep telling you the same thing but you persist! :( I keep telling you this but you persist in misunderstanding.

Meanwhile why not use what I gave you? I seem to be wasting my time providing answers on a plate for you! :sad:

Oh, my intention was not to make you sad or be arrogant to your recommendations! I hope I didn't say anything harmful... I must admit, I didn't check your recommendation before posting here but hey I was just trying to make my point concerned that checking that particular offset may not help... even though it looked as the only reasonable condition to check.

Also, I was confused when I saw in the event log that control parameter actually changes from 0 to 1 and back. I thought there must be a way to check those parameters programmatically, like "if ipc.control(66477,0) == true/false then".

 

3122 is a collection of 8 swtich settings, one in each bit of the byte. (Remember -- a byte is a collection of 8 bits). When a bit is set to 1 then it means that switch is ON (or True, if you like). When it is 0 then it is OFF (or False).

As I showed in my last reply, in the part you evidently ignored, to test the state of the switch you must test the state of the relevant bit. In the case of the Marker sound being enabled or not, it is bit 2, which is the 3rd bit up so worth 2 x 2 (2^2) or 4. (You DID refer to that FAQ thread I hope?).

I think there are uses of the logic library in many of the Lua examples provided and written by others.

Again, thank you very much for your tips!!!

PS: Judging from that huge list of FSX controls and knowing that control parameters cannot have states, does it mean that each control can be checked using your published offsets?

Rustam

[Read value of FSX control?]

Thank you, Pete!
 

No. Toggle controls ignore the parameter, they just toggle the action -- i.e. turn it off if on and on if off. That's why they are called "toggles". Since controls are things SENT to FS to make it do something, they aren't read-outs. And even if you did read them (FSUIPC intercepts them for logging), their parameter would not necessarily indicate the state. Whether the control does somerthing or not is up to FS and the subsystem involved. And, as just stated, in the case of Toggles, there's no parameter of use in any case.

 
Yes, I know that. To be more specific, I think the question I had to ask shouldn't be HOW to check the state of control but WHAT conditionality can be used to effectively know the control's state if developer hadn't specify a local variable to check against, or when it's impossible to get such variable with regular tools (like an event log) even if LVar exists. But you've answered that already below recommending to employ offsets which I did actually in my example... to no avail yet. :)

 

Is it possible to get control's state/parameter similar to how FSUIPC writes it into the log file?
 

I don't know what you mean by " I'm not sure that the read offset is a solid reference when the actual marker sound is not audible:". The flags in 3122 show the state of the option, not whether a sound is actually playing at the time.

Oh, good to know that, thanks! What I mean is I cannot think of any other conditionality to use for checking the state of such a simple control as 66477. It's just a toggle switch with 2 parameters only, as I described above, and I really didn't want to bother writing a special function for checking its on/off condition. Even the offset 0x3122 we discuss here doesn't seem to be a reliable condition to check against. Sorry but I cannot comment more on this since I don't know the specifics of what this marker sound offset controls - I just saw it on the list of offsets and it seemed to be the only option to use as a condition to check control's state.
 

That's no good.  Bit 2 (i.e. value 4) is only one bit in use in 3122. Testing equal to 4 would only work if you made sure all the other sound options were switched off!
 
To test a single bit in an offset you need to separate it, like so:
 
soundbits = ipc.readUB(0x3122)
if logic.And(soundbits, 4) ~= 0 then ...

Can you expand this part a bit, please? Two questions:

# What condition(s) should be met so that the check of offset 3122 returns true or false? Again, I don't know much about this offset except that it's listed in FSUIPC document... If it doesn't control an actual marker sound then what?! Will this help to check the control's (66477) state? I'm confused...
# Where can I get more info/examples on LUA logic library? I read about it in on p.11 of the reference paper but there is just a table with not much details covered.
 

I strongly suggest you review the thread on bits and numbers in the FAQ subforum (http://forum.simflight.com/topic/63908-about-bits-numbers-and-hexadecimal/, and also try perusing some of the Lua examples supplied in your FSUIPC Documents subfolder and written by Users in the User Contributions subforum.

I will for sure! The quest goes on... :)

Thanks a lot for your time and unprecedented support!!!

[Read value of FSX control?]

I know, it's a rather old thread but I came across a similar situation when I need to know ipc.control parameter value to do one of the two actions using the same button on my joystick when there is no LVar as a condition to check against. Eg., Marker Sound Toggle which is 66477 and accepts two parameters only: 1 to do this, 0 to do that... in my case to switch between the toggle's sound files at on/off positions.

 

The event log also shows the control, its name, and parameters (0 or 1) but I don't know how to make that work in LUA file. Being unable to effectively check ipc.control's parameter, I've tried this workaround with marker sound offset mask from the "List of FSX Offsets" but I'm not sure that the read offset is a solid reference when the actual marker sound is not audible:

 

	if ipcPARAM == 41 then	--	Toggle

		if ipc.readUB(0x3122) == 2^2  then  -- <-- I need a valid condition to check on this line. Eg, "if ipc.control(66477) parameter = 1 then do this"...
			ipc.control(66477)
			ipc.writeLvar(soundSet, 10) -- <-- sound file to play when ON
		else
			ipc.control(66477)
			ipc.writeLvar(soundSet, 11) -- <-- sound file to play when OFF
		end
		
	end

Thanks!

[LUA file and button / keypress assignments]

 

 

This is confusing! So you are NOT trying to assign actions to a real hardware 3 position switch? You are just using ordinary buttons?

 

If by "ordinary buttons" you mean joystick buttons, yes, I am.

I don't have any 3-position switch on my Saitek X52 Pro, unfortunately, but use a HAT3 switch with up/down/left/right buttons instead.

 

So, at first I was thinking to assign all 3 positions of the clutch switch to a single button. But then it seemed totally unrealistic and illogical to me - a user may simply revoke his decision to start the engine and may want to return the switch to OFF (from LVar param = 1 to 0) without even going further to LVar param = -1 as an extra (unnecessary) step. So, two buttons are OK since this also complies with real-world operation of the aircraft - one button (ipcPARAM = 0) will toggle the switch from 0 to 1 (and back) while the other one (ipcPARAM = 1) will control positions 0 and -1, respectively. The latter doesn't work... yet! 

 

And thanks for info about offsets!!! I'll check that and report back.

 

All the best,

 

Rustam

[LUA file and button / keypress assignments]

 

You can make as many assignments to the same button as you wish. FSUIPC executes them in order. But if you have a 3 position switch, surely each position is detected seperately -- or at least one position = "released" and the other two different button numbers? If not, then the wiring of the switch is all wrong, with all three positions, or at least two of them, wired together!

 

I'm not sure about the wiring of the switch but, in fact, it uses both mouse buttons as in a real-life engine startup procedure - LMB as a toggle for LVar positions 0 (OFF) and 1 (to charge actuator preparing it for engine startup when ampermeter shows at least 8 ampers), and RMB as a toggle for positions 0 and -1 (ON) from which the switch automatically springs back to position 0 after a couple of seconds (when the engine is started). My code emulates LMB actions well but fails to switch from pos 0 to -1 (note the sign!) and back since p = 1 (see: my code above). See also the attached image to visualize positions on this particular gauge.

 

The same problem exists with other switches like the fuel selector valve which has even 4 positions (All OFF, Left, Right, All ON). But here the developers used a native FSX control (FUEL_SELECTORS_SET, if memory serves me well) instead of a local variable. Hence using a syntax like if p == ipc.control(xxxxx) to check for the state of FSX control, similar to LVar check in my code, returns a LUA error "attempt to compare nil with number" which, AFAIU, is due to... FSX control doesn't return an explicit parameter value but rather gives a specific instruction / command. 

 

I think you are rather confused here. The FSUIPC macro facility is a method of allowing a single or sequence of commands, whether L:Var writes or simple control or keyboard assignments, to be stored in files (.mcro files) with names which can be assigned in the Buttons & Keys tab.

 

Maybe you are assuming that "macros" always means "mouse macros". Mouse macros are a specific type of macro which operates mouse action areas in gauges which are suited. But that is only one type of macro (and the most recent addition to the range of things macros can do as well).

 

I think you need to review some of the documentation and examples. Also browse through others' work in the User Contributions subforum.

 

Oh, indeed, I meant mouse macros only... I better go back to re-read the manual. Thanks for heads-up!!! 

[LUA file and button / keypress assignments]

Pete,

Thank you for replies!
 

The Lua file you have written runs once, then terminates. There is nothing there keeping it running, so why bother to have it loaded in an [Auto] section?

 

Absolutely! Changed...
 

In the former case you assign to "Lua name" in the second to "LuaValue name".

 

I think I need to read and practice more with "LuaValue" method.

After some trial and error this is what I have for now. Although this doesn't work as required with a 3-position clutch switch:

-- LVar values:
-- off = 0
-- charge = 1
-- on = -1

if ipcPARAM == 0 then

   local p = ipc.readLvar("L:AN2_inertial_clutch") 

   if p < 1 then p = p + 1 end

      ipc.writeLvar("L:AN2_inertial_clutch",p)

end

As I said, this code works but partially - the clutch stops when p = 1. But since the switch has 3 positions, I can't figure how to return it to any other position when p = 1 using the same button. So, i guess i have no other choice than use two buttons with different parameters, or (if it's ever possible) to assign different parameters to the same button inside FSUIPC.INI.

Paul, thank you too! In case of this particular model, unfortunately, I can't use macros. They simply don't initiate except with default FSX aircraft. So, i guess my only resort is to use Lua plugins.

Thanks!