Author Topic: iFly MAX8 for MSFS - A couple of questions/suggestions  (Read 753 times)

WebMaximus

  • Sr. Member
  • ****
  • Posts: 478
iFly MAX8 for MSFS - A couple of questions/suggestions
« on: November 09, 2024, 11:24:32 am »
Would it be possible to have GSX automatically open the cockpit door when boarding is starting and then close it when boarding has been completed? And the other way around when arriving at your destination, where the cockpit door is opened when deboarding starts and then I guess be left open for next flight.

Also speaking of doors, any chance to have GSX automatically operate the slides to make sure they are armed before pushback and disarmed once arriving at the destination gate?
Richard Åsberg

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51917
    • VIRTUALI Sagl
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #1 on: November 09, 2024, 11:53:27 am »
GSX cannot operate stuff on any airplanes, especially when custom systems are concerned, and something like an internal cockpit door or slides are an example, since they don't have a standard Event we can call associated to them like default systems (a door using a default door ID).

In some cases we can, but that cannot be taken for granted. For example, all the interaction we have with the PMDG, it's only possible because PMDG has an SDK with documented custom events we can use to control custom systems, but it's not something very common, usually it's the airplane developer that reads what GSX is doing, so he can add extra automation on his own.

WebMaximus

  • Sr. Member
  • ****
  • Posts: 478
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #2 on: November 09, 2024, 12:46:31 pm »
Ah, got it.

Maybe we'll be able to see more automation after the iFly has been properly released 🙂
Richard Åsberg

Captain Kevin

  • Beta tester
  • Hero Member
  • *****
  • Posts: 1973
  • Captain Kevin
    • Captain Kevin
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #3 on: November 09, 2024, 10:31:10 pm »
Richard, I don't know if you use either SPAD.neXt or AAO, and if so, I don't know how familiar you are with programming things on there. I can't comment on AAO since I use SPAD.neXt, but at least with SPAD.neXt, if you use the built-in script panel, you could see if there is a variable for the flight deck door. If so, you may attempt to set it up, so when de-boarding is started, the flight deck door is opened, and when boarding is completed, the flight deck door is closed. I've managed to configure it to automatically open the doors on the PMDG aircraft when de-boarding starts and close the doors once boarding is complete. Additionally, I've set the catering doors to open and close automatically.
Captain Kevin

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51917
    • VIRTUALI Sagl
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #4 on: November 10, 2024, 10:30:35 am »
I can't comment on AAO since I use SPAD.neXt, but at least with SPAD.neXt, if you use the built-in script panel, you could see if there is a variable for the flight deck door. If so, you may attempt to set it up, so when de-boarding is started, the flight deck door is opened, and when boarding is completed, the flight deck door is closed.

That might work (or not), visually, but it's not a clean way of doing it, and it's why we don't do it in GSX, unless the airplane has proper Events to trigger such state changes, because you never know what the side effects might be if you just change an LVar tied to some animation. Without even mentioning some planes have custom code running at ever frame, which actively prevents you from doing it.

As an example, suppose a door animation is linked to another internal system, like electrics or hydraulic and this system runs its own internal simulation, which would normally prevent the door to be opened when you are not supposed to. If you act directly on the LVar that controls the door animation itself, it might work visually, but you might cause a loss of sync between the internal simulation of the system behind the door, which is still assuming the door should be closed, but you opened it anyway. That is, assuming it's not actively checking at every frame so, you open the door with the LVar, and the simulation will close it again, because according to its own internal status, it shouldn't be opened.

That's why, even if we could write over variables very easily from GSX, we chose NOT TO, so no airplane developer could complain we might screw up its internal simulation by doing things they don't expect.

The proper way to act on the airplane status safely, is always through K: or F: events instead, which will in turn trigger the whole chain of events that might eventually lead to an effect, like the door being opened. Some examples:

- On a default airplane with a door ID of 0, we don't set the A:INTERACTIVE POINT OPEN variable directly. Instead, we send the (>K:TOGGLE_AIRCRAFT_EXIT) which causes the door to be opened AND the variable to change automatically.

- On the PMDG 777, which has a custom LVar for door 1L named L:7X7XCabinDoor1L, we don't set it directly. Instead, we send the 83637 (>F:KeyEvent), which sends a custom key event that according to the PMDG SDK, triggers opening door 1L, causing the door to open (if possible) AND the L: variable to change automatically.

That's the safest possible way of acting on the airplane status, and it's why we only use this Event->Variable method, and with 3rd party airplanes with custom door controls, only if the airplane has a documented way of doing it and if it doesn't, we either leave the task to the airplane developer himself, which can use GSX LVars to know if GSX expects some door to be opened/closed and open it using its own means, and lacking that, to the user, since every airplane with custom door controls will surely offer some way to controls them.
 
Yes, I understand that we might boast more "compatibility" and automation if we just reversed any L: expression on wrote back to the variable. It might work on some planes, but could have serious issues on others, and the most complex the plane simulation is, the more we would risk affecting it.

Of course, as an user, you are free to experiment with SPAD.neXt or AAO and try on a case by case basis to see if the direct method works for you.
« Last Edit: November 10, 2024, 10:32:25 am by virtuali »

Captain Kevin

  • Beta tester
  • Hero Member
  • *****
  • Posts: 1973
  • Captain Kevin
    • Captain Kevin
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #5 on: November 10, 2024, 09:18:05 pm »
I'll concede the point that my wording might not have been the best, but when I did this with the PMDG aircraft, I set it to trigger the event to open the doors, as you can see here.
Captain Kevin

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51917
    • VIRTUALI Sagl
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #6 on: November 10, 2024, 11:36:47 pm »
I'll concede the point that my wording might not have been the best, but when I did this with the PMDG aircraft, I set it to trigger the event to open the doors, as you can see here.

Yes, that is correct.

I replied that way, because you suggested to see if there's a variable for the flight deck door, so I wanted to explain why manipulating variables directly is not a good idea, even assuming the airplane let you do that, which is not a given.

The best and safest way is through events, but of course not all airplanes (in fact, most of them don't) use the same method with custom event IDs like PMDG.

Captain Kevin

  • Beta tester
  • Hero Member
  • *****
  • Posts: 1973
  • Captain Kevin
    • Captain Kevin
Re: iFly MAX8 for MSFS - A couple of questions/suggestions
« Reply #7 on: November 11, 2024, 07:50:44 am »
Yes, that is correct.

I replied that way, because you suggested to see if there's a variable for the flight deck door, so I wanted to explain why manipulating variables directly is not a good idea, even assuming the airplane let you do that, which is not a given.

The best and safest way is through events, but of course not all airplanes (in fact, most of them don't) use the same method with custom event IDs like PMDG.
We were both trying to say the same thing, I just used the wrong words is all.
Captain Kevin