TOE resupply is based on a batch system. When a vehicle resupply is scheduled for “7 hours from now” the time is converted into a batch number. If two riflemen or two tigers are scheduled for delivery within a few seconds of each other, they are grouped onto the same “docket”.
A docket specifies “1 rifleman was requested to replace the one bobn spawned” or “5 new riflemen for initial supply” etc, and a batch is the list of dockets scheduled for a particular delivery window.
Each docket is assigned a number, which is based on the resupply time when the request was made. Nominally, resupply time is 7 hours, but this can go up depending on RDP delays. If there is a 10% RDP penalty, your resupply time is 7.7 hours.
The time between dockets – the docket rate – is nominally 15 seconds. So requests for vehicles in 150-164 seconds would be placed on batch number 10.
The twist is that rate at which the batch processor pulls tickets off the queue can be variable. It can pull batches off the queue faster or slower. For example, if we implemented “slower resupply further from your DivHQ” the resupply times would remain the same, but by waiting 20 seconds between batches instead of 15, the equipment would arrive more slowly.
This two pronged approach will mean that the population-based supply adjustments – which will affect the rate at which the batch processor takes tickets off the queue – will not undo RDP bombing affects. The two compliment each other.
The result is a more even distribution and scaling of effect between increases and decreases in player population, the epic raids of peak play won’t be total annhilation to the low-peak population and the low-peak heroic raids won’t be a fart in a thunderstorm to the guys logging in after them.