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.
-
Hi there! I’m thinking of buying the Piston Duke - it sounds like it's an excellent aircraft! From reading the posts above I understand that Black Square are working on updates for compatibility with MSFS 2024, however I couldn't see info that explained whether (for the Duke) these updates will be:
- A native FS2020 aircraft, with fixes to make it play nice with FS2024
- A native FS2024 aircraft but retaining the “legacy” structure file/folder structure. For example the Just Flight Vulcan and Hawk take this approach for their FS2024 versions.
- A native FS2024 aircraft using the new modular structure.
I’m assuming it might be #1 or (hopefully) #2, since the rework required for #3 is presumably significant. Can anyone shed any light on this please? I’d be happier buying the Duke knowing it’ll at least get to some level of native FS2024 support, even if not the full modular structure with whatever bells and whistles that brings.
-
I thought I might see your question over here! I'm glad you were able to make an account. I'm always watching the official forums and AVSIM, even if I do not post there.
The most complete answer I can give is #2.5.
I've been following in Just Flight's lead when it comes to MSFS 2024 compatibility, so our collective users will know what to expect. The first update I will publish for the Dukes, TBM, and Velocity will ensure the aircraft are enjoyable in MSFS 2024 the way I designed them to be. This will include everything you would expect, like graphical tweaking, 2024 avionics, and reverse compatibility bug fixes. I apologize that this has taken me so long, but the challenges presented by major bugs in MSFS 2024 and reverse-compatibility breaking changes have been very frustrating for someone so focused on quality and consistency. Many of these bugs are still present in SU2, so I decided to implement my own workaround, rather than wait any longer.
I ascribe this method "#2.5" in your list, as I will also include walkaround and collision features that were not possible in MSFS 2020. While this does not make use of the 2024 native walkaround features (blue highlights instead of blue dots), my aircraft already implement far more complex behavior concerning doors, engine covers, etc, than the native MSFS 2024 system would allow. This actually gives me far more control than the native walkaround templates, which is theme you will notice in my aircraft in general.
I hope that answers your questions! Please feel free to share this response on the official forums, and thanks for asking. If you decide to join the Duke pilot crew, I'm always here to answer your questions, no matter how obscure and technical!
-
@Black-Square Thanks very much for the speedy and detailed reply! So it's good to know the Duke will be well supported into FS2024 - and I'm pretty much decided on the purchase - I'm looking forward to flying the Duke very soon!
Oh btw the issues I had creating an account here were all of my own making - I had an old account I'd forgotten all about.
Edit: I just went ahead and bought it 😁
-
Thanks for your kind words, both of you. I also realized something else that I should have added. I also do not have any plans to stop supporting MSFS 2020 for the time being. It is clear to me that the majority of my users are, at least presently, still using 2020 for various reasons. I want to ensure that they are well served for the best simulation experience possible.
-
First off, I absolutely love the level of detail of these aircraft. Just wanted to get that said. but I have had some issues with the duke. I bought it off of the msfs 2020 market place. works fine in 2020, but will not transfer. Ive tried putting it in the 2024 community folder, official folder, and nothing has worked. I had bought the caravan the same way and it worked right away, and still does. I don't know what ive done differently or wrong, if i could get some help that would be awesome
-
-
I have the bonanza, baron and king air all from just flight, and i did what everyone's done; enable the 2020 versions. When I purchased the caravan, i did the same thing and it appeared in the selection right away. but with the duke, given that it doesn't need an included aircraft like the rest, i assumed it would just appear but it isn't even in my library. the only dukes that appear are the ones i tried putting in my community, but those don't enable.
@Black-Square If you have any insight that would be awesome
