What do you want in the next version of Lines?

This raises a question that ties to one I asked a week or so ago, but no one answered…

So, the “times” that are used for planning, I’m left wondering how the “back end” time is calculated.

Space Mountain is a good example. If the wait time is the time from when you get in line to when you board the ride, and the ride time is the time it takes to actually be on the ride, then what about the time it takes to walk from the point you exit the ride vehicle itself to when you exit Space Mountain entirely? It is a rather long walk. Is that time always included in the walk time to the next ride? Or is it unaccounted for?

Astro Orbiter is the case I wondered about as well. The ride time is listed as like 2 minutes, but after I get off the ride, I still have another two minutes (give or take) to wait for the elevator and take it down. How is that time being accounted for? Is it built into the wait time? But then, how does a ride like Space Mountain account for walking speed?

I think without the numbers for time off the ride to actually being outside, ready to head to the next attraction, it throws things off. For a lot of attractions, it might not matter so much…but others, it does make a difference.

It’s probably answered elsewhere, but I was wondering about “mandatory queues”, for instance, the pre-ride video at Dinosaur. Are these included in the ride time? The wait time?

1 Like

I much prefer (a)

1 Like

Also, if you added the location services, you could spend a lot of money and develop a system that estimates my walking pace, so the plans can be adjusted (just like kindle estimates my reading speed)?

1 Like

Actually, it looks like it sorts alphabetically, then by Super Land for dining. I’d rather have it all together by Super Land.

1 Like

I think it would make a lot of sense to use that data.

(a) since it will be right-aligned.

I second the push notification about a ride re-opening!

2 Likes

So if it was a), and right-aligned, that would effectively do what you are saying, as the times would all be lined up on the right, but the labels (Arrival, Wait, etc.) wouldn’t be lined up like they are in your post (where they are left-aligned).
And I’m good with that … I agree with the point about currently having to ‘work’ for the numbers.

I would not have a problem with that. If it’s using GPS data, it could more accurately know where I am when re-optimizing, right? :slight_smile:

2 Likes

Well, they would only light up if right-aligned if they had the same exact number of characters/digits in a mono-width font. Which is why I think the numbers should be left justified, but for the numbers only, and the labels right-justified. This can be done fairly easily in HTML.

1 Like

Ohh – I agree with the archiving old TPs – I can see them on the web version, but no need to see them on the app!

Super Land makes me feel like I’m in the park (from 2000 miles away)!

2 Likes

Definitely (a) when right aligned.

Maybe this is more for the website, but it would be nice to get estimates for ride times at park opening if you arrive one hour before park opening or 30 minutes before park opening etc. and “rope drop” something. Right now the ride estimates are all very long for the start of the park day.

2 Likes

I prefer a whether right aligned or left. But I never can resist not including a colon in the title for any presentation I have ever given, so I may not be the best judge…

1 Like

It would be great to be able to “lock” an attraction when optimizing. If we know we want to do an attraction at a specific time (a potentially nausea-enducing ride prior to our dining reservation or a water ride when it is hot)… it would be great to be able to do that.

5 Likes

Yes, maybe sort of like putting in meals anchored around a time? +/- this many minutes of HH:MM

Or mid-morning break in the mid-morning, not at RD. lol.

I am curious. Do you build your touring plans on the app or the website?