#Option to disable PMDG Advanced Integration (all of it)

1 messages · Page 1 of 1 (latest)

rain sapphire
#

Like the Title says: Please implement an Option (GSX Settings UI, ini File or Aircraft Profile) to disable PMDG Advanced Integration completely: so no Synch, no Ground-Equipment Handling, nothing - basically treating a PMDG Aircraft like any other Aircraft.
It would be preferable as GSX Setting which can be set via L-Var - so an external Integration could set it dynamically when it runs, without the User needing to do anything special Configuration-wise.
Also: this Option is meant for all Advanced Integrations - so if there should be any future Advanced Integration for other Aircrafts, it would be reasonable to have a common enabled/disable Setting for all of them!

Reason: Having that Integration enabled all the Times makes it very difficult to impossible for external 3rd Parties to do an Integration (e.g. like Fenix2GSX, brokering between the Aircraft and GSX)

hazy plank
#

This probably is something that needs to happen on the PMDG side.

rain sapphire
hazy plank
# rain sapphire Wrong.

Not wrong; I took a look at the hex for the PMDG 777 WASM file.. It's PMDG that is doing the advanced integration; there is nothing that GSX can do about it unless they change their variable names (which would break every airplane that has GSX integration).

Basically PMDG activates the doors when it detects boarding, deboarding, or catering has been called for/begun.

#

So unless Umberto has the ability to modify PMDG's WASM files without breaking them, FSDT cannot create a toggle for PMDG's integration into GSX.

rain sapphire
hazy plank
rain sapphire
#

No it's not.

hazy plank
#

Okay, then, you tell me where I'm wrong. Where in the files does it say that GSX controls the advanced integration?

rain sapphire
#

Else please elaborate why GSX is not in Control of its own Feature?

hazy plank
#

It is not a GSX feature. It is a PMDG feature. It is coded into the WASM module of the 777, not GSX

rain sapphire
#

Listen, I'm aware that PMDG has done some half-assed Stuff they call Integration. Got the same Confirmation/Explanation from Umberto has you just gave me (on Variables in the WASM Files).
But there is a GSX Side to it. So I adress it in the GSX Discord 😉

hazy plank
# rain sapphire GSX Manual, Page 113.

Literally every single one of the features you have a problem with is a result of PMDG's code, not GSX's. GSX integrated a flow into the PMDG aircraft using the PMDG SDK, however it does not control services automatically, only doors and a manual loading of fuel/cargo by entering into the CDU.

The automatic door opening without the use of the CDU comes from PMDG. The issues with GSX and PMDG come from PMDG.

#

For the "PMDG 777/737 Advanced Integration", there is no other way to integrate other than PMDG to code something in, as PMDG historically has locked most of their files down. FSDT uses the PMDG SDK for that.

#

Fenix2GSX would not work in the way it has been coded for the PMDG base.

#

Nor would any other, similar method. PMDG themselves has to do the deep integration or nobody can - just because of how PMDG's SDK, EULA, and software are written.

north idol
#

This discord and thread is about GSX and there are reasons to want to have an option to disable the GSX input in that mess.

rain sapphire
#

The automatic door opening without the use of the CDU comes from PMDG. The issues with GSX and PMDG come from PMDG.
No it doesn't, the GSX Log shows clearly that it is GSX openeing the Doors.

north idol
#

It's well known that GSX has logic to trigger doors and do the fuel+cargo loading via CDU.

north idol
summer marsh
#

I must clarify here:

  • GSX is doing door automation on both the 737 and the 777 except the 700-200

  • PMDG might be doing something too, but I can't say for sure what, because the only thing I can see, is there are GSX LVars in their code, but I can't say if they are using it or it's just part of something planned.

  • If they are doing door automation, there's a chance their door automation might clash with GSX's one, but it all depends how and when their are checking GSX LVars, meaning how robust is their code handling somebody else possibly operating doors because, since they have a published SDK, they should expect anybody ( GSX, another utility ) possibly using it.

  • I haven't got any feedback (positive or negative) if they had any issues with GSX door automation.

And again, ALL of this is valid for 737 and 777 except the -200, becaue this still doesn't have an internal GSX Profile, so there's NO GSX automation AT ALL on the -200.

north idol
#

This is all known, and yes the PMDG automation does some things with the doors when using GSX.
But despite someone who jumped into this thread with wrong information, this is a feature request to have a toggle to turn off the GSX integration (everything that GSX sends to the aircraft, like door events and CDU presses etc) to allow for external tools to take over this task.

