News Star Wars: Rise of the Resistance Standby Line and Boarding Groups at Disney's Hollywood Studios

[DCBaker]

4:35pm - caught in another pause. The last group (90) was called roughly ~30 minutes ago.

 

[KevinPage]

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: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

7:57:30

• 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

Here's one where you could possibly get bit by the automatic calls to getPositions:

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

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

 

[DCBaker]

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.

 

[chicorage]

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.

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.

 

[Joel]

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

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".

 

[Darstarr]

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".

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?

 

[KevinPage]

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".

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

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).

 

[Joel]

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?

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.

The one thing I really don't like about telling people not to start the app until a couple of minutes before opening is if the app asks you to log in, as it sometimes randomly seems to. I would rather there be a solution where you can start the app plenty ahead of time and make sure everything's working fine, so you aren't panicking over something unexpected right before the moment of truth.

One method that should work:

1. Load the app whenever.
2. Tap Find Out More, then My Status. Stay on the Boarding Status page.
3. 7:58: hit the home icon in the bottom left corner.
4. 8:00: Tap Find Out More
5. Is Join Boarding Group enabled? Tap it and finish the BG process.
6. Otherwise, tap My Status.
7. Is Join Boarding Group enabled? Tap it and finish the BG process.
8. Otherwise, force close and reload the app.

Another possible option:

1. Load the app whenever.
2. 7:58 or earlier: Tap Find Out More, then My Status. Stay on the Boarding Status page. Don't swipe down to refresh.
3. 8:00: Go back to the previous page.
4. Is Join Boarding Group enabled? Tap it and finish the BG process.
5. Otherwise, tap My Status.
6. Is Join Boarding Group enabled? Tap it and finish the BG process.
7. Otherwise, force close and reload the app.

 

[KevinPage]

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.

One potential caveat to this, and I can’t speak with absolute authority or 100% certainty, but I asked this question previously in the sense that:

- the more people you have, the more admission ticket status’s the system needs to check so potentially if one of those requests gets hung up or lags, it could cost you time. But you really wouldn’t have any idea (if there was an issueunless you get notified of a specific issue.

I haven’t read any reports of big parties sizes being an issue. Any one the day and time you go for a group could have a better or worse connection between your cell carriers connection to Disney’s servers than a party of 1 standing next to you.

Lots of variables to this whole process, which high makes semi nerve wracking. But knowing the screens, timing and flow gives you a huuuuge leg up on the competition (assuming no MDE glitches)

 

[nyrebel3]

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!

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.

 

[Joel]

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

I definitely recommend doing what works for you and what you're comfortable with!

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).

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.

 

[flynnibus]

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?

It's the concept of a cache...

You look something up and hold the answer.. then you start a timer
During that timer, anyone that asks for the same question... you give them the answer you were holding onto you got the first time you lookup up the question. You don't look it up again, just give the answer you already had.
When the cache timer expires.. you consider the data old or 'stale'... so next time the question is asked, you go and lookup the answer... and start the expiration timer again.

It's a performance technique. You improve response time by not having to go and lookup the answer fully.. and it reduces load on the target because you answer a ton of queries without even hitting the target.

 

[KevinPage]

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.

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

 

[Joel]

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

Bingo!

 

[DCBaker]

6:30pm - group 97 was called just before 5:35pm and looks to be the last group of the night.

 

[disneygeek90]

Me reading through these posts:

Everything certainly sounds logical. Now I’m second guessing what I’ve done during my refresh/Demarke methods and thinking maybe my timing was off. I’m definitely down to give it a go again but it seems like the worst case default is to restart the app so why not reload it right at 8 to avoid potentially losing even more time? I think a case could be made fresh and geeky is still the safest approach.

One thing that’s made me nervous lately is the inexplicable dropping of friends or even the main account being completely removed from the friends list when it comes time to selection. I wonder if using the method of sitting on the app would do anything to sure this up but it really only seems like the app searches for your friends list once join boarding group is pressed.

 

[DisneyPirate123]

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

@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....

 

[jinx8402]

@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....

Perhaps launching the app between 7:56 and 7:57. if you tap find out more just a second too early and use up that api call, and the background api call after 3 minutes also fires before 8 am.

 

[krause]

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.

Oh no! That’s too bad. Yeah we only have the one day to try so I don’t want to mess it up by being in that building. Thanks for the reply!

 

[DisneyPirate123]

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!

What cell provider were you using or were you using WiFi?