http://www.fsdeveloper.com/wiki/api.php?action=feedcontributions&feedformat=atom&user=RpmcFSDeveloper Wiki - User contributions [en-gb]2026-05-24T16:28:35ZUser contributionsMediaWiki 1.41.1http://www.fsdeveloper.com/wiki/index.php?title=XML:_Key_Traps&diff=10560XML: Key Traps2018-06-19T16:19:45Z<p>Rpmc: </p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = true<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = false <br />
| XP9 = false <br />
}}<br />
'''KEY TRAP'''<br />
<br />
A Key Trap is gauge code that ‘listens’ for a specific keyboard entry to be made. Its purpose is to allow custom XML script to be executed when the user types that specific key. By nature, it’s conditional: if the keystroke is made, then disregard whatever that key is currently assigned to do, if anything, and then process the key trap script.<br />
<br />
In XML, the trap is defined using an <On Key> block placed within a <Keys> section:<br />
<br />
1 <Keys><br />
2 <On Key="Alphanumeric"><br />
3 <Visible>(L:KeyTrapEnabled, bool) 1 ==</Visible><br />
4 (M:Key) chr (>C:fs9gps:NameSearchEnterChar)<br />
5 </On><br />
6 </Keys><br />
<br />
Here, the key trap definition is any alphanumeric character (line 2) and the key trap script (line 3 and line 4) passes the character that was typed to a gps variable provided, however, that L:KeyTrapEnabled = 1. <br />
<br />
'''<Visible>:''' <Visible> expressions are frequently added to key traps so the user can control when the trap is functional, which is especially important when broad key definitions “ascii” or “alphanumeric” are used. In the example above, whenever the user has ''not'' set L:KeyTrapEnabled to 1, the key trap is not functional. That way, the typical (i.e., default) key assignment of “G” will still toggle the landing gear rather than being trapped and the character “G” sent to the gps variable.<br />
<br />
<On Key> blocks are nested within <Keys> sections and therefore should be placed at the bottom of the gauge script in order to catch all keystrokes and events triggered during each gauge update cycle.<br />
<br />
<br />
'''DEFINING THE TRAP KEY''' <br />
<br />
Format of the trap key definition is flexible.<br />
<br />
- It can be broadly specified using “ascii” or “alphanumeric” expressions, or<br />
<br />
- individually specified using the decimal or hex ascii code value of a key, or<br />
<br />
- specified using the individual character itself (includes Backspace, Tab, Enter, Esc, Space, A thru Z, and F1 thru F12. See tables).<br />
<br />
<br />
'''Examples:'''<br />
<br />
<On Key=”ascii”> traps any of the following characters:<br />
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 and space, minus, plus, comma, period <br />
<br />
<On Key=”alphanumeric”> traps any of the following characters:<br />
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 and space<br />
<br />
<On Key=”87”> traps the letter “W”. 87 is the decimal value of the ascii code for character “W”<br />
<br />
<On Key=”0x57”> traps the letter “W”. 0x57 is the hex value of the ascii code for character “W”<br />
<br />
<On Key=”W”> traps the letter “W”<br />
<br />
Hex and decimal values are always interchangeable in the trap definition - it can accept either number format.<br />
<br />
<br />
'''Ctrl and Shift Combination:''' Ctrl and/or Shift can be combined with most keys and trapped in an <On Key> block. <br />
<br />
The table below shows binary representation of the ascii code for letter W. The ascii decimal value of W is 87, hex equivalent is 0x57, and binary is 1 0 1 0 1 1 1. <br />
<br />
To add Shift, place 1 in Bit 8. For Ctrl, add 1 in bit 9 . Ctrl+Shift is 1 in both bit 8 and bit 9. The key trap definition can accept the decimal or hex equivalent of the result, but not the binary.<br />
<br />
[[File:CtrlShift2.png]]<br />
<br />
<br />
Alt can also be combined with a key to form a trap, but it appears to conflict with the FS Menu system, so I would say it's use is not recommended.<br />
<br />
Several formats are acceptable for definition of the key combination.<br />
<br />
<On Key=”855”> traps the key combination Ctrl + Shift + W<br />
<br />
<On Key=”0x357”> traps the key combination Ctrl + Shift + W, and<br />
<br />
<On Key=”Ctrl+Shift+W”> also traps the key combination Ctrl + Shift + W and may be the easiest format to remember <br />
(includes Backspace, Tab, Enter, Esc, Space, A thru Z, and F1 thru F12. See tables).<br />
<br />
When the <On Key> definition includes Shift and/or Ctrl, (M:Key) will return only the root character code.<br />
<br />
<Keys><br />
<On Key="599"><br />
<Visible>(L:KeyTrapEnabled, bool) 1 ==</Visible><br />
(M:Key) (>L:CtrlW_Value, enum)<br />
</On><br />
</Keys><br />
<br />
In the Ctrl+W trap example above, (L:CtrlW_Value, enum), and hence, (M:Key), returns 87, which is the decimal value of the ascii code for W, ''not'' 599 which is the decimal value for Ctrl + W used in the trap definition.<br />
<br />
<br />
'''TRAPPABLE KEYSTROKES'''<br />
<br />
The tables at the bottom of the wiki summarize keystroke trap capability. Blue font with no shading reflects keys and combinations that are trappable. Pink shading indicates that the key, or key combination, is not trappable, and grey represents uncertainty as my keyboards do not have these keys. <br />
<br />
'''Ascii and Alphanumeric:''' "yes" indicates keys that are trappable using <On Key=”Ascii”> or <On Key=”Alphanumeric”> definitions.<br />
<br />
'''Trap using Name:''' indicates keys that can be trapped using the character name in the definition, for example <On Key=”Backspace”> or <On Key=”A”>. Ctrl and Shift can be used in combination with these, for example <On Key=”Ctrl+Shift+Enter”>. Includes Backspace, Tab, Enter, Esc, Space, A thru Z, and F1 thru F12, or whatever is the maximum F key number. The tables at the bottom of this wiki show a more complete, though likely not exhaustive, list.<br />
<br />
'''Trap using Ascii Decimal, Ascii Hex:''' indicates keystrokes that are trappable using decimal or hex values in the definition. For example, the '''Home''' key can be trapped using <On Key=”36”> or <On Key=”0x24”> definition.<br />
<br />
'''Trap using Ctrl, Shift and Ctrl+Shift:''' Ctrl and Shift can be used in combination with most keys. For example, a Ctrl+Capslock trap is defined as <On Key=”532”> or <On Key=”0x214”> (0x214 is the hex equivalent of decimal 532). <br />
<br />
<br />
Differences in keyboards may alter the trap capability shown in the tables. If a keyboard has a NumPad with stand alone keys (1 isn't paired with END , 2 isn't paired with Down Arrow, etc.) then all the NumPad keys ''may'' be trappable.<br />
<br />
<br />
'''NEUTRALIZING AN EXISTING KEY ASSIGNMENT'''<br />
<br />
A key trap without a trap script neutralizes an existing key assignment because the trap momentarily disregards the existing assignment and instead, processes the trap script. As an example,<br />
<br />
<Keys><br />
<On Key=”Q"/><br />
<On Key=”L"/><br />
</Keys><br />
<br />
disables the default sound and lights keyboard assignment toggles.<br />
<br />
'''Note:''' Multiple <On Key> and/or <On Event> traps are permissible within a <Keys> block.<br />
<br />
<br />
'''KEY TRAP PROCESSING''' <br />
<br />
Keystrokes trapped in the current update cycle are queued and then their trap routines are sequentially processed at the end of the cycle. All simulation variables (A:Vars) affected by the trap routines return updated values on the subsequent cycle.<br />
<br />
'''Key Traps across the Gauge Set:''' FS processes <On Key> trap routines found in all gauges of the aircraft’s panel (the ‘gauge set’).<br />
<br />
So, if Gauge00 contains the following:<br />
<br />
<Keys><br />
<On Key=”Ctrl+W"><br />
<Visible>(L:KeyTrapEnabled, bool) 1 ==</Visible><br />
(L:MyVarA,enum) 10 + (>L:MyVarA,enum)<br />
</On><br />
</Keys><br />
<br />
and Gauge01 contains:<br />
<br />
<Keys><br />
<On Key=”Ctrl+W"><br />
<Visible>(L:KeyTrapEnabled, bool) 1 ==</Visible><br />
(L:MyVarA,enum) 20 + (>L:MyVarA,enum)<br />
</On><br />
</Keys><br />
<br />
Then, on the update cycle following entry of Ctrl+W, (L:MyVarA, enum) will return 30.<br />
<br />
<br />
'''VISIBLE WINDOW REQUIREMENT'''<br />
<br />
Key traps have the same visibility requirements as Event traps. One condition is that gauges must be in a visible window for their trap routines to be processed. If a gauge is part of a window whose visibility is set to visibility=0, then no <On Key> routines in that gauge will be run until visibility of the window is set to 1, or if the window is visible on the screen.<br />
<br />
Another important condition is that key trap routines in XML gauges are disabled when the user is in External view. This is a problem for those who like to manage systems (i.e. the autopilot) via keystrokes while flying in External view. <br />
<br />
'''Note:''' A recently released FSX module ([http://fsdeveloper.com/forum/resources/xmltools-a-common-xml-expansion-module-for-fsx.131/ XMLTools v.1.0], June 2014, from Tom Aguilo) will handle FSX event traps in any view mode, thus overcoming the visible and external window limitations of stock FSX. XMLTools can be freely downloaded from the FSDeveloper Resources site. Check that site or FSDeveloper Gauges Forum for XMLTools update notices.<br />
<br />
<br />
'''M:KEY'''<br />
<br />
M:Key is a parameter that returns the decimal ascii code value of a keystroke.<br />
<br />
In the following key trap,<br />
<br />
<Keys><br />
<On Key="Alphanumeric"><br />
<Visible>(L:KeyTrapEnabled, bool) 1 ==</Visible><br />
(M:Key) (>L:MKeyValue, enum)<br />
</On><br />
</Keys><br />
<br />
if the letter “X” is typed, (L:MKeyValue, enum) is 88. Whenever Ctrl and/or Shift are used in combination with a key, M:Key returns the ascii decimal value for the key.<br />
<br />
<br />
'''SHIFT REGISTER'''<br />
<br />
In certain situations, the user may want to concatenate and store multi-character ascii keystroke entries, for example, gps data entry when the user prefers to type the input rather than use the mouse to rotate knob images. Without use of an external module such as XMLVars, FS cannot easily store string values in XML environment. FS is mostly limited to storing the decimal ascii code equivalent of individual letters into individual L:Vars. This has traditionally been accomplished through the use of a shift register inside a key trap.<br />
<br />
The example below accommodates typing of up to 5 keystrokes, storing the ascii code value of each typed character into a separate L:Var, subsequently retrieving the L:Vars, converting the ascii code back to characters, concatenating the characters, then ultimately storing the string into FlightPlanNewWaypointIdent.<br />
<br />
1 <Keys> <br />
2 <On Key="Alphanumeric"><br />
3 <Visible>(L:KeyEntry, enum) 39 ==</Visible><br />
4 (L:Num394,enum) (>L:Num395,enum)<br />
5 (L:Num393,enum) (>L:Num394,enum)<br />
6 (L:Num392,enum) (>L:Num393,enum)<br />
7 (L:Num391,enum) (>L:Num392,enum)<br />
8 (M:Key) (>L:Num391,enum)<br />
9 (L:Num395,enum) chr <br />
10 (L:Num394,enum) chr scat <br />
11 (L:Num393,enum) chr scat <br />
12 (L:Num392,enum) chr scat <br />
13 (L:Num391,enum) chr scat<br />
14 (>@c:FlightPlanNewWaypointIdent, string) <br />
15 </On> <br />
16 </Keys><br />
<br />
'''Lines 4-7:''' The “shift register”. Before storing the decimal ascii value of the current keystroke into L:Num391 (Line 8), the value of the previous keystroke entry, which was initially stored in L:Num391, is stored into L:Num392 (Line 7). Preceding that (Line 6), the value in L:Num392 is shifted up to (stored into) L:Num393, and so forth. After 5 keystrokes, the ascii value of first keystroke entered will end up being stored in L:Num395.<br />
<br />
'''Line 8:''' The ascii decimal value of the current keystroke, (M:Key), is stored into L:Num391. <br />
<br />
'''Lines 9–13:''' The L:Var ascii values are recalled in a last-in, first-out order, converted back to symbols using the ‘chr’ operator, and concatenated using the ‘scat’ operator to form a string.<br />
<br />
'''Line 14:''' The concatenated string is entered into FlightPlanNewWaypointIdent.<br />
<br />
External dll modules such as Tom Aguilo’s XMLVars (included in his [http://fsdeveloper.com/forum/resources/xmltools-a-common-xml-expansion-module-for-fsx.131/ XMLTools module]) or Doug Dawson’s [http://www.douglassdawson.ca/ String_Storage] allow the user to store and retrieve string values without the use of a Shift Register and are highly recommended. For a more complete discussion of string storage options in Flight Simulator, refer to the [http://fsdeveloper.com/wiki/index.php?title=Xml:_storing_strings Storing Strings] wiki.<br />
<br />
<br />
''Acknowledgements: [http://www.schiratti.com/dowson.html Peter Dowson], Rob Barenregt, [http://fsdeveloper.com/forum/resources/xmltools-a-common-xml-expansion-module-for-fsx.131/ Tom Aguilo]''<br />
<br />
''[[rpmc]] (July 2014)''<br />
<br />
<br />
[[File:KT1b.png]]<br />
[[File:KT2b.png]]<br />
[[File:KT3b.png]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_PID_Controller&diff=10544XML: PID Controller2018-04-16T16:58:37Z<p>Rpmc: </p>
<hr />
<div>[http://fsdeveloper.com/forum/threads/ap-speed-hold-pid-controller.437633/ AP speed hold PID controller]<br />
<br />
Thank you to Bjoern Kesten (Heretic) for providing a detailed explanation and XML example of a PID Controller and consolidating a link list of PID threads authored by various FSDeveloper contributors.<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Events_and_Traps&diff=10543XML: Events and Traps2018-04-15T16:20:34Z<p>Rpmc: </p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = true<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = unknown<br />
| XP9 = unknown<br />
}}<br />
<br />
'''EVENT''' <br />
<br />
An Event is a user-initiated instruction to execute a certain Flight Sim (FS) function. Examples include control surface movement, radio tuning, landing gear retraction/extension, throttle movement, etc. Events are initiated via joystick or other controller, keyboard, mouse, or gauge software. Initiating an event from within one’s gauge software is often referred to as “throwing”, “firing” or “triggering” an event. <br />
<br />
From within XML gauge script, an event is triggered using (>K:EVENT) or <Click Event="EVENT"/> instructions. <br />
<br />
Examples:<br />
<br />
(>K:MIXTURE_RICH) <br />
instructs FS to set all mixture levers to maximum rich. This event does not require a number, or argument, to be passed to it. It’s just (>K:MIXTURE_RICH). The majority of events require no argument.<br />
<br />
8100 (>K:MIXTURE_SET) <br />
instructs FS to set mixture levers to 8100, or about mid range. This is an example of an event that requires an argument. <br />
<br />
<br />
Almost all events have related read-only simulation variables (A:Variables) that change in response to the event’s execution. The simulation variable <br />
<br />
(A:GENERAL ENG MIXTURE LEVER POSITION:''index'', percent) <br />
<br />
is associated with the MIXTURE_SET event. If 8100 is passed to MIXTURE_SET, then the A:Var will return 49.44. (Note: 8100/16383 = 49.44. As per SDK, 16383 is the maximum value allowed for MIXTURE_SET. Its range is 0 to 16383 **).<br />
<br />
<br />
Events are single and instantaneous. Even the smooth increase of the throttle on a game controller is sampled as a series of singular THROTTLE_INCR_SMALL events.<br />
<br />
Event expressions don’t contain Units.<br />
<br />
<br />
The FSX SDK has the complete list in the Events ID section of the [http://msdn.microsoft.com/en-us/library/cc526980.aspx online Microsoft ESP SDK].<br />
<br />
The [http://support.microsoft.com/kb/555857 FS9 SDK can be downloaded here]. Go to the Panels and Gauges link.<br />
<br />
Use the Simconnect Name / String Name entries for XML gauges rather than the Event ID name (containing KEY_) which is used with C++ gauges.<br />
<br />
<br />
'''EVENT TRAP''' <br />
<br />
An Event Trap is gauge code that ‘listens’ for specified events to be triggered. Its purpose is to allow customized, user-defined script to also be executed anytime the specified event is triggered. By nature, it’s conditional: if Event A is triggered, then process the event trap script and then execute the event.<br />
<br />
In XML, the trap is defined using an <On Event> block placed within a <Keys> block:<br />
<Keys><br />
<On Event="LANDING_LIGHTS_TOGGLE"><br />
1 (>L:Sound_Click,number)<br />
</On><br />
</Keys><br />
<br />
The event is LANDING_LIGHTS_TOGGLE. The event trap routine is 1 (>L:Sound_Click,number).<br />
<br />
<On Event> blocks should be placed at the bottom of the gauge script in order to catch all events triggered during each gauge update cycle.<br />
<br />
<br />
<br />
'''EVENT PROCESSING AND XML SCRIPT''' <br />
<br />
All events that are triggered in the current gauge update cycle are queued and then executed sequentially along with their trap routines, if any exist, at the ''end'' of the cycle. All simulation variables (A:Vars) affected by the executed events return updated values on the subsequent cycle.<br />
<br />
<br />
'''Event Traps across the Gauge Set:''' FS processes <On Event> trap routines found in all gauges of the aircraft’s panel (the ‘gauge set’) before coming back to the point where the original event was processed – at the end of the update cycle in the gauge that triggered the event. <br />
<br />
So, if Gauge00 contains the following:<br />
<br />
<Keys><br />
<On Event="PITOT_HEAT_ON"><br />
(L:MyVarA,enum) 10 + (>L:MyVarA,enum)<br />
</On> <br />
</Keys><br />
<br />
and Gauge01 contains:<br />
<br />
<Keys><br />
<On Event="PITOT_HEAT_ON"><br />
(L:MyVarA,enum) 20 + (>L:MyVarA,enum)<br />
</On> <br />
</Keys><br />
<br />
then on the update cycle of the triggering gauge following the PITOT_HEAT_ON event trigger, (L:MyVarA, enum) will return 30.<br />
<br />
<br />
'''Visible Window:''' A condition is that gauges must be in a visible window for their trap routines to be processed. If a gauge is part of a window whose visibility is set to visibility=0, then no <On Event> routines in that gauge will be run until visibility of the window is set to 1, or until the window is made visible on the screen (e.g., drop down menu Views - Instrument Panel - ''Window whatever'').<br />
<br />
Another important condition is that event trap routines in XML gauges are disabled when the user is in External view. Code-fired events still work fine, but their <On Event> capture sections will not. This is a problem for those who like to manage systems (i.e. the autopilot) via keystrokes while flying in External (Spot plane) view. A discussion of work-arounds for this limitation can be found in this [http://www.fsdeveloper.com/forum/threads/events-wiki.430484/#post-675044 EVENTS wiki thread] (see post number 13).<br />
<br />
'''Note:''' A recently released FSX expansion module ('''XMLTools''' v.1.0, June 2014, from Tom Aguilo) will handle ''FSX'' event traps in any view mode, thus overcoming the visible and external window limitations of stock FSX. XMLTools can be freely downloaded from the [http://fsdeveloper.com/forum/resources/xmltools-a-common-xml-expansion-module-for-fsx.131/ FSDeveloper Resources] site. Check that site or FSDeveloper Gauges Forum for XMLTools update notices.<br />
<br />
<br />
'''Events are processed regardless of aircraft type:''' Events and event traps are processed whether or not the event is relevant for the current aircraft. Any SDK defined event can be triggered and executed in any aircraft. The event (>K:TOGGLE_WATER_RUDDER), for example, can be triggered and trap routines processed in an aircraft that is not a float plane. Same thing for helicopter events; their events and traps will be processed in any aircraft. <br />
<br />
As for associated simulation variables, however, following an event the sim will update only those A:Vars that are active for the current aircraft. (A:WATER RUDDER HANDLE POSITION, percent) will return a non-zero value ''only if'' the current aircraft contains water rudders. <br />
<br />
This can be helpful to know because sometimes a user may want to ‘hijack’ an otherwise useless event to accomplish an un-related chore. A recent [http://www.fsdeveloper.com/forum/threads/water-rudder-mod-xml.430240/ FSDeveloper forum thread] discussed use of the default water rudder toggle keyboard assignment (ctrl+W) to actually perform a prop reversing routine in a non-seaplane aircraft. The event trap routine, below, is performed whenever keyboard ctrl+W is pressed. It has nothing to do with water rudders, but that doesn’t matter.<br />
<br />
<Keys><br />
<On Event="TOGGLE_WATER_RUDDER"><br />
(L:Reversing,bool) ! (>L:Reversing,bool)<br />
(L:Reversing,bool)<br />
if{<br />
491 (>K:THROTTLE_SET)<br />
-491 (>K:PROP_PITCH_SET)<br />
}<br />
els{<br />
(>K:PROP_PITCH_LO)<br />
}<br />
</On> <br />
</Keys><br />
<br />
Note: Prop reverse action will simulate correctly only on aircraft whose model and aircraft.cfg file are already appropriately configured, but the <On Event="TOGGLE_WATER_RUDDER"> trap above will always fire the THROTTLE_SET and PROP_PITCH_SET events.<br />
<br />
<br />
'''AIRCRAFT LOAD AND RE-LOAD ISSUES''' <br />
<br />
When an aircraft loads or is re-loaded, gauge script begins running slightly before the sim’s event and trap handling system is operational. Consequently, if events are fired as part of an <Update> initialization sequence, event and trap errors may occur where the events are apparently not processed, or may seem to be processed incorrectly. <br />
<br />
In fact, however, triggered events are queued, and the queued events plus trap routines are processed all together when the event handling system finally becomes functional. The length of delay is variable, on the order of 10s of update cycles, and is dependent upon how and when the aircraft is loaded, cache, where the gauge is defined in the panel.cfg, etc. To deal with this, event triggering in an <Update> initialization sequence should be delayed until the sim’s event handling system is ready.<br />
<br />
There are a couple of approaches to construct the delay. The first invokes a cycle counting routine; the other lets the sim tell you when it’s ready.<br />
<br />
Consider the initialization sequence below. The intention is to set one notch of flaps when the aircraft loads. As written, however, that is not what occurs.<br />
<br />
'''Initialization Sequence:'''<br />
<br />
<Update><br />
(L:MyVarA, enum) 0 ==<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
} <br />
</Update><br />
<br />
'''Event Trap:'''<br />
<br />
<Keys><br />
<On Event="FLAPS_INCR"><br />
(L:MyVarA, enum) ++ (>L:MyVarA, enum)<br />
</On><br />
</Keys><br />
<br />
On my system, nothing appears to happen until the 20th cycle after the gauge initialization sequence starts running, when the following is returned:<br />
<br />
3 (A:FLAPS HANDLE INDEX, enum)<br />
100 (A:FLAPS HANDLE PERCENT, percent) <br />
19 (L:MyVarA, enum)<br />
19 (L:MyVarB, enum)<br />
<br />
The flaps have been increased to the maximum, 100% position, not just one notch, and both MyVarB and MyVarA are 19. This result seemingly does not make sense. <br />
<br />
Without delaying execution of the initialization sequence, the (>K:FLAPS_INCR) event and it’s associated event trap responsible for incrementing MyVarA, is queued each cycle until the event handling system is ready, at which point the queue is processed ''at once'': the flaps are incremented 19 times as is MyVarA which returns 19, not 1.<br />
<br />
<br />
'''Cycle Counting approach:''' If <Update> is edited to include a cycle skipping delay after aircraft reload (the Event Trap is the same as above),<br />
<br />
<Update><br />
(L:CycleCounter, enum) 20 &lt;=<br />
if{ (L:CycleCounter, enum) ++ (>L:CycleCounter, enum) }<br />
<br />
(L:MyVarA, enum) 0 == (L:CycleCounter, enum) 20 &gt;= and<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
}<br />
</Update><br />
<br />
then the following is obtained. One notch, only, of flaps and both MyVarA and MyVarB are 1. <br />
<br />
1 (A:FLAPS HANDLE INDEX, enum)<br />
33.3 (A:FLAPS HANDLE PERCENT, percent) <br />
21 (L:CycleCounter, enum)<br />
1 (L:MyVarA, enum)<br />
1 (L:MyVarB, enum)<br />
<br />
In this case, the 20 cycle delay provided sufficient time for the event and trap handling system to load before the initialization sequence containing (>K:FLAPS_INCR) was executed. The event trap was processed in the same cycle, incrementing MyVarA from 0 to 1, and thereby shut off the init sequence in the next cycle. The event fire initialization sequence now works as intended.<br />
<br />
<br />
'''Note:''' <Update> could have been written:<br />
<br />
<Update><br />
(L:MyVar'''[[B]]''', enum) 0 ==<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
} <br />
</Update><br />
<br />
and the FLAPS_INCR event and trap would have been triggered and processed only once. For the purposes of this wiki, it was written as (L:MyVar'''A''', enum) 0 == with the incrementer in the Event Trap rather than in Update to shed light on the event handling system delay.<br />
<br />
<br />
<br />
'''Let FS tell you when it’s ready:''' In another [http://www.fsdeveloper.com/forum/threads/fsx-ignores-events-at-flight-loading.429672/ FSDeveloper thread], Rob Barendregt proposed an elegant and more fool-proof method of introducing the necessary delay. He suggests to simply fire an event, in his case, the infrequently used<br />
<br />
CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE<br />
<br />
event, and when its associated simulation variable, <br />
<br />
(A:CABIN SEATBELTS ALERT SWITCH, bool)<br />
<br />
returns 1 that means the sim's event handling system is operating. Following that, his desired initialization events can be executed successfully. <br />
<br />
A slight clarification is that if event traps are included, they will not execute until the cycle following (A:CABIN SEATBELTS ALERT SWITCH, bool) = 1.<br />
<br />
<br />
''' C-code version: '''A "C" language version of Rob Barendregt's method was written by Dai Griffiths and posted in this [https://www.fsdeveloper.com/forum/threads/gauge-search-priority.442569/#post-796989/ FSDeveloper thread]<br />
<br />
<br />
'''“RACE” CONDITION - CONSTANT EVENT FIRING''' <br />
<br />
As commonly defined in XML related discussions in this forum, a Race Condition is an uncontrolled and likely unintentional, repetitive event firing situation. <br />
<br />
It’s an issue because continuously firing events can cause unforeseen errors across the gauge set and potentially interfere or conflict with other commands being received. Race conditions can adversely affect stream code from <Update> and <Element> sections as well as event code from <Mouse> and <Keys> sections in any gauge, not just the gauge that is firing the event. The culprit gauge (or controller) may be difficult to identify without use of an event logging application. Doubly difficult if your panel contains a mix of XML and C/C++ gauges.<br />
<br />
To mitigate, there are a few best practices to incorporate in XML:<br />
<br />
- Take care when including an event trigger in an <Update> section. Unless its execution is conditional, it will fire continuously. <br />
Add a check, or condition that will limit the event to ''one'' firing only. A good example of such logic is included in this <br />
FSDeveloper post by Roman Stoviak ([http://fsdeveloper.com/forum/threads/setting-fuel-flow-order.430781/#post-677935 see response #16]).<br />
<br />
- Place the event trigger within a mouse click when applicable. That way, the event is sure to be fired only once unless Repeat="Yes"<br />
is invoked for example, in connection with a VOR1_OBI_INC event.<br />
<br />
<br />
'''TOGGLE EVENTS''' <br />
<br />
Event toggles come in two varieties; those that require an argument and those that do not. Most event toggles are of the second type and simply reverse the state of the associated simulation variable. If the variable was “On”, it now becomes “Off”. If it was “Off”, it now becomes “On”. <br />
<br />
The current state of the variable can be tricky to keep track of in a panel where multiple gauges can trigger the same event toggle. To mitigate this, most contributors to this forum suggest instead of using toggles, use _SET, _ON, or _OFF events to explicitly set the state of the variables. TOGGLE events are best avoided or limited to only a single gauge in the gauge set.<br />
<br />
<br />
**<br />
(>K:MIXTURE_RICH) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 100<br />
<br />
16383 (>K:MIXTURE_SET) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 99.9939<br />
<br />
16384 (>K:MIXTURE_SET) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 100<br />
<br />
Consequently, if you want '''100.000%''' full rich, then use (>K:MIXTURE_RICH), best, or 1638'''4''' (>K:MIXTURE_SET), second best.<br />
<br />
A similar situation may apply to other events, but experiment to be sure.<br />
<br />
16383 = 14 bit binary 11 1111 1111 1111<br />
<br />
<br />
''Acknowledgments: Tom Aguilo, Bill Leaming, Paul (Gypsy Baron), Rob Barendregt, Manfred Jahn, Doug Dawson, Roy Holmes, Roman Stoviak, Arne Bartels, Dai Griffiths''<br />
<br />
''[[rpmc]] edited April 2018''<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Events_and_Traps&diff=10542XML: Events and Traps2018-04-15T16:17:21Z<p>Rpmc: </p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = true<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = unknown<br />
| XP9 = unknown<br />
}}<br />
<br />
'''EVENT''' <br />
<br />
An Event is a user-initiated instruction to execute a certain Flight Sim (FS) function. Examples include control surface movement, radio tuning, landing gear retraction/extension, throttle movement, etc. Events are initiated via joystick or other controller, keyboard, mouse, or gauge software. Initiating an event from within one’s gauge software is often referred to as “throwing”, “firing” or “triggering” an event. <br />
<br />
From within XML gauge script, an event is triggered using (>K:EVENT) or <Click Event="EVENT"/> instructions. <br />
<br />
Examples:<br />
<br />
(>K:MIXTURE_RICH) <br />
instructs FS to set all mixture levers to maximum rich. This event does not require a number, or argument, to be passed to it. It’s just (>K:MIXTURE_RICH). The majority of events require no argument.<br />
<br />
8100 (>K:MIXTURE_SET) <br />
instructs FS to set mixture levers to 8100, or about mid range. This is an example of an event that requires an argument. <br />
<br />
<br />
Almost all events have related read-only simulation variables (A:Variables) that change in response to the event’s execution. The simulation variable <br />
<br />
(A:GENERAL ENG MIXTURE LEVER POSITION:''index'', percent) <br />
<br />
is associated with the MIXTURE_SET event. If 8100 is passed to MIXTURE_SET, then the A:Var will return 49.44. (Note: 8100/16383 = 49.44. As per SDK, 16383 is the maximum value allowed for MIXTURE_SET. Its range is 0 to 16383 **).<br />
<br />
<br />
Events are single and instantaneous. Even the smooth increase of the throttle on a game controller is sampled as a series of singular THROTTLE_INCR_SMALL events.<br />
<br />
Event expressions don’t contain Units.<br />
<br />
<br />
The FSX SDK has the complete list in the Events ID section of the [http://msdn.microsoft.com/en-us/library/cc526980.aspx online Microsoft ESP SDK].<br />
<br />
The [http://support.microsoft.com/kb/555857 FS9 SDK can be downloaded here]. Go to the Panels and Gauges link.<br />
<br />
Use the Simconnect Name / String Name entries for XML gauges rather than the Event ID name (containing KEY_) which is used with C++ gauges.<br />
<br />
<br />
'''EVENT TRAP''' <br />
<br />
An Event Trap is gauge code that ‘listens’ for specified events to be triggered. Its purpose is to allow customized, user-defined script to also be executed anytime the specified event is triggered. By nature, it’s conditional: if Event A is triggered, then process the event trap script and then execute the event.<br />
<br />
In XML, the trap is defined using an <On Event> block placed within a <Keys> block:<br />
<Keys><br />
<On Event="LANDING_LIGHTS_TOGGLE"><br />
1 (>L:Sound_Click,number)<br />
</On><br />
</Keys><br />
<br />
The event is LANDING_LIGHTS_TOGGLE. The event trap routine is 1 (>L:Sound_Click,number).<br />
<br />
<On Event> blocks should be placed at the bottom of the gauge script in order to catch all events triggered during each gauge update cycle.<br />
<br />
<br />
<br />
'''EVENT PROCESSING AND XML SCRIPT''' <br />
<br />
All events that are triggered in the current gauge update cycle are queued and then executed sequentially along with their trap routines, if any exist, at the ''end'' of the cycle. All simulation variables (A:Vars) affected by the executed events return updated values on the subsequent cycle.<br />
<br />
<br />
'''Event Traps across the Gauge Set:''' FS processes <On Event> trap routines found in all gauges of the aircraft’s panel (the ‘gauge set’) before coming back to the point where the original event was processed – at the end of the update cycle in the gauge that triggered the event. <br />
<br />
So, if Gauge00 contains the following:<br />
<br />
<Keys><br />
<On Event="PITOT_HEAT_ON"><br />
(L:MyVarA,enum) 10 + (>L:MyVarA,enum)<br />
</On> <br />
</Keys><br />
<br />
and Gauge01 contains:<br />
<br />
<Keys><br />
<On Event="PITOT_HEAT_ON"><br />
(L:MyVarA,enum) 20 + (>L:MyVarA,enum)<br />
</On> <br />
</Keys><br />
<br />
then on the update cycle of the triggering gauge following the PITOT_HEAT_ON event trigger, (L:MyVarA, enum) will return 30.<br />
<br />
<br />
'''Visible Window:''' A condition is that gauges must be in a visible window for their trap routines to be processed. If a gauge is part of a window whose visibility is set to visibility=0, then no <On Event> routines in that gauge will be run until visibility of the window is set to 1, or until the window is made visible on the screen (e.g., drop down menu Views - Instrument Panel - ''Window whatever'').<br />
<br />
Another important condition is that event trap routines in XML gauges are disabled when the user is in External view. Code-fired events still work fine, but their <On Event> capture sections will not. This is a problem for those who like to manage systems (i.e. the autopilot) via keystrokes while flying in External (Spot plane) view. A discussion of work-arounds for this limitation can be found in this [http://www.fsdeveloper.com/forum/threads/events-wiki.430484/#post-675044 EVENTS wiki thread] (see post number 13).<br />
<br />
'''Note:''' A recently released FSX expansion module ('''XMLTools''' v.1.0, June 2014, from Tom Aguilo) will handle ''FSX'' event traps in any view mode, thus overcoming the visible and external window limitations of stock FSX. XMLTools can be freely downloaded from the [http://fsdeveloper.com/forum/resources/xmltools-a-common-xml-expansion-module-for-fsx.131/ FSDeveloper Resources] site. Check that site or FSDeveloper Gauges Forum for XMLTools update notices.<br />
<br />
<br />
'''Events are processed regardless of aircraft type:''' Events and event traps are processed whether or not the event is relevant for the current aircraft. Any SDK defined event can be triggered and executed in any aircraft. The event (>K:TOGGLE_WATER_RUDDER), for example, can be triggered and trap routines processed in an aircraft that is not a float plane. Same thing for helicopter events; their events and traps will be processed in any aircraft. <br />
<br />
As for associated simulation variables, however, following an event the sim will update only those A:Vars that are active for the current aircraft. (A:WATER RUDDER HANDLE POSITION, percent) will return a non-zero value ''only if'' the current aircraft contains water rudders. <br />
<br />
This can be helpful to know because sometimes a user may want to ‘hijack’ an otherwise useless event to accomplish an un-related chore. A recent [http://www.fsdeveloper.com/forum/threads/water-rudder-mod-xml.430240/ FSDeveloper forum thread] discussed use of the default water rudder toggle keyboard assignment (ctrl+W) to actually perform a prop reversing routine in a non-seaplane aircraft. The event trap routine, below, is performed whenever keyboard ctrl+W is pressed. It has nothing to do with water rudders, but that doesn’t matter.<br />
<br />
<Keys><br />
<On Event="TOGGLE_WATER_RUDDER"><br />
(L:Reversing,bool) ! (>L:Reversing,bool)<br />
(L:Reversing,bool)<br />
if{<br />
491 (>K:THROTTLE_SET)<br />
-491 (>K:PROP_PITCH_SET)<br />
}<br />
els{<br />
(>K:PROP_PITCH_LO)<br />
}<br />
</On> <br />
</Keys><br />
<br />
Note: Prop reverse action will simulate correctly only on aircraft whose model and aircraft.cfg file are already appropriately configured, but the <On Event="TOGGLE_WATER_RUDDER"> trap above will always fire the THROTTLE_SET and PROP_PITCH_SET events.<br />
<br />
<br />
'''AIRCRAFT LOAD AND RE-LOAD ISSUES''' <br />
<br />
When an aircraft loads or is re-loaded, gauge script begins running slightly before the sim’s event and trap handling system is operational. Consequently, if events are fired as part of an <Update> initialization sequence, event and trap errors may occur where the events are apparently not processed, or may seem to be processed incorrectly. <br />
<br />
In fact, however, triggered events are queued, and the queued events plus trap routines are processed all together when the event handling system finally becomes functional. The length of delay is variable, on the order of 10s of update cycles, and is dependent upon how and when the aircraft is loaded, cache, where the gauge is defined in the panel.cfg, etc. To deal with this, event triggering in an <Update> initialization sequence should be delayed until the sim’s event handling system is ready.<br />
<br />
There are a couple of approaches to construct the delay. The first invokes a cycle counting routine; the other lets the sim tell you when it’s ready.<br />
<br />
Consider the initialization sequence below. The intention is to set one notch of flaps when the aircraft loads. As written, however, that is not what occurs.<br />
<br />
'''Initialization Sequence:'''<br />
<br />
<Update><br />
(L:MyVarA, enum) 0 ==<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
} <br />
</Update><br />
<br />
'''Event Trap:'''<br />
<br />
<Keys><br />
<On Event="FLAPS_INCR"><br />
(L:MyVarA, enum) ++ (>L:MyVarA, enum)<br />
</On><br />
</Keys><br />
<br />
On my system, nothing appears to happen until the 20th cycle after the gauge initialization sequence starts running, when the following is returned:<br />
<br />
3 (A:FLAPS HANDLE INDEX, enum)<br />
100 (A:FLAPS HANDLE PERCENT, percent) <br />
19 (L:MyVarA, enum)<br />
19 (L:MyVarB, enum)<br />
<br />
The flaps have been increased to the maximum, 100% position, not just one notch, and both MyVarB and MyVarA are 19. This result seemingly does not make sense. <br />
<br />
Without delaying execution of the initialization sequence, the (>K:FLAPS_INCR) event and it’s associated event trap responsible for incrementing MyVarA, is queued each cycle until the event handling system is ready, at which point the queue is processed ''at once'': the flaps are incremented 19 times as is MyVarA which returns 19, not 1.<br />
<br />
<br />
'''Cycle Counting approach:''' If <Update> is edited to include a cycle skipping delay after aircraft reload (the Event Trap is the same as above),<br />
<br />
<Update><br />
(L:CycleCounter, enum) 20 &lt;=<br />
if{ (L:CycleCounter, enum) ++ (>L:CycleCounter, enum) }<br />
<br />
(L:MyVarA, enum) 0 == (L:CycleCounter, enum) 20 &gt;= and<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
}<br />
</Update><br />
<br />
then the following is obtained. One notch, only, of flaps and both MyVarA and MyVarB are 1. <br />
<br />
1 (A:FLAPS HANDLE INDEX, enum)<br />
33.3 (A:FLAPS HANDLE PERCENT, percent) <br />
21 (L:CycleCounter, enum)<br />
1 (L:MyVarA, enum)<br />
1 (L:MyVarB, enum)<br />
<br />
In this case, the 20 cycle delay provided sufficient time for the event and trap handling system to load before the initialization sequence containing (>K:FLAPS_INCR) was executed. The event trap was processed in the same cycle, incrementing MyVarA from 0 to 1, and thereby shut off the init sequence in the next cycle. The event fire initialization sequence now works as intended.<br />
<br />
<br />
'''Note:''' <Update> could have been written:<br />
<br />
<Update><br />
(L:MyVar'''[[B]]''', enum) 0 ==<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
} <br />
</Update><br />
<br />
and the FLAPS_INCR event and trap would have been triggered and processed only once. For the purposes of this wiki, it was written as (L:MyVar'''A''', enum) 0 == with the incrementer in the Event Trap rather than in Update to shed light on the event handling system delay.<br />
<br />
<br />
<br />
'''Let FS tell you when it’s ready:''' In another [http://www.fsdeveloper.com/forum/threads/fsx-ignores-events-at-flight-loading.429672/ FSDeveloper thread], Rob Barendregt proposed an elegant and more fool-proof method of introducing the necessary delay. He suggests to simply fire an event, in his case, the infrequently used<br />
<br />
CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE<br />
<br />
event, and when its associated simulation variable, <br />
<br />
(A:CABIN SEATBELTS ALERT SWITCH, bool)<br />
<br />
returns 1 that means the sim's event handling system is operating. Following that, his desired initialization events can be executed successfully. <br />
<br />
A slight clarification is that if event traps are included, they will not execute until the cycle following (A:CABIN SEATBELTS ALERT SWITCH, bool) = 1.<br />
<br />
<br />
''' C-code Version: '''A "C" language version of Rob Barendregt's method was written by Dai Griffiths and posted in this [https://www.fsdeveloper.com/forum/threads/gauge-search-priority.442569/#post-796989/ FSDeveloper thread]<br />
<br />
<br />
'''“RACE” CONDITION - CONSTANT EVENT FIRING''' <br />
<br />
As commonly defined in XML related discussions in this forum, a Race Condition is an uncontrolled and likely unintentional, repetitive event firing situation. <br />
<br />
It’s an issue because continuously firing events can cause unforeseen errors across the gauge set and potentially interfere or conflict with other commands being received. Race conditions can adversely affect stream code from <Update> and <Element> sections as well as event code from <Mouse> and <Keys> sections in any gauge, not just the gauge that is firing the event. The culprit gauge (or controller) may be difficult to identify without use of an event logging application. Doubly difficult if your panel contains a mix of XML and C/C++ gauges.<br />
<br />
To mitigate, there are a few best practices to incorporate in XML:<br />
<br />
- Take care when including an event trigger in an <Update> section. Unless its execution is conditional, it will fire continuously. <br />
Add a check, or condition that will limit the event to ''one'' firing only. A good example of such logic is included in this <br />
FSDeveloper post by Roman Stoviak ([http://fsdeveloper.com/forum/threads/setting-fuel-flow-order.430781/#post-677935 see response #16]).<br />
<br />
- Place the event trigger within a mouse click when applicable. That way, the event is sure to be fired only once unless Repeat="Yes"<br />
is invoked for example, in connection with a VOR1_OBI_INC event.<br />
<br />
<br />
'''TOGGLE EVENTS''' <br />
<br />
Event toggles come in two varieties; those that require an argument and those that do not. Most event toggles are of the second type and simply reverse the state of the associated simulation variable. If the variable was “On”, it now becomes “Off”. If it was “Off”, it now becomes “On”. <br />
<br />
The current state of the variable can be tricky to keep track of in a panel where multiple gauges can trigger the same event toggle. To mitigate this, most contributors to this forum suggest instead of using toggles, use _SET, _ON, or _OFF events to explicitly set the state of the variables. TOGGLE events are best avoided or limited to only a single gauge in the gauge set.<br />
<br />
<br />
**<br />
(>K:MIXTURE_RICH) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 100<br />
<br />
16383 (>K:MIXTURE_SET) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 99.9939<br />
<br />
16384 (>K:MIXTURE_SET) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 100<br />
<br />
Consequently, if you want '''100.000%''' full rich, then use (>K:MIXTURE_RICH), best, or 1638'''4''' (>K:MIXTURE_SET), second best.<br />
<br />
A similar situation may apply to other events, but experiment to be sure.<br />
<br />
16383 = 14 bit binary 11 1111 1111 1111<br />
<br />
<br />
''Acknowledgments: Tom Aguilo, Bill Leaming, Paul (Gypsy Baron), Rob Barendregt, Manfred Jahn, Doug Dawson, Roy Holmes, Roman Stoviak, Arne Bartels, Dai Griffiths''<br />
<br />
''[[rpmc]] edited April 2018''<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Events_and_Traps&diff=10541XML: Events and Traps2018-04-15T16:12:16Z<p>Rpmc: </p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = true<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = unknown<br />
| XP9 = unknown<br />
}}<br />
<br />
'''EVENT''' <br />
<br />
An Event is a user-initiated instruction to execute a certain Flight Sim (FS) function. Examples include control surface movement, radio tuning, landing gear retraction/extension, throttle movement, etc. Events are initiated via joystick or other controller, keyboard, mouse, or gauge software. Initiating an event from within one’s gauge software is often referred to as “throwing”, “firing” or “triggering” an event. <br />
<br />
From within XML gauge script, an event is triggered using (>K:EVENT) or <Click Event="EVENT"/> instructions. <br />
<br />
Examples:<br />
<br />
(>K:MIXTURE_RICH) <br />
instructs FS to set all mixture levers to maximum rich. This event does not require a number, or argument, to be passed to it. It’s just (>K:MIXTURE_RICH). The majority of events require no argument.<br />
<br />
8100 (>K:MIXTURE_SET) <br />
instructs FS to set mixture levers to 8100, or about mid range. This is an example of an event that requires an argument. <br />
<br />
<br />
Almost all events have related read-only simulation variables (A:Variables) that change in response to the event’s execution. The simulation variable <br />
<br />
(A:GENERAL ENG MIXTURE LEVER POSITION:''index'', percent) <br />
<br />
is associated with the MIXTURE_SET event. If 8100 is passed to MIXTURE_SET, then the A:Var will return 49.44. (Note: 8100/16383 = 49.44. As per SDK, 16383 is the maximum value allowed for MIXTURE_SET. Its range is 0 to 16383 **).<br />
<br />
<br />
Events are single and instantaneous. Even the smooth increase of the throttle on a game controller is sampled as a series of singular THROTTLE_INCR_SMALL events.<br />
<br />
Event expressions don’t contain Units.<br />
<br />
<br />
The FSX SDK has the complete list in the Events ID section of the [http://msdn.microsoft.com/en-us/library/cc526980.aspx online Microsoft ESP SDK].<br />
<br />
The [http://support.microsoft.com/kb/555857 FS9 SDK can be downloaded here]. Go to the Panels and Gauges link.<br />
<br />
Use the Simconnect Name / String Name entries for XML gauges rather than the Event ID name (containing KEY_) which is used with C++ gauges.<br />
<br />
<br />
'''EVENT TRAP''' <br />
<br />
An Event Trap is gauge code that ‘listens’ for specified events to be triggered. Its purpose is to allow customized, user-defined script to also be executed anytime the specified event is triggered. By nature, it’s conditional: if Event A is triggered, then process the event trap script and then execute the event.<br />
<br />
In XML, the trap is defined using an <On Event> block placed within a <Keys> block:<br />
<Keys><br />
<On Event="LANDING_LIGHTS_TOGGLE"><br />
1 (>L:Sound_Click,number)<br />
</On><br />
</Keys><br />
<br />
The event is LANDING_LIGHTS_TOGGLE. The event trap routine is 1 (>L:Sound_Click,number).<br />
<br />
<On Event> blocks should be placed at the bottom of the gauge script in order to catch all events triggered during each gauge update cycle.<br />
<br />
<br />
<br />
'''EVENT PROCESSING AND XML SCRIPT''' <br />
<br />
All events that are triggered in the current gauge update cycle are queued and then executed sequentially along with their trap routines, if any exist, at the ''end'' of the cycle. All simulation variables (A:Vars) affected by the executed events return updated values on the subsequent cycle.<br />
<br />
<br />
'''Event Traps across the Gauge Set:''' FS processes <On Event> trap routines found in all gauges of the aircraft’s panel (the ‘gauge set’) before coming back to the point where the original event was processed – at the end of the update cycle in the gauge that triggered the event. <br />
<br />
So, if Gauge00 contains the following:<br />
<br />
<Keys><br />
<On Event="PITOT_HEAT_ON"><br />
(L:MyVarA,enum) 10 + (>L:MyVarA,enum)<br />
</On> <br />
</Keys><br />
<br />
and Gauge01 contains:<br />
<br />
<Keys><br />
<On Event="PITOT_HEAT_ON"><br />
(L:MyVarA,enum) 20 + (>L:MyVarA,enum)<br />
</On> <br />
</Keys><br />
<br />
then on the update cycle of the triggering gauge following the PITOT_HEAT_ON event trigger, (L:MyVarA, enum) will return 30.<br />
<br />
<br />
'''Visible Window:''' A condition is that gauges must be in a visible window for their trap routines to be processed. If a gauge is part of a window whose visibility is set to visibility=0, then no <On Event> routines in that gauge will be run until visibility of the window is set to 1, or until the window is made visible on the screen (e.g., drop down menu Views - Instrument Panel - ''Window whatever'').<br />
<br />
Another important condition is that event trap routines in XML gauges are disabled when the user is in External view. Code-fired events still work fine, but their <On Event> capture sections will not. This is a problem for those who like to manage systems (i.e. the autopilot) via keystrokes while flying in External (Spot plane) view. A discussion of work-arounds for this limitation can be found in this [http://www.fsdeveloper.com/forum/threads/events-wiki.430484/#post-675044 EVENTS wiki thread] (see post number 13).<br />
<br />
'''Note:''' A recently released FSX expansion module ('''XMLTools''' v.1.0, June 2014, from Tom Aguilo) will handle ''FSX'' event traps in any view mode, thus overcoming the visible and external window limitations of stock FSX. XMLTools can be freely downloaded from the [http://fsdeveloper.com/forum/resources/xmltools-a-common-xml-expansion-module-for-fsx.131/ FSDeveloper Resources] site. Check that site or FSDeveloper Gauges Forum for XMLTools update notices.<br />
<br />
<br />
'''Events are processed regardless of aircraft type:''' Events and event traps are processed whether or not the event is relevant for the current aircraft. Any SDK defined event can be triggered and executed in any aircraft. The event (>K:TOGGLE_WATER_RUDDER), for example, can be triggered and trap routines processed in an aircraft that is not a float plane. Same thing for helicopter events; their events and traps will be processed in any aircraft. <br />
<br />
As for associated simulation variables, however, following an event the sim will update only those A:Vars that are active for the current aircraft. (A:WATER RUDDER HANDLE POSITION, percent) will return a non-zero value ''only if'' the current aircraft contains water rudders. <br />
<br />
This can be helpful to know because sometimes a user may want to ‘hijack’ an otherwise useless event to accomplish an un-related chore. A recent [http://www.fsdeveloper.com/forum/threads/water-rudder-mod-xml.430240/ FSDeveloper forum thread] discussed use of the default water rudder toggle keyboard assignment (ctrl+W) to actually perform a prop reversing routine in a non-seaplane aircraft. The event trap routine, below, is performed whenever keyboard ctrl+W is pressed. It has nothing to do with water rudders, but that doesn’t matter.<br />
<br />
<Keys><br />
<On Event="TOGGLE_WATER_RUDDER"><br />
(L:Reversing,bool) ! (>L:Reversing,bool)<br />
(L:Reversing,bool)<br />
if{<br />
491 (>K:THROTTLE_SET)<br />
-491 (>K:PROP_PITCH_SET)<br />
}<br />
els{<br />
(>K:PROP_PITCH_LO)<br />
}<br />
</On> <br />
</Keys><br />
<br />
Note: Prop reverse action will simulate correctly only on aircraft whose model and aircraft.cfg file are already appropriately configured, but the <On Event="TOGGLE_WATER_RUDDER"> trap above will always fire the THROTTLE_SET and PROP_PITCH_SET events.<br />
<br />
<br />
'''AIRCRAFT LOAD AND RE-LOAD ISSUES''' <br />
<br />
When an aircraft loads or is re-loaded, gauge script begins running slightly before the sim’s event and trap handling system is operational. Consequently, if events are fired as part of an <Update> initialization sequence, event and trap errors may occur where the events are apparently not processed, or may seem to be processed incorrectly. <br />
<br />
In fact, however, triggered events are queued, and the queued events plus trap routines are processed all together when the event handling system finally becomes functional. The length of delay is variable, on the order of 10s of update cycles, and is dependent upon how and when the aircraft is loaded, cache, where the gauge is defined in the panel.cfg, etc. To deal with this, event triggering in an <Update> initialization sequence should be delayed until the sim’s event handling system is ready.<br />
<br />
There are a couple of approaches to construct the delay. The first invokes a cycle counting routine; the other lets the sim tell you when it’s ready.<br />
<br />
Consider the initialization sequence below. The intention is to set one notch of flaps when the aircraft loads. As written, however, that is not what occurs.<br />
<br />
'''Initialization Sequence:'''<br />
<br />
<Update><br />
(L:MyVarA, enum) 0 ==<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
} <br />
</Update><br />
<br />
'''Event Trap:'''<br />
<br />
<Keys><br />
<On Event="FLAPS_INCR"><br />
(L:MyVarA, enum) ++ (>L:MyVarA, enum)<br />
</On><br />
</Keys><br />
<br />
On my system, nothing appears to happen until the 20th cycle after the gauge initialization sequence starts running, when the following is returned:<br />
<br />
3 (A:FLAPS HANDLE INDEX, enum)<br />
100 (A:FLAPS HANDLE PERCENT, percent) <br />
19 (L:MyVarA, enum)<br />
19 (L:MyVarB, enum)<br />
<br />
The flaps have been increased to the maximum, 100% position, not just one notch, and both MyVarB and MyVarA are 19. This result seemingly does not make sense. <br />
<br />
Without delaying execution of the initialization sequence, the (>K:FLAPS_INCR) event and it’s associated event trap responsible for incrementing MyVarA, is queued each cycle until the event handling system is ready, at which point the queue is processed ''at once'': the flaps are incremented 19 times as is MyVarA which returns 19, not 1.<br />
<br />
<br />
'''Cycle Counting approach:''' If <Update> is edited to include a cycle skipping delay after aircraft reload (the Event Trap is the same as above),<br />
<br />
<Update><br />
(L:CycleCounter, enum) 20 &lt;=<br />
if{ (L:CycleCounter, enum) ++ (>L:CycleCounter, enum) }<br />
<br />
(L:MyVarA, enum) 0 == (L:CycleCounter, enum) 20 &gt;= and<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
}<br />
</Update><br />
<br />
then the following is obtained. One notch, only, of flaps and both MyVarA and MyVarB are 1. <br />
<br />
1 (A:FLAPS HANDLE INDEX, enum)<br />
33.3 (A:FLAPS HANDLE PERCENT, percent) <br />
21 (L:CycleCounter, enum)<br />
1 (L:MyVarA, enum)<br />
1 (L:MyVarB, enum)<br />
<br />
In this case, the 20 cycle delay provided sufficient time for the event and trap handling system to load before the initialization sequence containing (>K:FLAPS_INCR) was executed. The event trap was processed in the same cycle, incrementing MyVarA from 0 to 1, and thereby shut off the init sequence in the next cycle. The event fire initialization sequence now works as intended.<br />
<br />
<br />
'''Note:''' <Update> could have been written:<br />
<br />
<Update><br />
(L:MyVar'''[[B]]''', enum) 0 ==<br />
if{<br />
(>K:FLAPS_INCR)<br />
(L:MyVarB, enum) ++ (>L:MyVarB, enum)<br />
} <br />
</Update><br />
<br />
and the FLAPS_INCR event and trap would have been triggered and processed only once. For the purposes of this wiki, it was written as (L:MyVar'''A''', enum) 0 == with the incrementer in the Event Trap rather than in Update to shed light on the event handling system delay.<br />
<br />
<br />
<br />
'''Let FS tell you when it’s ready:''' In another [http://www.fsdeveloper.com/forum/threads/fsx-ignores-events-at-flight-loading.429672/ FSDeveloper thread], Rob Barendregt proposed an elegant and more fool-proof method of introducing the necessary delay. He suggests to simply fire an event, in his case, the infrequently used<br />
<br />
CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE<br />
<br />
event, and when its associated simulation variable, <br />
<br />
(A:CABIN SEATBELTS ALERT SWITCH, bool)<br />
<br />
returns 1 that means the sim's event handling system is operating. Following that, his desired initialization events can be executed successfully. <br />
<br />
A slight clarification is that if event traps are included, they will not execute until the cycle following (A:CABIN SEATBELTS ALERT SWITCH, bool) = 1.<br />
<br />
<br />
''' C Version: '''A "C" language version of Rob Barendregt's method was written by Dai Griffiths and posted in this [https://www.fsdeveloper.com/forum/threads/gauge-search-priority.442569/#post-796989/ FSDeveloper thread]<br />
<br />
<br />
'''“RACE” CONDITION - CONSTANT EVENT FIRING''' <br />
<br />
As commonly defined in XML related discussions in this forum, a Race Condition is an uncontrolled and likely unintentional, repetitive event firing situation. <br />
<br />
It’s an issue because continuously firing events can cause unforeseen errors across the gauge set and potentially interfere or conflict with other commands being received. Race conditions can adversely affect stream code from <Update> and <Element> sections as well as event code from <Mouse> and <Keys> sections in any gauge, not just the gauge that is firing the event. The culprit gauge (or controller) may be difficult to identify without use of an event logging application. Doubly difficult if your panel contains a mix of XML and C/C++ gauges.<br />
<br />
To mitigate, there are a few best practices to incorporate in XML:<br />
<br />
- Take care when including an event trigger in an <Update> section. Unless its execution is conditional, it will fire continuously. <br />
Add a check, or condition that will limit the event to ''one'' firing only. A good example of such logic is included in this <br />
FSDeveloper post by Roman Stoviak ([http://fsdeveloper.com/forum/threads/setting-fuel-flow-order.430781/#post-677935 see response #16]).<br />
<br />
- Place the event trigger within a mouse click when applicable. That way, the event is sure to be fired only once unless Repeat="Yes"<br />
is invoked for example, in connection with a VOR1_OBI_INC event.<br />
<br />
<br />
'''TOGGLE EVENTS''' <br />
<br />
Event toggles come in two varieties; those that require an argument and those that do not. Most event toggles are of the second type and simply reverse the state of the associated simulation variable. If the variable was “On”, it now becomes “Off”. If it was “Off”, it now becomes “On”. <br />
<br />
The current state of the variable can be tricky to keep track of in a panel where multiple gauges can trigger the same event toggle. To mitigate this, most contributors to this forum suggest instead of using toggles, use _SET, _ON, or _OFF events to explicitly set the state of the variables. TOGGLE events are best avoided or limited to only a single gauge in the gauge set.<br />
<br />
<br />
**<br />
(>K:MIXTURE_RICH) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 100<br />
<br />
16383 (>K:MIXTURE_SET) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 99.9939<br />
<br />
16384 (>K:MIXTURE_SET) results in (A:GENERAL ENG MIXTURE LEVER POSITION:1, percent) = 100<br />
<br />
Consequently, if you want '''100.000%''' full rich, then use (>K:MIXTURE_RICH), best, or 1638'''4''' (>K:MIXTURE_SET), second best.<br />
<br />
A similar situation may apply to other events, but experiment to be sure.<br />
<br />
16383 = 14 bit binary 11 1111 1111 1111<br />
<br />
<br />
''Acknowledgments: Tom Aguilo, Bill Leaming, Paul (Gypsy Baron), Rob Barendregt, Manfred Jahn, Doug Dawson, Roy Holmes, Roman Stoviak, Arne Bartels, Dai Griffiths''<br />
<br />
''[[rpmc]] edited April 2018''<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Units:_How_FS_handles_Units&diff=10468XML: Units: How FS handles Units2017-03-03T16:27:23Z<p>Rpmc: </p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = false<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = false <br />
| XP9 = false <br />
}}<br />
<br />
Thanks go to Tom Aguilo for providing the following information on Units:<br />
<br />
<br />
'''A:Vars'''<br />
<br />
Simulation Variables (A: type) have values saved together with their units' ''flag''. The numerical value saved is always that associated with the default unit of measurement for the appropriate measurement category. The default is what is considered by Flight Simulator as the reference unit in the Metric system.<br />
<br />
Units grouped within the same category maintain a given relationship, or conversion factor, for its reciprocal conversion except Miscellaneous, which generally maintains a 1:1 factor (ie: (A:Light Landing, bool/number/part/enum,etc) all return the same value, 0 or 1 )<br />
<br />
If an ( A: ) variable is written without a unit (ie: (A:Fuel weight per gallon) ) a 0 is returned as the relationship of nothing is of course 0.<br />
<br />
If an ( A: ) variable is written with a unit not corresponding with its category, the value returned means a conversion between the unit defined and the default unit of the category that unit belongs to.<br />
<br />
<br />
'''A:Var Example 1'''<br />
<br />
Suppose an aircraft is holding on Rwy 32L at Chicago O’Hare International Airport. The aircraft altimeter will indicate about 673 feet and (A:PLANE ALTITUDE, feet) will return 672.9. However, the numerical value actually saved is 205.1 which is the value of the altitude measured in the default units for the Distance Category, meters.<br />
<br />
If the unit of measurement is changed to a unit not corresponding to the Distance category, for example, (A:PLANE ALTITUDE, Kelvin), then the number 205.1 is returned because Kelvin is the default unit of measurement in the Temperature Category. On the other hand, (A:PLANE ALTITUDE, Fahrenheit) will return -90.5 because that is the degrees Fahrenheit equivalent of 205.1 degrees Kelvin.<br />
<br />
<br />
'''A:Var Example 2'''<br />
<br />
A:FUEL TANK LEFT MAIN QUANTITY is a volume variable, and the default unit of measurement for volume is cubic meter. For some Cessna 421 sim models, a full left main tank contains 121 gallons (U.S. liquid gallons), so, for that aircraft, with a full left main tank, Flight Sim stores the value 0.458038 into memory (121 gallons=0.458038 cubic meters), together with a flag that says its a volume type of unit. When Flight Sim is asked to display (A:FUEL TANK LEFT MAIN QUANTITY, ''gallons''), then it recognizes ''gallons'' as a volume type unit, applies the cubic meter to gallons conversion, and returns 121.<br />
<br />
However, if Flight Sim is asked to display (A:FUEL TANK LEFT MAIN QUANTITY, ''pounds''), then it assumes this is a ''weight'' variable. The default weight unit is kilogram, so Flight Sim assumes that the 0.458038 stored in memory represents 0.458038 '''kg'''. When it is asked to covert that to pounds, it returns 1.0098 (0.458038 kg=1.0098 pounds), or in other words, (A:FUEL TANK LEFT MAIN QUANTITY, pounds) = 1.0098. This value isn't intuitive and has no meaning because A:FUEL TANK LEFT MAIN QUANTITY is a volume variable, not a weight variable.<br />
<br />
<br />
'''L:Vars'''<br />
<br />
Local Variables (L:type) follow the same logic, although when expressed without a unit, or if expressed using a unit that is not defined by Flight Simulator, no conversion occurs and their values return as literal, taking by default a 1:1 relationship.<br />
<br />
L:Var Example:<br />
1 (>L:Test) or 1 (>L:Test, dogs) then <br />
(L:Test, seconds/minutes/cu meter/number,etc) returns 1<br />
<br />
2 (>L:Test, number) then <br />
(L:Test, seconds) returns 2 because seconds is the default unit in the Time Category<br />
(L:Test, minutes) returns 0.03333 because seconds is the default unit in the Time Category and there are 0.03333 minutes in two seconds.<br />
(L:Test, liters) returns 2000 because cu meter is the default unit in Volume Category and there are 2000 liters in two cubic meters.<br />
<br />
1 (>L:Test, minutes) then <br />
(L:Test, seconds) returns 60<br />
(L:Test, number) returns 60<br />
(L:Test, liters) returns 60000<br />
(L:Test) or (L:Test, dogs) returns 1<br />
<br />
<br />
'''Default Unit of Measurement'''<br />
DISTANCE: meter<br />
AREA: sq m<br />
VOLUME: cubic meter<br />
TEMPERATURE: kelvin<br />
ANGLE: radian<br />
ANGULAR VELOCITY: radian per second<br />
SPEED: meter per second<br />
ACCELERATION: meter per second squared<br />
TIME: second<br />
POWER: watt<br />
VOLUME RATE: meter cubed per second<br />
WEIGHT: kilogram<br />
WEIGHT RATE: kilogram per second<br />
ELECTRICAL CURRENT: ampere<br />
ELECTRICAL POTENTIAL: volt<br />
FREQUENCY: hertz<br />
DENSITY: kilogram per cubic meter<br />
PRESSURE: pascal = newton per square meter<br />
TORQUE: newton meter<br />
<br />
'''No conversion applied'''<br />
SPEED: mach<br />
TIME: year<br />
<br />
'''Not a Pressure Unit'''<br />
PRESSURE: slug feet squared<br />
<br />
'''1 : 1'''<br />
MISCELLANEOUS: part<br />
MISCELLANEOUS: percent over 100<br />
MISCELLANEOUS: times<br />
MISCELLANEOUS: ratio<br />
MISCELLANEOUS: number<br />
MISCELLANEOUS: scaler<br />
MISCELLANEOUS: position<br />
MISCELLANEOUS: enum<br />
MISCELLANEOUS: bool<br />
MISCELLANEOUS: mask<br />
MISCELLANEOUS: flags<br />
MISCELLANEOUS: per radian<br />
<br />
'''Conversion is applied'''<br />
MISCELLANEOUS: per degree<br />
MISCELLANEOUS: half<br />
MISCELLANEOUS: third<br />
MISCELLANEOUS: percent<br />
MISCELLANEOUS: bel<br />
MISCELLANEOUS: decibel<br />
MISCELLANEOUS: more_than_a_half<br />
MISCELLANEOUS: bco16<br />
<br />
'''Non-functional Unit of Measurement (in FSX)'''<br />
DENSITY: pound per gallon<br />
<br />
The system variable (A:Fuel weight per gallon, pounds per gallon) returns 6 in FS9, but the units are not valid in FSX, so the variable returns 0. This is a handy phenomenon, in that the difference can be exploited to distinguish between FS9 and FSX simulations. See wiki<br />
<br />
'''XML: Refreshing Panels in FS9 & FSX'''<br />
<br />
for an example application.<br />
<br />
<br />
'''Non-Numerical value'''<br />
MISCELLANEOUS: string<br />
<br />
[[- rpmc]]<br />
<br />
<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Units:_How_FS_handles_Units&diff=10467XML: Units: How FS handles Units2017-03-02T03:54:08Z<p>Rpmc: </p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = false<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = false <br />
| XP9 = false <br />
}}<br />
<br />
Thanks go to Tom Aguilo for providing the following information on Units:<br />
<br />
<br />
'''A:Vars'''<br />
<br />
Simulation Variables (A: type) have values saved together with their units' ''flag''. The numerical value saved is always that associated with the default unit of measurement for the appropriate measurement category. The default is what is considered by Flight Simulator as the reference unit in the Metric system.<br />
<br />
Units grouped within the same category maintain a given relationship, or conversion factor, for its reciprocal conversion except Miscellaneous, which generally maintains a 1:1 factor (ie: (A:Light Landing, bool/number/part/enum,etc) all return the same value, 0 or 1 )<br />
<br />
If an ( A: ) variable is written without a unit (ie: (A:Fuel weight per gallon) ) a 0 is returned as the relationship of nothing is of course 0.<br />
<br />
If an ( A: ) variable is written with a unit not corresponding with its category, the value returned means a conversion between the unit defined and the default unit of the category that unit belongs to.<br />
<br />
<br />
'''A:Var Example 1'''<br />
<br />
Suppose an aircraft is holding on Rwy 32L at Chicago O’Hare International Airport. The aircraft altimeter will indicate about 673 feet and (A:PLANE ALTITUDE, feet) will return 672.9. However, the numerical value actually saved is 205.1 which is the value of the altitude measured in the default units for the Distance Category, meters.<br />
<br />
If the unit of measurement is changed to a unit not corresponding to the Distance category, for example, (A:PLANE ALTITUDE, Kelvin), then the number 205.1 is returned because Kelvin is the default unit of measurement in the Temperature Category. On the other hand, (A:PLANE ALTITUDE, Fahrenheit) will return -90.5 because that is the degrees Fahrenheit equivalent of 205.1 degrees Kelvin.<br />
<br />
<br />
'''A:Var Example 2'''<br />
<br />
A:FUEL TANK LEFT MAIN QUANTITY is a volume variable, and the default unit of measurement for volume is cubic meter. For some Cessna 421 sim models, a full left main tank contains 121 gallons (U.S. liquid gallons), so, for that aircraft, with a full left main tank, Flight Sim stores the value 0.458038 into memory (121 gallons=0.458038 cubic meters), together with a flag that says its a volume type of unit. When Flight Sim is asked to display (A:FUEL TANK LEFT MAIN QUANTITY, ''gallons''), then it recognizes this as a volume type unit, applies the cubic meter to gallons conversion, and returns 121.<br />
<br />
However, if Flight Sim is asked to display (A:FUEL TANK LEFT MAIN QUANTITY, ''pounds''), then it assumes this is a ''weight'' variable. The default weight unit is kilogram, so Flight Sim assumes that the 0.458038 stored in memory represents 0.458038 '''kg'''. When it is asked to covert that to pounds, it returns 1.0098 (0.458038 kg=1.0098 pounds), or in other words, (A:FUEL TANK LEFT MAIN QUANTITY, pounds) = 1.0098. This value isn't intuitive and has no meaning because A:FUEL TANK LEFT MAIN QUANTITY is a volume variable, not a weight variable.<br />
<br />
<br />
'''L:Vars'''<br />
<br />
Local Variables (L:type) follow the same logic, although when expressed without a unit, or if expressed using a unit that is not defined by Flight Simulator, no conversion occurs and their values return as literal, taking by default a 1:1 relationship.<br />
<br />
L:Var Example:<br />
1 (>L:Test) or 1 (>L:Test, dogs) then <br />
(L:Test, seconds/minutes/cu meter/number,etc) returns 1<br />
<br />
2 (>L:Test, number) then <br />
(L:Test, seconds) returns 2 because seconds is the default unit in the Time Category<br />
(L:Test, minutes) returns 0.03333 because seconds is the default unit in the Time Category and there are 0.03333 minutes in two seconds.<br />
(L:Test, liters) returns 2000 because cu meter is the default unit in Volume Category and there are 2000 liters in two cubic meters.<br />
<br />
1 (>L:Test, minutes) then <br />
(L:Test, seconds) returns 60<br />
(L:Test, number) returns 60<br />
(L:Test, liters) returns 60000<br />
(L:Test) or (L:Test, dogs) returns 1<br />
<br />
<br />
'''Default Unit of Measurement'''<br />
DISTANCE: meter<br />
AREA: sq m<br />
VOLUME: cubic meter<br />
TEMPERATURE: kelvin<br />
ANGLE: radian<br />
ANGULAR VELOCITY: radian per second<br />
SPEED: meter per second<br />
ACCELERATION: meter per second squared<br />
TIME: second<br />
POWER: watt<br />
VOLUME RATE: meter cubed per second<br />
WEIGHT: kilogram<br />
WEIGHT RATE: kilogram per second<br />
ELECTRICAL CURRENT: ampere<br />
ELECTRICAL POTENTIAL: volt<br />
FREQUENCY: hertz<br />
DENSITY: kilogram per cubic meter<br />
PRESSURE: pascal = newton per square meter<br />
TORQUE: newton meter<br />
<br />
'''No conversion applied'''<br />
SPEED: mach<br />
TIME: year<br />
<br />
'''Not a Pressure Unit'''<br />
PRESSURE: slug feet squared<br />
<br />
'''1 : 1'''<br />
MISCELLANEOUS: part<br />
MISCELLANEOUS: percent over 100<br />
MISCELLANEOUS: times<br />
MISCELLANEOUS: ratio<br />
MISCELLANEOUS: number<br />
MISCELLANEOUS: scaler<br />
MISCELLANEOUS: position<br />
MISCELLANEOUS: enum<br />
MISCELLANEOUS: bool<br />
MISCELLANEOUS: mask<br />
MISCELLANEOUS: flags<br />
MISCELLANEOUS: per radian<br />
<br />
'''Conversion is applied'''<br />
MISCELLANEOUS: per degree<br />
MISCELLANEOUS: half<br />
MISCELLANEOUS: third<br />
MISCELLANEOUS: percent<br />
MISCELLANEOUS: bel<br />
MISCELLANEOUS: decibel<br />
MISCELLANEOUS: more_than_a_half<br />
MISCELLANEOUS: bco16<br />
<br />
'''Non-functional Unit of Measurement (in FSX)'''<br />
DENSITY: pound per gallon<br />
<br />
The system variable (A:Fuel weight per gallon, pounds per gallon) returns 6 in FS9, but the units are not valid in FSX, so the variable returns 0. This is a handy phenomenon, in that the difference can be exploited to distinguish between FS9 and FSX simulations. See wiki<br />
<br />
'''XML: Refreshing Panels in FS9 & FSX'''<br />
<br />
for an example application.<br />
<br />
<br />
'''Non-Numerical value'''<br />
MISCELLANEOUS: string<br />
<br />
[[- rpmc]]<br />
<br />
<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_PID_Controller&diff=10448XML: PID Controller2017-02-04T17:21:21Z<p>Rpmc: Created page with "[http://fsdeveloper.com/forum/threads/ap-speed-hold-pid-controller.437633/ AP speed hold PID controller] Thank you to Bjoern K. (Heretic) for providing a detailed explanation..."</p>
<hr />
<div>[http://fsdeveloper.com/forum/threads/ap-speed-hold-pid-controller.437633/ AP speed hold PID controller]<br />
<br />
Thank you to Bjoern K. (Heretic) for providing a detailed explanation and XML example of a PID Controller and consolidating a link list of PID threads authored by various FSDeveloper contributors.<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10438XML: NOT Operator !2016-12-27T18:22:45Z<p>Rpmc: /* NOT Operator ! */</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
''Explanation of the '''[[!]]''' Operator courtesy Tom Aguilo:''<br />
<br />
The NOT Operator, '''!''' (negation sign) acts like a toggle operator. It works by extracting the top value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )<br />
From FSDeveloper thread: [[http://fsdeveloper.com/forum/threads/landing-variable.439017/#post-761124]]<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10437XML: NOT Operator !2016-12-26T16:06:02Z<p>Rpmc: /* NOT Operator ! */</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
''Explanation of the '''[[!]]''' Operator courtesy Tom Aguilo:''<br />
<br />
The NOT Operator, '''!''' (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )<br />
From FSDeveloper thread: [[http://fsdeveloper.com/forum/threads/landing-variable.439017/#post-761124]]<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10436XML: NOT Operator !2016-12-26T16:05:45Z<p>Rpmc: /* NOT Operator ! */</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
''Explanation of the '''[[!]]''' Operator courtesy Tom Aguilo:''<br />
<br />
The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )<br />
From FSDeveloper thread: [[http://fsdeveloper.com/forum/threads/landing-variable.439017/#post-761124]]<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=Units:_How_FS_handles_Units&diff=10435Units: How FS handles Units2016-12-26T16:03:12Z<p>Rpmc: Rpmc moved page Units: How FS handles Units to XML: Units: How FS handles Units</p>
<hr />
<div>#REDIRECT [[XML: Units: How FS handles Units]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Units:_How_FS_handles_Units&diff=10434XML: Units: How FS handles Units2016-12-26T16:03:12Z<p>Rpmc: Rpmc moved page Units: How FS handles Units to XML: Units: How FS handles Units</p>
<hr />
<div>{{Infobox-Applicable-FSVersion<br />
| P3D2 = true<br />
| P3D = true<br />
| FSXI = false<br />
| FSXA = true<br />
| FSX = true<br />
| FS2004 = false<br />
| FS2002 = false<br />
| FS2000 = unknown<br />
| FS98 = unknown<br />
| XP10 = false <br />
| XP9 = false <br />
}}<br />
<br />
Thanks go to Tom Aguilo for providing the following information on Units:<br />
<br />
<br />
'''A:Vars'''<br />
<br />
Simulation Variables (A: type) have values saved together with their units' ''flag''. The numerical value saved is always that associated with the default unit of measurement for the appropriate measurement category. The default is what is considered by Flight Simulator as the reference unit in the Metric system.<br />
<br />
Units grouped within the same category maintain a given relationship, or conversion factor, for its reciprocal conversion except Miscellaneous, which generally maintains a 1:1 factor (ie: (A:Light Landing, bool/number/part/enum,etc) all return the same value, 0 or 1 )<br />
<br />
If an ( A: ) variable is written without a unit (ie: (A:Fuel weight per gallon) ) a 0 is returned as the relationship of nothing is of course 0.<br />
<br />
If an ( A: ) variable is written with a unit not corresponding with its category, the value returned means a conversion between the unit defined and the default unit of the category that unit belongs to.<br />
<br />
<br />
'''A:Var Example 1'''<br />
<br />
Suppose an aircraft is holding on Rwy 32L at Chicago O’Hare International Airport. The aircraft altimeter will indicate about 673 feet and (A:PLANE ALTITUDE, feet) will return 672.9. However, the numerical value actually saved is 205.1 which is the value of the altitude measured in the default units for the Distance Category, meters.<br />
<br />
If the unit of measurement is changed to a unit not corresponding to the Distance category, for example, (A:PLANE ALTITUDE, Kelvin), then the number 205.1 is returned because Kelvin is the default unit of measurement in the Temperature Category. On the other hand, (A:PLANE ALTITUDE, Fahrenheit) will return -90.5 because that is the degrees Fahrenheit equivalent of 205.1 degrees Kelvin.<br />
<br />
<br />
'''A:Var Example 2'''<br />
<br />
A:FUEL TANK LEFT MAIN QUANTITY is a volume variable, and the default unit of measurement for volume is cubic meter. For some Cessna 421 sim models, a full left main tank contains 121 gallons (U.S. liquid gallons), so, for that aircraft, with a full left main tank, Flight Sim stores the value 0.458038 into memory (121 gallons=0.458038 cubic meters), together with a flag that says its a volume type of unit. When Flight Sim is asked to display (A:FUEL TANK LEFT MAIN QUANTITY, ''gallons''), then it recognizes this as a volume type unit, applies the cubic meter to gallons conversion, and returns 121.<br />
<br />
However, if Flight Sim is asked to display (A:FUEL TANK LEFT MAIN QUANTITY, ''pounds''), then it assumes this as a ''weight'' variable. The default weight unit is kilogram, so Flight Sim assumes that the 0.458038 stored in memory represents 0.458038 '''kg'''. When it is asked to covert that to pounds, it returns 1.0098 (0.458038 kg=1.0098 pounds), or in other words, (A:FUEL TANK LEFT MAIN QUANTITY, pounds) = 1.0098. This value isn't intuitive and has no meaning because A:FUEL TANK LEFT MAIN QUANTITY is a volume variable, not a weight variable.<br />
<br />
<br />
'''L:Vars'''<br />
<br />
Local Variables (L:type) follow the same logic, although when expressed without a unit, or if expressed using a unit that is not defined by Flight Simulator, no conversion occurs and their values return as literal, taking by default a 1:1 relationship.<br />
<br />
L:Var Example:<br />
1 (>L:Test) or 1 (>L:Test, dogs) then <br />
(L:Test, seconds/minutes/cu meter/number,etc) returns 1<br />
<br />
2 (>L:Test, number) then <br />
(L:Test, seconds) returns 2 because seconds is the default unit in the Time Category<br />
(L:Test, minutes) returns 0.03333 because seconds is the default unit in the Time Category and there are 0.03333 minutes in two seconds.<br />
(L:Test, liters) returns 2000 because cu meter is the default unit in Volume Category and there are 2000 liters in two cubic meters.<br />
<br />
1 (>L:Test, minutes) then <br />
(L:Test, seconds) returns 60<br />
(L:Test, number) returns 60<br />
(L:Test, liters) returns 60000<br />
(L:Test) or (L:Test, dogs) returns 1<br />
<br />
<br />
'''Default Unit of Measurement'''<br />
DISTANCE: meter<br />
AREA: sq m<br />
VOLUME: cubic meter<br />
TEMPERATURE: kelvin<br />
ANGLE: radian<br />
ANGULAR VELOCITY: radian per second<br />
SPEED: meter per second<br />
ACCELERATION: meter per second squared<br />
TIME: second<br />
POWER: watt<br />
VOLUME RATE: meter cubed per second<br />
WEIGHT: kilogram<br />
WEIGHT RATE: kilogram per second<br />
ELECTRICAL CURRENT: ampere<br />
ELECTRICAL POTENTIAL: volt<br />
FREQUENCY: hertz<br />
DENSITY: kilogram per cubic meter<br />
PRESSURE: pascal = newton per square meter<br />
TORQUE: newton meter<br />
<br />
'''No conversion applied'''<br />
SPEED: mach<br />
TIME: year<br />
<br />
'''Not a Pressure Unit'''<br />
PRESSURE: slug feet squared<br />
<br />
'''1 : 1'''<br />
MISCELLANEOUS: part<br />
MISCELLANEOUS: percent over 100<br />
MISCELLANEOUS: times<br />
MISCELLANEOUS: ratio<br />
MISCELLANEOUS: number<br />
MISCELLANEOUS: scaler<br />
MISCELLANEOUS: position<br />
MISCELLANEOUS: enum<br />
MISCELLANEOUS: bool<br />
MISCELLANEOUS: mask<br />
MISCELLANEOUS: flags<br />
MISCELLANEOUS: per radian<br />
<br />
'''Conversion is applied'''<br />
MISCELLANEOUS: per degree<br />
MISCELLANEOUS: half<br />
MISCELLANEOUS: third<br />
MISCELLANEOUS: percent<br />
MISCELLANEOUS: bel<br />
MISCELLANEOUS: decibel<br />
MISCELLANEOUS: more_than_a_half<br />
MISCELLANEOUS: bco16<br />
<br />
'''Non-functional Unit of Measurement (in FSX)'''<br />
DENSITY: pound per gallon<br />
<br />
The system variable (A:Fuel weight per gallon, pounds per gallon) returns 6 in FS9, but the units are not valid in FSX, so the variable returns 0. This is a handy phenomenon, in that the difference can be exploited to distinguish between FS9 and FSX simulations. See wiki<br />
<br />
'''XML: Refreshing Panels in FS9 & FSX'''<br />
<br />
for an example application.<br />
<br />
<br />
'''Non-Numerical value'''<br />
MISCELLANEOUS: string<br />
<br />
[[- rpmc]]<br />
<br />
<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=NOT_Operator_!&diff=10433NOT Operator !2016-12-26T16:01:27Z<p>Rpmc: Rpmc moved page NOT Operator ! to XML: NOT Operator !</p>
<hr />
<div>#REDIRECT [[XML: NOT Operator !]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10432XML: NOT Operator !2016-12-26T16:01:27Z<p>Rpmc: Rpmc moved page NOT Operator ! to XML: NOT Operator !</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
''Explanation of the '''!''' Operator courtesy Tom Aguilo:''<br />
<br />
The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )<br />
From FSDeveloper thread: [[http://fsdeveloper.com/forum/threads/landing-variable.439017/#post-761124]]<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10431XML: NOT Operator !2016-12-26T15:59:05Z<p>Rpmc: /* NOT Operator ! */</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
''Explanation of the '''!''' Operator courtesy Tom Aguilo:''<br />
<br />
The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )<br />
From FSDeveloper thread: [[http://fsdeveloper.com/forum/threads/landing-variable.439017/#post-761124]]<br />
<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10430XML: NOT Operator !2016-12-26T15:55:41Z<p>Rpmc: /* NOT Operator ! */</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
''Explanation of the '''!''' Operator courtesy Tom Aguilo:''<br />
<br />
The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )<br />
<br />
Reference [http://fsdeveloper.com/forum/threads/landing-variable.439017/#post-761124<br />
/ Tom Aguilo]''<br />
<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10429XML: NOT Operator !2016-12-26T15:53:45Z<p>Rpmc: /* NOT Operator ! */</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
<br />
Explanation of the ! Operator courtesy Tom Aguilo:<br />
<br />
The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_NOT_Operator_!&diff=10428XML: NOT Operator !2016-12-26T15:53:25Z<p>Rpmc: Created page with " == NOT Operator ! == Explanation of the ! Operator courtesy Tom Aguilo: The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last val..."</p>
<hr />
<div><br />
== NOT Operator ! ==<br />
<br />
Explanation of the ! Operator courtesy Tom Aguilo:<br />
<br />
The NOT Operator, ! (negation sign) acts like a toggle operator. It works by extracting the last value on the stack and converting it:<br />
<br />
- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )<br />
- to 1 when it is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10370XML: Stack Example2016-04-25T06:45:37Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx this old blog]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this [http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953 FSDeveloper thread] is a simple XML gauge that can be used to view the stack at any point in an XML script. To understand what the lesser known XML Operators actually do or to Q/C complicated script logic, it is sometimes useful to see the stack, step by step.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10369XML: Stack Example2016-04-25T04:35:52Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx this old blog]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this [http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953 FSDeveloper thread] is a simple XML gauge that can be used to view the stack at any point in an XML script. To understand what the lesser known XML Operators actually do or to Q/C complicated script logic, it is sometimes useful to see the stack, step by step.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10368XML: Stack Example2016-04-25T04:33:44Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this [FSDeveloper thread [http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953]] is a simple XML gauge that can be used to view the stack at any point in an XML script. To understand what the lesser known XML Operators actually do or to Q/C complicated script logic, it is sometimes useful to see the stack, step by step.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10367XML: Stack Example2016-04-25T04:33:15Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this [FSDeveloper thread http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953] is a simple XML gauge that can be used to view the stack at any point in an XML script. To understand what the lesser known XML Operators actually do or to Q/C complicated script logic, it is sometimes useful to see the stack, step by step.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10366XML: Stack Example2016-04-25T04:31:24Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this FSDeveloper thread [http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953] is a simple XML gauge that can be used to view the stack at any point in an XML script. To understand what the lesser known XML Operators actually do or to Q/C complicated script logic, it is sometimes useful to see the stack, step by step.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10365XML: Stack Example2016-04-25T04:27:40Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this FSDeveloper thread [http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953] is a simple XML gauge that can be used to view the stack at any point in an XML script. To understand what the lesser known XML Operators actually do, it is sometimes useful to see how they influence the stack.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10364XML: Stack Example2016-04-25T04:23:24Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this FSDeveloper thread [http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953] is a simple XML gauge that can be used to view the stack at any point in the XML script. To understand what the lesser known XML Operators actually do, it is sometimes useful to see how they influence the stack.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10363XML: Stack Example2016-04-25T04:22:22Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog [http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx]<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this FSDeveloper thread [[http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953]] is a simple XML gauge that can be used to view the stack at any point in the XML script. To understand what the lesser known XML Operators actually do, it is sometimes useful to see how they influence the stack.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10362XML: Stack Example2016-04-25T04:20:53Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
'''STACK GAUGE'''<br />
<br />
Attached to this FSDeveloper thread [[http://fsdeveloper.com/forum/threads/colored-trim-position-in-percent-text-string.437125/#post-741953]] is a simple XML gauge that can be used to view the stack at any point in the XML script. To understand what the lesser known XML Operators actually do, it is sometimes useful to see how they influence the stack.<br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10361XML: Stack Example2016-04-25T04:10:43Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10360XML: Stack Example2016-04-25T04:10:06Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
''[[Acknowledgement:]] Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10359XML: Stack Example2016-04-25T04:09:39Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
[[- rpmc]]<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10358XML: Stack Example2016-04-25T04:08:52Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10357XML: Stack Example2016-04-25T04:08:00Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
''Acknowledgement: Thanks to Tom Aguilo for information on stack structure.''<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10356XML: Stack Example2016-04-25T04:06:33Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack XML operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10355XML: Stack Example2016-04-25T04:05:49Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load/Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10354XML: Stack Example2016-04-25T04:04:24Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10353XML: Stack Example2016-04-25T04:04:09Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10352XML: Stack Example2016-04-25T04:03:48Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10351XML: Stack Example2016-04-25T04:03:26Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
''' '''<br />
'''EXAMPLE 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10350XML: Stack Example2016-04-25T04:02:57Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
<br />
'''EXAMPLE 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10349XML: Stack Example2016-04-25T04:02:32Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''EXAMPLE 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''EXAMPLE 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10348XML: Stack Example2016-04-25T04:01:14Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30. When the stack is full, any new value pushed onto the top causes the bottom value to be removed and discarded<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
The stack is cleared at the beginning of each gauge cycle, or by applying the Clear Stack operator, "c". Of course, also during a panel Load or Reload.<br />
<br />
<br />
'''DIFFERENT STACKS'''<br />
<br />
The stack is shared between <Update> and all of the <Element> set. As well, each <Area>, <On Event> and <On Key> structures hold their own stacks. <br />
<br />
<br />
Acknowledgement: Thanks to Tom Aguilo for information on stack structure<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10347XML: Stack Example2016-04-24T14:25:38Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30.<br />
<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
[[... Work in progress]]<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10346XML: Stack Example2016-04-24T14:25:14Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''MAXIMUM STACK DEPTH'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30.<br />
<br />
'''CLEARING THE STACK'''<br />
<br />
[[Work in progress]]<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10345XML: Stack Example2016-04-24T05:12:40Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
<br />
'''OTHER'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10344XML: Stack Example2016-04-24T05:12:15Z<p>Rpmc: /* Stack examples */</p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
'''OTHER'''<br />
<br />
According to this old blog http://blogs.technet.com/b/engauged/archive/2005/11/08/413947.aspx<br />
the maximum stack depth is 30.<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10343XML: Stack Example2016-04-24T05:07:19Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10342XML: Stack Example2016-04-24T05:06:52Z<p>Rpmc: </p>
<hr />
<div><br />
== Stack examples ==<br />
<br />
'''Example 1'''<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
'''Example 2'''<br />
<br />
[[File:Stack Example.png]]<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=XML:_Stack_Example&diff=10341XML: Stack Example2016-04-24T05:05:33Z<p>Rpmc: /* Stack example */</p>
<hr />
<div><br />
== Stack example ==<br />
<br />
[[File:Stack Example 0.png]]<br />
<br />
<br />
- rpmc<br />
[[Category:Aircraft Design]]<br />
[[Category:Panel and Gauge Design]]</div>Rpmchttp://www.fsdeveloper.com/wiki/index.php?title=File:Stack_Example.png&diff=10340File:Stack Example.png2016-04-24T05:04:04Z<p>Rpmc: </p>
<hr />
<div></div>Rpmc