I talked to @rain sapphire and maybe it would be the best to have a simvar to tell GSX to suppress the integration logic so that an external tool could set it and take over the integration part.
The simvar should not be PMDG specific but more genral and have effect on any kind of current or future events sent by GSX (e.g. standard door events as well) to not be just PMDG specific.

If that would be possible, there would be no user interaction needed if they want to use another external tool to control PMDG aircraft events.

summer marsh
#

I only wanted to clarify exactly what is the current situation, to prevent spreading of wrong information about what GSX does or doesn't with PMDG, because it's changes with the variant so, at least one thing is certain and can be tested: If doors automation doesn't work well with the 777-200, you can be sure it's not a GSX issue.

I'm NOT opposed to adding LVars to enable/disable GSX automation in principle, but as usual, things shouldn't be done for the wrong reasons, for example:

  • If somebody thinks a part of GSX automation doesn't work well, asking an LVar to disable it is the wrong reason and the wrong approach, when instead the correct approach is to report it, so we can fix it, because we WANT to have it fixed in GSX first and foremost.

  • If there's a problem with PMDG automation code, we have a good chance right now to TEST if it's caused by a conflict with GSX own automation or not, because we have two very similar planes to test now (777 300 and 200), and the 200 is not automated by GSX, so we can assess if PMDG own automation code works at least when it's the only thing that controls door. Depending on this results, there might be different outcomes and things to do:

  1. The PMDG own GSX automation might work well on its own, but clashes with GSX own automation (so the 200 is good, but the 300 isn't), in this case the correct course of action would be first trying to clarify with PMDG (something I must do), if they took into account GSX (or any other utility using their SDK) might be also operating doors and see if they can improve their code. Since they have complete control of the airplane, more than what they expose with the SDK, it shouldn't be difficult for them to automate doors in a "safe" way, that is checking if the door status is not what they expect, because something else might automating doors.
#

.
2) The PMDG automation might not working well even when it's alone. If this is the case, disabling GSX automation won't fix anything. If ever, if PMDG used such new LVars to disable GSX automation, to replace it with a worse version, we might lose a chance to workaround issues with PMDG automation from our own side. Again, the 777-200 is a good testbed for this.

  1. The are only TWO "good" reasons why I would agree disabling GSX automation would make sense:

  • Because you like operating the FMC by yourself, maybe you bought a fancy Winwing unit and take pleasure using it.

  • Because you might want to code a separate utility that does things differently or more automated.

  • NOT because you think you are supposed to "fix GSX automation bugs" with it. Bugs are bugs, and we want to have it reported and fixed and, sorry to be frank, I don't want an utility that advertise itself as being useful to "fix some GSX bug", that's not acceptable, a GSX bug must be fixed first, and then we can discuss disabling part of GSX to create alternative procedures for it.

Also, we are considering something similar to the Python airport customization, and that would be EXPOSING the coding part of the GSX Internal profile which we call "Aircraft Handler", so you might have a .PY file supplied together with the airplane profile that can be used to customize or even rewrite the whole GSX automation for that airplane, maybe following airline-specific procedures. This is something for the future, because it's way more complex and extensive than airport customization, so we need better support in GSX, like better error handling, some way to debug code, a way to prevents errors from crashing GSX, etc.

north idol
#

This thread is about disabling the integration for the purpose of either implementing an external integration program (pmdg2gsx, as mentioned in the opening post) or because I'd rather want to operate things (doors, loading) myself with no influence of GSX like I'm used to from other aircraft.

This thread is not about fixing issues, it's about taking GSX out of the influence to use other means to do it.

summer marsh
summer marsh
#

ok, I'm doing some tests now, what about these ?

FSDT_GSX_AUTOMATION_DOORS
FSDT_GSX_AUTOMATION_FUEL
FSDT_GSX_AUTOMATION_PAYLOAD

By default, they will start all at 1, when the airplane profile is loaded. If you set any one to 0, you will disable the relevant part of the GSX automation.

north idol
#

Sounds like a plan, would be nice if inflight restarts of couatl wouldn't reset it. So if the variable is already set to 0 it shouldn't be set back to 1. Also to avoid some race condition on startup

#

But @rain sapphire should check if that suits his idea 🙂

summer marsh
north idol
#

Aren't simvars reset completely if you switch aircraft (which makes you exit to main menu)?

summer marsh
#

.
About the PMDG 777, it seems the option to switch the cabin configuration from dual class to economy is not there in the -200 and seems to have been removed from the -300 as well, have you noticed that ?

