Repository navigation
Alternative non-GSX boarding trigger (Fasten Seatbelt sign) for VR & realism #119
Replies: 16 comments 15 replies
|
Unfortunately the majority of the modules (not even the Asobo ones) actually support setting the LIGHT SEATBELT standard SimVar for this, so it means I could never really use it. See here for a controller binding and some history of this: #4 I am currently looking at non GSX supported playbacks so will have a think. |
|
Hi! Thanks for explaining the background and technical limitations regarding SimVars—that makes complete sense! I really appreciate that you're looking into possibilities for non-GSX users. At the same time, I fully understand what a tough challenge it is to find a universal trigger that works seamlessly across all complex add-ons without requiring custom code or breaking full automation. Looking forward to seeing what you come up with! Reading through that other thread you linked to, do I understand it correctly that I could trigger the FastenSeatbelt announcement in UA by binding the seatbelt switch in the PMDG to the ANNOUNCIATOR SWITCH ON/OFF found in MSFS 2024 by using for example SPAD.neXt? Meaning, UA "listens" to the ANNOUNCIATOR SWITCH command in MSFS 2024 and whenever it's set to ON (or AUTO?), the announcement to fasten seatbelts will be played. I don't see an announcement for the reverse, meaning when the seatbelt signs have been switched OFF again. Which would trigger a message like "Ladies and gentlemen, the seatbelt signs have now been switched off. Meaning you are free to move around the cabin but we do recommend you always keep your seatbelt fastened whenever you are seated". Best regards, |
|
Gave it a shot today using SPAD.neXt, making the seatbelt signs switch in the PMDG 737 switched to ON send the ANNUNCIATOR SWITCH ON command which in turn successfully triggered the FastenSeatbelt.ogg file in UA. Now we just need an UnfastenSeatbelt.ogg file being triggered when the ANNUNCIATOR SWITCH OFF command is sent. Such as when you are clear of the turbulence 😉 Based on this and back to the trigger to start boarding and now when I've verified this method works. Would it be possible for you to add the seatbelt sign set to ON (triggering the ANNUNCIATOR SWITCH ON command) as a second trigger next to using the LOGO LIGHTS switch? That would be awesome, not having to switch the LOGO LIGHTS switch ON even during daytime just to get the boarding started. |
|
The new app beta release has the Fenix v3 Airline Packs calls, which includes the new The replacement for the logo lights with the seat belts is a little problematic realism wise as (like running logo lights during the day) in that some airline ops do it as a specific step before arm doors rather than boarding beginning. Also, the Have you considered using the new 1.0.2.1 beta 2 announcements panel or MSFS toolbar UI (the same thing now, due to how many extra manual calls the Fenix v3 can make) to do the 'Play Next' to initiate the boarding? EDIT: I checked the beta 2 release and the ANNUNCIATOR going to off should fire the new |
|
That makes total sense regarding refueling rules and keeping the seat belt signs off during boarding—definitely a crucial safety aspect! Regarding the beta, I completely agree—since you mentioned you need to investigate if simvars can properly report the OFF state, I'll hold off for now and let you look into it first. I really appreciate your openness to feedback and how quickly you implement new and suggested features. Keep up the great work! |
|
It should work now in beta 2, with the simvar announcing the seatbelt on and off using ANNUNCIATOR. One thing I could look at is finding some rare simvar and then letting people trigger 'play next' or something via it, to serve as a general 'start boarding' at the beginning. There's a few never used ones that would work. I could also look at some general keyboard/device bindings for the new announcements panel, e.g. sort of like GSX did with numbers when the window is focused. |
|
One idea in this area is that you can use SPAD.neXT to set the GSX variable values fairly easily I think? That way you can not use GSX but link up anything to trigger things. So if you don't use GSX then you can set things like L:FSDT_GSX_BOARDING_STATE to 5 and the app would take that as boarding etc. Here's what the app reads currently:
|
Correct me if I'm wrong but wouldn't that require that you still have GSX installed? I don't since I want to keep my setup as tidy as possible and not have things I don't use installed. |
|
No, you can set a simvar value from SPAD and it doesn't need GSX installed I don't think. The app is just looking for simvars with those names/values so it doesn't care what sets them in the sim. I'm not really a SPAD user so not sure how to set that up, but thought I'd suggest it anyway. |
OK, that's interesting! Will have a look at it tomorrow 👍 |
|
I totally understand how you mean now and I'm just about to test setting the GSX L-vars directly via SPAD.neXt. Just to be 100% sure before I start: with this approach, I should leave 'GSX Integration' enabled/checked in UA so it listens for those variables, right? If this works as well as we expect, there's really no need for you to look into adding Really looking forward to testing this—it sounds like a brilliant way to achieve a fully automated turnaround workflow for non-GSX setups! Which to UA will be like GSX is installed even when it's not 🙂 |
|
That's great news, will give it a try 👍 Also happy to hear you might have found a good way to allow people to start the boarding without having to switch the LOGO LIGHT ON. |
|
Happy to report it works perfectly now with the seatbelt sign switch in the PMDG 737 where I've used SPAD.neXt as seen below to trigger the announcements whenever I switch the seatbelt signs switch to OFF/ON 👍 I do have another issue/question after having started using generated announcements with placeholders. Where for whatever reason the .ogg files are not regenerated even when the text include placeholders and the SimBrief flight plan is showing it's been refreshed with the correct origin and destination. Will post about that separately since it's not related to this topic and will also include the logfile. Can't do it right now since I'm enroute and want to make sure you get a complete log file. 
|
|
Happy to report I seem to have everything working over here now, using the GSX variables but without having GSX installed. Only did some testing on the ground so far but very much looking forward to do an actual flight. To make sure the logic works as intended all the way from the gate at the origin to the gate at the destination and also, being able to do multiple legs. If you or anyone else is interested, this is how I configured things in SPAD.neXt. About the GSX variables, I could also mention that they were not there from start but seem to have been added when I enabled GSX-integration in UA. This to start the boarding: 
This to start the deboarding followed by a reset of UA to prepare for next leg 3 minutes later: (I know, world record speed in deboarding but that's the beauty of imaginary PAX 😂) Ended with a short delay of 5 seconds before both variables are reset to 0 to make sure they are "fresh" for next leg. 
|
|
Great to hear. I will do those other things for weather source and perhaps tailhook up/down for reset and mute (as that makes it even easier for others just using MSFS bindings ingame as well. Thanks for trying this. I'll update the manual and do a release candidate for all these beta changes now. |
|
Added https://github.com/fearlessfrog/MSFS_Universal_Announcer/releases/tag/1.0.2.3 and will try a test flight over the weekend, but then will update other sites etc as has been a while and some good fixes etc. |
|
Thought I would do a proper test flight today but noticed a problem straight away. After I loaded the flight (PMDG 737-800), UA which started up waiting for boarding to start instead played the Disembark Completed announcement. This was when I just loaded the flight and was sitting in a cold & dark state on the apron. After doing lots of testing, I think I have figured out why this is happening. As mentioned above and shown in the screenshot from SPAD.neXt, I have an event created which used the IFE switch in the PMDG as a trigger to both start the boarding when switched to ON and after the flight, trigger the disembark started followed by the disembark completed announcements when the switch is moved back to OFF. What I think is happening here is when I start the flight with the cold & dark panel state, initially when the aircraft loads in the default/"out of the box" state from PMDG, the IFE switch is in the ON position. A split second later, it loads my cold and dark state where the IFE switch is in the OFF position. I think this is what trigger my event in SPAD.neXt to think I moved the IFE switch from ON -> OFF. Which is turns trigger the actions to set the GSX_DEBOARDING_STATE to 5 followed by 6. Which in turn triggers UA to think the deboarding started (state 5) followed by deboarding completed (state 6) which plays the disembark completed announcement. My SPAD event the finishes off by setting both GSX LVAR:s (boarding and deboarding) to state 0. Meaning, everything is correctly set for next flight. No big deal really other than it feels a bit odd always hearing UA telling me disembarking is completed whenever I start a new flight. Will see if I can fix it by adding another condition to the event in SPAD.neXt saying the uptime of the simulator needs to be greater than 1 minute for example before the event will run. To give everything some time to settle after a new flight has just been loaded. |
|
Even after adding a condition where the sim uptime needs to be greater than 1 minute before my SPAD.neXt event is allowed to execute, I get the same thing when I load a new flight. How UA within 1-2 minutes after I've loaded the flight announces that disembark has been completed. With the aircraft still standing on the apron in cold and dark. I'm quite puzzled right now so figured I would try the new method using the tailhook command instead to reset the flight in UA but when looking for the tail hook up/down commands in MSFS 2024 (and SPAD.neXt) I fail to find them. This is what I see in MSFS 2024 searching through all available commands for the word 'tail': 
|
|
Hi, SET TAIL HOOK HANDLE, the first entry in your screenshot, is the command UA listens for. In SPAD.neXt, use Send Simulation Event with SET_TAIL_HOOK_HANDLE and set its data value to:
If you want to set a '0' using a keyboard or controller action inside MSFS you can hit the 🛞 icon and use 'Device input value override' and set the Input value to 0.00 - that would then trigger the Flight Reset. |
|
I actually just found the explanation in the updated documentation, sorry for wasting your time 😊 One follow-up question though, you mention how I should set its data value to 0. That would have been my next question because in SPAD.neXt, you can see how it's called 'Static Value'. If I choose the icon to the right with the label 'Data Value', the field where I have now put in a '0' changes to a Browse button and clicking that one brings me to 'Select data definition' popup. Also seen below. 
|
|
I don't really know spad.next sorry, just that the simvar needs to be set to 0 so a static value seems likely and worth trying. For the 'cog/wheel' comment I meant the one in MSFS controller bindings UI, as in a way to get to more settings per configuration setting. |
|
All good now 👍 Now when I disabled GSX integration in UA and using the tailhook set to 0 for reset instead, I no longer get the DeboardingComplete annoucement when starting a new flight and I've also checked that both start boarding/play next works (sending the SMOKE ON command) where setting the simvar SET_TAIL_HOOK_HANDLE to 0 (static expression in SPAD.neXt) results in UA resetting. Very happy to have this working now 🙂 The only thing you won't get when using this method vs using the GSX variables is a way to have the DeboardingComplete announcement. Since UA no longer will be able to see GSX_DEBOARDING_STATE change to 6. I do see though how you also mention this in the documentation and how that announcement needs to be played manually for non-GSX users. Fair enough and no big deal. Now it will so great to do a test flight and see how everything works and especially, the newly implemented real time weather reports 🙂 |
|
Actually came to think of one more thing. For those of us using SMOKE ON to trigger UA to start boarding / Play Next, I see how that might interfere with the LOGO LIGHT switch also acting as a trigger for the same thing. Meaning, if you're flying at night time when you switch on the LOGO LIGHTS as part of the preflight, then flipping the switch you have chosen to trigger the start boarding process will instead result in Play next. Which you of course don't want. I suppose one way making sure this doesn't happen is to do it in the right order. Meaning, first flip the switch you have assigned SMOKE ON to and then...switch the LOGO LIGHTS ON. Would be very nice though if it's a simple thing for you to add to have an option on the Tweaks tab where those of us using the SMOKE ON solution could disable the LOGO LIGHT switch acting as a trigger to start boarding. |
|
If you have GSX integration enabled then the logo light is ignored as a trigger I believe? Might be worth a check, as that would be a workaround and you can still use the smoke/tail ways and it saves having to add another tweak setting. |
|
Thought of it but figured it might have some side-effects but will give it a try as a workaround. With that said, I personally think it would be more clean with a proper option now when you so kindly gave us non-GSX users an alternative way to start the boarding. Of course up to you being the developer 🙂 |
|
Forgot to mention I can confirm this is working as a work-around if you don't like to add it as an option on the tweak page. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi!
I hope you're doing well! I'm still using Universal Announcer on every single flight and loving it – it remains an essential part of my setup.
Recently, I decided to completely remove GSX from my system to eliminate background CPU stutters and get smooth performance in VR (currently flying the PMDG 737). As I'm now transitioning to running UA standalone without GSX, I noticed a small immersion obstacle in the manual/documentation regarding the default non-GSX boarding trigger.
Currently, starting the boarding phase without GSX relies on toggling the Logo Light. While I fully understand why Logo Light was chosen (being a standard MSFS SimVar that works across all aircraft and turnarounds), toggling it on during daytime flights breaks cockpit realism, as it's not something real-world pilots do in broad daylight.
Suggestion:
Would it be possible to add a setting/option in UA to trigger the Boarding phase via the Fasten Seatbelt Sign (
LIGHT SEATBELTSimVar) instead of the Logo Light?Why this works so well:
LIGHT SEATBELTis a standard MSFS SimVar supported natively by PMDG, Fenix, FlyByWire, and default aircraft alike.Having this as a configurable option in UA would make standalone mode seamless and completely hands-free for VR users looking for max realism without menu interactions or unnatural light switches.
Thanks again for all your hard work on this great tool!
Best regards,
Richard
All reactions