key event codes + ace.exe tool in FSX XML gauges

[B21]

I have a couple of lines in my gauge intended to trigger key events, i.e.

1 (>K:KOHLSMAN_DEC)

This gives an error in the ace.exe tool:

Error: Invalid key event specified in XML: "KOHLSMAN_DEC"

The same error occurs for all other values of key event code I've tried also, so I don't think it's peculiar to KOHLSMAN_DEC.

My source XML actually contains "1 (>K:KOHLSMAN_DEC)" and I don't think the error has anything to do with the greater-than sign.

Have I done something obviously wrong?

thanks,
B21

 

[taguilo]

I believe ace.exe could have some kind of "syntax validation" that is overriden when the gauge is parsed.
KOHLSMAN_DEC is a void event, it means should have no left argumment and its calling gives the action per se; in this case, decrement value by one.
Then the proper way to use it is just by (>K:KOHLSMAN_DEC), despite it won't give a runtime error if called with a previous argument ie 0 (>K:KOHLSMAN_DEC); 1 (>K:KOHLSMAN_DEC), etc.


Tom

 

[B21]

Thanks Tom, but there's some issue here I don't get. Pushing a number onto the stack before the (>K:KEY_EVENT) can't be an error as far as I can see, because there might be many legitimate reasons you want something on the stack at that point .

I'm not sure whether a 'zero argument' key event would pop one item off the stack or not - my guess is the stack gets popped with the value discarded.

I have the big disadvantage that I've never had any working FSX xml gauge key event code, and any examples I've found refer to mouse clicks or FS2004, so I'm not sure if my code is basically wrong in some way.

B21

 

[n4gix]

You can always "un-CAB" any of the default XML scripts and use them for 'examples!'...

