Read value of FSX control?

[mhlarsen]

Hi Pete,

 

 

Is there any way to read the current value of a given FSX control, if this control does not have an offset value?

 

I assume that a command like this will just activate the control?:

 

if (ipc.control(XXXX)) == 0 then

...

 

 

Thanks

Michael

[Pete Dowson]

Is there any way to read the current value of a given FSX control

 

There are two ways:

 

1. Enable Event logging in FSUIPC's logging tab, and use the switch or control and view the number and name in the log file, or

2. Just look in up in the List of controls document installed in your FSUIPC Documents folder.

 

I assume that a command like this will just activate the control?:

 

if (ipc.control(XXXX)) == 0 then

 

Just ipc.control(control number, parameter)

(you can omit the parameter if it doesn't take one, or if zero is okay).

 

This Lua function isn't a test of anything. There's no point in using "if" on it. What condition are you trying to test?

 

Pete

[mhlarsen]

An example would be to test the status of the Launch Bar (FSX control 66879), if extended or retracted (Carrier Ops).

 

I have no Offset value for this control.

 

 

Michael

[Pete Dowson]

An example would be to test the status of the Launch Bar (FSX control 66879), if extended or retracted (Carrier Ops).

I have no Offset value for this control.

 

Controls are controls, not values. They cannot be "read".  They are merely encoded messages to FS to tell it to do something.

 

I don't even have 66879 listed, nor anything called "launch bar".. Is this an add-on control, not even an FS one? If so then it's no wonder there's no "offset" for its status.

 

If you want status values for add-on implementations you'll need to check their documentation or ask their developer. FSUIPC is an interface to FS. It knows nothing about add-ons (with few exceptions, like Project Magenta and the PMDG 737NGX). Some add-on implementers use FSUIPC offsets to provide access to things. Some provide other means. Maybe the one you want is encoded inside their gauges as an L:Var, and L:Vars can be read in Lua. Try logging L:Vars and see if it's there.

 

Regards

Pete

[mhlarsen]

The 'Launch Bar' is from default FSX Acceleration and activated through the keyboard command Shift+U.

 

 

 

Michael

[Pete Dowson]

The 'Launch Bar' is from default FSX Acceleration and activated through the keyboard command Shift+U.

 

Ah, my List of FSX controls is incomplete! No one's pointed that out before! I shall rectify that today.

 

Alas, though, there seems to be no SimConnect variable with that name, so it looks like its status is not readable. All you can do really is keep your own status for it and reverse it each time you change it with the control.

 

There are many such values simply not made visible. As I said, you could see if there's an L:Var for this.

 

Regards

Pete

[mhlarsen]

Hi Pete,

 

Unfortunately I do not have an Lvar option for this function, but I will create a 'normal' toggle using the FSX control.

 

Will the Offset document be updated as well?  ;-)

 

 

Michael

[Pete Dowson]

Unfortunately I do not have an Lvar option for this function

 

You mean you've logged the LVars, using the Lua LVar logging plug-in, and not seen any change when you toggle the setting of the Launch switch?

 

Will the Offset document be updated as well?  ;-)

 

When it needs changing. What aspects of it do you think need updating?

 

Pete

[mhlarsen]

Actually I am using the application LINDA, which I think does the same job.

And no, the only action is that an FSX control is activated.

I really wish all aircraft designers would add Lvar to all buttons, levers and switches.

 

Well, if you add all the new Acceleration controls, it would be nice to have these Associated with an Offset value.

I am not really sure, if I can do this myself.

 

 

Michael

[Pete Dowson]

Well, if you add all the new Acceleration controls, it would be nice to have these Associated with an Offset value.

I am not really sure, if I can do this myself.

 

Sorry, I think you may misunderstand what the FSUIPC maintained offsets are really for. The provide data read out from FS. I can't read the state of the "Launch Bar" switch, as we already discussed.

 

What are "all the new Acceleration controls" anyway?

 

Regards

Pete

[xcorez]

What are "all the new Acceleration controls" anyway?

 

Pete, i think what he mean is "the control offsets for FSX Acceleration simulation variables" such like this 'Launchbar' SimVars.

