Undocumented LVARs not a sign of lack of commitment from Black Square
-
I have done some work to map homemade external switches for Bonanza and Baron and what I see is not Black Square having a lack of commitment to LVARs but rather Asobo.
People have to realize that specific aircraft panels are a mixture of locally-defined switches and instruments totally written by the aircraft developer and instrument templates imported from the Asobo core. And a depressing number of Asobo core templates make no provision for external control. My impression is that beyond the basic yoke and throttle, and the limited list of standard sim events, Asobo is mostly happy with mouse control.
Of course all of the aircraft and Asobo template code is there to examine and sometimes a 'hook' that provides both switch action and animation can be found. But too often this requires deep dive through the templates through an inconstant world of sorta-documented K:, L:, and A: vars into the undocumented nether world of B:, O:, H:, and XML vars.
Take something seemly simple like Prop Deice switch which is imported unmodified by BKSQ and defined by "ASOBO_DEICE_Switch_Propeller_Template" . Controlling the deice with K:TOGGLE_PROPELLER_DEICE works - the Amps go up - but the switch does not move. If you want to move the switch animation you need to go all the way down to (B:DEICE_Propeller_1, Number) using a complicated tool like AAO. Is this an Asobo template bug? Is it a design oversight? Or does Asobo not care that much about external cockpit builders? Or is there an easier solution that I did not stumble across?
I have not found any switches so far that I was totally unable to control and animate given enough digging. But I am retired after 45 years of making a living in low-level programming.
-
@jbbz You may be right in a way, but nobody forces developers to use the base LVars. It's fine if they do, and if they work they should use them, but they could easily add their own LVars and wouldn't even have to write extensive documentation on them if they use names like "L:BKSQ_MasterAvioncs, bool" or something else that can be identified. You just bundle the functionality into this one viriable and you're good to go. If we have to figure out circuit number X and switch number Y to get them to work, it's a chore for us and we waste hours and hours before we can really have fun.
And I ask for LVars because they can be used in really any software easily and reliably.
And that's especially true for developers like Black Square. They make extremly high quality full study level products for a target audience that sees it more as a hobby and simulation than a game.
-
@lemny Do you mean "nobody forces Black Square to use the standard Asobo templates?" Well, that is ultimately a matter of economics. The areas that Black square has improved beyond the original Asobo aircraft are well done. But it is unrealistic to expect them to rewrite the entire panel without using the in-game templates. Too much time and $.
Lets look at the upcoming updates to these 4 make-overs. And the B60 which I understand they are doing from 'scratch' before judging their commitment.
In a way we are disadvantaged by our interest in 'traditional' gauge panels. The current design of FS2020 does really work better with glass cockpits with soft switches (push-button). The switch state can be read from the screen.
But even the basic C172-G1000 needs BVARS is you want to control the lighting level from external control. I would not say Asobo has no commitment to external controls but I can definitely say the commitment is uneven.
-
@jbbz It's always a matter of economics, but you have to decide where to stop developing and where to go the extra mile to satisfy your target audience. Maybe we, who don't want to mouse around until all warning and caution lights are off, are a minority :-) but I think this stuff suits the kind of product of this complexity very well.
I switched from the Black Bird C310R to the Baron and I think they are comparable in complexity, but the C310R, in addition, is a fully custom aircraft which also delivers features like external and internal dirt building up with flying hours, and a fully working state saving and wear and tear system that results in an incredible sense of ownership.
And if you look at their manual... you find this (only a snippet... goes on for 3 pages)
They have done it for every single thing in this airplane. And they modeled a full aircraft inside and out for nearly the same price. I think there is room for that here too.
Edit: And you'll find original performance tables too. ;-) Would love to see them for the Turbo Baron.
-
@lemny Correct of course. 310 is also a favorite of mine. No BVARs needed but using the LVARs still takes some work. For example here is my script for panel lights knob turning to increase. The way it is written in the 310 the Milviz defined LVAR is readable but not writable (in my tests of course). So not perfect.
(L:C310_SW_LIGHTS_FLT_INST, enum) 100 < if{ 10 (L:C310_SW_LIGHTS_FLT_INST, enum) + (>L:C310_SW_LIGHTS_FLT_INST, enum) } (SPLIT:100) (L:C310_SW_LIGHTS_FLT_INST, enum) (>K:LIGHT_POTENTIOMETER_4_SET) (L:C310_SW_LIGHTS_FLT_INST, enum) 0 > if{ 1 (>K:PANEL_LIGHTS_ON) } els{ 1 (>K:PANEL_LIGHTS_OFF) }BKSQ Bonanza actually slightly simpler using the sim-defined LVAR. But you need to read the code to match potentiometer number to function.
(A:LIGHT POTENTIOMETER:1, Percent Over 100) 0.95 <= if{ (A:LIGHT POTENTIOMETER:1, Percent Over 100) 0.05 + 100 * (>K:LIGHT_POTENTIOMETER_1_SET) }My initial post was because I thought people could be more patient with the 3rd party developers. I wish Asobo would care enough to define a new K: event that sets the panel light intensity not just the on/off that they provide today. But new K: events come slowly.