rain sapphire
rain sapphire
# summer marsh ok, I'm doing some tests now, what about these ? FSDT_GSX_AUTOMATION_DOORS FSDT...

That sounds even better, since it would allow "mix & match" of Features. I.e. while "CDU Loading" the Aircraft is the only Option, I could just continue to use GSX' Integration (I hope with Weight&Balance coming to the UFT someday that there is a Way via CommBus)

BUT: This still would mean that GSX would handle the PMDG GPU & Chocks and also does special Checks (i.e. when Calling Pushback while the GPU is in Place) which lead to the PMDG still behaving differently (needed to be treated differently). So if broken down to Sub-Features, it would also need something like "FSDT_GSX_AUTOMATION_GROUNDEQUIP"

north idol
#

Does GSX control chocks and gpu? On my 77F I always have to do it manually.

rain sapphire
north idol
#

Ah yeah but those are checks, not automation. Not sure how checks are implemented, I thought it's default simvars

summer marsh
#

GSX operating the GPU is automation.

GSX not starting pushback unless chocks are removed is not automation, because GSX is not changing the aircraft state in this case.

rain sapphire
#

But it is something special to the PMDG, isn't it?

#

I don't see the same Behavior on Aircrafts like Fenix A320 or iniBuilds A306 - the Departure/Pushback Service behaves normally, regardless of the Aircraft's GPU being in place or not

north idol
#

And btw, the pushback sequence starts even if chocks are in place but it halts at some point until you remove them. Same for Ground Power afaik. Not sure which states the simvars get though

summer marsh
rain sapphire
# summer marsh It's not strictly special to the PMDG, it can foreseeably support any airplane w...

Hmm, where is the Focus of what is Automation and what not is coming from?
I mean for me the Topic is about a Way to disable the "PMDG Advanced Integration" Feature so that a PMDG Aircraft behaves like any other Aircraft. Yes, that includes Automation Aspects, but it also includes non-Automations Aspects as specialized Checks and Pop-Ups (especially if the Former leads to a different Service State Behaviour)

summer marsh
rain sapphire
#

I don't know how I make it more Complex, when my original Suggestion does not have single Mention of "Automation" and only suggests a single on/off Switch for a whole Feature 😅

summer marsh
#

Fact you didn't called it "Automation", doesn't change the fact what Automation means. Again:

  • GSX clicking, setting airplane variables, pushing buttons on the airplane, sending events to it IS Automation

  • GSX doing all sort of different things to ITSELF without changing anything in the airplane state and only reading airplane variables IS NOT Automation.

rain sapphire
summer marsh
#

.
We are having this discussions because you cited two cases, one which is clearly GSX automation (the operate GPU command), and the other clearly isn't ( GSX not starting pushback with Chocks ), so I had to clarify what I consider Automation and what those LVars will have an effect on.

north idol
#

Can we somehow turn off the PMDG specific checks?

rain sapphire
#

^ This ^

north idol
#

Because that's what it boils down... On top of the automation which would be fine with the discussed variables

#

Because door checks are in the aircraft profile, so one could turn them off there. What about the other checks?

rain sapphire
#

For me the Thing is: I'm trying to write a general Solution. A general Variant of Fenix2GSX so to say, which also should include PMDG Aircrafts (but not only).
So I need to handle many different Aircrafts in a general Way. So GSX behaving differently on a PMDG Aircraft is conflicting with that.

#

Hence the Suggestion.

north idol
#

Doesn't GSX also have fenix specific chocks/gpu checks?

summer marsh
#

This is a new request, which goes beyond the simple "Stop GSX touching my airplane", which has always been the issue since now.

rain sapphire
rain sapphire
north idol
#

Does it matter if it's a new request or not? Can't we just find a solution?

Like adding a _AUTOMATION_GROUNDEQUIP
_CHECKS_GROUNDEQUIP

And call it a day?

rain sapphire
#

Would be great ^^

#

I mean there is no Pressure in implementing - my Any2GSX Work is currently more or less prototyping at the Moment 😉

summer marsh
#

There's no PMDG-specific test about Chocks, it's just part of the standard airplane profile parking brake test.

The only PMDG-specific thing other than those already discussed (Doors, Fuel and Payload) is the operate GPU, which as I've said IS automation, so we might just need an extra LVar for that.

north idol
#

If it's different in complexity, then adding first the automation toggles and then add the checks toggle a bit later?

rain sapphire
#

