No edit summary
No edit summary
Line 1: Line 1:
The <code>ai_queue</code> trigger has 20 different queues available to use. The trigger’s subject is the NPC type.
NPC queues aren’t referenced by names. They are done by “ID” instead, this way the subject is always known ahead of time.
 
Processing is done very similarly to players, and will not run if the queue isn’t ready or the NPC is delayed.
 
Developers are able to use any queue “ID” to handle special logic, though there are some conventions (see below).
 
Hunt modes may be configured to run queues when they find a target.
 
== Command ==
<code>npc_queue(id, delay, arg);</code>
 
NPC queues may pass one int argument here for the queue to use. Inside the trigger, you use <code>last_int</code> to reference what you’ve passed.
 
We have an inauthentic difference here: We support passing an arg list to the queue too. I’ve intentionally not documented it as that will change, and for remake purposes people can do everything with a single int.
 
==== Additional Args ====
They have an asterisked variant of this command that lets you pass additional arguments: <code>npc_queue*(id, delay)(args, …);</code>
 
I assume this denotes to their compiler that parsing rules change.
 
== Trigger ==
The <code>ai_queue</code> trigger has 20 queue IDs available to use. The trigger’s subject is the NPC type.


There are a few conventions used globally:
There are a few conventions used globally:
Line 10: Line 31:


<code>[ai_queue8,type]</code> runs on '''bind spells''' - this means something has hit them with a bind spell and movement should be blocked for a period of time.
<code>[ai_queue8,type]</code> runs on '''bind spells''' - this means something has hit them with a bind spell and movement should be blocked for a period of time.
Outside of these conventions, developers may use any queue “ID” to handle special logic.
Hunts may be configured to run queues when they find a target.

Revision as of 18:59, 12 January 2025

NPC queues aren’t referenced by names. They are done by “ID” instead, this way the subject is always known ahead of time.

Processing is done very similarly to players, and will not run if the queue isn’t ready or the NPC is delayed.

Developers are able to use any queue “ID” to handle special logic, though there are some conventions (see below).

Hunt modes may be configured to run queues when they find a target.

Command

npc_queue(id, delay, arg);

NPC queues may pass one int argument here for the queue to use. Inside the trigger, you use last_int to reference what you’ve passed.

We have an inauthentic difference here: We support passing an arg list to the queue too. I’ve intentionally not documented it as that will change, and for remake purposes people can do everything with a single int.

Additional Args

They have an asterisked variant of this command that lets you pass additional arguments: npc_queue*(id, delay)(args, …);

I assume this denotes to their compiler that parsing rules change.

Trigger

The ai_queue trigger has 20 queue IDs available to use. The trigger’s subject is the NPC type.

There are a few conventions used globally:

[ai_queue1,type] runs on retaliate - this means something has hit them and the NPC may react.

[ai_queue2,type] runs on damage - this means something has hit them and the NPC may apply that damage.

[ai_queue3,type] runs on death - this means something has dropped their health to 0 and the NPC may drop items or advance a player’s quest state.

[ai_queue8,type] runs on bind spells - this means something has hit them with a bind spell and movement should be blocked for a period of time.