Overview
In RideOps, the Queues and Dispatches sections of a ride's RideOps Settings decide how Operators post wait times and record dispatches on the tablet, and how much throughput RideOps expects from the ride. Expected riders and every utilization figure are measured against these settings, so they need to describe the ride as it really runs.
This article explains each queue and dispatch setting, how RideOps turns them into expected throughput, and what Operators see on the tablet. For the rest of the RideOps setup, see Setting up RideOps. For running a ride day to day, see Operating a ride in RideOps.
At a glance |
|
Who can do this | Super Users, or a Role with Locations › Modify, to change the settings. Operators use them in RideOps. |
Where | Locations › a Location › RideOps Settings › Queues and Dispatches |
Works on | Backend (web) to configure; RideOps on the tablet |
Availability | All organizations. Enable Delayed Dispatches needs the Delayed Dispatches feature. |
💡 Why this matters: Every throughput and utilization number RideOps produces compares what Operators record with what these settings say the ride should do. A wrong capacity or dispatch time skews all of them, so a few minutes checking the values here is what makes the rest of your operating data trustworthy.
Queue settings
In RideOps Settings, the Queues section controls how Operators post wait times:
Maximum Queue Time — the longest queue time, in minutes, an Operator can post. Default 60.
Queue Time Step Size — the interval, in minutes, between the queue times an Operator can pick. Default 5. Smaller steps are more precise; larger steps are quicker to set on the tablet.
Queue Time Update Warning Threshold — minutes without a queue update before the queue widget on the tablet shows a warning. Default 15. The minimum is 1 minute, so you can raise the threshold but not switch the warning off.
Dispatch settings
The Dispatches section describes the ride's capacity and pace:
Number of dispatchable units — how many cars, trains or other units the ride has. It sets how many Cars in use the tablet starts with. It isn't part of the expected throughput calculation.
Capacity per dispatchable unit — how many guests fit in one unit.
Time between dispatches — the expected number of seconds between dispatches on a normal day.
Ideal time between dispatches — the best number of seconds between dispatches the ride can achieve. It's used when you switch the Ride Throughput or Ride Capacity Utilization dashboard widgets to Ideal. If you leave it blank, Time between dispatches is used.
Dispatch Update Warning — minutes without a dispatch before the dispatch widget shows a warning. Default 15, minimum 1.
Minimum time between dispatches — seconds the Dispatch button stays unavailable after each dispatch, so a double tap isn't recorded as two dispatches. It's off unless you set it, and only the tablet enforces it.
Enable Delayed Dispatches — lets Operators mark a dispatch as delayed and pick a reason. It appears only if your organization has the Delayed Dispatches feature.
Enter the pace on the Seconds/Dispatch tab (Time between dispatches and Ideal time between dispatches) or on the Riders/Hour tab (Riders per hour and Ideal Riders per hour). Mobaro converts between them using Capacity per dispatchable unit: riders per hour = 3,600 ÷ seconds between dispatches × capacity per unit.
How RideOps calculates throughput
RideOps treats each dispatch as one unit leaving the station. Expected riders for a period are the time the ride was open, divided by Time between dispatches, multiplied by Capacity per dispatchable unit. Number of dispatchable units isn't multiplied in.
Setting | What to enter | Example |
Number of dispatchable units | The units the ride has | 3 trains |
Capacity per dispatchable unit | The seats in one unit | 20 |
Time between dispatches | Seconds from one unit leaving to the next | 60 |
With these settings, RideOps expects 1,200 riders per hour (3,600 ÷ 60 × 20), which is what the Riders/Hour tab shows. Adding a fourth train doesn't change the figure unless trains leave more often, so set Time between dispatches to the real gap between departures.
On a ride where everything moves at once, such as teacups or a flat ride, treat one cycle as one dispatch. Because RideOps counts one unit's capacity per dispatch, set Number of dispatchable units to 1 and Capacity per dispatchable unit to the capacity of the whole ride so expected riders match reality.
🛑 Critical: Enter the capacity of one unit in Capacity per dispatchable unit, never the total for all units. In the example, entering 60 instead of 20 triples expected riders, so every utilization figure shows a third of the real value.
What Operators see in RideOps
Queue widget — the Operator sets the queue time, up to Maximum Queue Time in steps of Queue Time Step Size, and taps Update Queue Time. The card shows Last updated and changes to a warning once the threshold passes.
Riders widget — the Operator enters the riders (or empty seats, if the widget is set to count empty seats) and taps Dispatch. Cars in use starts at Number of dispatchable units and can be lowered if a unit is out of service. Unavailable Seats records seats that can't be used, and lowers the capacity counted as available for that dispatch. With delayed dispatches enabled, Delayed lets the Operator pick a reason.
The day-to-day steps are in Operating a ride in RideOps.
⚠️ Heads-up: The Riders and Queue widgets show only while the ride is open and ready for operation. If a handover note becomes active, a critical Assignment or required check comes up, the Preopening Checklist's validity runs out, a Blocking Downtime starts or a mandatory Position is left unstaffed, RideOps replaces them with Not ready for operation until it's cleared. The ride isn't closed. See Handover notes.
Best practices
Check capacity against the real seats. Count the seats in one unit rather than copying a total from a spec sheet.
Set realistic times. Use what the ride achieves on a normal day for Time between dispatches, and its best achievable gap for Ideal time between dispatches.
Match the step size to the ride. Use a smaller Queue Time Step Size on busy rides where waits change quickly.
Cover the whole day with the Preopening Checklist. Set Preopening Checklist Validity (minutes) long enough that an expiring check doesn't interrupt dispatching mid-day.
Frequently asked questions
What's the difference between Time between dispatches and Ideal time between dispatches?
Time between dispatches is the ride's normal gap and sets expected riders everywhere. Ideal time between dispatches is the best achievable gap, used only when you switch the Ride Throughput or Ride Capacity Utilization widgets to Ideal. Left blank, it uses Time between dispatches.
On a ride where all the cars move together, like teacups, what counts as a dispatchable unit?
Treat the whole ride as one unit. RideOps counts one unit's capacity per dispatch, so set Number of dispatchable units to 1, Capacity per dispatchable unit to the seats across all the cars, and Time between dispatches to the time from one cycle starting to the next.
Can I correct a queue time or rider count afterwards, or add a missing one, from the desktop?
Yes, in the Location's Operational Log in the Backend: Edit Activity changes an entry and Create Activity adds one. You need Super User or Operations › Manage Dispatch Entries (or Manage Queue Entries). See Updating and adding to the Operational Log.
We opened the ride but can't enter dispatches anymore, and a checklist is showing again. Why?
The ride stopped being ready for operation, so RideOps hid the Riders and Queue widgets. A common cause is the Preopening Checklist's validity running out; complete it again. A handover note, critical Assignment, required check or Blocking Downtime does the same.