Add enough requirements and you are told there is no room. The area is split into five, each a fixed size, and there is no slack between them: when one overflows you have to make room inside that same one.
| 유닛 | 1,096 bytes, pointer table FG_PReqUnit, 228 entries |
|---|---|
| 업그레이드 | 840 bytes, FG_PReqUpg, 61 entries |
| 기술 연구 | 320 bytes, FG_PReqTechUpg, 44 entries |
| 기술 사용 | 688 bytes, FG_PReqTechUse, 44 entries |
| 명령 | 1,316 bytes, FG_PReqOrder, 189 entries |
The whole of require.dat is 5,392 bytes: 1,132 of pointer tables (228, 61, 44, 44 and 189 u16 entries) followed by the five data areas in the same order, 4,260 bytes. That the arithmetic closes exactly is the check to run before any requirement surgery.
A pointer is a word index inside its own area - not a byte offset and not an absolute address. Each record begins with one word holding its own object id, then the requirement words, then 0xFFFF; the pointer points past that id, at the first requirement word.
Counted on the stock require.dat there are no exceptions: 91 unit records, 51 upgrade, 26 tech-research, 33 tech-use and 112 order records all begin with their own id. A pointer you compute yourself that lands on the id has the game read that id as an opcode.
| 요구사항 없음 | Leave the pointer at 0 - word 0 of every area is a zero. |
|---|---|
| 항상 허용 | Just one 0xFFFF word. |
| 직접 지정 | The requirement words, closed with 0xFFFF. |
Never swap the order area (FG_PReqOrder) for another map's values. The symptom is not an error but a refused order: a worker takes a build command and does not move, and MSQC dies. Editing one entry in place is fine.