B-VAR Support in 0.8.0

[richardkennedy]

I'm testing the change log for 0.8.0 but I'm struggling to get B-VARS working, could you confirm the format?

[Fragtality]

Well, the API/SDK of MSFS is still very limited when it comes to B-VARS / InputEvents. From my Research only a Fraction is exposed - only the "Set" Part works. The Author of SPAD.next did a Video about that: https://www.youtube.com/watch?v=QKlOUs-xtns On top of that, they are in a strange "middle ground" between H-VARs and L-VARs. Sometimes they only work as Command (so the Value send does not matter and their Value will not change, but they do trigger something) like H-VARs, sometimes their Value can be read & written like L-VARs (or other Variable/Read Types).

So if and how they are useful comes down to the Aircraft. The Fenix has only a few for the EFIS/FCU Knobs and they work mostly fine (in the Sense of actually turning the Knob visually and changing the FCU Display). The Ini A300 has a Truckload of them, but from the few I tested they only move the Button visually, but not actually trigger the underlying Function (e.g. the ECP "ENG" Button moves, but the ENG Page does not show up).

Other Issues that might be, since not documented yet:

• Their Syntax requires to always add a "B:" before the Name - regardless if being for a Value or as a Command!
• Don't use the Names as seen in the Dev-Mode, because you will also see the InputEvents which MSFS does not expose via SimConnect. Either look in the Log, or use something like FSUIPC to list the Names. For Example the B-Vars for the Fenix' FCU Speed Knob would need to be configured as:

B:FNX320_Input_Knob_PushPull_E_FCU_SPEED_Push
B:FNX320_Input_Knob_PushPull_E_FCU_SPEED_Pull
B:FNX320_Input_Knob_PushPull_E_FCU_SPEED_Knob

[richardkennedy]

Thanks, will keep testing 👍🏻

[Fragtality]

Check the latest Version - there was a Bug where B-Vars used as Value did not work

[richardkennedy]

This appears to be working well

[markhlam]

@Fragtality you mentioned that B-vars should be tracked through the Log

Don't use the Names as seen in the Dev-Mode, because you will also see the InputEvents which MSFS does not expose via SimConnect. Either look in the Log, or use something like FSUIPC to list the Names

Which "Log" are you referring to? Which setup should I use to track them in FSUIPC?

[Fragtality]

The Plugin's Log - but it is now a separate File in the Plugin-Directory, containing the B-Vars for the current Aircraft: InputEvents.txt

FSUIPC GUI?

[markhlam]

I'm struggling with the B-vars, being totally unable to handle them.

I'm trying to manage a lever which in the developer mode for the Inc and Dec has the following code:

(O:FUEL_LV_Fuel_supply_engine_3_Position) p0 + (>B:FUEL_LV_Fuel_supply_engine_3_Set)
(O:FUEL_LV_Fuel_supply_engine_3_Position) p0 - (>B:FUEL_LV_Fuel_supply_engine_3_Set)

Which in the end means you put a value from 0 to 3

First I tried with the BVar option, using Command Address FUEL_LV_Fuel_supply_engine_3_Set, then I also tried with a Lua,

SimVar("B:FUEL_LV_Fuel_supply_engine_3_Set")

function ToggleFuelOilEng_3()

    SimWrite("FUEL_LV_Fuel_supply_engine_3_Set",3)

end

But none of those worked. I also tried to find that dedicated log to B-Vars, but I couldn't find it in the log folder

I still have a lot to learn about the simulator guts...

[richardkennedy]

@Fragtality Any update on this and the general timeline for 0.8.0?

[Fragtality]

Well the initial Post did not enough Information to Troubleshoot - e.g. Logs, Timestamps, which Aircraft - and contained obvious Errors on Stuff mentioned before (always add a "B:" before the Name).

The Timeline is currently in the "done when it is done" Region, because I'm rewriting most of the Plugin Foundation currently to better maintainable and extensible in the Future (especially being able to add an Idea for an even more complex & flexible Action). With all the new Stuff I've worked more around than with my Code and I slowly lost Track of what happens where (e.g. determining which command needs be executed how was spread all over the Place). It is already progressed well - the Foundation is done, the Connectors are connecting, Variables are read, Commands are send ... it's currently about reimplementing the missing Actions and do some basic Tests with them before I can make the "big switch". In the Moment it is in a separate Repository and runs on its own parallel to the existing Version. But it is getting closer to the Point where I can switch its UUID to the original and test & fix that it will run with existing Actions. Some Actions may need to be changed. When that looks promising and stable enough for others, it will replace this Iteration and will be available as Dev-Build as with before during the 0.8.0 Development.

[Fragtality]

Maybe an Example I just stumbled over: External Power Switches in the 787-9 via B-Vars.

There is an InputEvent B:AIRLINER_ext_pwr_1 which does not have a Value to read and with that to write - i.e. you can't set it to on or off by writing Values like 1 or 0. Regardless which Value is send, I always had to press the StreamDeck Button twice to make the Control in the Cockpit toggle. So I changed it to be a Reset Switch with 1 as both the On and Off Value and now it works as expected.

That is what meant that they are in some kind of "middle-ground" - sometimes they are like an parameterless Event (H-Var), sometimes a Event with Parameter (K-Var) sometimes even like an Variable (L-Var)

[markhlam]

Hi!

Another unsuccessful attempt with B-vars here. Let me explain my case.

I have started preparing a profile for my new adquisition iniBuilds' SC.7, which has a ton of B-vars. Currently I'm trying to act over the seatbelt sign. Someone in the official forum said that had been able to map all switches and buttons (through SPAD.next) and confirmed me that for the setbel sign the targer event was B:INSTRUMENT_Switch_Seat_Belt_Set (as I suspected during my research).

