7:57:30 isn't exactly perfect, but it's close enough considering, for all I know, Demarke just randomly pulled it out of a hat. The actual "perfect" time to load the app would 7:58, since it's smack dab in the middle of the 1-3 minutes before opening that we've determined as "safe".
This issue is kind of tricky, which is what makes it so annoying -- especially since there doesn't seem to be any good reason for the app to be making these API call automatically anyway. But let's work through some examples (times are approximate):
7:55
7:57:30
- 7:55 - getQueues called on app load (expires at 7:56)
- 7:58 - getPositions called automatically (expires at 7:59)
- 8:00 - Queue opened, both API calls available
Here's one where you could possibly get bit by the automatic calls to getPositions:
- 7:57:30 - getQueues called on app load (expires at 7:58:30)
- 8:00:00 - Queue opened, both API calls available
- 8:00:30 - getPositions called automatically, but the queue is already open (and you should have gotten a BG by now anyway) so it doesn't matter
7:56:30
- 7:56:30 - getQueues called on app load (expires at 7:57:30)
- 7:59:30 - getPositions called automatically (expires at 8:00:30)
- 8:00:00 - Queue opened, only getQueues is available for the next 30 seconds
Great information on this forum on the best strategies for giving yourself the best odds of getting on a boarding group.
Does anyone have any information on the best size party you should have to increasing your odds of getting on a boarding group? My family has 4 people in it and we are going with another family of 4. We are all linked together in the app.
Is it better to keep our families separated and try for parties of 4 or have all of us try for a party of 8? To clarify there are only two adults per family, so only 4 of us will be running the app and trying to get on.
Thank you,
If you only have the people linked to your MDE account that are actually with you (so everyone with you is tapped through the turnstiles), you can just hit "Select All" at the party selection screen. You won't be loosing time while you select people. I've not heard anything about the size of your group interrupting your position in boarding groups.
It's technically no better or worse as long as you keep the app open after you load it at 7:55. You would have both API calls available at 8:00 either way. The situation just gets more complicated, and more difficult to give simple advice for, when you load the app three minutes or more before the queue opens. It's easier to just say "load the app at 7:58" than "load the app between, oh, a little after 7:57 but before 7:59, or 7:51-7:56, but not 7:56-7:57 or 7:50-7:51".So why would 7:58 be the best time when 7:55 has both calls available at 8:00am? That is the ultimate goal after all, to have those 2 bites of the in your hip pocket waiting to go
Do I need to take into account how long it takes my app to load? My phone usually takes between 11 and 15 seconds. Do I add that time on to open (theoretically) at 7:57:45-7:57:49?It's technically no better or worse as long as you keep the app open after you load it at 7:55. You would have both API calls available at 8:00 either way. The situation just gets more complicated, and more difficult to give simple advice for, when you load the app three minutes or more before the queue opens. It's easier to just say "load the app at 7:58" than "load the app between, oh, a little after 7:57 but before 7:59, or 7:51-7:56, but not 7:56-7:57 or 7:50-7:51".
It's technically no better or worse as long as you keep the app open after you load it at 7:55. You would have both API calls available at 8:00 either way. The situation just gets more complicated, and more difficult to give simple advice for, when you load the app three minutes or more before the queue opens. It's easier to just say "load the app at 7:58" than "load the app between, oh, a little after 7:57 but before 7:59, or 7:51-7:56, but not 7:56-7:57 or 7:50-7:51".
You don't have to so much for the earlier time, because the 3 minutes (which is actually more like 2:57) is measured from the initial call to getQueues, which happens after the app has loaded. You do have to take your phone's loading speed into account for the absolute latest time you should start the app, which is 7:59. I think you should give yourself a 15 second cushion either way, regardless of how long it takes the app to load.Do I need to take into account how long it takes my app to load? My phone usually takes between 11 and 15 seconds. Do I add that time on to open (theoretically) at 7:57:45-7:57:49?
Yes your assumption is correct, only the people with us are linked in my MDE account. So yes using the "Select All" option would be the quickest. Thank you for the information that party size should have no influence on the outcome.
Has anyone rope dropped MMRR and gotten a boarding pass? Are you in the MMRR building or does the queue just wait outside until park opening? Just wondering if the wifi/data is okay in the building if you are in there at park opening time. Thanks!
I definitely recommend doing what works for you and what you're comfortable with!Yea I do keep it open and I move my finger up and down so the screen NEVER locks on me. So I pulled a BG2 by loading app at 7:55am on Sunday, gonna do this until it burns me
Yeah, probably wasn't the best way to word it. What I meant is that the "lockout period" for that API call expires at those times, if that makes sense. The app itself keeps track of when it last made each API call. If you try to call it again before the 60 seconds are up (by pressing the button again), it just does nothing. No communication with the server.And 1 last clarification point (thank you for your patience in all of this): when the app makes/requests these API calls and you say it “expires”, is the app “holding the status” or constantly “pinging in the background” for the 60 second length of time (and checking) or is it just checking the status at that EXACT MOMENT and then not looking for anything again for 60 seconds?
The way you worded it made me think it constantly checks over and over within that 60 second time frame (like multiple fetch attempts over and over).
And 1 last clarification point (thank you for your patience in all of this): when the app makes/requests these API calls and you say it “expires”, is the app “holding the status” or constantly “pinging in the background” for the 60 second length of time (and checking) or is it just checking the status at that EXACT MOMENT and then not looking for anything again for 60 seconds?
I definitely recommend doing what works for you and what you're comfortable with!
Yeah, probably wasn't the best way to word it. What I meant is that the "lockout period" for that API call expires at those times, if that makes sense. The app itself keeps track of when it last made each API call. If you try to call it again before the 60 seconds are up (by pressing the button again), it just does nothing. No communication with the server.
Bingo!Ok so I THINK I finally understand this (after reading this over and over and over) as I have this compulsion for knowing EXACTLY how something “works”.
So the reason why loading the app at both 7:55 & 7:57:30 works and has both API calls available is because:
7:55 - the GetQueues is again available at 7:56 and doesn’t auto request unless you request it by clicking FIND OUT MORE at 8am?
- GetPositions auto requests 7:58and expires prior to 8am (7:59) and this one would auto call again but it not until post 8am and you’ve likely already requested it yourself OR nabbed a group/hard closed the app and trying again
7:57:30
- GetQueues ready to go at 7:58:30 and doesn’t auto update again prior to 8am
-GetPositions doesn’t even get a chance to auto update prior to you attempting to trigger it
@JoelOk so I THINK I finally understand this (after reading this over and over and over) as I have this compulsion for knowing EXACTLY how something “works”.
So the reason why loading the app at both 7:55 & 7:57:30 works and has both API calls available is because:
7:55 - the GetQueues is again available at 7:56 and doesn’t auto request unless you request it by clicking FIND OUT MORE at 8am?
- GetPositions auto requests 7:58and expires prior to 8am (7:59) and this one would auto call again but it not until post 8am and you’ve likely already requested it yourself OR nabbed a group/hard closed the app and trying again
7:57:30
- GetQueues ready to go at 7:58:30 and doesn’t auto update again prior to 8am
-GetPositions doesn’t even get a chance to auto update prior to you attempting to trigger it
@Joel
Is there a specific app opening timing that would lead to both the Red (Find out More) Join Boarding Group and Blue (My status) Join Boarding Group to be grayed out at 8:00? Because that definitely happens sometimes....
My experience from today - don’t do it. The signal inside the building is very poor. The line to MMRR opened into the building and we inside before 8:00. I had to restart the app several times. We got Backup Group 101 and they are closing Rise at 98. Epic fail!
We talked to the cast members who said that they don’t reopen the groups after sending notices of cancellation even if they get the ride back open. It stinks that Rise was running again at 5:30. But because they prematurely sent notices I’m SOL. The Guest Service rep acknowledged that the signal inside the building is poor but wouldn’t do anything for us.
Hope for better luck tomorrow.
That’s awful. Thanks for the warning!My experience from today - don’t do it. The signal inside the building is very poor. The line to MMRR opened into the building and we inside before 8:00. I had to restart the app several times. We got Backup Group 101 and they are closing Rise at 98. Epic fail!
We talked to the cast members who said that they don’t reopen the groups after sending notices of cancellation even if they get the ride back open. It stinks that Rise was running again at 5:30. But because they prematurely sent notices I’m SOL. The Guest Service rep acknowledged that the signal inside the building is poor but wouldn’t do anything for us.
Hope for better luck tomorrow.
Register on WDWMAGIC. This sidebar will go away, and you'll see fewer ads.