Two wrong builds: order() with orders.Move, and functions that keep a state

[jeany55]

Two scripts that built maps doing the wrong thing, in both builds (eudplib's and our own).

order() with orders.Move. It made an Order action of modifier 6, the number orders.dat has for Move, where the action knows only 0, 1 and 2 (move, patrol, attack). Any other orders.* passed as a number too, and orders.Die and orders.Stop were taken for move and patrol. Now orders.Move, orders.Patrol and orders.AttackMove give the action's own numbers, and any other order is a type error. A raw number is a second signature: in one union with it, TypeScript took Order<0> for a number.

A function that keeps a state was worked out once when the script was built. A function changing a variable declared outside it (a closure's, or a let of the file's), or a field of this outside a constructor, was worked out where its call was written. A loop printing next() of const next = counter() showed 1, 1, 1. A call of such a function is now the program's (hoist.ts, keepsState):

• a closure made in the program runs in the game;
• one made when the script was built, or a method of an instance made then, is refused;
• a function writing the script's own let or record is refused, as that write is when written in the program.

A cache filled by a method stays a build-time call. A diagnostic said again for each call of the same function is now said once.

Ledger: game/order.ts describes the three orders the action takes. language/closure-keeps-a-count.ts is new. Both stay refused by a map of our own (steps 5 and 9), and no other row changed.

Tests: tests/events.test.ts, tests/script-functions.test.ts, tests/script-structured.test.ts. Suite 1,244 passing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01T1CM9pLuTuAn3mgTEkjgVg