Black Square Updates for MSFS2024
-
@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
-
Unfortunately, I have no insights to share with you. I can't imagine why one would work and not the other. Unless anyone else has an idea here, I would suggest contacting Just Flight support. They deal with all the installer issues, and I suspect they might know what's going on here.
While I'm not planning on "supporting" the transfer of the Steam Gauge Overhaul fleet into MSFS 2024, we should definitely be able to get the Duke into MSFS 2024 for you asap. It pains me to think about the bugs that it currently has when the 2020 version is just copied over, but hopefully those are mostly just small things that only I notice...
-
All updates to MSFS 2024 will be free. I appreciate your sentiment :)
I saw some confusion regarding the Professional Series after one of my new posts, while we're all discussing things here. Those new aircraft, which some might call "updates" of the Steam Gauge Overhaul Series will not be free, though they will come at a discount for existing owners. The Professional Series aircraft represent around 1,000hrs of work each, and roughly a doubling of the scope of each aircraft. In short, my goal was to create new aircraft that I could be really proud of. The longer story is as follows...
When MSFS 2024 became available, I immediately assessed the difficulty of porting the Steam Gauge Overhaul Series to the new sim. When it became clear that this would take an abundance of effort, if it was possible at all (I was thoroughly thwarted at every turn), I decided it would be far smarter to work on standalone aircraft with loads of new features, rather than spend the same amount of time just to get already aging software into a new simulator that would continue to fight me every step of the way. Creating standalone aircraft frees me of many limitations, increases maintainability drastically, and allows me to focus on new simulation experiences that otherwise would not have happened. I hope the majority of you agree with this approach, but I thought I would take the time to explain it more completely.