is the operate GPU ... so we might just need an extra LVar for that.
Yes, that please 🙂

north idol
#

Appreciate the time you take to clarify, especially if it ends up meeting with same expectations 🙂

rain sapphire
#

💯
(meaning thanks from my side too ^^)

summer marsh
#

And, we don't even need a separate "check" variable, it's just a matter where the automation switch off is used so, for example, if this code now lools like this:

def onJetwayDisconnected(self):
  print "PMDG_Handler.onJetwayDisconnected()"
  if self.extPowerAvailOn() or self.extPowerOn() and self.gsx:
    choice = self.gsx.gateMenu.showChoiceMenu("Release Ground Power?", ["Yes", "No"], title = "GSX - Jetway")
    if choice == 0:
      print "PMDG_Handler - Release Ground Power"
      self.operateGpu()

With a dedicated variable to switch off automation for the gpu or other vehicles, if the variable is read at the proper time:

def onJetwayDisconnected(self):
  print "PMDG_Handler.onJetwayDisconnected()"
  if self.gsxAutomationGroundEquip.getValue(True):
    if self.extPowerAvailOn() or self.extPowerOn() and self.gsx:
      choice = self.gsx.gateMenu.showChoiceMenu("Release Ground Power?", ["Yes", "No"], title = "GSX - Jetway")
      if choice == 0:
        print "PMDG_Handler - Release Ground Power"
        self.operateGpu()
  else:
    print "GSX not operating GPU because automation has been disabled for Ground equipment"

Everything will be skipped, including the menu pop-up, so the airplane would behave like one without any kind of automation.

rain sapphire
summer marsh
#

There's a new version with those 4 LVars you can try now, so you can also try the new BETA channel in the installer (there's no UI for that yet):

  • Start the installer from the command line like this:

Couatl_Updater2 /INSTALLMODE /BETA

  • You should see a big red Beta letter on it, showing you are on the Beta channel. Select Update. The new LVars are:

FSDT_GSX_AUTOMATION_DOORS
FSDT_GSX_AUTOMATION_FUEL
FSDT_GSX_AUTOMATION_PAYLOAD
FSDT_GSX_AUTOMATION_GROUND_EQUIP

Pay attention to the log, which will tell you when an automation feature has been disabled, in place of the operation it was supposed to perform.

rain sapphire
# summer marsh There's a new version with those 4 LVars you can try now, so you can also try th...

Thanks! 😃
Updates to the Beta as instructed and did Test with the new Variables/Settings.

  • FSDT_GSX_AUTOMATION_GROUND_EQUIP:
    • no log message although disabled?
    • works: no Menu Questions regarding GPU
    • no change, still the same: FSDT_GSX_PUSHBACK_STATUS not advancing to 1, FSDT_GSX_DEPARTURE_STATE staying in 4/requestedd
  • FSDT_GSX_AUTOMATION_DOORS:
    • log messages confirming being disabled
    • works: on Service Doors (received toggle for open and close and handled externally)
    • does not work: Variable FSDT_GSX_AIRCRAFT_EXIT_4_TOGGLE is not set to 1 when Rear-Stair connected (could workaround with Stair State I think)
    • Just to be on the same Page: the Cargo Doors are completely handled by the Aircraft, right? (neither saw log messages nor received toggle variables)
  • FSDT_GSX_AUTOMATION_FUEL: no fuel synch via CDU although variable untouched (value of 1 as of Developer View) - set manually then in CDU to continue
  • FSDT_GSX_AUTOMATION_PAYLOAD: no payload synch via CDU although variable untouched (value of 1 as of Developer View)
📎 Couatl.log
summer marsh
#

