Black Square Updates for MSFS2024
-
Hi All,
I just wanted to give you a quick update to say that I have been finally working hard on MSFS 2024 compatibility and new MSFS 2024 features for my existing standalone aircraft and upcoming releases. I am hoping to have them ready to coincide with the marketplace arriving in MSFS 2024, but I also have some travel coming up during the same window. All of those aircraft are now MSFS 2024 ready, with the exception of one issue that may be out of my control. I was hoping the custom exterior registration system would be fixed in SU1, but since that didn't come to pass, have started trying to raise the issue with Asobo myself. I can get the exterior registration to work consistently, so long as you do not preview the aircraft in the aircraft selection configurator menu, which leads me to believe this is a simulator problem, as opposed to a model/materials problem.
Thank you all for being patient with us developers as we work through these MSFS 2024 compatibility issues. It's been very hard to predict which issues would be fixed quickly by Asobo, and which have required us to create our own solutions. Luckily, the issue I mention above, along with small differences in how materials and lights are rendered between the two simulators, seem to be all that remains for my aircraft.
Thank you!
Nick C. -
Thanks for your had work! I'm happy to be one of the lucky folks who has the Turbine Duke, TBM, and Caravan working quite well in 2024 -- but looking forward to compatibility updates as well as the Professional series!
-
@Black-Square Great news, personally the two feature I'm hoping most for, except for developer-certified compatibility, are updates to the new hardware binding system in MSFS2024 (with all buttons and knobs being bindable and animated) and also rerouting to the new ´24 versions of the GNS'es.
Is this something we can expect for the first round of updates to '24?
-
@GunStrauss I'm glad you're looking forward to it. All avionics options will be updated to their latest MSFS 2024 versions, including the GNS 530/430. Unfortunately, I don't know what this new hardware binding system is that you're referring to. If you give me some information, I can look into it.
-
It seems like all binding events has the default suffix'es _inc, _dec _set, _on, _off and _toggle, and in MSFS 2024 they can be sent from external applications such as MobiFlight and Spad.next: https://devsupport.flightsimulator.com/t/enumerateinputevents-doesnt-return-inc-dec-toggle-on-and-off-events/6598
These events can also be mapped in the internal control mapping system in MSFS 2024, so it seems like there should be no problem with hardware mapping in the future, as the internal system can map everything and it can also be accessed from external applications.
Examples of _inc, _dec and _set:
https://docs.flightsimulator.com/html/Content_Configuration/Models/ModelBehaviors/#IncI'm now able to map everything in the default airplanes, while also having all the knobs and switches animated.
-
@Black-Square, seems like the URL to the SDK does not work, but the input system that can be used for animation, internal and external mapping (as well as tooltips) is explained in the SDK under: Model -> Model Behaviors -> Input Event Definitions:
The goal when creating an Input Event is to shift the code complexity outside of the <MouseRect> - which defines what to do based on the user interaction with a knob or button, etc... - and into the input event <Preset>. This greatly simplifies interactions as you only have to define some aliases to do the job most of the time, and it also simplifies animations since you can simply retrieve the input event value and base your animation on that instead of looking for the SimVar state which can get quite complicated quite rapidly. The added bonus is that input events are only executed when they are needed, so it's far cheaper to get an animation value using the cached value inside the input event rather than recalculating it every frame in the animation code."
The principle behind the InputEvent system is the creation of one or more <Preset> elements, where each element has a unique ID with which it can then be referenced elsewhere in the model behavior. If you want to define an InputEvent preset the principle elements that you'll be required to create will be:
<Inc>, <Dec>, <Set>: These elements are what govern the logic of what the InputEvent preset does as well as its bindings. These are obligatory elements as without them the preset won't register the user input correctly.
<Value>: If defined, this element will associate a value to the InputEvent preset which can be used to keep a state in memory (either a number or a string).
<Tooltip>: If defined, this element will associate data that can be used to display some information about the event.
It is also worth noting that you have the B: variable for use in these elements to modify the value of an input event using Reverse Polish Notation. When using B: you would supply the <Preset> ID with the operation you wish to perform appended onto it. For example, to increment the preset "Sound_COM1_Volume" you would have some RPN like this: -
Thanks for the context. That is what I thought you might be talking about, but I wasn't sure, since B:Vars exist in MSFS 2020 too. Unfortunately, the XML resources available to us developers for implementing the B:Vars are not well documented, and require an immense amount of additional programming and testing to implement. For example, it takes me 233 lines of code to create a B:Var for the two-position condition lever in the Turbine Duke, which could otherwise be accomplished with a single L:Var in one line. I have been very sparing with my use of B:Vars and overriding native K:Events, because it's also easy to cause unintended behavior with all the different hardware being used.
I have not seriously considered moving my aircraft over to a B:Var centric interaction system instead of L:Vars, and I will likely not do so unless I have a lot more requests for this feature. I know it must be convenient for some users, but I have found that most of my userbase is already very familiar with programming for L:Vars in third party binding software. I will remember your suggestion the next time I hear a request for B:Var support, so I don't want you to think that I'm ignoring your suggestion. Talking with you guys here is how I learn what people are looking for, and how to best implement it, so I always appreciate your thoughts.
-
Understand, and you're right, the system you have now works very well, maybe except for the GNS'es where button animation is not currently possible when hardware mapping the button and knobs.
-
I haven't tried it myself, but I think that might actually depend on the aircraft. I would expect the Dukes to have B:Vars for the GNS's, but the knobs might not work with B:Vars in my older aircraft. It's a long story, but it's actually because of the sound that I had to overwrite the default knob code in my older aircraft. In general, the further the level of abstraction in code, the harder it can be to get out of corner cases, and the default GNS behavior templates were a great example of that.