(* and i'll be very gratefull if you could also add those heli-specific new simvars eg. rotor Disk Pitch/Bank Angle, Coning etc :)  )

 

Unfortunately I do not have an Lvar option for this function, but I will create a 'normal' toggle using the FSX control.

Michael, you can workaround this by converting/transform the Launchbar SimVars to custom Lvars using an XML gauge,

<?xml version="1.0" encoding="utf-8"?>
<Gauge Name="Launchbar Status" Version="1.0">
    <Comment>
    FSXA SimVars to Lvars for Launchbar status 
    Insert this gauge in one of [VcockpitXX] section.
    </Comment>

    <Element>
        <Rectangle Width="1" Height="1" Color="transparent" FillColor="transparent" Bright="No"/>
    </Element>

    <Update Hidden="Yes" Frequency="6">    
        (A:LAUNCHBAR POSITION, percent) (>L:LaunchBarPos, percent)    
        (A:LAUNCHBAR SWITCH, bool) (>L:LaunchBarSwitch, bool)    
        (A:LAUNCHBAR HELD EXTENDED, bool) (>L:LaunchBarExtended, bool)
    </Update>

</Gauge>

so that you can read the Launchbar LVars value for FSUIPC LUA scripting ( * via ipc.readLvar or event.Lvar since it's non-set-able variable *).

 

Regards,

-xcorez-

[Pete Dowson]

Pete, i think what he mean is "the control offsets for FSX Acceleration simulation variables" such like this 'Launchbar' SimVars.

 

I don't see a "launchbar" simvar listed. What is its name in Simconnect?

 

(* and i'll be very gratefull if you could also add those heli-specific new simvars eg. rotor Disk Pitch/Bank Angle, Coning etc :)  )

 

I'm always glad to add specific values, by request, but you do need to be specific. Can you tell me the actual SimVars you need, by name as known in SimConnect, please?

 

I am not doing blanket additions of all possible SimVars to fSUIPC. FSUIPC's interface to FSX is mainly for compatibility with FS9 and before. I would expect any new application for FSX to be using SimConnect directly. I do understand some extras may be needed for, for example, Lua plugins and the like, but I'd like these to be specifically needed and therefore requested.

 

Regards

Pete

[mhlarsen]

Pete,

 

The new Acceleration controls would be specific for Aircraft carrier and SAR aircrafts/helicopters.

They pop up in LINDA when I try mapping one of these aircrafts/helicopters. I might just make a list of these.

 

Just like we have FSX controls for various aircraft lights, then we also have Offset values to control them directly, which is way more powerful.

Thats what I am looking for in the Acceleration controls.

 

xcorez,

 

Thanks for the XML gauge workaround, which I will try out  :)

 

 

Michael

[Pete Dowson]

The new Acceleration controls would be specific for Aircraft carrier and SAR aircrafts/helicopters.

They pop up in LINDA when I try mapping one of these aircrafts/helicopters. I might just make a list of these.

 

Just like we have FSX controls for various aircraft lights, then we also have Offset values to control them directly, which is way more powerful.

Thats what I am looking for in the Acceleration controls.

 

I fear you still misunderstand, but please correct me if you are simply using words differently to me:

 

If they are merely controls, not values or switch settings that can be read from SmConnect, then they are simply NOT suitable for reserved offsets -- because FSUIPC cannot possibly maintain them in their correct values!

 

ALL controls, as opposed to values are better assigned and sent as controls. This is not "less powerful" than offsets. If you want to send controls via offsets just use the facility for that, offset 3110.

 

Please do NOT provide a list of FS controls you want in offsets. Only SIM VARs -- which you can find listed in the Simulation Variables section of the FSX and P3D SimConnect SDK.

 

Regards

Pete

[xcorez]

I don't see a "launchbar" simvar listed. What is its name in Simconnect?

 

Not sure if the OP still need these Simvar to be listed on FSUIPC offsets. But for references, they are "LAUNCHBAR POSITION" and "LAUNCHBAR SWITCH" as documented in FSX Acceleration SDK of Carrier Operations and Notes on Catapult Launches.

 

There's also "LAUNCHBAR HELD EXTENDED" which is triggered by the "HOLDBACK BAR INSTALLED" Simvar.  The related FSX controls which already mapped in FSUIPC offsets are TOGGLE LAUNCH BAR SWITCH (66879) and SET LAUNCH BAR SWITCH (66880).

 

I am not doing blanket additions of all possible SimVars to fSUIPC. FSUIPC's interface to FSX is mainly for compatibility with FS9 and before. I would expect any new application for FSX to be using SimConnect directly.

Understood. personally I don't have specific neccessity of additional FSUIPC offset(s) for such those 'unmapped' SimVars in my daily regular use of FSUIPC for interfacing my controller hardware to FSX. I still able to cope with those Simvars simply by using XML to create custom LVars as 'intermediating- variables' which can be used in FSUIPC LUA scripting. So far this way works perfectly on my setup, thanks for the marvelous FSUIPC features.

And honestly, rather than the addition of extra control offsets to the list I'm more expecting FSUIPC will be able to have "more efficient profile-specific setting" feature that should be easier to manage. Anyway, as not to hijack this thread any furher I'll discuss this on the original thread of its relating topic.

 

 

Regards,

 

-xcorez-

 

[Pete Dowson]

 

Not sure if the OP still need these Simvar to be listed on FSUIPC offsets. But for references, they are "LAUNCHBAR POSITION" and "LAUNCHBAR SWITCH" as documented in FSX Acceleration SDK of Carrier Operations and Notes on Catapult Launches.

 

Hmm. Those aren't in the Acceleration SimConnect SDK. Following the links you give takes me to the ESP SDK on-line. I used to have ESP but following its demise, and seeing my disk gradually fill up, I removed it. Are they actually in FSX as well, just undocumented? If I add offsets for variables which are only in ESP or later I need to say so, or I just get complaints that they don't work in FSX.

 

The related FSX controls which already mapped in FSUIPC offsets are TOGGLE LAUNCH BAR SWITCH (66879) and SET LAUNCH BAR SWITCH (66880).

 

There's still this confusion I see! Offsets are NOT controls and those aren't mapped, unless you find an offset which you think relates to these but without the word "launch" included (because that is what I searched on).  Offsets are repositories for values. They can be read and sometimes written. Controls are things you assign buttons and keypresses to, or send via offset 3110, and are just messages to FS to tell it to do something. They are not values and cannot be read (except as messages by the receiving program, i.e. FSX).

 

FSUIPC's assignment drop-downs always contain all of the fS controls, even non-working ones, because it s built from FS's own internal list inits CONTROLS.DLL. The names listed are the names from that DLL, and are the same as those used in FS's own control assignments XML files.

 

Meanwhile, I've printed off the ESP list of SimVars so I can in future deal with folks' requests on these, presumably for P3D which is derived from ESP.

 

Regards

Pete

[rustam]

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!

[Pete Dowson]

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.

 

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". 

 

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

 

 

 

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.

 

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:

 

Reading offsets is generally the only way of determining the state of things in the main FS engiine. The L:Vars you've perhaps been used to reading are Local Variables (hence the name) and are very specific to particular gauges. That's why they don't reside in offsets -- if they were part of the main FS engine they would be there instead!

 

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.

 

        if ipc.readUB(0x3122) == 2^2 then

 

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 ...

 

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.

 

Pete

[rustam]

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!!!

[Pete Dowson]

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

 

I think you are still misunderstand. The control 66477 does have any parameters at all. It is just a toggle.

 

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.

 

More misunderstanding here too! A "control" which is also known inside FS as a "KEY EVENT" cannot have a "state". It is a message, an event, a command. I keep telling you this but you persist in misunderstanding. It's something you assign to a button or keypress. It does not exist outside of requesting the designated action! You cannot test for it afterwards because once it has been sent, that's it, it's gone!

 

# 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?

 

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?).

 

! Will this help to check the control's (66477) state? I'm confused...

 

Controls cannot have states!! I keep telling you the same thing but you persist! :--(

 

# 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 think there are uses of the logic library in many of the Lua examples provided and written by others. But what is the problem? There are only a few logic actions. In arithmetic you have + Add - Subtract * Multiply and / Divide. you are aware of those, right? Well, logical operations have similar operations.

 

The main ones you'll need are And and Or, and maybe Not. In other programming languages And is represented by &, Or by | and Not by ~.

 

These pretty much accord with their meaning in English when operating on simply True and False values. With bits in bytes it's not much more complicated. But I cannot tutor you here. You'd be best Googling the subject.

 

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

 

Pete

[rustam]

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

[Pete Dowson]

Also, I was confused when I saw in the event log that control parameter actually changes from 0 to 1 and back. 

 

What is sending the control with the parameter? The log merely shows what the parameter value sent is set to -- that depends who has set it. I can assign a keypress or button to send it with a parameter of 12345, but it won't change the toggle action. The parameter is ignored except for those controls which use it!

 

 

I thought there must be a way to check those parameters programmatically, like "if ipc.control(66477,0) == true/false then".

 

The ipc.control function does not have a value, so you cannot test it. That code is meaningless. The parameter there (you have 0) will be logged. It could be any number. It will be logged. But for this control it does nothing, as i keep telling you!

 

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?

 

No, because many controls do things which don't change any data which is readable. Think about it for a while. Pause Toggle wiil change the pause state, which you can read in an offset, but "ATC MENU 3" just selects something in a menu, "Capture screenshoot" captures a screenshot, "exit" closes FS. What do you expect to read from such events?

 

Events are things that happen, and controls trigger events. Some events change values somewhere, some don't. Many, but not all, values can be read from offsets. I try to cover all the needs, but some escape.

 

Regards

Pete