All those Simconnect exceptions are worrysome (of course I don't have any), you should probably enable the Simconnect diagnostic log, and output to a file in Simconnect.INI, because it's the only way to know exactly what they mean.

lime rose
#

Hello How can I disable door aumation then? didn't understand very well please. Help

north idol
#

@summer marsh
I updated to 3.5.3 and now see that the CDU operation on the 77F doesn't happen anymore, so Fuel and Payload wasn't entered. The doors were triggered but not sure if by GSX or by PMDG because the main cargo door remained open and was not closed after cargo loading.

Since you did not comment here I'm not sure if the reported issues should be resolved or are not. To me it seems like they still persist

north idol
#

Correction: In the log I can see that GSX does some interaction with the CDU, but not for the payload and fuel setting. I do not set/read the new variables, so expected it to behave as before.

Checked the simvar FSDT_GSX_AUTOMATION_FUEL was set to 1 by default and GSX did not type in the fuel. Manually set that simvar to 0 and same result. It appears that this simvar has no effect and the automation is now disabled entirely.

wooden tree
#

i wish teh PMDGs where the same as the Fenix airbus's with the GSX intergration makes alot of sence

north idol
#

Maybe at some point there will be a pmdg2gsx as this is the intention of this request

rain sapphire
#

^ this ^
The current PoC works good so far - even with real (non-CDU) Fuel & Payload Synch on the 777F (and possibly 200ER)

#

And it's not pmdg2gsx, it is Any2GSX with a Plugin for the PMDG-777 🤓

north idol
wooden tree
north idol
#

I know but you are at the wrong place to ask for this. This kind of integration needs to be done by PMDG or third parties. GSX didn't natively implement the Fenix logic. Fenix implemented it from their side (that's how it should be).

So blame PMDG for not caring about GSX integration enough.

#

Possible that "third party" is Fragtality who is working on a separate tool similar to fenix2gsx which would do the pmdg integration as well, but this is not the place to discuss this.

summer marsh
# wooden tree this is what i ment for the PMDGs only the Fenix does this atm i always pic...

That is entirely Fenix own work. They made the automation themselves, based on GSX available documentation, with only very minor help from our side, only to ask for clarifications, but other than that, it's completely their own design.

Clearly, the airplane developers can do an integration much better than we could ever do, they know the airplane, they know what and when it's safe to do something, they have control of the airplane complete UI.

Clearly, the different results in ease of use or reliability, all depends on the developer ability and willingness to support GSX. Fenix is particularly admirable, because they did it BEFORE we officially documented the full "Remote Control" in the SDK.

wooden tree
#

i know what your all saying i was just saying that PMDG need to do somthing like this but ive a feeling they wont

north idol
willow relic
#

How are you guys using this new feature? I would have preferred a simple UI setting, but oh well. Can these SimVars somehow be set automatically? I'm using SPAD.neXt, but I don't want to remember to press a button each time I load into the sim, I would prefer if it could be set automatically

north idol
#

Either you just have a periodic trigger (that's possible with AxisAndOhs) or bind it to a button which you often press (e.g. the camera reset button). Since if GSX restarts it will reset the simvar as well.
Eventually that would be something a program like any2gsx would be setting/monitoring.

willow relic
#

Oh, you are right. I didn't consider that GSX crashes so often and may revert the values. Seems like there is no other way than to run it on a timer. I know you can write proper C# programs in SPAD, I'm still hoping that there is a simpler solution though

rain sapphire
#

Using it more or less like Coppo describes 😉
Any2GSX (more precisely the PMDG 777 Plugin) checks and sets these Variables every Time GSX/Couatl starts. Depending on the Capabilities of the 777 UFT.

#

This Feature/Variables were intended for Addons, not really directly for Users - that is why they are not in the GUI.

willow relic
#

Thanks guys. I guess I will try to work out how to do this with a SPAD C# Script then, I think that should allow me to do what I need

rain sapphire
#

Out of curiosity: what is your Use-Case for that? I.e. why disabling something which then does not get handled anymore.

north idol
#

Disabling GSX door automation to not have PMDG and GSX fight each other

rain sapphire
#

Right, the erratic behaviour of PMDG's Code made the Door-Handling of the 777 Plugin much more complicated that it would need too 😅

willow relic
rain sapphire
#

Hmm messing with the VA, how come?
Yeah the FMC clicking is quite annoying, but it is sadly the only (official) Way to interface with the Aircrafts Fuel & Payload

willow relic
#

My VA checks the ZFW. If I import the Simbrief data in the EFB, everything is fine. GSX then modifies the weights again to some different values. Sometimes multiple times whenever a bus comes. I really just want to load the aircraft once manually, check that the ZFW is correct in the Acars client and then be done with it

rain sapphire
#

Interesting, hadn't seen this Issue on the 300ER (where I still rely on GSX' Fuel & Payload Sync) - as long as GSX also imported the SimBrief Data 🤔

#

So to eventually prevent such Issues with the Stuff I'm working on: what exactly does the VA check on the ZFW? Not being the planned amount when the Aircraft starts moving or something like that?

willow relic
#