But if I use a Simple Button, select a BVAR as Command Type and in Command Address I type:

(B:INSTRUMENT_Switch_Seat_Belt_Set) or B:INSTRUMENT_Switch_Seat_Belt_Set

And values of 1 and 0 in the ON/OFF

The result when I push the button is a CAUTION yellow triangle. The Plugin log says that:

24-08-26 18:00:34.107 [WRN] [ SimConnectInputEvents:SendInputE ] No Hash available for InputEvent 'B:INSTRUMENT_Switch_Seat_Belt_Set'

So it seems that I'm not using the correct name.

I've tried to get the actual name by selecting InputEvent in the FSUIPC log, but I obtain nothing when I clic the switch in the simulator

I have the last (?) version of your plugin, as I download it yesterday.

And just a final piece of information, code for the event I'm trying to map is: Inc (O:INSTRUMENT_Switch_Seat_Belt_Position) p0 + (>B:INSTRUMENT_Switch_Seat_Belt_Set) Dec (O:INSTRUMENT_Switch_Seat_Belt_Position) p0 - (>B:INSTRUMENT_Switch_Seat_Belt_Set) Set p0 1 min 0 max (>O:INSTRUMENT_Switch_Seat_Belt_Position) (O:INSTRUMENT_Switch_Seat_Belt_Position) s0 l0 0 == if{ 0 (>L:SEATBELT) 0 (>L:Switch_Seat_Belt) 0 (>L:) g1 } l0 1 == if{ 1 (>L:SEATBELT) 1 (>L:Switch_Seat_Belt) 1 (>L:) g1 } :1 1 (>O:_ButtonAnimVar)

Any ideas on how continue my investigation?

[Fragtality]

Seems there was a Problem with the Enumeration of the available Input Events (aka B-Vars). Was this B-Var (or any at all) listed in the InputEvents Text File? Every B-Var the Plugin receives via SimConnect is dumped there (refreshed after each Session Ready).

How/When did you load the Plugin? As far as I remember it worked when the Plugin was active while the Sim is loading. Did you try to reload it while the Plane is loaded and the Session is already Ready? Can't really look into this now, you're using almost a completely different Plugin by now 😅

[markhlam]

Seems there was a Problem with the Enumeration of the available Input Events (aka B-Vars). Was this B-Var (or any at all) listed in the InputEvents Text File? Every B-Var the Plugin receives via SimConnect is dumped there (refreshed after each Session Ready).

Yeah! that did the trick!!

I didn't know that file, I checked and it was registered as B:INSTRUMENT_Switch_Seat_Belt (without _Set). Changing that it works perfectly... and opens a bunch of possibilities for other profiles muahahahaha

Thank you very much!!

[Fragtality]

@richardkennedy FYI, I have finished the Rewrite of the Plugin and pushed it to the Repository: https://github.com/Fragtality/PilotsDeck/blob/master/Install-PilotsDeck-latest.exe I would appreciate some help with Testing to get some Feedback if everything is working properly. A good Opportunity to actually contribute something 😜 Making a Export/Backup of your Profiles is highly recommended! The Intention is that everything just continues to work and I had not seen any Showstoppers with my Setup - but it is better to be safe than sorry 😉

On the B-Vars: I changed how they are handled, especially when used as Command to better incorporate their "Dual Personality". Per Default they are treated as a Command-only Type (like for Example an H- or K-Var) since most I came across do not have a Value to read. If there B-Vars with a readable/writable Value, that Behavior can be disabled and they are treated like any other Variable-based Command. The Readme was updated for all the new Changes, be sure to check it out! So it would also good to know if the Readme does it Job of giving useful Information 😅

Since you are a Profile Author and distribute "a few" Profiles, I'd also appreciate if you take a look at the Profile Packages and their Installation via the Profile Manager with your Expert Knowledge. 😉 (also added to the Readme now) When I recall correctly, you have some Installer-Stuff on your own, but I'd still recommend to use the Package Files/Profile Manager for that Sub-Task since it takes care of some Additional Steps for better User Comfort - i.e. deleting the old Profiles, removing the "(Copy)" from the new ones and transfer configured Profile Mappings for Switching to the new ones.

[richardkennedy]

Brilliant, I'll start working through it tomorrow 👍🏻

[richardkennedy]

@Fragtality We've done quite a bit of testing and found a handful of issues. Would you prefer a new ticket per issue or consolidated feedback?

[Fragtality]

Hmm, I think a consolidated feedback would be better - it all relates somehow to the new Version ^^

And you have checked the GitHub from Time to Time? There where plenty of Commits since I initially reached out ;)

[richardkennedy]

Hmm, I think a consolidated feedback would be better - it all relates somehow to the new Version ^^

And you have checked the GitHub from Time to Time? There where plenty of Commits since I initially reached out ;)

Yep, but I'll double check that they're still present in the very latest build before posting. Still have additional testing to do, but hopefully you'll find some of the initial info useful.

[Fragtality]

Btw, depending from which Build you are coming, the "reset configuration" checkbox should be used in the Installer. There where some Changes needed to the default Parameters used for MobiFlight and Variables used from this Connection.

[Fragtality]

@richardkennedy Are some of the Issues still there with the current Build? You don't need to report all at once, that Way I could already look into some of them ;)

What I forget to mention: I've made also Changes to the Profile Packaging: the json Property to keep the Package Contents is gone (the Option is still there for the User). Doesn't hurt if it is still in the json, will just be ignored. I've added a better Mechanic to distribute additional Files witch a Package. It is already in the Readme, so here the short summary: put the Files in a Folder called "Extras" and the Profile Manager will extract them to the Users Desktop ;)