Is it possible to catch the state of events (when they are triggered) in XML?
For example. Somewhere in the code, an event is called 1
(>K:TOGGLE_CABIN_LIGHTS) Is it possible to catch the change in this event and
execute an additional part of the code?
Hello @Mugz If Iām not mistaken, thatās what Input Bindings are for: Model
Behaviors - Input Bindings
(flightsimulator.com)
You can override whatās happening when an event occurs. Regards, Sylvain
and here we are, 3 months later, and Iām not convinced the ānewā InputEvent
support adds anything to the sim at all with regard to āexternalā events (i.e.
key events) at all. Maybe at a pinch you can define 30 lines of XML to create
an XML structure that maps a key event to a ānewā event, but at that point you
havenāt really gained any benefit I can see. The entire stack of Asoboās XML
template-based inputEvent ācodeā ultimately collapses to small fragments of
RPN including e.g. (>K:TOGGLE_MASTER_BATTERY). There is no useful support
provided to actually subscribe to events in the model XML. You can see in
parts of the code where vars may be monitored to detect a change. So the
assumed model is when the actual user input generates a key event, e.g.
clicking a keyboard key mapped to TOGGLE_MASTER_BATTERY, then you need to
detect that event by monitoring the simvar telling you switch state, so there
is no change from before in MSFS, and no equivalent of the FSX event
subscriptions. As far as I can tell, Asobo assumes the user input is entirely
by interacting with the 3d model, hence the design to bundle the āInputEventā
support with the animations etc. I.e. a 3D animated lever in the cockpit may
generate an InputEvent as a result of the user dragging on it. This has made
support for āexternalā events coming into the sim extremely fragile, hence the
broken throttle support in the prior update. The Asobo design is kinda ok if
you just want a Cessa throttle in the cockpit and youād rather write a few
lines defining template vars instead of what probably would have been fewer
lines of actual ModelBehaviour XML/RPN. If you have a custom requirement, then
the fact that Asobo has hidden any new functionality under thousands of lines
of undocumented XML makes new support unusable. The SDK documentation is
simply how to use the Asobo template which is only going to work if you have a
requirement identical to something already in an Asobo aircraft. IMHO this
entire structure is a colossal mistake - it primarily wraps very very few
lines of actual RPN code into THOUSANDS of lines of template XML mainly
branching into every permutation required by the Asobo stock aircraft. Youāre
left with the impression there is ānewā event support but in reality it is
mostly Asobo re-structuring their code for their aircraft.
1 Like
@B21 Your post is indeed just confirming what it has always been in my
opinion. I believe any and all FS SDK have always been designed for the FS
studio development needs to build in-game content first and foremost (if not
only). What is publicly shared is only and has always been only a subset of
what they deem worthy of sharing, based on the assumption of what we need must
be the same as what they need and how they are doing it. NB: Iām not trying
to let you think Iām any āauthorityā about these matters. Iām just sharing my
expertise and knowledge so that I can provide feedback to understand these
questions from a 3rd party devs perspective, what matters to some 3rd party
developers, and how the topic is much more complex than what it seems. NB:
Although the points Iām listing below are conceptual, it doesnāt diminish at
all the great work done with the JS/HTML implementation and I want to make it
clear: the FS2020 Gauges and Systems SDK is just the same as in FSX with less
possibilities for 3rd party developers because of sandboxing. But the FS2020
Gauges and Systems JS/HTML Interface is the modern foundation Iād expect they
document and Iād like they focus on with the 3rd party vendors. This new
foundation is still however based on a certain vision of the 3rd party
developer needs and methods which is still strongly infused by old FSX
standards and there is not much to do to open this to more capabilities. There
are notably a few core concepts needing slight changes, not hard to implement
nor disruptive to the whole, which would radically help breaking some of the
hard-limits 3rd parties are struggling with since FS9 at least. Iāve no doubt
they are actively working everyday with a select few developers but the lack
of transparency is in my opinion really hurting a lot of other 3rd party
developers eager to help contributing to the franchise success. To get
started, FSX is built upon FS9, built upon FS8, etcā¦ Look at the FS2020 SDK
and you still get the FS4 area gauge and system SDK structures and principlesā¦
Given the PR statements and the reality of the gauges and system SDK, you
might believe therefore these antiquated and creativity limiting constructs of
a Pascal/C area might still be considered good enough for FS2020 because they
are kept as-is. Having said this, it is also important to note Asobo did a
marvelous job with the gauge and system āinterfaceā in the form of the JS/HTML
layer. I still donāt understand why they are not just documenting and solely
focusing on this layer instead of trying to build the legacy SDK bridges to
WASM, with a pseudo GDI+ on top of NanoVG on top of their own bare bone (but
sufficient) path tracing API. The truth of the matter is that XP11, P3D5,
FS2020 (to list only the latest) are not much different for many aspects, but
XP11 has a clear differentiator in terms of SDK and I believe it is all rooted
in a very simple explanation which I can see after having been working in this
industry and on several different simulators for decades: - The FS SDK
originate from the internal private headers ACE studio (and maybe even before
them) developers were using for developing the stock aircraft. The only need
therefore was having access to pre-digested events and variable suitable to
binding with a 3D animation or a panel gauge element. The first public SDK was
just the same header files āsanitizedā from internal private things. The idea
most likely was if this was good for us building our own aircraft, it is good
for 3rd parties building theirs. And todayās is not different: if this is good
for Aerosoft building the CRJ, it is good for all developers (Jorgās comment
several Q&As; ago). - The X-Plane SDK originate from the same need to build
aircraft but it was thought first and foremost for 3rd party developers, in a
way which is not shielding the developer form the internal core simulation.
Over time it has grown larger and bigger with an increasing number of simvars
but few more API functions because of the simple reason there is no need for
more: in giving access to low level API and constructs form the get go, there
is no need for XPlane devs to provide add-ons developers with new functions
anytime there is a need for something new, because the low level access
already in place gives you access to this directly. Please understand Iām not
saying XP11 is superior to FS2020 or P3D, Iām just saying the SDK is superior
because it lets developers doing what they do best: create new stuff the
simulation developers canāt envision nor provision in advance for you. And in
this department, at least for gauges and systems, Iām afraid to say FS2020 is
a step back from P3D let alone XP11. In my opinion, the reason X-Plane is
vastly superior to any other FSX, FS2020 or Prepar3d simulator in the gauges
and system department is simply because: - XP11 is exposing dozen of
thousands low level fine grained data points, whereas FS is exposing a mere
couple thousand pre-digested pre-filtered values. The former is the equivalent
of low level data probes from within the very core of all these systems
simulations, the later is equivalent to what is needed to drive gauge needles
and lights in a cockpit only. - XP11 is not limiting creativity in giving
direct access to the Video Card silicon right in the context of the rendering
loop, FS is shielding the add-ons from the rendering loop and from the
hardware therefore with lower perfs. - XP11 is not imposing a graphics API
but the core video card OpenGL layer, FS is only giving add-ons a software
based blit function (most likely a memcpy to a RAM backing store for a VRAM
texture) and a bunch of path drawing APIs we donāt know anything about their
latency, resources and performance impact. - XP11 is letting add-ons being
called back on the frame, the simulation, the panel, the rendering update
loops, FS is limiting add-ons to whatever it is it limits add-ons to with no
latency guarantee when using SimConnect - XP11 data and event system is
based on a comprehensive override and callback system (which would make the
10deg increment bug a no question at all) whereas FS is not letting any add-on
interposing in the middle, which is directly depraving FS customers from a
certain number of add-on types, and/or a certain number of add-on features. -
Prepar3D 4 and 5 at least, are offering lower level access to some core
internal simulator architectural elements and data, but is still suffering
from the same FS4 area SDK heritage regarding simvars and APIs. - FS9 to
P3D5 are not sandboxing the add-ons and can therefore be augmented with all
the missing features. The Reality XP GNS and Reality XP GTN are examples of
products augmenting all these simulator versions with a complete simvar
override system, autopilot override system, and much more. This is mandatory
in order to make these products available in the āFlight Simulatorā type of
simulators, whereas the same Reality XP products are implemented solely on the
XP11 SDK with no hacks whatsoever. - FS9 to P3D5 and XP9 to XP11 are all
running add-ons in the process address space and experience shows professional
add-ons developers are doing it right and poses no risk to the simulator
stability whatsoever in general. FS2020 sandboxing for stability argument is
questionable therefore. Fundamentally what is needed in my opinion is quite
simple: - JS/HTML for everything presentation - JS and/or WASM for
everything computation - JS <=> WASM pipe for communication between the two
- Overriding and interposing any event and data - SIM (JS and/or WASM) <=>
External apps Simconnect, why not, but no guarantee to latency or throughput.
Better letting 3rd party build their own transport atop low level data sharing
if they need/want (needing ShareMemory and/or Sockets) - Getting rid of
most, if not all, ancient SDK concepts Enums for vars instead of plain text
really? Have you seen this SDK update causing a mess when someone thought it
was a good idea to alphabetically sort the legacy enumsā¦ and how these
constructs of the past are limiting the expansion, like user events using
number ranges which makes them non usable in any add-on because you never know
if another addon is using the same range as you?
very agree to this, the case of inputevent is weird, and we ended up using
this only for tooltip, as the aircraf entire logic, behaviour, animation,
audio control, event handlingā¦ is best to be handled by wasm or js, its
proper language, its well known, its easier, its debugable and its more
readable we dont need RPN, we dont need modelbehaviordef xml, even worse is
InputEventā¦ huge xml template nested with another template is hellā¦ its
faster to code proper logic or handler in js than searching how to use built
in template, so why not just get rid of those template just provide proper and
generic API for JS and wasm, its a simple as : get var, set var, trigger
event, handle event
Iām STILL confused whether the MSFS āInputEventā support adds anything to the only part that was missing in MSFS which is the ability to āsubscribeā to a user input event. The mystery is why do the SDK docs refer to a long list of Input Event Keys if you canāt do anything with them anyway? I fell like Iāve missed something but thereās still no example I can find from anyoneās code that theyāre listening for some MSFS event and doing something about it.
E.g. I might want to āsubscribeā / ālistenā whatever for the FLAPS_INCR event listed in the SDK docs 'event keys section.
(i) is that even possible? Or has nothing changed in MSFS and you actually need to monitor some simvar like FLAP HANDLE POSITION and trigger your code when that changes.
(ii) if it is possible to detect that key event before it has impacted MSFS, is it even possible to stop it propagating? Everything I can see in MSFS is you canāt detect a user FLAPS_INCR event (e.g. they just hit F7) until it has already had the underlying effect and you actually need to detect that.
I feel like I must have completely misinterpreted the docs - it certainly seems to list a whole load of ākey event idsā you could āhandleā which looks positive but there are only examples that show custom new interactions in the cockpit nothing to do with those listed key events which seems less positive.
1 Like
As per the documentation on Model Behaviors (flightsimulator.com)
- Input Events allow you to intercept key Event IDs in order to force them to go through the Input Eventās code rather than the normal C++ code.
NOTE: This also means that you can disable some key events, or add some XML code to keys (By intercepting them, running your XML code, then calling that Key again
Lol exactly. The docs donāt seem related to the implementation. Thereās no code I can find that gives you that capability at all.
E.g.
Intercept FLAPS_INCR (e.g. user hit F7)
Execute RPN ā77 (>L:MYVAR)ā
Donāt have the sim change the flap setting.
Surely that would be a very short entry in the model XML if the capability existed but as far as I can see the reference info omits any method that would enable you to do that.
There is a lot of other useful info about using XML templates for your custom instruments and making new custom events, but TBH thatās a bit of value-add onto something we can do already rather than the provision of some new stock event intercept capability.
For example, the support could be
<InputEvent>
<CAPTURE_EVENT>FLAPS_INCR</CAPTURE_EVENT>
<ANIM_CODE>77 (>L:MYVAR)</ANIM_CODE>
<PROPAGATE>0</PROPAGATE>
</InputEvent>
but if thatās not it (obviously it isnāt) what is?
An example:
<UseInputEvent ID="PROCEDURE">
<INPUT_EVENT_ID_SOURCE>PROCEDURE</INPUT_EVENT_ID_SOURCE>
<IE_NAME>EMERGEAR</IE_NAME>
<SET_ARG_COUNT>1</SET_ARG_COUNT>
<BINDING_SET_0>L0</BINDING_SET_0>
<BINDING_SET_0_PARAM_0>2</BINDING_SET_0_PARAM_0>
<BINDING_SET_0_EVENT_ID>GEAR_EMERGENCY_HANDLE_TOGGLE</BINDING_SET_0_EVENT_ID>
<BINDING_SET_0_EVENT_ID_ONLY>True</BINDING_SET_0_EVENT_ID_ONLY>
<INC_CODE>1 (>B:#INPUT_EVENT_ID_SOURCE#_#IE_NAME#_Set)</INC_CODE>
<DEC_CODE>0 (>B:#INPUT_EVENT_ID_SOURCE#_#IE_NAME#_Set)</DEC_CODE>
<SET_CODE>1 (>B:LANDING_GEAR_FN333_EMERGEAR_Toggle)</SET_CODE>
</UseInputEvent>
This snipped will override GEAR_EMERGENCY_HANDLE_TOGGLE.
In my case, I am using SET_CODE to send a B: InputEvent. But that is RPN and anything can go there.
2 Likes
See
āInput Bindingsā in the docs Model Behaviors and then there are some helper templates as shown by MariopilotPD808 above (ASOBO_GIE_Base, which other IE templates use).
Thanks very much. Is there an XML <InputEvent> definition somewhere else with the ID āPROCEDUREā that this <UseInputEvent> is referencing? Given my āFLAPS_INCRā example Iām trying to get to the minimalist base-level code that will detect when the user has hit F7 (assuming they have F7 ā FLAPS_INCR). You can see how this is really hard to get to but your example is by far the best clue so far.
Iāll see what I need to add to this to get it to actually work (maybe Iām being pessimistic):
<UseInputEvent ID="PROCEDURE">
<BINDING_SET_0_EVENT_ID>FLAPS_INCR</BINDING_SET_0_EVENT_ID>
<BINDING_SET_0_EVENT_ID_ONLY>True</BINDING_SET_0_EVENT_ID_ONLY>
<SET_CODE>77 (>L:MYVAR)</SET_CODE>
</UseInputEvent>
I donāt think Iām crazy, any normal programming environment would explain some basic concept in a couple of lines. For example, in FSX:
<Keys>
<On Event="FLAPS_INCR">77 (>L:MYVAR)</On>
</Keys>
itās odd this is so hard to do in MSFS if the support exists. I get that Asobo are proud of all the templates value-add but that shouldnāt make it essentially impossible to do a simple event subscription.
Regarding my template, IU think that a minimalist version will look like this:
<UseInputEvent ID="PROCEDURE">
<INPUT_EVENT_ID_SOURCE>PROCEDURE</INPUT_EVENT_ID_SOURCE>
<IE_NAME>EMERGEAR</IE_NAME>
<SET_ARG_COUNT>1</SET_ARG_COUNT>
<BINDING_SET_0>L0</BINDING_SET_0>
<BINDING_SET_0_EVENT_ID>GEAR_EMERGENCY_HANDLE_TOGGLE</BINDING_SET_0_EVENT_ID>
<BINDING_SET_0_EVENT_ID_ONLY>True</BINDING_SET_0_EVENT_ID_ONLY>
<SET_CODE>1 (>B:LANDING_GEAR_FN333_EMERGEAR_Toggle)</SET_CODE>
</UseInputEvent>
I am unsure if you can remove SET_ARG_COUNT.
You may use other EventID souces than PROCEDURE.
PARAM_0 can be used to pass parameters to your RPM if needed (you call it back with āp0ā in the RPN). Useful if you tie multiple EventIDs within the same binding set (e.g. INC & DEC)
2 Likes
Thanks again very much for this hugely useful information, which works great. Recently I had the stamina to work backwards through the templates and ultimately settled on this similar minimalist XML, based on yours:
<UseInputEvent ID="ASOBO_GIE_Base">
<BINDING_SET_0_EVENT_ID>MAC_CREADY_SETTING_INC</BINDING_SET_0_EVENT_ID>
<INPUT_EVENT_ID_SOURCE>GF</INPUT_EVENT_ID_SOURCE> <!-- INPUT_EVENT_ID_SOURCE+IE_NAME form unique ID for this entry. -->
<IE_NAME>MC_INC</IE_NAME> <!-- as above, simply used to extend INPUT_EVENT_ID_SOURCE -->
<INIT_CODE>0 (>L:B21_TEST_INC)</INIT_CODE><!-- RPN executed on plane load -->
<SET_CODE>(L:B21_TEST_INC) ! (>L:B21_TEST_INC)</SET_CODE> <!-- RPN executed when event occurs -->
<BINDING_SET_0>L0</BINDING_SET_0> <!-- required as not defaulted in template -->
</UseInputEvent>
Not much difference except the <UseInputEvent ID="PROCEDURE"> simply calls a template in
fs-base-aircraft-common/ModelBehaviorDefs/Asobo/Common/Inputs/Common_Inputs.xml
that fails to match the āPROCEDUREā ID with āAUTOSTARTā, āGEAR_CONTROLLED_CIRCUITā and āALL_LIGHTS_TOGGLEā and then drops through to template āASOBO_GIE_Baseā in
fs-base-aircraft-common/ModelBehaviorDefs/Asobo/inputs/Generic.xml
This worked using a stock MSFS event (in this case MAC_CREADY_SETTING_INC) but for those I canāt see any relevance to the <INC_CODE> or <DEC_CODE> parameters.
2 Likes