If you were looking at a absolute history - yes. But instead, we are talking about abstracting into a model - that you apply to discuss not just history, but behavior overall. When talking about 'how does LL impact attractions' -- No one cares about Jan 12th at 9:04am - They want to understand how it applies so the comprehension can be applied more broadly. Which is why you consider the steady state - not the transition period from zero startup.
And because it varies over time, you should care about the ramp up period. Also, if and when it hits its tipping point. And whether, because of the tipping point, the wait is getting longer or shorter.
No - you don't. The ramp up period is throwaway because it's meaningless to apply to other scenarios. It's unique to it's own situation and not representative of the broader solution. AKA 'true - but meaningless'
Stop hurting my brain. You can't declare you want an instantaneous picture without caring what happened before, and yet you then put the whole thing into motion talking about throughput and feedback loop. And then you put an artificial limit on what you're looking back on without saying how far back and without starting where you should start: at the start of the day.
When did I say I want an instantaneous picture? The whole point was about what the impact of pulling capacity out of the throughput was to the system.
Customer load is not fixed or pre-determined -- it's a function that includes the current posted wait as feedback. Customer load doesn't care if the ride was in a deficit or not 6hrs ago.. it cares about what the system has converged to now. The balancing happens over a lookback period that is shortened by the feedback loop.
If customer demand were pre-determined and immutable, you could map out the posted wait at any point in the day if you knew the ride's operational time... but demand isn't immutable, it's dynamic based on the inputs the customer takes in when they determine to get in line or not. This is exactly why popular rides wait times will recover and converge back to 'normal' waits after an interruption. The wait time will recover eventually because demand will decrease due to the posted elevated wait time.. reducing the demand and reducing the accumulating queue... until the wait time reduces enough to the point to customers are satisified to accept the posted time and get into queue again.The inflow into the queue is a function of customer interest which in itself is influenced by wait times. This is a feedback loop.
Rides only recover when the rate of guests (standby and LL) getting on line is less than the rate of the rides throughput, i.e., less than the tipping point. And that only occurs viewing the line over time, not an instantaneous scenario that came out of nowhere.
Again with this instantaneous non-sense you've dreamt up in your own head. I can't speak to strawmen you dream up.
In a mathmatically sense we would describe the concern you raise... the accumulated backup from some prior point in time... as approaching zero as time moves forward. This is because of the feedback loop that leads to customer influx rate to decrease (when waits are abnormally high). This allows the queue to 'catch up', until the wait time approaches a more acceptable time, and eventually you reach a balance point where customer interest and wait time balance out.
The prior backup you point out is something the formula works its way out of over time... hence it's not interesting when describing how the system operates with it's major parameters. It's a chunk that gets washed out over time.
Contrast that with something like.. LL capacity allocation.. which doesn't converge to zero or get washed out over time.
