Hi, just a quick question to see if this SDK page is still being worked on? It could use some explanation on how to actually make any of the interactions perform a function. Right now, it helps you make a button/switch/lever move, but doesn’t tell you how to make it set simvars or key events
1 Like
+1 for the question - these templates are a good attempt at value-add but the simple core functionality in the sim can get obscured. TBH I can’t even see how the basic ‘button’ template makes an animation move so the OP is way smarter than me there.
The ‘simple interaction template’ might be a common base (map a clickspot to a node, detect the click, execute some RPN) but that’s actually difficult to work out from the docs (below). Some docs API that has you clicking through template after template to try and work out what each template is actually for and what arguments it may or not need is pretty awful (sorry).
I do understand how these templates are designed to help people who otherwise would struggle to program a multi-position switch but IMHO it would be more optimal to have much better documentation for the half-dozen (max) basic templates from which pretty much any other gauge/animation programming could be derived, and then best efforts on the huge volume of other optional templates.
2 Likes
Any news on this?
Apologies for not diving into this topic earlier - I think B21’s statement here is very true. I’ll talk to the appropriate team and see if they can identify the most relevant templates that could then have some kind of full explanation and use cases in the documentation.
Best regards,
Eric / Asobo
I just checked with our Technical Writer and as far as he knows there was no further information provided by the team in charge of this aspect of the sim. Suggestions (as that made by B21) as to how it should be improved are welcome.
Best regards,
Eric / Asobo
1 Like
If it’s any help at all, I grepped which XML templates were used on two of our most complex planes, and removed the ones used specifically for some embedded stock instrument:
<UseInputEvent ID="ASOBO_GIE_Base">
<UseTemplate Name="ASOBO_GT_Update">
<UseTemplate Name="ASOBO_GT_Anim">
<UseTemplate Name="ASOBO_GT_Visibility">
<UseTemplate Name="ASOBO_GT_Interaction_LeftSingle_Code">
<UseTemplate Name="ASOBO_GT_Interaction_WheelAndContinuousLeft_LeftSingle">
<UseTemplate Name="ASOBO_GT_Interaction_WheelLeftDrag_Axis">
<UseTemplate Name="ASOBO_GT_Knob_Finite_Code">
<UseTemplate Name="ASOBO_GT_Knob_Infinite">
<UseTemplate Name="ASOBO_GT_Knob_Infinite_Push_Timed">
<UseTemplate Name="ASOBO_GT_Lever_DraggingWheelLeftDrag_Axis">
<UseTemplate Name="ASOBO_GT_Lever_DraggingYAxis_Code">
<UseTemplate Name="ASOBO_GT_Material_Emissive_Code">
<UseTemplate Name="ASOBO_GT_Part_ID_Subtemplate">
<UseTemplate Name="ASOBO_GT_Push_Button">
<UseTemplate Name="ASOBO_GT_Switch_3States">
<UseTemplate Name="ASOBO_GT_Switch_Code">
<UseTemplate Name="ASOBO_HANDLING_Wheel_ElevatorTrim_Template">
You can see there’s a certain logic to this (unplanned) selection, although with some (unplanned) overlap. The set captures the functionality required for
- RPN code unrelated to any particular node or animation (ASOBO_GT_Update)
- RPN-controlled animations incl. just with a single variable (ASOBO_GT_Anim)
- RPN-controlled node visibility (ASOBO_GT_Visibility)
- Event capture → RPN execution (ASOBO_GIE_Base?)
- Combinations of click / mouse scroll up/down/drag node input capture → RPN execution, probably with overlap.
- The trim template is an oddity required to reverse the input reversal.
I haven’t worked out yet what’s added in terms of base-level template support in 2024 - in general my starting point is to try and work out what new functionality, if any, is being provided. This can easily be obscured by a desire to explain how flexible the usage can be for a given template. E.g. creating a component that simply runs some RPN when the THROTTLE_SET event is captured is not possible to work out from the docs (Model Behaviors Inputs)
I’d like to suggest the other issue that can obscure the base level functionality is higher-level templates assume the existence of nodes and animations without any specification of what those animations should be or whether it’s reasonable to not have that animation. For example common ‘switch’ templates that e.g. allow push and rotate assume the existence of push and rotate animations. Should we be using the MouseRect/MouseFlags for that?
1 Like
I have spent many hours looking through all the EX1 model behavior code trying to figure out how to effectively use interaction templates and how they use or create input events.
I can understand how to use parameter functions but it is not clear which parameters can be used from the built-in behavior functions and where we need to create custom input events.
Two particular areas where I am having difficulty is with a flap lever and magneto/starter switch. There doesn’t appear to be a handling template for flaps control and my attempt at using a lever interaction template only moves the handle but doesn’t activate the flaps. The behavior debugger shows no flap event bindings so I am left to wonder how it is supposed to use the correct input event.
My suggestion is to add more examples in the documentation from another Asobo-authored aircraft. The c172 seems to be one of the most complete aircraft. If we could see how the behavior code is constructed, it would help developers build out all the basic functions. The DA62 sample is good but does not cover everything.
This is probably asking a lot from the SDK team where the complexity of the behavior code falls on a different development team. This is why working examples where an aircraft developer has already solved the interactions are useful. With the VFS Projector, we can only get the compiled behaviors which no longer have references to the original templates.
2 Likes
Hello,
From what I understand of all the topics that are open on this forum, the teams of Dev and those who deal with the SDK are separate teams without much connection between the two: the team working on the SDK seems to be based on the work of the first team.
I worked for 38 years in a world company that produced military software (developer then adm and finally integration project manager) and for each new project (which lasted 7 and 15 years) we always had the creation of a framework and then the developers used this framework to develop the product.
In your case, I have the distinct impression that the opposite is perhaps due to your iterative development process which forces the SDK team to follow what developers do: the framework is created after a working release and this explain a lot of things. With this kind of policy, the SDK is never up to the releases.
Between 2020 and 2024 I spent all my time (I’m retired) to understand how FS20 worked and I think I know it quite well now. If we have to do “the same path of penance” to learn FS24, the solution I consider is to leave completely FS24 for 6 months or even 1 year and use the means FS20 that are known and work quite well now.
When FS24 and its SDK will be mature, I’ll see if it is conceivable to change the way of doing things. Unfortunately I think many freeware and payware developers will do the same unless your priority changes by then which would be surprising considering the positions of the Asobo stakeholders who answer our questions.
To be pragmatic and without giving you advice, having an aircraft like a C172 that could be used effectively as an example with its well-documented code (also Model Behaviors) would already be a good start and could satisfy all those who cannot have access to the sources as was previously the case in previous versions of the simulators Microsoft.
My 2 cents 
3 Likes
REF:
I worked for 38 years in a world company that produced military software (developer then adm and finally integration project manager) and for each new project (which lasted 7 and 15 years) we always had the creation of a framework and then the developers used this framework to develop the product.
In your case, I have the distinct impression that the opposite is perhaps due to your iterative development process which forces the SDK team to follow what developers do: the framework is created after a working release and this explain a lot of things. With this kind of policy, the SDK is never up to the releases.
100% agree …I have a similar background.
Ref “Framework”
(1) Design Spec
(2) Test Spec
(3) Then start coding to the design spec, ensuring that design can be tested to the test spec,
As opposed to the typical amateur, hobbyist programmer who
(a) Start coding with some vague idea of what might be cool
(b) See what can be done, and what evolves
(c) Release at some point
(d) Deals with testing to a test spec and documentation later-- if ever…
Most Game development is obviously VERY different to Commercial or Military software development. --( so are the development cost ) - and the final product’s reliability !!
Bring this full circle , back to the question
Is MSFS a “SIMULATOR” or a “GAME”, or is it trying to be both at the same time, and failing to fully achieve either ?
Yes, MSFS is a “GAME” but it’s also a software which need to be developed with some good pratices.
It is obvious that the practices and the heavy processes in the military field cannot be applied as such but even in the military field we have done prototypes to validate certain concepts and in this case we used processes Light but still rigorous so that we can have a good traceability of what we were doing.
According to some readings, following the acquisition by Microsoft of a company that specialized in AI, Microsoft would have asked Asobo to integrate these new functions. This would have happened in the first quarter of 2024 and therefore given the delays, it would explain why the release of MSFS2024 was delayed and especially the status of this version which is absolutely not a successful version.
I understand that the release of MSFS2024 before Christmas was an essential milestone but why break the milestones less than 6 months before the release of the product? Money ?