Two of my goals this year are to make the touring plan software faster to run and easier to maintain.
In looking at the code, it’s clear that one set of scenarios adds a ton of complexity and runtime: When you’ve got 1 or more reservations and multiple requests to ride the same ride.
For example, you might have 1 Genie+ reservation for Jungle Cruise and want to ride it twice. Or (in the old Fastpass+ days) 2 day-of Fastpass+ reservations for Jungle Cruise, and 3 “Ride Jungle Cruise” steps.
In those cases, it’s a lot of work to figure out the best way to assign reservations to rides so that your overall wait is minimized.
I’d like to eliminate as much of that complexity as possible. It would make the code simpler to work on, and faster to run.
One of the ways to do that is to ask y’all, when you’re using “Evaluate Only”, to specify which ride reservation goes with which request to ride that ride.
For example, in the image below, there’s a step that obtains a Genie+ reservation for Jungle Cruise and two “Ride Jungle Cruise” steps.
How difficult would it be for y’all to say “I want to use this reservation for the ride in this step”?
Assume that we’d give each step its own unique ID (as shown), and give you the ability to say which reservation gets which step.
This would only be for:
Evaluate-Only scenarios
With multiple ride reservations or ride steps for the same attraction
Not at all!! As a matter of fact this is a feature I’ve been craving. So often TP wants to use the G+ when it might save a couple minutes, but not really be “optimal” for my own plans.
I’ve had TPs start out so well in the first drafts & set-up only to get thrown completely out of whack when the code wants to insist I use the reservation when it tells me to during when I “Evaluate”! Thanks!!!
I use Evaluate most of the time. If I want to ride something twice then either I’ll know when I want to use the G+ or I can work it out from the predicted wait times.
I see the shorter evaluation run time as a big plus for making ad-hoc decisions later in the day as to whether or not to double down on an attraction or not.
I often wish I could do this! Because you know us evaluators already have a good sense of what we want to do when, we just want TP to tell us whether it is feasible. For me those second and third rides are the “can I push my luck ones”.
I almost exclusively use Evaluate. Optimize is only useful for me to get a FIRST DRAFT of a plan. After that, I manually arrange things and evaluate to see how it does. (Sometimes, I can come up with an order that out-performs Optimize.)
To me, it only makes sense, then, that I would manually assign reservations and evaluate. If I don’t like it, I could manually swap them and evaluate again.
What MIGHT be nice, however, is if the interface knew about a LL, and then provided me a means to assign via maybe a checkbox/radio button which of the entries to pick. This way I could just tap on the first Jungle Cruise (using your example) to assign it to that one before evaluating, and if I don’t like it, I could tap the second Jungle Cruise, and it would switch the LL to that one automatically. (As opposed to having to re-order the steps manually or something.)
Mostly, though, I just wish that when I hit Evaluate, it would actually reload the screen when the evaluate finished, rather than making me having to manually reload. (I’ve never seen this work where it automatically refreshes the page after evaluating.) Right now, if I evaluate, it will say something that the current action was being calculated for 2 seconds…and 20 seconds later, it still says this (2 seconds). I finally just have to reload.
I envision something like this - Each “Get a LL” step will have a widget that lets you select which of the “Ride” steps to associate it with. Or to un-associate it, if you want to try something else. Let me see if I can mock it up.
One of the reasons why I wanted a step-specific identifier for these things is that concepts like ‘first’ or ‘in step 12’ can be changed by the user. A unique ID that moves with each step seems like it would work better.
To me, it sounds like the solution that is convenient for the programmer, but not the end user.
I guess what I mean is you might had at the top of the plan the list of your LL’s. So, maybe it says there is a LL for Jungle Cruise and an ILL for Tron.
Then, in the list of steps, if there is only one Tron, it should automatically associate it with the appropriate step. But if there are two Jungle cruises, then that step would offer the option to “Use LL”…if selected, it would automatically “grab” the appropriate LL. If I select the other Jungle Cruise, it would automatically disassociate the first and use the second. I shouldn’t need to care about IDs as an end user.
I literally just used the updated software yesterday and while there are a ton of improvements I have been really struggling with the “Get a LL” functionality. Like @ryan1 I optimize once to get an idea and then generally evaluate only after that. But my plan was then having me get LLs for times that I wasn’t actually going to ride the ride so it was a waste.
This sounds incredibly complicated with evaluate, but if you just had “LL eligible” placeholders and then let me choose which LL I wanted to get at that time, I think it would work well. I REALLY like how you are estimating what time the return time will be.
Hm. I guess I’m not explaining myself. My suggestion involves ZERO guesswork on the part of the software. The end-user merely selects which Jungle Cruise they want the LL for within the step itself.
I don’t have a way to mock things up. But the point is, if there is a Jungle Cruise LL listed for the touring plan, the user can then select which of the two different Jungle Cruise steps it is by simply ticking off the checkbox that would show up for the Jungle Cruise steps. As the user, I can select one or the other. If i select the first, then the LL becomes associated with that one. If I select the second, the LL becomes associated with the second one. If I select the second after having selected the first, it would just disassociate the LL from the first one and apply to the second one.
There is no need to have unique IDs shown to the end-user in any of this…and there is no guesswork on the part of the software.
Ah, I see. Okay, for the purposes of this discussion, assume:
Two “Get a Genie+ reservation for Jungle Cruise” steps exist in the plan
At least four “Ride Jungle Cruise” steps exist in the plan
One of those “Ride Jungle Cruise” steps happens before the first “Get a Genie+ reservation for Jungle Cruise”
Then in the first “Get a Genie+” step, when we display the 3+ checkboxes for the user to select which “Ride Jungle Cruise” step they mean, how should the software refer to each possible “Ride Jungle Cruise” step?
My concern is that using words like “first” or “Step 5” are a relative ordering that can change when the user moves things around. It seems like a lot of work for both the system and the user to keep track of, and update what was meant.
I think perhaps @ryan1 is meaning we don’t need to see the ID in the plan.
So when the different options are displayed to select which one to use this LL for, the app code would have the ID associated with each one but the user would not see that.
Perhaps the app could simply show A, B or C, whilst hiding the unique ID of that step. So the UI is more user friendly.
So the code behind it might get say
IF ride-ID = ‘RQH43217” then DISPLAY “Jungle Cruise A”
That’s an implementation detail. I presume each step in a plan has some kind of unique ID that the software uses to identify it…but that ID is not something the end-user ever sees nor cares about.
So, it shouldn’t be a problem to have 3 LLs for Jungle Cruise, and 4 steps. That just means the software would allow the user to select 3 of the 4 Jungle Cruises.
Now, I can see where this might pose a problem to automatically deselect one. In this case, I guess you could instead just pop-up a warning message that indicates all LLs for that ride have been assigned. This means the end user would have to deselect a different one first. One extra step for the user which seems reasonable to me, so that they are aware they have used all available LLs for a given ride already.
Of course…I do have a bigger concern in all of this. That is…how does the Evaluate take into consideration the availability of such LLs? I kind of would expect that when I evaluate, instead, the software would recommend which LLs to try for, rather than me putting them in manually anyhow. I might WANT a LL for Jungle Cruise…but in my plan, it might not make sense because the next available LL might be well beyond anything in my plan.
(I recognize the complexity that dealing with G+ is in all of this…)
How should the UI refer to each possible “Ride Jungle Cruise” step for the user? What text shows up next to the checkbox to explain to the user what it is they’re choosing?
Ah, thank you. Okay, let’s assume we have “A”, “B”, “C” and “D” for each “Ride Jungle Cruise” step. That’s doable.
Some scenarios to consider:
The user deletes the “(D) Ride Jungle Cruise” step and the “(A) Ride Jungle Cruise” step, and adds another “Ride Jungle Cruise” step. What letter do we assign to that new step? I’m thinking it’s either A, D, or (a new letter) E?
I think ‘E’ would be less confusing, since the user just deleted A and D. The assumption there is that the user will not find it confusing that the remaining steps are labeled B, C, and E. I think I’m okay with that.
