A queue is a list of commands waiting in line to be run. Commands are added to the end of queues, and removed from the fronts of queues to be run.
Many people talk about "the queue". In fact, there are four queues, but they are, as the server runs, merged into a single queue. The four queues are:
- The player queue. This queue contains commands that were indirectly initiated by a player.
- The object queue. This queue contains commands that were initiated by a non-player object.
- The wait queue. This queue contains commands waiting unconditionally until a particular time to be executed. Commands are added to this queue with @wait <number of seconds> = <command>
- The semaphore queue. The queue contains commands waiting conditionally to be executed when a semaphore is notified (or for a given amount of time). Commands are added to this queue with @wait <obj>[/<seconds>]=<cmd>
In all these cases, a command may be a simple command or a list of commands separated by semicolons -- lists of commands are queued together as a single queue entry to insure that they run immediately one-after-the-other, without anything intervening.
Approximately every second, whatever's on the object queue is added to the end of the player queue. Any entries on the wait queue that have waited long enough are then added to the end of the player queue. Any timed sempahores that have waited long enough are then added to the end of the player queue. (Semaphores that are @notified are immediately added to the end of either the player or object queue, depending on the type of object that initiated the semaphore's @wait). When it's time to actually execute commands, they are taken off the player queue and executed.
The practical upshot of this scheme is that player-initiated commands tend to run first and faster, which makes the server feel responsive. On the other hand, commands queued by objects are always delayed by at least one second, while they are waiting to be moved from the object queue to the player queue.
Several commands cause additional commands to be queued, including: @wait, @force, @trigger, @switch (matching actions are queued), and @dolist (for each list element, the action is queued up into a separate queue entry, though no other queue entries will intervene between the entries for the list elements).
With the conceptual framework above, you should understand why:
@pemit %#=Hi; @pemit %#=Hi again
think [pemit(%#,Hi)][pemit(%#,Hi again)]
run equally fast (or are negligibly different in run speed).
You should also understand why:
@emit Hi; @dol a b c=@emit ##; @emit Hi again
will result in the following output:
Hi Hi again <pages, etc. from other objects may intervene here and only here> a b c