Black Square Updates for MSFS2024
-
Hi, It's been more than 2 months since MSFS 2024 released. We were promised a free compatible version of the Dukes. I know there were some showstoppers at the beginning. Are they still present? Why is there still no officially compatible version for 2024?
-
@meurkel Probably because MSFS 2024 is FUBAR right now and any attempt to release an official supported version is a waste of everyone's time. Drop the duke in the 2024 community folder and see if it works for you.
And where did the dev ever promise we would get a free official 2024 compatible version of any BSQ addons? -
I cannot wait for the update , black square has the best planes.
-
Will the Starship come to 2020? Any other 2020 updates? I realize the trend will move to 2024 over time, but for now the newer sim is troublesome and unstable. Also, will the King Air be brought to 2024? I know a lot of users want a King Air update. You have a lot of Black Square fans in the V1 Simulations Discord, including myself. We're currently doing a Duke tour: https://www.youtube.com/live/PXDDOUBrLhQ?si=H1O5K7PqfxAUOj74
Nvm, I see where the Starship will be released on both. Excellent news! I'm waiting for 2024 to become stable before I switch, so I'm glad to pay a smaller fee for both sims on any developed/updated aircraft.
-
Looking forward to the professional versions of the Caravan, Baron and Bonanza.
Just hoping the flightmodels also get a "professional" upgrade. These seemed to have been taken over from the default planes with some small tweaks. Especially with the single engine planes like the caravan who lack some proper engine torque (just take a look at the SWS Kodiak 100).
With all the features added and hopefully Career mode added in the future i would happily pay full price again for these addons.
Cheers,
André -
Of course, Black Square would be the one to pull off the insanity that is a PT6'd Bonanza. đŸ¤£
Thanks for making them for 2020 as well. I honestly can't wait to throw my wallet at you again.
-
How is it with the TBM 850 and the Dukes, still a long way to go for official 2024 versions?
-
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.
