Sylpheed/docs/re/structures/squadron-orders.md

The four squadron order classes

Status: ✅ three named from the game's own strings; 🟡 the fourth named from weaker, independent evidence — recorded at lower confidence deliberately.

The script tells a squadron what to do by posting an interpreter command whose handler pushes an order object onto the unit's order deque at obj+216. Four such classes exist, distinguished by size, constructor and a type tag at [order+4].

✅ Three named directly by the game

sub_8232C4C0 is a unit message pump. Three of its arms build orders, and each loads its own format string — the strings are verified present at these addresses:

0x820AF17C  "Set Squadron order attack %08x %08x \r\n"
0x820AF1A4  "Set Squadron order trace %08x %08x \r\n"
0x820AF1CC  "Set Squadron order escort %08x %08x \r\n"

The three stack slots holding them are written once at function entry and never rewritten, so the pairing is unambiguous. The printf itself is bl 0x82674028 — li r3,0 ; blr, i.e. compiled out — but the format strings and their arguments survive, which is exactly what makes them usable as labels.

The join to the script side is that the same poster functions serve both the message path and the interpreter-command path, so the identity transfers:

opcode	size	vtable	tag	order	ISL built-in
517	160	0x820AEB2C	2	trace — follow a named unit	46
784	192	0x820AFB0C	3	attack	47
790	240	0x820AFB34	4	escort	48
512	124	0x820AFAEC	1	route/waypoint move 🟡	3 (move_order)

Built-ins 46/47/48 share one blob shape: blob+4 = actor (symtab-2 index), blob+12 = target (symtab-2 index), blob+16 == 1 = an immediate/override flag. 48 additionally carries a 3-double position. All four orders keep the target at [order+92].

🟡 The fourth is named on weaker evidence

Set Squadron order … names only three. Opcode 512's label rests on different ground:

• its vtable slot 1 is the sole referencer of "%08x Now Generating Routes [%d]...." (0x820AFAA4, verified present);
• its [order+92] comes from a symbol-table-1 name (routes/messages), not the unit table the other three use;
• the posting built-in resolves a route point count;
• isl.py had already labelled built-in 3 move_order from handler behaviour.

That is four independent lines, but none of them is the game naming it. Recorded as 🟡 rather than levelled up to match the other three.

🔴 A different enum that is NOT this

sub_82320B48 selects a voice line from twelve strings at 0x820AEEB0…. Note the spelling, which is the game's own and matters because it is the join key: the WINGMAN and SQUAD names are ORDER_, and all four SQUADRON names are misspelled ORDOR_ — ORDOR_SQUADRON_{FORMATION,ATTACK,COVER,EXTENDED}. (An earlier revision of this document rendered all twelve as ORDER_.)

The names are tempting — ATTACK and COVER look like they should map onto the order classes — but there is no evidence they index the order types, and it is a UI/comms axis. Not connected; do not conflate them.

✅ Settled 2026-08-27, and the warning above holds. All twelve are record names in the reactive-chatter rule table, carrying the same misspelling on the data side — see preset-message-rules.md. They are the twelve events "a squadron order was issued", each with its own lines, priority and interval. Triggers for barks, not order types.

🟡 Not settled

• [order+80] is plausibly speed and [unit+84]+16 / +20 plausibly engagement range and standoff distance. Neither is established.
• [unit+628], set to 2/4/5/3 by the four message arms, is read by sub_82318EC8 — meaning unknown.