Yes, the ZFW is checked once the OUT event is sent (Usually parking brakes off). It can change during boarding (Like Fenix, that's fine). The ZFW needs to be within a certain tolerance, otherwise the flight will be flagged

rain sapphire
#

Ah gotcha, makes sense. But Parking Brake off seems like an odd Event - I mean the Brakes can normally be released if there are Chocks in place

willow relic
#

It usually works fine, once you start the acars client, you would set the parking brakes. It can also be configured to the beacon lights

rain sapphire
#

Great, thanks!
I think my current approach should be fine then 🙂

willow relic
#

It wasn't even too difficult to automate it with SPAD.neXt. If it helps anybody, just add the script in the extra->scripts tab

📎 DisablePmdgGsx.cs
north idol
rain sapphire
north idol
#

nooooice

rain sapphire
#

AND: Services start by importing the FlightPlan in the EFB UFT like with the Fenix 😉

summer marsh
north idol
#

It crashes inflight sometimes, it's nothing new and really nothing you should be surprised about

summer marsh
north idol
#

So you don't expect GSX to crash at all? Maybe we can get rid of couatl_boot.exe again then?

summer marsh
north idol
#

Well and that's the crashes we're talking about.

#

If GSX is restarted inflight, it'll reset your simvars back to enable automation.

summer marsh
# north idol Well and that's the crashes we're talking about.

How you can be sure of the cause, without a log ? The restarter will restart GSX in any case, both if there's an external error, but also if there's a GSX error.

It's quite easy to detect a restart, by checking the FSDT_GSX_COUATL_STARTED LVar, it will go to 0 during a restart and then back to 1, and now there are even extra LVars to monitor the restart progress, but that's probably overkill.

north idol
#

It's honestly easier to just regularly set the simvars to how you need them or monitor them and switch back if they change...

#

And the solution has been posted above, it's not hard.

#

If I check FSDT_GSX_COUATL_STARTED once every minute, and between the checks the simvar flips from 1 to 0 and back to 1, that's not a reliable approach.

summer marsh
north idol
#

Your solution does not work for how I access simvars, but I don't understand what this discussion is about. GSX resets simvars and we have to take care to set them properly again. The way HOW to do it doesn't matter, there are many approaches depending on your tools at hand.
The message you replied to was about the fact that this reset IS done and further discussion shows solutions. That's it.

summer marsh
north idol
#

We're not talking about the "best" solution. We're talking about the problem that GSX resets simvars and we need to make sure that they are set as we need them.

#

You don't know which tools I'm using, so better not try to figure out how much burden something has, ok?

#

Let's stay on the topic of the simvars in this thread.

summer marsh
#

I mentioned subscriptions, and you said it wouldn't, that already indicates your method doesn't allow you to do subscriptions so ?

Do you think GSX should not reset the variables on restart ?

A restart can happen in many ways, because the user quit the couatl engine manually, the user restarted it from the menu manually, or it went back to the main menu and loaded a different aircraft. ALL of these situations are normal cases which will trigger a restart. A crash is just one of them, so even if GSX was theoretically 100% crash proof, you'll still have plenty of situations were a restart might happen normally.

So you just need to deal with it, and if you need to set again the automation LVars, you should do that, in any way you like.

north idol
#

I'm dealing with it. We all do.

rain sapphire
#

To come back to the original Topic maybe ... 😅

#

@summer marsh I see GSX is still doing some Stuff (Service Vehicles? Chocks?) in the CDU although all Vars/Features are disabled. Is that intended?

rain sapphire
summer marsh
# rain sapphire Would be great to hear your Feedback about that <@727319617902608425> 🙂

It would help if you said exactly what's "some stuff" means, because some things are not disabled, since they are an hindrance to GSX normal operation, like the PMDG loaders, that are always being removed if they are there before boarding/deboarding is called. It's different than the automation as such, which does extra things that are not part of normal GSX.

That is, unless you mean "I would like a new, separate LVar for that.

Instead, if you mean that some of the stuff that is supposed to be disabled, are still happening, like fuel/payload entering, for example, would be useful to know exactly what they are and when it happens.

rain sapphire
summer marsh
#

ok, but then you also referred to chocks, and those are not operated if your set the FSDT_GSX_AUTOMATION_GROUND_EQUIP LVar.

rain sapphire
#

Was just a Guess since I don't knew what GSX was doing exactly in the CDU 🙂

#

Vehicles are covered by Any2GSX / the B777 Plugin - so an additional L-Var would be nice, but it is working fine like it is at the Moment since there is no conflict between A2G and GSX checking on the Vehicles

summer marsh
kindred void
kindred void
#

It would be nice if there was a UI switch for this within gsx

tiny geode