This is primarily for @brklinck and others who’re interested in the inner workings of the TP software.
= The Problem =
A user reported an issue with plan 2765011, an Animal Kingdom plan that was ‘Evaluate Only’ and had the ‘Force Use of Fastpasses’ flag set to yes.
The Optimizer was not using the 10:30 a.m. Fastpass for Kali River Rapids, even with the ‘Force’ flag on. Instead, it was telling the user to ride Kali around 9:20 a.m., with a posted wait of 4 minutes.
Internally, the Optimizer looked at it this way:
If we ride now, the wait is 4 minutes.
Or we can have 70 minutes of free time, then ride with a wait of 1 minute
Keep in mind that the Optimizer tries to minimize the sum of Walk Time+Wait Time+Free Time.
The ‘cost’ of the first option is 4 minutes. The ‘cost’ of the second option is 1 minute of wait + the cost of 70 minutes of waiting. Obviously, free time is ‘better’ than waiting in line, so it should have less cost. Internally, the Optimizer considers free time at a 90% discount to wait time (that is, 1 minute of free time = 10 minutes of waiting in line).
Thus, the cost of the second option is (70 * .10 ) + 1 = 8 minutes
The Optimizer was therefore taking the first option at 4 minutes of cost, versus waiting and incurring an 8-minute cost.
In fact, the optimizer would take the second option even if it resulted in just 1 minute of savings.
= The Solution =
It’s kind of needlessly strict for the Optimizer to ignore a user’s wishes with the ‘Force Fastpass’ flag if it only results in a couple of minutes of lost time. When the results are that close, we should prioritize what the user wants over a few minutes of savings.
If the user is in ‘Evaluate Only’ mode AND the user has specified ‘Force Fastpass’ AND the loss of free time is 20 minutes or less, then the Optimizer will now add free time so that the FP is used.
This change should be released this week. Let me know if there are any questions.