QualityWings 787 - GSX/SimBrief Integration & Automation

[Fragtality]

​Hello Community!

So I got myself the QW787 and directly missed GSX/SimBrief Integration FSLabs has to offer - so I have spent most of my time developing for instead of flying the Plane   

Since that might be of interest for other Users, I've published it on GitHub - you can get it there along with a (hopefully) extensive Readme!

If this Toolset is of interest to you, can be answered easily by yourself:
- Wished that you could just get the planned Fuel and Weights from your SimBrief OFP automatically by calling the GSX Services? Without any Payload Dialog or Dispatch Page / Dispatcher involved?
- Wished that the Plane was actually & progressively refueled and (De-)Boarded when GSX is active? (Not refueling and boarding an already loaded Plane - really seeing the GW rise and fall as the Passengers - are entering/leaving Plane and the Containers are loaded/unloaded)
- Wished that the Ground- and Cabin-Crew would just take care of the Doors, instead you "leaving" the Cockpit to open/close all that Doors?
- Wished the Jetway/GPU would just automatically be called / removed, the Chocks being set / removed and External Power connected / disconnected?

So if the Answer is 'yes' to any of these Questions and you have a registered Version of FSUIPC: go and try it out! >>LINK<<
The only thing it does not / can not do is loading the FlightPlan into the FMS 

There are two Releases / Zip-Archives to choose from:
- If you're not using "PilotsDeck" -> download the QualityWings2GSX.zip File. It contains everything needed for the Automation/Integration to work.
- If you are using my StreamDeck Plugin and want to use the StreamDeck Profiles I've published in the PilotsDeck Repository -> download the QualityWings2GSX-PilotsDeck.zip File (they include also the Profiles and needed Files).

If should have any Questions, Problems or Suggestions (after reading the Readme) - feel free to contact me. 

​

[CS-TMT]

I'm interested in this! Can you send it to me please?

[Fragtality]

HOLY SH*** ... I totally forgot to actually put a Link to the Repository *DOH* 

The Post is corrected and the Repository is now linked, you can download it from GitHub

[CS-TMT]

Thanks a lot for the reply and the link and thank you even more for your wonderful work! I haven't tested it yet, but according to your description it must be wonderful and I believe so. Thanks for your effort!

[Fighter2309]

This is simply amazing! Many thx for sharing it.
Would it be possible to create this also for PMDG planes?

[CS-TMT]

Following the question regarding PMDG, I would ask as well if it's possible to do this for PFPX users as well, for those who don't use Simbrief?

[TheCaptain3618]

Following the question regarding PMDG, I would ask as well if it's possible to do this for PFPX users as well, for those who don't use Simbrief?

Please, do it. I stopped using Simbrief permanently in favor of PFPX. Still the question is: can I use it without Simbrief?

[CS-TMT]

For me possibly it will be the opposite way, now that PFPX development ceased for now, PFPX keeps being a simply amazing software, but maybe sometime in the future I may have to go to Simbrief. So far I never used Simbrief.
As for your question, I think this mod/tool is unusable without Simbrief.

[Fragtality]

Hey there! Sorry for the late answer, wasn't informed of new replies 

This is simply amazing! Many thx for sharing it.
Would it be possible to create this also for PMDG planes?

