0xFF — NOP
Immediate return 0; no handler-side behavior. Because StepProcess already consumed the command header and skips default extra-word advancing for opcodes >= 0xF0, this consumes only the header.
proven— handler traced, and exercised by at least one shipped script.
At a glance
| Opcode | 0xFF (255) |
|---|---|
| Handler | CRadiScript::Command_ff |
| Signature | CRadiScript::Command_ff(int,SCR_DATA*,unsigned int,unsigned int) |
| Translation unit | r_script_runf.cpp |
| Address | — debug build, the only one that confirms it Not placed in the ENG or JPN maps. Those maps are derived, and neither a byte match nor a porting rule has pinned this handler down there — it is still installed in that build's dispatch table. |
| Handler size | 0x8 (8 bytes) |
| Family | Markers and return |
| Command size | Always 4 bytes — opcodes >= 0xF0 ignore the extra-word count. |
Handler behaviour
Immediate return 0; no handler-side behavior. Because StepProcess already consumed the command header and skips default extra-word advancing for opcodes >= 0xF0, this consumes only the header.
Encoding
The command header is one 32-bit word, as described in §3 Instruction encoding:
31 24 23 16 15 8 7 0
+----------------+----------------+----------------+----------------+
| flags | argument byte | extra words | 0xFF |
+----------------+----------------+----------------+----------------+Because this opcode is >= 0xF0, the stepper consumes only the header and ignores the extra-word count. The payload therefore lives in the header word itself — see §4 0xF0 markers.