Repository navigation
Command layer design
The design for what's still to build in the command layer: in-game commands, the web console and the player portal, and the roles that decide who may run what. Step 3's first stage built the dispatcher, the audit, the local console and the first commands, described on Command layer and its references; this page holds the rest. The web side's own design is on Server core design, and Roadmap says how far the build has got.
Every front end dispatches the same typed commands through the one dispatcher the console already uses. Permissions come from roles, the old role-based set lifted, and the commands too dangerous without a second factor stay console-only. A command that changes an online character goes through the map that holds it.
The game client can't do two-factor, so whatever needs it can't be reachable from in game. And an online character belongs to its map, so changing it any other way would race the map's own state.
In-game GM chat, the web console and the player portal dispatch the same commands as the local console, through the same dispatcher, checks and audit.
Permissions are the old role-based set, lifted, with one dotted key per command. Built-in roles can't be deleted. Commands too dangerous without a second factor (role changes, bulk deletes, settings) are console-only, since the game client can't do two-factor.
An online character is changed by its map. A command that touches one posts to the map that holds it, like any other command to its owner.
- In-game GM commands, with the old roles lifted, come after the first stage.
None recorded for what's left. The layer's rejected ideas are on Command layer.
| Claim | Basis |
|---|---|
| Roles and the front ends' checks | Designed; held by the dispatcher's own tests as they're built |
- How the web front end is treated for console-only commands, decided before it's built.