From the Bombardier_CRJ_700.CAB for example, I find this for the event in question. From these examples, I believe your specific problem is the lack of a blank space between your 'number' and the opening parenthesis!\
Not 1(
but 1 (

            <MouseArea id="Knob">
                <FloatPosition>185.000,187.000</FloatPosition>
                <Size>39,38</Size>
                <MouseArea id="Decrement">
                    <FloatPosition>0.000,0.000</FloatPosition>
                    <Size>20,38</Size>
                    <CursorType>DownArrow</CursorType>
                    <MouseClick id="MouseClick">
                        <Script>
                        	(G:Var1) 10 - s0 0 &lt; if{ 340 } els{ l0 } (&gt;G:Var1)
                        	(A:CIRCUIT AVIONICS ON, bool) if{ 2 (&gt;K:KOHLSMAN_INC) }
                        </Script>
                        <ClickRepeat>True</ClickRepeat>
                    </MouseClick>
                </MouseArea>
                <MouseArea id="Increment">
                    <FloatPosition>20.000,0.000</FloatPosition>
                    <Size>19,38</Size>
                    <CursorType>UpArrow</CursorType>
                    <MouseClick id="MouseClick">
                        <Script>
                        	(G:Var1) 10 + s0 360 &gt; if{ 0 (&gt;G:Var1) } els{ l0 } (&gt;G:Var1)
                        	(A:CIRCUIT AVIONICS ON, bool) if{ 2 (&gt;K:KOHLSMAN_DEC) }
                        </Script>
                        <ClickRepeat>True</ClickRepeat>
                    </MouseClick>
                </MouseArea>
                <Tooltip id="Tooltip">
                    <DefaultId>TOOLTIPTEXT_BACKUP_ALTIMETER_KOHLSMAN_INHG</DefaultId>
                    <MetricId>TOOLTIPTEXT_BACKUP_ALTIMETER_KOHLSMAN_MBAR</MetricId>
                    <EnglishId>TOOLTIPTEXT_BACKUP_ALTIMETER_KOHLSMAN_INHG</EnglishId>
                </Tooltip>
            </MouseArea>

 

[taguilo]

Thanks Tom, but there's some issue here I don't get. Pushing a number onto the stack before the (>K:KEY_EVENT) can't be an error as far as I can see, because there might be many legitimate reasons you want something on the stack at that point .

I'm not sure whether a 'zero argument' key event would pop one item off the stack or not - my guess is the stack gets popped with the value discarded.

I have the big disadvantage that I've never had any working FSX xml gauge key event code, and any examples I've found refer to mouse clicks or FS2004, so I'm not sure if my code is basically wrong in some way.

B21

The (> string removes the inmmediate value existing to its LEFT on the stack. If what follows the (> is an L/G var, the value is assigned to that var; if it's a K: event, the value is passed to the event, if it's an A var, the value is lost. If the stack to the left is empty, a zero is assumed by default.

There are some events that use the value passed and others that don't need it at all, and simply ignore it.

Now, KOHLSMAN_DEC and KOHLSMAN_INC are special cases in which the value passed behaves like this:

-no value or a 0 or a 1= inc/dec the first instance of this event found in the panel's gaugeset, in top/bottom order.
-a 2 will update the second instance (normally standby instrument)
-any higher number seems to be ignored, as long as there are not more than 2 altimeters (normal and stdby)

Further testing would be necessary to get a plenty idea of the whole functioning.

Now, in your example I can confirm ace.exe goes rather mad because it throws me the same errors you describe, but after editing the line it seems to come back to normal.

Hope this helps to clarify the issue.

Tom

 

[B21]

Thanks Bill & Tom - these were major value-added replies.

Bill - with the "known good" Bombardier example you gave me I was able to diagnose my ace.exe fault - my SDK install is somehow faulty and ace.exe doesn't seem to be finding the key event list it needs. I have gauges.h but I note this lists the C event name but not the string value to be used in an XML gauge. My XML gauge has 2800 lines of code (it's a glider flight computer) and the reference to the two key events are the only errors. For what it's worth even though I edit my XML in a regular editor, I don't think I could do without the ace.exe syntax error checking - it's too easy to miss a bracket, or insert a space between 'if' and '{' ...

Tom - thanks for the extremely valuable info on the specific KOHLSMAN_INC event. I guess I was lucky using 1 (>K:KOHLSMAN_INC) but I have no idea how you could have known that crucial snippet of information...

thanks
B21

 

[n4gix]

I have gauges.h but I note this lists the C event name but not the string value to be used in an XML gauge. My XML gauge has 2800 lines of code (it's a glider flight computer) and the reference to the two key events are the only errors.

Forget about gauges.h as that is only used for C gauges... The only two lists you need be concerned with are:

Event IDs
Simulation Variables

both of which are (in)conveniently and illogically located in the SDK's ..\SDK\Core Utilities Kit\Variables folder, instead of where one might expect to find it (..\Panels and Gauges SDK).

Even then, be mindful that the left column in the EventIDs is for C gauges. The center column is for both XML and SimConnect!

Tom - thanks for the extremely valuable info on the specific KOHLSMAN_INC event. I guess I was lucky using 1 (>K:KOHLSMAN_INC) but I have no idea how you could have known that crucial snippet of information...

A lot of stuff has to be "inferred from context." This is a prime example of what I mean. If you look closer at the script example I posted, notice the leading "2" before the key_event... That, along with the name of the gauge ("standby") provides the necessary clues.

 

[taguilo]

Tom - thanks for the extremely valuable info on the specific KOHLSMAN_INC event. I guess I was lucky using 1 (>K:KOHLSMAN_INC) but I have no idea how you could have known that crucial snippet of information...

thanks
B21

Well, the only thing I've found so far is investing a lot of time on documentation research and my own tests. Bill is right when he says some stuff can be "inferred from context", but it can only give you the certain that code which is working fine can be used/copied and will work fine as well. I prefer to understand as much as possible the reasons that make the code work as it does...

Tom

 

[B21]

thanks for that info. To add something, I wondered how an altimer knows it's the primary or the secondary, and the answer is the secondary altimeter displays (A:INDICATED ALTITUDE:2, feet) i.e. :2 can appear after the var name.

I still don't know where ace.exe looks to find the valid key event strings (I knew it's not gauges.h) but I doubt this is of general interest...

B21

 

[taguilo]

thanks for that info. To add something, I wondered how an altimer knows it's the primary or the secondary, and the answer is the secondary altimeter displays (A:INDICATED ALTITUDE:2, feet) i.e. :2 can appear after the var name.

I still don't know where ace.exe looks to find the valid key event strings (I knew it's not gauges.h) but I doubt this is of general interest...

B21

It's not enough to use a :1 or :2 in those related instruments' data code but also necessary to enable a dual/multiple version in aircraft.cfg.
For example, to enable independant barometric setting, you must put

[altimeters]
altimeter.0=1
altimeter.1=1

in aircraft.cfg

About ace.exe, it doesn't look into gauges.h but in propdefs subfolder inside the panels and gauges' SDK folder, where .xml property schemas are placed to be used as reference - for example propgauge.xml -

Tom

 

[DNLK]

B21

Were you ever able to get Ace.exe to stop giving the errors. I have the same problem. Doesn't matter what gauge I open, it errors on all the key events.

I am using ace as my primary editor, because the gauge I am working on is very graphical. The error is annoying, but I don't want to "cancel" to ignore errors because I like the syntax checking.

 

[B21]

Nope sorry - I just live with the errors and hit 'ok' or 'cancel' depending on what I just adjusted. Once you've hit 'ok' though ace.exe ignores all errors for the whole time remaining you have the application open, i.e. on multiple xml gauge loads.

FWIW ace.exe also gives errors on my C: mission variables. I have two PC's and two genuine copies of FSX and one ace.exe works ok and the other doesn't. From memory for some reason I *copied* the SDK files onto one of the machines instead of a proper install (maybe I have 1 copy of deluxe and the other not) and that's the one that ace.exe is broken.

I find it more productive to have both ace.exe and a text-editor open with the XML, and do an editor-save/ace-load sequence after each significant update. I use ace.exe to tweak coordinates and get an immediate layout view but never *save* in ace.exe.

I concur ace.exe is quite good for graphics but it's a non-starter for scripting more than a few lines.

B21

 

[taguilo]

I concur ace.exe is quite good for graphics but it's a non-starter for scripting more than a few lines.

B21

IMHO the best thing ace.exe gives is the ability to compile XML files to a highly compressed SPB format. Thanks to this the loading time of a complex multigauge panelset can be improved a lot, because SPB are quite smaller than their sources. Besides, the schema structure becomes "protected" from unwanted watchers, as the classic tags are replaced by their compiled code. As expected scripts are kept in native -plain text- format so they can be recognized when reading the file in a hex editor, but nothing is perfect...

Tom

 

[B21]

the classic tags are replaced by their compiled code

ah if only it were so... I created an SPB using ace.exe and then de-compiled my gauge using the freeware utility available on the web, and there were all my original variable names, comments, the lot...

B21

 

[Kronzky]

Forget about gauges.h as that is only used for C gauges... The only two lists you need be concerned with are:

Event IDs.htm
Simulation Variables.html

both of which are (in)conveniently and illogically located in the SDK's ..\SDK\Core Utilities Kit\Variables folder, instead of where one might expect to find it (..\Panels and Gauges SDK).

Sorry for digging up this ancient thread, but I seem to have the same issue as was described here.
Ace will give me an "Invalid Key Event" with every single K: event I define (even though the gauge was copied from the official Lear45 package), and I also don't seem to have any of those HTML files mentioned above in my SDK branch.
I tried to repair the installation (up to SP2), but that didn't change anything.

I seem to remember that, at some point, there were a bunch of HTML files in that folder, but they were removed with one of the service packs.
So it could just be that these resources are stored somewhere else by now, but that means I'm still stuck with the issue of getting errors for every key event I define...

The code for my test gauge is listed here, and is also included in the attached zip file (along with a tree listing of the SDK folder):

<?xml version="1.0" encoding="UTF-8"?>

<SimBase.Document
        Type="AceXML"
        version="1,0"
        id="TST">
    <Descr>AceXML Document</Descr>
    <Filename>tst.xml</Filename>
    <SimGauge.Gauge id="Gauge" ArtDirectory=".">
        <FloatPosition>0.000,0.000</FloatPosition>
        <Size>100,100</Size>
        <Element id="a">
            <FloatPosition>5.000,5.000</FloatPosition>
            <GaugeText id="GaugeText">
                <Fixed>True</Fixed>
                <FontFace>arial</FontFace>
                <FontColor>red</FontColor>
                <FontHeight>12</FontHeight>
                <GaugeString>TST</GaugeString>
                <HorizontalAlign>CENTER</HorizontalAlign>
                <Length>3</Length>
                <Size>90,90</Size>
                <Transparent>True</Transparent>
                <VerticalAlign>CENTER</VerticalAlign>
            </GaugeText>
        </Element>
        <MouseArea id="MouseArea all">
            <FloatPosition>5.000,5.000</FloatPosition>
            <Size>90,90</Size>
            <CursorType>Normal</CursorType>
            <MouseArea id="fullon">
                <FloatPosition>0.000,0.000</FloatPosition>
                <Size>90,90</Size>
                <CursorType>Hand</CursorType>
                <MouseClick id="MouseClick">
                    <Script>
			(M:Event) 'LeftSingle' scmp 0 == if{ 1 (&gt;L:SK_L2A Pushed,bool) 1 (&gt;K:THROTTLE_FULL) } 
			(M:Event) 'LeftRelease' scmp 0 == if{ 0 (&gt;L:SK_L2A Pushed,bool) }
                    </Script>
                    <ClickType>LeftSingle+LeftRelease</ClickType>
                </MouseClick>
            </MouseArea>
        </MouseArea>
    </SimGauge.Gauge>
</SimBase.Document>

 

[Flying Officer Jevans]

I seem to remember that, at some point, there were a bunch of HTML files in that folder, but they were removed with one of the service packs.
So it could just be that these resources are stored somewhere else by now, but that means I'm still stuck with the issue of getting errors for every key event I define...

I take it you haven't found the actual SDK manual, then? It helps a little. It's the chm file in the root of the SDK folder.

Anyway, your code works fine in my ACES editor. I haven't got time to test it in the sim, but if it works fine in the sim, I think you can safely ignore anything the editor throws at you.

 

[Kronzky]

Forget about gauges.h as that is only used for C gauges... The only two lists you need be concerned with are:

Event IDs.htm
Simulation Variables.html

both of which are (in)conveniently and illogically located in the SDK's ..\SDK\Core Utilities Kit\Variables folder, instead of where one might expect to find it (..\Panels and Gauges SDK).

Even then, be mindful that the left column in the EventIDs is for C gauges. The center column is for both XML and SimConnect!


A lot of stuff has to be "inferred from context." This is a prime example of what I mean. If you look closer at the script example I posted, notice the leading "2" before the key_event... That, along with the name of the gauge ("standby") provides the necessary clues.

Yeah, I did find the new CHM file, but I guess they originally were HTML files, as I created a shortcut to them after the initial install, and after either the first or second service pack that link didn't work anymore.
But since n4gix was mentioning that these two HTML resource files (Event IDs.htm &
Simulation Variables.html) were needed for the proper event interpretation, I though that they may have been deleted during the update, even though they're still needed.

Sure, the gauges I've made with ACE so far all work in FSX, but it would still be nice to have error messages that are actually meaningful (especially if it's just a matter of finding those missing files).

 

[Flying Officer Jevans]

No, those files are not needed for FS or the ACES tool to run at all. They're just the HTML help files, human readable only, and their content is now in the chm file.

The ACES editor reads it's definitions from the propdefs files, in the propdefs directory.

To be honest, the ACES tool has so many bugs in it it's difficult to get meaningful errors from it sometimes. Mind, I still use it.

 

[n4gix]

Specifically this folder:

..\SDK\SimObject Creation Kit\Panels and Gauges SDK\PropDefs

If the SDK is not properly configured in the Registry, that may be why the ACE.exe tool can't find the definitions for the EventIDs.

 

[beatle]

Ace.exe was originally developed as a visual design editor for the dialogs in FSX (and it was never all that good at doing that either, I probably used plain text editor on XML files at least 50% of the time :-> ). Susan just sorta hacked on the gauge editing abilities, which, as has already been pointed out, has several issues of its own :->.