Command Reference
Complete reference for Pilaf framework primitives - commands that cannot be accomplished using normal Minecraft server commands or player commands.
Overview
Pilaf provides framework-level primitives organized into three categories:
-
Server Commands - Framework primitives for server-level operations
-
Player Commands - Framework primitives for player-level operations
-
Workflow & Assertion Commands - Control flow, state management, and validation
|
Framework Primitives vs. Minecraft Commands The commands documented here are framework primitives that cannot be done with normal Minecraft commands: - Service health checks - State capture and comparison - Player connection/disconnection - Framework-level assertions For game operations, use |
Server Commands
Server commands are framework-level primitives that interact with the Minecraft server through RCON.
| Primitive | Description |
|---|---|
Execute any Minecraft server command via RCON (framework primitive) |
|
Verify service availability (framework health check) |
|
Use SERVER_COMMAND for Game Operations For all game operations, use |
Player Commands
Player commands are framework primitives for player lifecycle management through connected clients (Mineflayer, HeadlessMc).
| Primitive | Description |
|---|---|
Connect a player to the server (framework lifecycle) |
|
Disconnect a player from the server (framework lifecycle) |
|
Execute a Minecraft command as a player (framework primitive) |
|
Execute a command through the Mineflayer client (framework primitive) |
|
Execute raw command through Mineflayer client (framework primitive) |
|
Use PLAYER_COMMAND for Game Actions For player game actions, use |
Workflow & Assertion Commands
Workflow and assertion commands are framework-level primitives for controlling test flow, managing state, and validating results.
| Primitive | Description |
|---|---|
Pause test execution for specified duration (system-level wait) |
|
Store result for later comparison (framework state management) |
|
Compare two stored states (framework state management) |
|
Extract specific values from JSON data (data extraction) |
|
Filter entities by criteria (post-processing) |
|
Assert that a specific entity exists (validation) |
|
Assert that a specific entity does not exist (validation) |
|
Assert response contains expected content (validation) |
|
Assert JSON structure matches (validation) |
|
Assert log contains pattern (validation) |
|
Assert custom condition (validation) |
Why Framework Primitives?
Pilaf focuses on framework-level operations that cannot be done with normal Minecraft commands:
-
Service Health: Check if services are available and responsive
-
State Management: Capture and compare states between test phases
-
Data Extraction: Query JSON responses with JSONPath
-
Player Lifecycle: Connect/disconnect players through testing clients
-
Assertions: Framework-level validation primitives
All game operations (spawning entities, giving items, changing time) should use SERVER_COMMAND or PLAYER_COMMAND with standard Minecraft syntax.
Examples
Basic Story with Framework Primitives
name: "Test Player Connection"
description: "Verify player can connect and execute commands"
setup:
- action: "CHECK_SERVICE_HEALTH"
name: "Check server health"
- action: "SERVER_COMMAND"
name: "Grant operator status"
command: "op pilaf_tester"
steps:
- action: "CONNECT_PLAYER"
name: "Connect test player"
player: "pilaf_tester"
- action: "PLAYER_COMMAND"
id: "give_diamond"
name: "Give diamond to player"
player: "pilaf_tester"
command: "/give @p diamond"
- action: "ASSERT_RESPONSE_CONTAINS"
name: "Verify diamond given"
source: "${{ steps.give_diamond.outputs.result }}"
contains: "diamond"
- action: "STORE_STATE"
id: "store_inventory"
name: "Capture inventory state"
sourceVariable: "${{ steps.give_diamond.outputs.result }}"
variableName: "inventory_state"
cleanup:
- action: "DISCONNECT_PLAYER"
name: "Disconnect test player"
player: "pilaf_tester"
- action: "SERVER_COMMAND"
name: "Remove operator status"
command: "deop pilaf_tester"
Entity Testing with SERVER_COMMAND
name: "Test Entity Spawning"
description: "Verify entity spawning and removal"
setup:
- action: "SERVER_COMMAND"
name: "Clear existing zombies"
command: "kill @e[type=zombie]"
steps:
- action: "ASSERT_ENTITY_MISSING"
name: "Verify no zombies exist"
entity: "zombie"
- action: "SERVER_COMMAND"
name: "Spawn test zombie"
command: "summon zombie ~ ~ ~ {CustomName:'\"test_zombie\"'}"
- action: "WAIT"
name: "Wait for entity spawn"
duration: 2000
- action: "ASSERT_ENTITY_EXISTS"
name: "Verify zombie spawned"
entity: "zombie"
- action: "SERVER_COMMAND"
name: "Remove test zombie"
command: "kill @e[type=zombie,custom_name=test_zombie]"
- action: "ASSERT_ENTITY_MISSING"
name: "Verify zombie removed"
entity: "zombie"
State Comparison Example
name: "Test World Time Changes"
description: "Verify time manipulation and state comparison"
setup:
- action: "SERVER_COMMAND"
id: "initial_time"
name: "Get initial time"
command: "time query gametime"
- action: "STORE_STATE"
name: "Store initial time"
sourceVariable: "${{ steps.initial_time.outputs.result }}"
variableName: "start_time"
steps:
- action: "SERVER_COMMAND"
name: "Set to noon"
command: "time set noon"
- action: "SERVER_COMMAND"
id: "final_time"
name: "Get final time"
command: "time query gametime"
- action: "STORE_STATE"
name: "Store final time"
sourceVariable: "${{ steps.final_time.outputs.result }}"
variableName: "end_time"
- action: "COMPARE_STATES"
name: "Compare time states"
state1: "start_time"
state2: "end_time"
cleanup:
- action: "SERVER_COMMAND"
name: "Reset time"
command: "time set day"
Related Documentation
-
Writing Stories - How to use commands in stories
-
Best Practices - Tips for effective testing
-
Architecture - How commands are executed