FSXA Audio Panel XML problem

[demyhr]

Hi all, I'm creating a Narco CP136 Audio Panel by modifying a Narco CP125 found on the web. The graphics are done and work fine. It's pretty simple and I was doing fine until I tried to make the speaker switch work. Nothing I seem to do will make the update code work. Ident button work as expected but the speaker button will not enable and disable them. I've spent all day hacking at this and I'm stumped. I'm sure it's something obvious and simple but I can't see what the problem is. I want the speaker (ident) sounds enabled when a radio and the speaker button are pressed.

Here is the all the code.I haven't added code for the marker beacons yet.
Thanks in advance for the help.

David

<?xml version="1.0"?>
<Gauge Name="Narco CP136 Audio Panel" Version="1.0">
	<Image Name="CP136.bmp"/>


	<!-- COM 1 TRANSMIT/Audio SELECT -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="123" Y="36"/>
		<Select>
			<Value>(A:COM1 TRANSMIT, bool) (L:COM1Audio,number) ||</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element>
	<!-- COM 2 TRANSMIT/Audio SELECT -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="173" Y="36"/>
		<Select>
			<Value>(A:COM2 TRANSMIT, bool) (L:COM2Audio,number) ||</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element>
	<!-- BOTH (COM1 + COM2) SELECT -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="224" Y="36"/>
		<Select>
			<Value>(L:BOTHAudio,number)</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element>
	<!-- NAV 1 Audio SELECT -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="292" Y="36"/>
		<Select>
			<Value>(G:Var2)</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element>
	<!-- NAV 2 Audio SELECT -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="341" Y="36"/>
		<Select>
			<Value>(G:Var3)</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element>
	<!-- ADF Audio Select -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="395" Y="36"/>
		<Select>
			<Value>(G:Var4)</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element><!--DME Audio Select  -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="450" Y="36"/>
		<Select>
			<Value>(G:Var5)</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element><!-- SPEAKER Audio SELECT -->
	<Element>
		<Image Name="Button_OUT.bmp"/>
		<Position X="508" Y="36"/>
		<Select>
			<Value>(L:SPKRAudio,bool)</Value>
			<Case Value="0">
				<Image Name="Button_OUT.bmp"/>
			</Case>
			<Case Value="1">
				<Image Name="Button_IN.bmp"/>
			</Case>
		</Select>
	</Element>


	<Update>

		(L:Var2,bool) (L:Var6,bool) AND if{ } els{ (&gt;K:RADIO_VOR1_IDENT_DISABLE)} 
		(L:Var3,bool) (L:Var6,bool) AND if{ } els{ (&gt;K:RADIO_VOR2_IDENT_DISABLE)}
		(L:Var4,bool) (L:Var6,bool) AND if{ } els{ (&gt;K:RADIO_ADF_IDENT_DISABLE)} 
		(L:Var5,bool) (L:Var6,bool) AND if{ } els{ (&gt;K:RADIO_DME1_IDENT_DISABLE)} 
	</Update>

	<Mouse>
		<!--COM 1-->
		<Area Left="122" Width="36">
			<Tooltip>COM 1 Transmit/Select (%((L:Com1Audio,bool))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(L:COM1Audio,number) ! (&gt;L:COM1Audio,number) (&gt;K:COM1_TRANSMIT_SELECT)
			(A:COM2 TRANSMIT, bool) if{ 0 (&gt;L:COM2Audio,number) 0 (A:COM2 TRANSMIT, bool)}</Click>
		</Area>
		<!--COM 2-->
		<Area Left="173" Width="36">
			<Tooltip>COM 2 Transmit/Select (%((L:Com2Audio,bool))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(L:COM2Audio,number) ! (&gt;L:COM2Audio,number) (&gt;K:COM2_TRANSMIT_SELECT)
			(A:COM1 TRANSMIT, bool) if{ 0 (&gt;L:COM1Audio,number) 0 (A:COM1 TRANSMIT, bool) }</Click>
		</Area>
		<!--COM1 + COM2 -->
		<Area Left="224" Width="36">
			<Tooltip>COM1 + COM2 (BOTH) Audio Select (%((L:BOTHAudio,bool))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(L:BOTHAudio,number) ! (&gt;L:BOTHAudio,number)</Click>
		</Area>
		<!--NAV 1-->
		<Area Left="291" Width="36">
			<Tooltip>NAV 1 Audio Select (%((G:Var2))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(G:Var2) ! s2 (&gt;G:Var2) (&gt;K:RADIO_VOR1_IDENT_TOGGLE) l2 (&gt;L:Var2,bool)</Click>
		</Area>
		<!--NAV 2-->
		<Area Left="341" Width="36">
			<Tooltip>NAV 2 Audio Select (%((G:Var3))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(G:Var3) ! s3 (&gt;G:Var3) (&gt;K:RADIO_VOR2_IDENT_TOGGLE) l3 (&gt;L:Var3,bool)</Click>
		</Area>
		<!--ADF-->
		<Area Left="395" Width="36">
			<Tooltip>ADF Audio Select (%((G:Var4))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(G:Var4) ! s4 (&gt;G:Var4) (&gt;K:RADIO_ADF_IDENT_TOGGLE) l4 (&gt;L:Var4,bool)</Click>
		</Area>
		<!--DME-->
		<Area Left="450" Width="36">
			<Tooltip>DME Audio Select (%((G:Var5))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(G:Var5) ! s5 (&gt;G:Var5) (&gt;K:RADIO_DME1_IDENT_TOGGLE) l5 (&gt;L:Var5,bool)</Click>
		</Area>
		<!--SPEAKER-->
		<Area Left="508" Width="36">
			<Tooltip>Speaker Audio Select (%((L:SPKRAudio,bool))%{if}ON%{else}OFF%{end})</Tooltip>
			<Click>(L:SPKRAudio,number) ! s6 (&gt;L:SPKRAudio,number) l6 (&gt;L:Var6,bool)</Click>
		</Area>
	</Mouse>
</Gauge>

 

[taguilo]

Hi,

Your code should work if you replace all AND words with and (in the <Update> section). I also think there is room for improvement in most part of it, but that's another question.

Tom

 

[demyhr]

No Cigar Tom, it doesn't seem to make a difference what the case of and is.

FSX XML and XML in general are about the most frustrating languages I have ever come across. I'm a retired test engineer and have programmed test systems (Teradyne, Fairchild etc) using C, Pascal and Assembly language to test Large Scale Integrated Circuits and consider myself to be fairly software savvy.

I am stumped for the moment. The only thing that will turn the IDENT sound on/off are the K:XXXident_toggle functions. I'm using BlackBox 2 to watch the variables and the K:XXX_IDENT_ENABLE/DISABLE/SET function do nothing. As you can see by the code I am trying to AND the speaker enable and the sound on when I want sound variables and disable the sound when either the speaker enable or radio sound is false. Having gotten an A in Boolean Algebra, albeit 40 years ago, I know how the logic works. There must be something else I am missing. I use Microsoft Visual Studio and EDitX as XML editors and both check for structure errors so I don't think its a missing bracket or such.

Anyway I'm retired and have plenty of time on my hands so I will continue hacking away.

Thanks

David

 

[taguilo]

No Cigar Tom, it doesn't seem to make a difference what the case of and is.

Oh yes, it does a difference. You cannot write AND in caps, it's not recognized as an operator. But there are more syntax errors; for example watch this:

els{ (&gt;K:RADIO_VOR1_IDENT_DISABLE)}

You need to put a space here, like at the begining. The other K events that follow this one have the same error...and there are more in some of the <Click> sections.

I suggest you check again the code, fix it and then see what happens.

Tom

PS: to be more explicit, in (L:Var2,bool) (L:Var6,bool) AND if{ } for example, if{ } will execute always as long as (L:Var6,bool) is true (1), no matter the value of (L:Var2,bool).

 

[demyhr]

At the risk of being argumentative the AND function in Boolean Algebra means if A=True AND B=True then C=True, True being 1. If either A or B or both are False then C = False, False being 0. What you have described is not an AND function. If XML functions as you say then AND/and is meaningless. My assumption that the first variable is pushed on the stack, then the second and the AND is done with the result left on the stack for the if{ } els{ } to operate on. Using the albeit buggy infix/postfix tool show this to be the case. I've tried both upper and lower case AND there is no difference. The Microsoft Docs show Upper case AND or &&, the && yields a syntax error in both of the editors I use.

As for the space I'm not sure I understand what you are referring to. There is a space after the bracket in the if{ and the els{ statements, again I have seen no difference between having a space after or not. I usually put spaces in for appearance.

If you can point me to some similar code that works or give me an example I would be greatly appreciative.

Thanks for your help

David

		(L:Var2,bool) (L:Var6,bool) AND if{ } els{ (>K:RADIO_VOR1_IDENT_DISABLE)} 
		(L:Var3,bool) (L:Var6,bool) AND if{ } els{ (>K:RADIO_VOR2_IDENT_DISABLE)}
		(L:Var4,bool) (L:Var6,bool) AND if{ } els{ (>K:RADIO_ADF_IDENT_DISABLE)} 
		(L:Var5,bool) (L:Var6,bool) AND if{ } els{ (>K:RADIO_DME1_IDENT_DISABLE)}

 

[taguilo]

I'm not discussing Boolean Algebra, just stating that AND in caps is not recognized as an operator by the scripting parser of FSX XML files. I don't know how to tell you this more emphatically. So, if you write:

Var1 Var2 AND if{ }

the parser evaluates AND, as it doesn't mean anything it's discarded so the stack turns into

Var1 Var2 if{ }

then, if Var2 is any number greater than/equal to 1 or lower than/equal to -1 (a TRUE result for a "bool" condition in FSX script) the if{ } conditional executes, no matter the value of Var1.

Now, if you write

Var1 Var2 and if{ }

the parser takes and as a logical operator, then evaluates Var1 and Var2. If both are "true", the if{ } executes otherwise the flow jumps to els{ }

As for the spaces, if{} and els{} both need a space after the { and before the }. In this example:

els{ (&gt;K:RADIO_VOR1_IDENT_DISABLE)}

there is a lack of space between the ) and the }, though you did it right with els{ (

These are the reasons for suggesting that you check your code again, and eventually search for more scripting examples on this forum if you're not sure on this version of XML's syntax.

BTW, you can replace &gt; with > freely in the code if you find it easier to read/write.

Tom

 

[demyhr]

Thanks Tom, I replaced the Update code with the following and it now behaves as I expected. Boolean Algebra reigns supreme. The root cause was the if{ }. I had to insert enable code there. I was then able to confirm that indeed the case of the and was important as well as the space before and after the brackets. The only concern left is that using a toggle in the mouse section and enable/disable in the update has the risk of things getting out of sync. I would rather have the mouse code sense the state of a button and do a enable/disable to force the proper state. If it weren't for the speaker switch a toggle wouldn't be a problem. Anyway, the gauge works now and I have one more switch to add, the marker mute button.

I sure wish Microsoft had written better docs for XML.

Thanks for the help, Tom.

David

  <Update>
    (L:NAV1Audio,bool) (L:SPKRAudio,bool) and if{ (&gt;K:RADIO_VOR1_IDENT_ENABLE) } els{ (&gt;K:RADIO_VOR1_IDENT_DISABLE) }
    (L:NAV2Audio,bool) (L:SPKRAudio,bool) and if{ (&gt;K:RADIO_VOR2_IDENT_ENABLE) } els{ (&gt;K:RADIO_VOR2_IDENT_DISABLE) }
    (L:ADFAudio,bool) (L:SPKRAudio,bool) and if{ (&gt;K:RADIO_ADF_IDENT_ENABLE) } els{ (&gt;K:RADIO_ADF_IDENT_DISABLE) }
    (L:DMEAudio,bool) (L:SPKRAudio,bool) and if{ (&gt;K:RADIO_DME1_IDENT_ENABLE) } els{ (&gt;K:RADIO_DME1_IDENT_DISABLE) } 
	</Update>

 

[rpmc]

The only concern left is that using a toggle in the mouse section and enable/disable in the update has the risk of things getting out of sync. I would rather have the mouse code sense the state of a button and do a enable/disable to force the proper state.

I am not sure I follow you on the sync issue, but have you considered putting the key event code (edited as needed) that is currently in <Update> into appropriate <Mouse> click code instead? Will that somehow mitigate things getting out of sync?

You're right about little MS documentation, but at least we have the SDKs and example xml, and forums like this. Using xml, you have a choice between FS9 and FSX syntax. FS9 syntax functions in both sim versions. I use FS9 syntax and am comfortable with it. Bill Leaming, the leading contributor to Gauges forums, has been pretty clear in his general preference for FS9 schema as well.

BTW, "At the risk of being argumentative" -- as I've learned from experience, there are a handful of guys in this forum you don't need to argue with. Aguilo is one.

Bob

 

[demyhr]

I made numerous attempts to replace the toggle function with enable/disable functions but only the toggle function would turn the A:XXX SOUND variable on and off. Now that I have what a working "and" function I may revisit it. I expressed my toggle concern because I have encountered this in other programming I have done in the past. It's been many years since I did any coding and the days of simple code, compile, link and run programming are long gone.

I just downloaded Microsoft's free Visual Studio C++ and Basic and I'm not sure my 71 year old brain is up to the learning curve. I'm going to try and recode the audio panel in C++ as an exercise but I think it will take quite a few trips to the gym before I'm in shape for the task, if you get my meaning.

I find it interesting that the if structure in a Tooltip has every thing crammed together with no spaces and the XML if structure requires no spaces in front of the bracket and spaces behind. Not very consistent IMHO.

As for being argumentative, Tom's first description of the problem didn't make sense to me but after questioning it his second description regarding how the parser works did.

In any event, I am grateful for having access to experts like Tom and Bill who has helped me in the past with designing a Foster 511 RNAV gauge which is still a work in progress.

David

 

[rpmc]

Foster 511 RNAV gauge which is still a work in progress.

I remember those recent threads very well ... thought you were finished with that one already. Not too many around that have used the real 511 or the Narco, at least not in the FS community.

Anyway, it looks like you have already made a lot of progress climbing the XML learning curve. Keep it up! XML can certainly handle everything you want to do with the audio panel and the 511. If you switch to C++, there will only be a few people in these forums that are able to offer advice so keep that in mind.

Bob

 

[n4gix]

I find it interesting that the if structure in a Tooltip has every thing crammed together with no spaces and the XML if structure requires no spaces in front of the bracket and spaces behind. Not very consistent IMHO.

David, it is that inconsistency that has been the proximate cause of much head-banging over the past years here as well!

I'll never understand why ACES decided that perverting the eXtended Markup Language (which isn't really a "language" to begin with!) was ever a "Good Idea..."

Then to take this lame, limp thing and create five incompatible and inconsistent "Schemas" was nothing less than sheer insanity!

1. FS9 "gauge" schema
2. FS9 "model" schema
3. FSX "gauge" schema
4. FSX "model" schema
5. FS9/FSX "tooltip" schema

As you've now learned, case and spaces are extremely critical. The pity is that when writing out examples, we have no way to easily differentiate when a "blank space" is absolutely required by syntax rules, or where a blank space has been used merely to make scripts "look pretty..."

Since you are like myself an "old school" programmer, you may remember that we used a struckout "b" to indicate critical blank spaces (e.g., /b where the / and the b were superimposed) when using a pencil and paper. Keyboards lack that decoration, darn it! I'd suggest using an underscored b as a replacement, but it would probably just confuse the youngsters...

So, having explained that, had you seen

(A) (B) and if{b(foo)b) els{b(bar)b}

the "syntax rules" might have been more apparent and obvious.

 

[demyhr]

Thanks all for the response. I have completed the audio panel with all the switches etc. The one small issue is that I can't remeber how the Marker/DME button actually functioned. Since I'm not an IFR pilot and my DME was hidden in the glove compartment (I used the Foster as my DME readout) the marker functions didn't get used. I have set it up to control the selected DME only.

The Foster needs the buttons controlling RNAV/VOR displays and WP selection. I am still looking for ideas on into how to implement the CDI deviation from the WP heading. The Audio panel project will help with the button/switch setup.

As for C++, I skimmed the FSX C++ gauge doc and it is indeed formidable. Since the doc is meant to be interactive I guess I'll have to try the example gauges.

Anyway Happy Easter to all.

David

 

[taguilo]

As for being argumentative, Tom's first description of the problem didn't make sense to me but after questioning it his second description regarding how the parser works did.

Honestly I should have given you a better explanation right in my first post; it happens I use to doubt on how much to expand the reasons for something in XML to work as it does because I feel it can be boring for most people who don't care about it and only want to make their code function as desired.
Hence I really appreciate when somebody does question a bit, like you did, showing interest on the subject. As I use to say, I can give many good arguments but I can fail as well like anyone, so my best advice is: TEST, TEST and TEST, don't stick to something said that doesn't seem to make sense, do your own tests as much as you can.

Tom

 

[taguilo]

Quote:
Originally Posted by demyhr
I find it interesting that the if structure in a Tooltip has every thing crammed together with no spaces and the XML if structure requires no spaces in front of the bracket and spaces behind. Not very consistent IMHO.

David, it is that inconsistency that has been the proximate cause of much head-banging over the past years here as well!

Actually those inconsistencies are not arbitrary but have their reason in that they are handled by different classes and/or functions. For example, a <Value> script and a <Tooltip> may seem similar but their process and interpretation, though shared in some aspects, are indeed different.

As you've now learned, case and spaces are extremely critical. The pity is that when writing out examples, we have no way to easily differentiate when a "blank space" is absolutely required by syntax rules, or where a blank space has been used merely to make scripts "look pretty..."

The only way is trying to understand how the scripting system works. Once you got the whole picture, you can realize why spaces go where they go, which ones are critical and which only decorative, why the stack behaves as it does, etc, etc.

Tom

 

[rpmc]

...why the stack behaves as it does

My suspicion is that probably many xml users don't really understand the stack nor think of it as they write xml.

An opportunity for a good wiki here?

Bob

 

[demyhr]

I have looked at many books on XML and they all relate to document processing, database development etc. FSX XML is quite unique I think. A wiki that I would like to see would be information on program flow, structure and execution. Stack operations are not foreign to me as some of the test equipment I once programmed were stack based. Most of the XML syntax is fairly well documented and some of the tutorials (Nick Pike's for instance) deal with specifics but I have yet to find something that looks at the big picture and how gauges fit into FSX operation.

 

[mgh]

I'll never understand why ACES decided that perverting the eXtended Markup Language (which isn't really a "language" to begin with!) was ever a "Good Idea..."

But it is a language for making up documents. I agree that it's a perversion, abomination etc etc. to use it as a programming language. Especially when it's so badly documented and inconsistent.

Actually those inconsistencies are not arbitrary but have their reason in that they are handled by different classes and/or functions. For example, a <Value> script and a <Tooltip> may seem similar but their process and interpretation, though shared in some aspects, are indeed different.

But where is all that documented?

On a slightly different point, I'm also far from impressed with Microsoft's approach to C/C++ gauge programming. I don't think gauge programming was Micosoft's finest hour.

 

[n4gix]

But it is a language for making up documents. I agree that it's a perversion, abomination etc etc. to use it as a programming language. Especially when it's so badly documented and inconsistent.

Yes, it is a "language" in the sense that it is part of the formal name.

It is however not a "language" in the sense meant in traditional programming languages.

The only real computer language more obtuse is LISP, but at least it is intended to be a very low level language and is very extensively documented as such!

Even ACES realized that XML wasn't their best decision ever made and had planned to switch to Lua (which btw has carried over into Flight)...

 

[n4gix]

Actually those inconsistencies are not arbitrary but have their reason in that they are handled by different classes and/or functions. For example, a <Value> script and a <Tooltip> may seem similar but their process and interpretation, though shared in some aspects, are indeed different.

That is true only in how it was implemented Tom, but there was no particular reason it had to be done that way. There is absolutely no good reason for having wound up with five different and incompatible schemas.

As for my other point regarding no good way to show everyone that a blank space is required, rather than simply decorative, I'm specifically referring to how we present sample script in written form here on a forum.

if{ } els{ }

isn't at visually clear that the space following the { is required or that the space preceding the } is required.

if{b b} els{b b}

on the other hand is more explicit...

if{¯ ¯} els{¬ ¬} maybe clearer?

 

[taguilo]

Yes, it is a "language" in the sense that it is part of the formal name.

It is however not a "language" in the sense meant in traditional programming languages.

Of course it is not a "language" nor treated like that by FS, but instead a support for data structures which are interpreted and "translated" (binded) into may different C++ classes at run time. Maybe was not the best solution as an easy development platform, but surely far from being the worst IMHO.

That is true only in how it was implemented Tom, but there was no particular reason it had to be done that way. There is absolutely no good reason for having wound up with five different and incompatible schemas.

Oh yeah, I agree those different schemas are sort of a mess. I never got used to FSX new supertagged schema ; even started to make some changes on it to make it more "friendly" but gave up almost immediately as the results were less than poor.

As for my other point regarding no good way to show everyone that a blank space is required, rather than simply decorative, I'm specifically referring to how we present sample script in written form here on a forum.

if{ } els{ }

isn't at visually clear that the space following the { is required or that the space preceding the } is required.

if{b b} els{b b}

on the other hand is more explicit...

if{¯ ¯} els{¬ ¬} maybe clearer?

Actually a better way to represent it could be:

<Script>operandboperatorb(variable)bstringbconditional{bdatab}</Script>

Spaces that don't fit on b places are decorative.

Tom