These are the events (and variables?) prefixed by B:
1 Like
I don’t like them.
I can program an event in SPAD.NeXT that performs an action, but the cockpit indication (switch movement, etc.) doesn’t happen. It’s dumb.
2 Likes
It’s really quote logical.
Say you have a LIGHT that can be ON or OFF, and you also have a Switch that you want to control the light.
There is an event that puts the Light on or off, and it does exactly that, and nothing else - putting ON the light does not move a switch.
If you want a Switch to turn on/off the light, you need an event to move the switch, and then code the position of the switch to control the light’s on/off event.
Bypassing the switch, and just making the light go ON/OFF is probably NOT what you intend to simulate.
What you almost certainly should not want to do, is have the light going on/off, controlling the switch !!
2 Likes
The electrical circuit system is there to control power to an individual circuit. So with an individual light the thing that needs to be controlled by the user is the switch. Therefore the use of Bvars for items that have a need to be interacted with by the user is poor on the devs part. All interaction items should have a means for external control and currently that means no use of B,I,O vars for things like that. This is a 2 way responsibility. Asobo need to give access for external control of the B, I, O vars but all the while that doesn’t happen aircraft devs need to ensure that all interaction items have an external means of control which means either using standard sim events or vars which they should all be doing anyhow where possible and if not by using an LVAR. Sadly this is not the case so the dev education has to continue on this until that Asobo access thing is resolved. Not a word on it for ages. We could all do with an update of what’s happening with it.
5 Likes
100%, and you put it a lot more politely than I could.
but just becuse Asobo has not yet seen the light, expecially wrt home cockpits, that does not mean that other developers cannot do this correctly – SOME ALREADY HAVE 
3 Likes
The B variables are used to trigger a custom event, that’s all. You can read more about Input Events in the docs. You may only need this for more complex things. The standard events and simvars the sim provides should cover just about any aviation system.
For I and O vars, those serve a specific use which is to be limited in scope to a component. These shouldn’t be accessed externally. You would use them only for temporary variables or to maintain internal logic.
I agree with the previous posts about compatibility with external events and hardware. Devs should consider that there is a wide range in the way we each like to interact with the sim and be as inclusive as possible.
1 Like
Agreed, it’s mainly the Bvars access that is needed but sometimes because of the way an aircraft is coded you have to get at the I or O ones too. This may well also be related to aircraft dev education because some are not solely using them for stuff you would consider internal only.
1 Like
I guess I don’t understand.
I program an event in SPAD and assign it to a switch on my HC Alpha. For example, ‘Turn cabin light on.’ When I turn the switch on, the cabin light comes on, and the cockpit switch moves to the on position.
(I don’t need to program anything else to tell the cockpit switch to move when I throw the switch on the Alpha.)
Next I program another Alpha switch to turn on the nav lights. I can see in the external view that the nav lights turn on. But the cockpit switch doesn’t move. (This is a hypothetical - it may be some other switch, but you get the point.)
I was told by the SPAD developer it’s because the aircraft developer made the latter example’s switch movement a ‘B’ event, which is not exposed in the SDK.
1 Like
Not sure what part you don’t get. The reason they are different is because they were coded differently by the aircraft dev. The second all too common example you gave happens when 2 different variables are used. One for the actual light and another for the switch animation. When the one used for the animation is not accessible to apps outside of the sim then it cannot be controlled. Hence the light works but the switch animation does not. At least it’s not the other way round.
While I agree that devs can do a lot to make sure that home cockpit and advanced hardware users can automate their aircraft by avoiding inaccessible var types for user-level interactions, the deeper issue is not necessarily a lack of dev education; it’s that they don’t generally care about specialised use cases like home cockpits.
The standard user interaction is a user clicking with a mouse somewhere in the virtual cockpit to trigger an action. For most devs, if that works, their job is done. If there’s a way to trigger that action from an external source via SimConnect etc and the way the dev implemented it happens to allow for that, well that’s great for us, but it isn’t usually the goal of the dev. It’s not that they don’t care in a negative way, ie not wanting to cater to us - it’s that they generally don’t consider any advanced use-cases because they themselves use the sim by pointing and clicking. It’s how the vast majority of users use the sim.
Some developers do a much better job here - for example FlightFX provides binding docs for the Vision Jet and HJet explaining how to automate all the aircraft functions, and SimWorks Studios is usually pretty helpful, among others - but the only true solution is for Asobo to open up all aspects of the sim to external control. And (for the same reasons as above), I don’t think that’s high up on their priority list.
1 Like
The part about what the difference is between all the different variable types, and how they are used in the sim. I’m learning, though, thanks to you and others.
1 Like
Thanks for your explanation. I for one would like to give my money to devs who go the extra mile to give home cockpit builders the tools they need to get the most out of the sim. Mine is quite humble compared to many, but I’m guessing my frustration is shared by them as well. I guess the bell curve rules this issue like it does so many other things in life.
On one side you have those who see this as nothing more than a game, and are happy to click their way through a flight. On the other side are those who want to control everything with peripheral hardware devices, and want a simulation that gives them the ability to duplicate the experience of flight as much as possible. In the middle are the large majority who are fine with something in-between.
Then you have VR, whose users have to struggle with being in a virtual world and at the same time interacting with the physical one. One of the promises of AR is that those worlds can overlap. To me it’s the holy grail. But as you say, that goal, which someday can (and I think will) become reality for gaming, is not currently high on the list of priorities. It is, after all, still in its infancy. But I remember when VR was in its infancy. I doubt the early developers of that technology ever imagined that it would become a large consumer market. It required that computer performance/price evolve dramatically. Back then, who could have imagined that a $3,000 computer would have the power they have today. Or that the market for them, while still somewhat specialized, would be as big as it is today.
Of course marketplace forces are, in general, the driving forces for any consumer product development, and devs are going to spend their time and money on those things that satisfy the majority of buyers.
1 Like
Yes some may do it deliberately one way or the other but from what I’ve experienced so far it’s generally because they don’t have that awareness. So education is a big big thing. Once the dev understands what will get asked of them they will likely provide updates and do things differently in future projects. The more we express to them what we need the more likely it gets better over time. After all it’s really no extra work up front for a new project. This will also help to highlight those devs to steer clear of if they choose to be one that doesn’t want to change.
1 Like
Yes. Equally, that’s why you tend not to get aircraft fixed if they are built the ‘wrong’ way, since re-working something that already works for 90% of your audience is hard to justify.
This is why I’d like to see Asobo and Microsoft take some leadership here. They always talk about the sim being open to all regardless of experience and the way they want to play. That includes console gamers and casual gamers, but it should also include cockpit builders and those with advanced hardware setups. Microsoft is in a position to have a more significant influence on 3rd party devs than we are as users. They could use that power to help us as much as to help other player groups.
2 Likes
You just have to stop it… just stop… 
(yes, I’m still laughing… does that make me a nerd? 
)
Only in Multiplayer – If I am a nerd, then you will also be a nerd !! 
1 Like
I’m trying to figure out where the B variables come from.
When I load the sim and the ka350 for a flight there are some (I think 6) B variables that should load up. Sometimes they load up fine but go away in the middle of the flight. The problem is some times they do sometimes they don’t. Can anyone shine some light on that?
B variables do not disappear. Think of B Vars as certain events that were only accessible via mouse click. What variables do you think should be there? BVARs are not used on everything nor are they all accessible in Spad. Furthermore if B Vars for an aircraft were accessible in Spad and then they disappeared in mid-flight, I would say you have a Spad issue.
Sometimes when I load the KA350 and use SPAD so look at data points I see all the B variables (I guess assigned to the aircraft?) some times the list is either not there or some variables are missing.
For example
B:FUEL_1_CONDITION_LEVER
When its there my Condition Lever works when its not it does not
As I said it would appear to me then, that you are having a Spad issue.