I simply don't know - I don't have any PMDGs and if, it would be only the 777 (basically only airframes not designed in the 60s^^)
But I would not have much hope - since PMDG more or less denies the existence of GSX it is questionable if they expose enough variables/functions to do something similiar (which also is a reason for me not to spend the Money - else I would have got it as soon as it was released for v5. The 777 is overpriced imho).
For example: it would be required that I can set existence of external Power from outside (via lvar, offsets or controls/events). Or a Variable for the Wheel Chocks (which would also be needed from GSX to recognize them. GSX in turn doesn't allow me to inform it that the Airplane has Chocks set and there is no intend to implement that in the foreseeable future).
The Thing with QualityWings is/was: they integrated with GSX, it's just that it is a very basic integration (compared to e.g. FSLabs), they could have gone much further (for Example to just ask Umberto to check their Chocks-Variable^^). I would have also tried to implement to load the FlightPlan in the CDU, but for that the CDU-Softkeys would need to work. Don't know when QW does fix that (at least they acknowledged it) ...

Following the question regarding PMDG, I would ask as well if it's possible to do this for PFPX users as well, for those who don't use Simbrief?

For me possibly it will be the opposite way, now that PFPX development ceased for now, PFPX keeps being a simply amazing software, but maybe sometime in the future I may have to go to Simbrief. So far I never used Simbrief.
As for your question, I think this mod/tool is unusable without Simbrief.

That is simply not true, basically it is implemented since release, check out the Readme! Especially the FAQ for "I dont use SimBrief, is that of any use to me?". You can provide an "Offline OFP" via the ofp.xml File which provides the Information the Binary needs for Refuel and Boarding! Most of the other automations (e.g. opening/closing doors) is not tied to the Binary. It is done with the Lua-(Sync-)Script provided.
So it maybe is not useable with it's full feature-set (when not using the binary) or with the same comfort (since you have to edit the xml File manually) - but you can use it without SimBrief.

So in Theory PFPX (or any other FlightPlanner) could export this xml-File for the Binary. IF PFPX would still be developed or IF it would allow to write Export-Plugins for
But although its "abandonware" State it still seems to have great User-Base ... does it have any Export-Option which exports the needed Information in a machine-readable and open Format (like xml, json)? If that is the case I maybe would look into it. But if the only way would be to parse an OFP via Regular Expression, it definitely won't happen sorry!

[CS-TMT]

That is simply not true, basically it is implemented since release, check out the Readme! Especially the FAQ for "I dont use SimBrief, is that of any use to me?". You can provide an "Offline OFP" via the ofp.xml File which provides the Information the Binary needs for Refuel and Boarding! Most of the other automations (e.g. opening/closing doors) is not tied to the Binary. It is done with the Lua-(Sync-)Script provided.
So it maybe is not useable with it's full feature-set (when not using the binary) or with the same comfort (since you have to edit the xml File manually) - but you can use it without SimBrief.

Oh, sorry for that! Indeed I didn't read the FAQ

So in Theory PFPX (or any other FlightPlanner) could export this xml-File for the Binary. IF PFPX would still be developed or IF it would allow to write Export-Plugins for
But although its "abandonware" State it still seems to have great User-Base ... does it have any Export-Option which exports the needed Information in a machine-readable and open Format (like xml, json)? If that is the case I maybe would look into it. But if the only way would be to parse an OFP via Regular Expression, it definitely won't happen sorry!

Well indeed PFPX allows one to save the OFP as a plain TXT file, which indeed is the current way to import the flight data into FSLabs. Although FSL needs to read this TXT file with certain naming rules, if one is not using FSL, one can save this TXT file with whichever name one would like.
Previously (before I started to use that aircraft) FSL allowed to uplink a flight from PFPX directly as it stil does with Simbrief, without downloading any TXT file or anything, but currently that uplink "on the fly" is only available through Simbrief as FSL dropped that similar functionality through PFPX.
I've attached a TXT OFP saved by PFPX ready to import to FSL so you can see.
Basically, for FSL to be able to read and interpret it, the file name has to be Callsign (space) DepartureAirport-ArrivalAirport (space) (Date inside parenthesis with the given date format) #(OFP release number). This file naming format is the one automated by PFPX, but if one is not using it in FSL, one can rename the file at will.
In the case of the file I attached here, CSDGA is the callsign, as it was a private flight with no airline code, so for a Delta flight for example the name would be DAL1234 LPAR-LMML...etc. (CSDGA/DAL1234 being the flight number one should insert on the FSL INIT page on the flight number).
Sorry for this extensive post, hope you understood my explanation!
Regarding PMDG, I love their ac althoug I currently have the 777 because it's the only one that I fly and although it's quite expensive (like every PMDG aircraft) I can guarantee that it's worth every cent, however I completely understaft your "frustration" (which I also have) regarding the denial of PMDG regarding GSX.

[Fragtality]

Had a look at the Text-File and I have bad news: that is not machine readable, so it won't happen - sorry! 

The thing is: to get any Information out of normal / human-readable Text-File you need to write Regular Expression (like FSLabs did). So something like that

Code: [Select]

$"^[^0-9]{{1}}((L:){{0,1}}[a-zA-Z0-9\x2D\x5F]){{1}}$"And that is "only" an Expression which tests if it a correct Lvar Name (example from my StreamDeck Plugin) - so a rather easy Expression for just a single Line. So to get multiple Information from a whole File you can imagine it is "a bit" more complex. Even with the same OFP template, there is much variability on if and how the Information is presented. And to know/research all the variations and describe them as Regular Expression takes time.

With SimBrief I'll just make a quick http-request, throw the returned xml-Document at a Parser (which already comes with the .NET Libraries) and get the whole Information in nicely indexed Collections. Getting the Pax-Weight (as Text) then is just:

Code: [Select]

sbOFP["weights"]["pax_weight"].InnerTextThe advantage is: I don't care which units you are using (the xml tells me) or which OFP Format you prefer as Output. The machine-readable Format is always formatted the same. Even if SimBrief would alter the Structure or Element-Names - such changes can be adopted rather quickly (in comparison to Regular Expressions).

So you have to manually edit the ofp.xml. But it sounds more complex than it is (imho):
Throw in your ICAO-AirlineCode, FlightNumber, Departure/Destination (ICAO), Aircraft-Variant, Fuel and Pax/Bag Count.
Something which can easily be done while Prepar3D is loading (The Binary looks for an OFP only after the Batteries are On, so there is no rush)

[virtuali]

Or a Variable for the Wheel Chocks (which would also be needed from GSX to recognize them. GSX in turn doesn't allow me to inform it that the Airplane has Chocks set and there is no intend to implement that in the foreseeable future).

GSX already recognizes Wheel chocks ( both as an alternative to Parking Brakes or a departure constraint ) in all PMDG models.

[Fragtality]

Or a Variable for the Wheel Chocks (which would also be needed from GSX to recognize them. GSX in turn doesn't allow me to inform it that the Airplane has Chocks set and there is no intend to implement that in the foreseeable future).

GSX already recognizes Wheel chocks ( both as an alternative to Parking Brakes or a departure constraint ) in all PMDG models.

Ah okay, at least PMDG allows that Level of Integration with GSX^^
But for a similiar Integration/Automation to be done for PMDG they would also need to allow to set/remove the Chocks programatically.

[virtuali]

Ah okay, at least PMDG allows that Level of Integration with GSX^^

It's not a matter of PMDG "allowing" things or not, it's more like GSX, by design, is made NOT TO TOUCH any systems on the airplane.

Meaning, it won't ever write on any variables on any of the plane systems, that's why we never made an automatic door opening system, because we can't possibly be sure if it's safe to "just" open a door when it might be tied to a custom system, for example the electrical system or the hydraulic system.  The one and only time GSX ever changes some variables on the airplane, is during Pushback, otherwise it wouldn't be able to...move the airplane. But this is done using entirely official documented variables, so it's not as if we are touching a custom system.

Same for fuel: we only refuel ( acting on fuel quantities ) planes that are known to use a standard fuel system, otherwise GSX will only do animations in reaction to the changing fuel levels which are already happening under the airplane own control.

Same for the battery charger or the external power availability, we only charge the battery for planes that has been flagged to be using the default electrical system, but most of the 3rd party planes aren't, so we just signal developers using GSX-specific variables that we would like to charge the batter or a jetway has power or air, and then it's left to the plane developer what to do with this information.

That's the only way to be sure GSX will never mess up with any airplane system that might have repercussions we cannot possibly be aware of, and that's why we ask plane developers to do some bits of integration themselves, because nobody better than them can possibly know when it's safe to act on their own system.

Some major plane developers ( FS Labs, Aerosoft, Leonardo ) fully understood this, so they did the integration themselves, since they obviously saw the value GSX added to their customers.

The one and only exception is PMDG, their explanation for not integrating it was they fear "GSX would mess the airplane", which is precisely the opposite of why they were supposed to do the integration themselves.

If GSX really tried to mess with the airplane, there would be no need for us to wait for plane developers to integrate anything, we could *hack* into the airplane ourselves (like we used to hack into FSX own memory when the SDK was missing features, but we don't do that in P3D) and could start setting stuff on our own and THAT would be a legitimate cause of concern for airplane developers, which would be unsustainable for us as well, since we'll likely have to keep our code updated with every release of the airplane.

[Fragtality]

Ah okay, at least PMDG allows that Level of Integration with GSX^^

It's not a matter of PMDG "allowing" things or not, it's more like GSX, by design, is made NOT TO TOUCH any systems on the airplane.

Sure, it is either allowing or accepting - if there would not be a Variable to read the Chocks-State from, even that Level Integration with GSX would not be possible

The one and only exception is PMDG, their explanation for not integrating it was they fear "GSX would mess the airplane", which is precisely the opposite of why they were supposed to do the integration themselves.

Wow! That is a very lame excuse for such a Developer with a Product where the Base-Package is already 139$! 

The only who rightfully could argue to "mess with the Plane": that is QualityWings about me