Howdy, Stranger!
Queue Feedback
Rokas
Member Posts: 180 ✭✭✭
I'm a pseudo-fan of the queue changes, because I remember that when I first started working on my system, I was frustrated by the queue being limited to one command. It made some things more tedious than I would have liked, such as having to walk through defenses instead of queuing all and forgetting, but the way the queue actually functioned was superior from a system-design standpoint.
I've been thinking how best to utilize an actual queue, and aside from streamlining some lazy aliases I made with coroutines, the optimal approach for a system is to clear the queue and only queue the next action.
Assume that a system wants commands P, Q, R, S to be fired, in that order.
- If P fires and fails, the queue is now QRS but the system will still want PQRS. Reconciliation is either to insert P at the top or clear queue and queue PQRS again.
- The queue is PQRS but the system determines it should be PRQS. Reconciliation is to clear queue and queue PRQS.
The code paths get easier by opting to always clear the queue. If there's any inconsistency between system and queue, do a hard reset and avoid any complex logic to determine if there's a more "optimal" way to fix it. But once you're at the point of having the system clear the queue, the next optimization to make is to only ever queue one action. No reconciliation is necessary if PQRS becomes PRQS if the system only queued P.
Which leads us to, in effect, the old queue.
I can appreciate why the change was made to enable server-side queuing to interject itself and prevent a person from queuing themselves to death by not giving autocuring a chance to pull arrows or dig out shots, but I do miss the old queue.
Would it be possible to set a bucket limit on actions, say a range from 1 to 10, and have server side curing be treated as priority 0? That option (setting a bucket-size of 1) would do wonders in reducing the QUEUE RESET EQBAL spam that I'm sure has been hitting the server lately, and it'd give the benefits of both queue implementations.
I've been thinking how best to utilize an actual queue, and aside from streamlining some lazy aliases I made with coroutines, the optimal approach for a system is to clear the queue and only queue the next action.
Assume that a system wants commands P, Q, R, S to be fired, in that order.
- If P fires and fails, the queue is now QRS but the system will still want PQRS. Reconciliation is either to insert P at the top or clear queue and queue PQRS again.
- The queue is PQRS but the system determines it should be PRQS. Reconciliation is to clear queue and queue PRQS.
The code paths get easier by opting to always clear the queue. If there's any inconsistency between system and queue, do a hard reset and avoid any complex logic to determine if there's a more "optimal" way to fix it. But once you're at the point of having the system clear the queue, the next optimization to make is to only ever queue one action. No reconciliation is necessary if PQRS becomes PRQS if the system only queued P.
Which leads us to, in effect, the old queue.
I can appreciate why the change was made to enable server-side queuing to interject itself and prevent a person from queuing themselves to death by not giving autocuring a chance to pull arrows or dig out shots, but I do miss the old queue.
Would it be possible to set a bucket limit on actions, say a range from 1 to 10, and have server side curing be treated as priority 0? That option (setting a bucket-size of 1) would do wonders in reducing the QUEUE RESET EQBAL spam that I'm sure has been hitting the server lately, and it'd give the benefits of both queue implementations.
1
Comments
As it is, I reset every time I push a new string to the queue, but right now that will mess with how autocuring tries to cure arrows, shots, etc.