Space Station 13 - Modules - TypesDefine Details

code/__DEFINES/verb_manager.dm

VERB_OVERTIME_QUEUE_THRESHOLDverb queuing thresholds. remember that since verbs execute after SendMaps the player wont see the effects of the verbs on the game world until SendMaps executes next tick, and then when that later update reaches them. thus most player input has a minimum latency of world.tick_lag + player ping. however thats only for the visual effect of player input, when a verb processes the actual latency of game state changes or semantic latency is effectively 1/2 player ping, unless that verb is queued for the next tick in which case its some number probably smaller than world.tick_lag. so some verbs that represent player input are important enough that we only introduce semantic latency if we absolutely need to. its for this reason why player clicks are handled in SSinput before even movement - semantic latency could cause someone to move out of range when the verb finally processes but it was in range if the verb had processed immediately and overtimed. queuing tick_usage threshold for verbs that are high enough priority that they only queue if the server is overtiming. ONLY use for critical verbs
VERB_HIGH_PRIORITY_QUEUE_THRESHOLDqueuing tick_usage threshold for verbs that need lower latency more than most verbs.
VERB_DEFAULT_QUEUE_THRESHOLDdefault queuing tick_usage threshold for most verbs which can allow a small amount of latency to be processed in the next tick
TRY_QUEUE_VERBattempt to queue this verb process if the server is overloaded. evaluates to FALSE if queuing isnt necessary or if it failed. _verification_args... are only necessary if the verb_manager subsystem youre using checks them in can_queue_verb() if you put anything in _verification_args that ISNT explicitely put in the can_queue_verb() override of the subsystem youre using, it will runtime.
QUEUE_OR_CALL_VERBqueue wrapper for TRY_QUEUE_VERB() when you want to call the proc if the server isnt overloaded enough to queue

Define Details

QUEUE_OR_CALL_VERB

queue wrapper for TRY_QUEUE_VERB() when you want to call the proc if the server isnt overloaded enough to queue

TRY_QUEUE_VERB

attempt to queue this verb process if the server is overloaded. evaluates to FALSE if queuing isnt necessary or if it failed. _verification_args... are only necessary if the verb_manager subsystem youre using checks them in can_queue_verb() if you put anything in _verification_args that ISNT explicitely put in the can_queue_verb() override of the subsystem youre using, it will runtime.

VERB_DEFAULT_QUEUE_THRESHOLD

default queuing tick_usage threshold for most verbs which can allow a small amount of latency to be processed in the next tick

VERB_HIGH_PRIORITY_QUEUE_THRESHOLD

queuing tick_usage threshold for verbs that need lower latency more than most verbs.

VERB_OVERTIME_QUEUE_THRESHOLD

verb queuing thresholds. remember that since verbs execute after SendMaps the player wont see the effects of the verbs on the game world until SendMaps executes next tick, and then when that later update reaches them. thus most player input has a minimum latency of world.tick_lag + player ping. however thats only for the visual effect of player input, when a verb processes the actual latency of game state changes or semantic latency is effectively 1/2 player ping, unless that verb is queued for the next tick in which case its some number probably smaller than world.tick_lag. so some verbs that represent player input are important enough that we only introduce semantic latency if we absolutely need to. its for this reason why player clicks are handled in SSinput before even movement - semantic latency could cause someone to move out of range when the verb finally processes but it was in range if the verb had processed immediately and overtimed. queuing tick_usage threshold for verbs that are high enough priority that they only queue if the server is overtiming. ONLY use for critical verbs