Developer Diary #18: How Are Mod Commands Checked?
In short: Mods can define game-specific checks for commands they add. The interface question and the check before a command is applied use the same rule; an interface question asked on one machine is also kept separate from the shared multiplayer flow.
In a strategy game, a player may ask, “Is this command valid right now?” before choosing a move. The world may change after that question, so the answer can differ when the command is processed. What matters is that the same rule evaluates the world as it stands at each point. Our aim is for a mod's own rule to work the same way at both points.
The same check for a command
A mod can define a rule that accepts or rejects one of its added commands. The same rule runs when the interface asks whether the command is available and just before the game applies it; each time, it checks the current world conditions. If the world has changed between those evaluations, the answer can change too.
If a mod does not define this extra rule, no mod-specific check is made; the game's and engine's other rules still apply. A rejected command is not applied and does not change the world. Acceptance means the command is allowed under the current rules; its change is made during the normal game step.
The check does not change the world
Command checking helps determine whether an action is valid under the current conditions in the world. The rule can inspect the world, but the check itself does not change the game state. Asking why a button is available therefore does not count as having already made the move.
Think of asking a shop assistant, “Can I buy this item?” The assistant checks the stock; answering the question does not mark the item as delivered. Delivery happens only when the purchase is processed.
If a rule stops unexpectedly while it is being checked, the command is rejected and the error is recorded. In the path we reviewed, that error alone does not stop the mod's other work; a later command can still be processed. The rejected command does not change the game world.
A local question, apart from the shared game
In a multiplayer game, every computer needs to process the same commands in the same order for the shared world. An interface question about a command, however, may be asked only on the player's own computer. The question itself does not enter a shared-world step, but a later check could produce different answers if it depends on temporary information left by that local question.
The engine keeps the interface question apart from shared game steps, so the question itself is not added to the common calculation. But separation alone does not ensure that shared steps match: the mod's check must depend only on shared world data and game content loaded for everyone, not on temporary information left by earlier local questions. In the fault path we examined, the affected command is rejected and the fault is recorded; this finding does not extend to other fault types.
When does player control matter?
A mod can specify that one of its commands acts on a particular game object and that the issuing player must control it. This check applies when the game provides information about which objects players control. If the mod also declares this condition for the command, the engine checks whether the player controls the object; it does not add a new control requirement to every command automatically.
The mod's rule handles conditions specific to the game, while the engine checks the declared player-control condition. This keeps “Is this command valid in my game?” separate from “Does this player control the specified object?”
What did we observe?
In the scenario we examined, shared steps after a local interface question matched those of a world that received no question. This finding is limited to checks that rely on shared game data rather than local question history. A faulty command check rejected its command; the mod's later command and regular work continued. This was not a real network session, a comparison across physical computers, or a measurement of latency or speed.
The same boundary appeared for a command-check fault: the command was not applied, the fault was recorded, and a later command could be evaluated. This does not mean every kind of mod fault is harmless; this account is limited to faults in command checks made by the interface or game step.
Why did we choose this design?
Writing separate rules for the interface question and the check before a command is applied could lead to different criteria over time. Using the same rule avoids that split; each evaluation uses the world conditions at that moment, so the answer may change if those conditions have changed.
Keeping a local interface question apart from shared world steps supports consistency, but it is not enough on its own. For shared steps to match, the check must use world data and common game content available to everyone, not information left by earlier local questions.
What does it cost?
This separation uses additional memory while the game runs; we did not measure how much or its effect on speed. In the scenario we examined, a local interface question did not change shared world steps; that result depends on the check not using local question history and does not cover real network performance or every kind of fault.
Frequently asked questions
Can a mod decide whether its own command is valid?
Yes. A mod can define an extra rule that accepts or rejects the command. The interface question and the pre-application check use the same rule, each against current conditions; if the world changes between them, the answer can differ.
Can command checking change the game world?
No. The check inspects current conditions; a rejected command is not applied. Changes happen when an accepted command is processed during a game step.
Does the game stop if a check faults?
In the command-check path we examined, the fault rejects the command and is recorded; later commands and the mod's other work can continue. This is not a general guarantee for other fault types.
Does the engine require player control for every command?
No. This check applies only when the command definition declares the condition and the game provides player-control information. The mod's own game rules are evaluated separately.
For how multiplayer worlds follow shared steps, read Developer Diary #2; for the scope of mods, see Developer Diary #8. For questions, visit the contact page.