Improved the development workflow and testing skills using skill-creator and a real server testing + feedback from actual workflow

This commit is contained in:
Anon 2026-03-23 15:35:34 +01:00
parent 9efb7ef767
commit 445c236914
6 changed files with 301 additions and 170 deletions

View file

@ -1,149 +1,141 @@
---
name: mcc-dev-workflow
description: Build, run, and debug Minecraft Console Client (MCC) in WSL. Use when the user wants to compile MCC, start a Minecraft test server, connect MCC to a server, debug MCC protocol issues, or run MCC commands.
description: Build, run, and debug Minecraft Console Client (MCC) against a real local Minecraft Java server in WSL. Use this whenever the user wants to compile MCC, start or inspect a local test server, connect MCC to a server, debug protocol or login issues, validate a code change end-to-end, or run MCC commands on a real server instead of guessing from static code.
---
# MCC Development Workflow
## Project Overview
Use this skill when the task needs a real local server loop, not just code reading.
- Solution: `MinecraftClient.sln` (projects: `MinecraftClient` + `ConsoleInteractive`)
- Build: `dotnet build MinecraftClient.sln -c Release`
- Output: `MinecraftClient/bin/Release/net10.0/MinecraftClient`
- Servers: `MinecraftOfficial/downloads/<version>/` — server.jar + runtime data (config, world, etc.)
## Defaults
Environment: WSL Ubuntu, Java 21, .NET 10 SDK, tmux, python3.
- Solution: `MinecraftClient.sln`
- Runtime target: `.NET 10` / `net10.0`
- Environment: WSL Ubuntu, Java 21, tmux, python3
- Default server root: `${MCC_SERVERS:-$MCC_REPO/MinecraftOfficial/downloads}`
- Default validation target when the user does not specify a version: `1.21.11-Vanilla`
## Compile
## Core rules
- Prefer a real local server over static reasoning for protocol, login, movement, inventory, entity, or command-path work.
- Treat tmux `mc-*` sessions as shared state. Do not run multi-version server workflows in parallel unless the harness explicitly isolates them.
- For scripted or repeatable runs, prefer a temporary config copied from `MinecraftClient.ini`. Use the repo-root config only for ad hoc manual work.
- A server log line containing `Done (` means startup finished. It does not guarantee that RCON is ready on the first attempt. Retry early `mc-rcon` commands.
- When instructions, docs, and code disagree, trust current code and current tool behavior first.
## Build
```bash
dotnet build MinecraftClient.sln -c Release
```
## Start a Test Server
## Server management
Servers live in `MinecraftOfficial/downloads/` with directories named by version (e.g. `1.20.6`, `1.21.11`).
Interactive shell:
```bash
tools/start-server.sh 1.20.6
source tools/mcc-env.sh
mc-start 1.21.11-Vanilla
mc-log 1.21.11-Vanilla 100
mc-rcon "op CursorBot"
mc-stop 1.21.11-Vanilla
```
Creates a tmux session `mc-1_20_6` with a named pipe `stdin.pipe` for command input. The server persists across Cursor sessions.
Non-interactive shell:
```bash
echo "op CursorBot" > MinecraftOfficial/downloads/1.20.6/stdin.pipe # server command
tmux capture-pane -t mc-1_20_6 -p -S -50 # view output
echo "stop" > MinecraftOfficial/downloads/1.20.6/stdin.pipe # stop
tools/start-server.sh 1.21.11-Vanilla
tools/mc-rcon.sh "op CursorBot"
```
### Server config checklist
If the servers live outside the repo, set `MCC_SERVERS` before sourcing or invoking the tools:
- `eula.txt`: `eula=true`
- `server.properties`: `online-mode=false` for offline testing
```bash
export MCC_SERVERS=/home/anon/Minecraft/Servers
source tools/mcc-env.sh
```
## Recommended automation recipe
Use this for reproducible local runs:
1. Source `tools/mcc-env.sh`.
2. Pick a concrete server directory, usually `1.21.11-Vanilla`.
3. Copy `MinecraftClient.ini` to a temp location and pin the account, version, and feature gates there.
4. Start the server and wait for `Done (` in the tmux log.
5. Launch MCC with `MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release --no-build -- "<temp-config>"`.
6. Drive MCC through `mcc_input.txt`.
7. Stop MCC and the server cleanly, then keep the temp logs.
## Temporary config recipe
```bash
source tools/mcc-env.sh
TEST_ROOT="${TMPDIR:-/tmp}/mcc-dev"
CFG="$TEST_ROOT/MinecraftClient.1.21.11.ini"
mkdir -p "$TEST_ROOT"
cp "$MCC_REPO/MinecraftClient.ini" "$CFG"
sed -i \
-e 's/Account = { Login = "test", Password = "-" }/Account = { Login = "CursorBot", Password = "-" }/' \
-e 's/MinecraftVersion = "auto"/MinecraftVersion = "1.21.11"/' \
-e 's/TerrainAndMovements = false/TerrainAndMovements = true/' \
-e 's/InventoryHandling = false/InventoryHandling = true/' \
-e 's/EntityHandling = false/EntityHandling = true/' \
"$CFG"
```
Add extra `sed -i` edits only for the scenario you are testing.
## Run MCC
ConsoleInteractive is patched for non-interactive terminals.
Direct temp-config launch:
```bash
MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release -- CursorBot - localhost 2>&1
cd "$MCC_REPO"
MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release --no-build -- "$CFG" 2>&1
```
- Format: `MinecraftClient <username> <password> <server>`, password `-` = offline mode
- Use `block_until_ms: 0` to background; `sleep 2` then read terminal to confirm join
- Config: `MinecraftClient.ini` (auto-generated). Set `MinecraftVersion = "auto"` unless pinning.
Quick manual launch with the repo-root config:
### FileInputBot
```bash
source tools/mcc-env.sh
mcc-run 25565
```
Set `MCC_FILE_INPUT=1` (shown above). MCC monitors `mcc_input.txt`:
`mcc-run` is fine for manual smoke tests. Use a temp config for repeatable automation.
## Verify connection and a basic command
MCC output should include:
- `[MCC] Server was successfully joined.`
Server output should include:
- `CursorBot joined the game`
Basic command check:
```bash
echo "inventory player list" >> mcc_input.txt
```
Polled every ~500ms. `sleep 1` then read terminal for response.
## Typical debug loop
### RCON
1. `source tools/mcc-env.sh`
2. `dotnet build MinecraftClient.sln -c Release`
3. start `1.21.11-Vanilla`
4. wait for `Done (`
5. launch MCC with a temp config
6. confirm the join in both logs
7. run one MCC command and one server command
8. inspect logs
9. stop both sides and iterate
```bash
tools/mc-rcon.sh "give CursorBot diamond_sword 1"
tools/mc-rcon.sh "op CursorBot"
tools/mc-rcon.sh "say hello" 25575 test123 # explicit port and password
```
## Debugging tips
## Verify Connection
MCC output: `[MCC] Server was successfully joined.`
Server output: `CursorBot joined the game`
## Server Lifecycle
**Keep the server running** unless you need to restart/switch version/user asks to stop.
Check before starting: `tmux list-sessions 2>/dev/null | grep "^mc-"`
## Typical Debug Workflow
1. `tools/start-server.sh 1.20.6` (background, `block_until_ms: 0`)
2. Wait for "Done": `tmux capture-pane -t mc-1_20_6 -p -S -5`
3. Build: `dotnet build MinecraftClient.sln -c Release`
4. Run MCC: `MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release --no-build -- CursorBot - localhost 2>&1` (background, `block_until_ms: 0`)
5. `sleep 2`, read terminal to confirm join
6. RCON: `tools/mc-rcon.sh "op CursorBot"`
7. MCC cmd: `echo "inventory player list" >> mcc_input.txt`
8. `sleep 1`, read terminal for output
9. `pkill -f MinecraftClient` → rebuild → repeat
| Operation | Typical Duration |
|-----------|-----------------|
| MCC startup → join | ~1s |
| FileInput → response | <500ms |
## Tools
All in `tools/`:
| Script | Purpose |
|--------|---------|
| `start-server.sh <ver>` | Start MC server in tmux |
| `mc-rcon.sh "cmd" [port] [pw]` | RCON command (default: 25575, test123) |
| `decompile.sh --version <ver>` | Decompile MC version + download server.jar |
| `mcc-env.sh` | Source for shell helpers (`mc-start`, `mcc-build`, etc.) |
`mcc-env.sh` exports `$MCC_REPO` and `$MCC_SERVERS` and defines convenience functions. Source it in interactive shells or `~/.bashrc`. In Cursor's non-interactive Shell, use the standalone scripts directly.
## Decompiled Server Source
`MinecraftOfficial/` contains decompiled official server/client code:
```bash
tools/decompile.sh --version 1.21.1 # server (default)
tools/decompile.sh --version 1.21.1 --side CLIENT # client
```
Auto-downloads `MinecraftDecompiler.jar` if missing; downloads `server.jar` into `MinecraftOfficial/downloads/<ver>/` for SERVER side.
## Key Code Paths
| Area | Files |
|------|-------|
| Protocol version map | `Protocol/ProtocolHandler.cs` |
| Packet palette (ID mapping) | `Protocol/Handlers/PacketPalettes/PacketPalette*.cs` |
| Core packet handling | `Protocol/Handlers/Protocol18.cs` |
| Data serialization | `Protocol/Handlers/DataTypes.cs` |
| Structured components (1.20.6+) | `Protocol/Handlers/StructuredComponents/` |
| Client logic | `McClient.cs` |
| Config phase packets | `Protocol/Handlers/ConfigurationPacketTypesIn.cs` / `Out.cs` |
| Console I/O library | `ConsoleInteractive/` |
## Debugging Tips
- Debug output: `DebugMessages = true` in `[Logging]` of `MinecraftClient.ini`
- Protocol version shown during connection: `Server version : X.XX.X (protocol vNNN)`
- Server `EncoderException` = protocol mismatch
- Packet reference: https://minecraft.wiki/w/Java_Edition_protocol/Packets
- Use `block_until_ms: 0` for long-running processes, read terminal files for output
## Git Commits
Commit at meaningful milestones. Messages in English with sufficient context.
- Protocol mismatches usually show up as a version line such as `Server version : 1.21.11 (protocol vNNN)` before the failure.
- If an early `mc-rcon` command fails, retry it before assuming the server setup is broken.
- If a supposedly isolated run behaves strangely, check `tmux list-sessions` and kill stale `mc-*` sessions first.
- Legacy `1.8` and `1.8.9` servers may need `use-native-transport=false` in `server.properties` on some Linux environments.
- For timing-sensitive work, do not trust wall-clock intuition. Use a real server run and capture evidence from logs or test scripts.

View file

@ -0,0 +1,41 @@
{
"skill_name": "mcc-dev-workflow",
"evals": [
{
"id": 1,
"prompt": "Build MCC, start the local 1.21.11 vanilla server from an MCC_SERVERS root, connect MCC with a temporary config, and verify a successful join plus one inventory command.",
"expected_output": "The workflow uses a real local server, a temp MCC config, and concrete log evidence for both the join and the MCC command.",
"files": [],
"expectations": [
"The workflow uses a real local 1.21.11 server instead of only reading code.",
"The workflow uses MCC_SERVERS-aware tooling or documents the server root explicitly.",
"The workflow uses a temporary MCC config instead of relying on the repo-root config.",
"The result includes join evidence from MCC output and the server log."
]
},
{
"id": 2,
"prompt": "Debug a flaky local MCC startup on 1.21.11 by checking for stale tmux server sessions, waiting for server readiness, and retrying early RCON commands before blaming protocol code.",
"expected_output": "The response treats tmux sessions as shared state, distinguishes server startup from RCON readiness, and uses the real local workflow rather than pure speculation.",
"files": [],
"expectations": [
"The workflow checks or mentions stale mc-* tmux sessions.",
"The workflow distinguishes Done from RCON readiness.",
"The workflow retries or advises retrying early RCON commands.",
"The workflow keeps the debugging loop grounded in real local commands."
]
},
{
"id": 3,
"prompt": "Run a repeatable local MCC debug loop for 1.21.11 that compiles the client, connects with movement, inventory, and entity handling enabled, and leaves enough evidence to inspect a regression afterward.",
"expected_output": "The response follows a real build-run-test-inspect loop and captures enough log evidence to support follow-up debugging.",
"files": [],
"expectations": [
"The workflow builds MCC before the run.",
"The workflow enables terrain, inventory, and entity handling for the scripted run.",
"The workflow captures or points to concrete log locations.",
"The workflow prefers a temp config for repeatability."
]
}
]
}

View file

@ -1,55 +1,109 @@
---
name: mcc-integration-testing
description: Repeatable local offline integration testing for Minecraft Console Client against a local Minecraft Java server. Use this whenever the user wants to validate MCC end-to-end against a local server, switch the server to persistent offline mode, run chat or server commands through FileInputBot, exercise inventory/entity handling, or perform deeper smoke testing with mobs, particles, sounds, TNT, and operator actions.
description: Repeatable real-server integration testing for Minecraft Console Client against a local offline Minecraft Java server. Use this whenever the user wants to confirm nothing broke, validate runtime or protocol changes end-to-end, exercise movement, physics, inventory, entity handling, or run a single-version or cross-version MCC regression sweep on a real server.
---
# MCC Integration Testing
Use this skill for local MCC validation. Helper functions (`mc-*`, `mcc-*`) come from `tools/mcc-env.sh`; standalone tools (`tools/start-server.sh`, `tools/mc-rcon.sh`) can also be called directly without sourcing.
Use this skill when the task is "prove it still works on a real server", not just "reason about whether it should work."
## Workflow
## Default target
1. Source `tools/mcc-env.sh` to load `mc-*` and `mcc-*` helpers, or call `tools/start-server.sh` and `tools/mc-rcon.sh` directly for non-interactive shells.
2. Ensure the target server is configured for persistent offline testing:
- `online-mode=false`
- `enforce-secure-profile=false`
- `enable-rcon=true`
- `rcon.password=test123`
3. Build with `dotnet build MinecraftClient.sln -c Release`.
4. Run the scripted scenario with `scripts/run_full_spectrum_test.sh`.
5. Summarize the evidence with `scripts/summarize_test_run.sh`.
- Use `1.21.11-Vanilla` unless the user asks for a different version or a version matrix.
- Use `MCC_SERVERS` if it is set. Otherwise the default server root is `MinecraftOfficial/downloads`.
## Required Preconditions
## Guardrails
- Server jar exists under `MinecraftOfficial/downloads/<version>/server.jar`
- `eula.txt` contains `eula=true`
- Repo root `MinecraftClient.ini` is the offline MCC test profile
- The MCC config round-trip issue must be fixed before relying on repeated launches
- Use a real local server.
- Keep version matrices sequential in shared local environments. The tmux server harness is shared state by default.
- Prefer temporary MCC configs for scripted runs so one test does not contaminate the next.
- Legacy and modern command syntax differ. Do not assume one server-command profile fits every version.
- Use actual MCC output and actual server logs for assertions. Do not invent success strings.
## Scripts
## Choose the test mode
- `scripts/ensure_offline_server.sh`
- Generates `server.properties` if missing
- Applies persistent offline and RCON settings
- `scripts/run_full_spectrum_test.sh`
- Builds MCC
- Starts server and MCC
- Runs the full-spectrum scenario
- Verifies key MCC and server log assertions
- `scripts/summarize_test_run.sh`
- Prints the most relevant evidence from the latest run directory
### 1. Single-version deep smoke
## Scenario Coverage
Use this when one supported version is enough and you want broad coverage:
The scripted run should cover:
```bash
.skills/mcc-integration-testing/scripts/run_full_spectrum_test.sh 1.21.11-Vanilla
```
- offline join
- MCC-originated chat
- MCC-originated slash command
- internal MCC commands such as `health`, `list`, `inventory`, and `entity`
- OP + creative mode
- passive and hostile mob spawns
- representative sound and particle events
- TNT / explosion handling
This covers join, chat, slash commands, internal MCC commands, creative inventory, entity handling, sounds, particles, TNT, kill/respawn, and log assertions.
If a command syntax needs to be checked, use `references/command-matrix.md`.
### 2. Ordered creative-mode E2E
Use this when the user asks for a regression sweep in a strict scenario order such as:
- connect
- send messages
- send commands
- receive messages
- movement
- physics
- mobs
- effects
- inventory
Command:
```bash
MCC_SERVERS=/home/anon/Minecraft/Servers bash tools/run-creative-e2e.sh 1.21.11-Vanilla 1.21.11 modern
```
For legacy targets such as `1.8` or `1.8.9`, switch the final argument to `legacy` and pass the pinned MC version.
### 3. Timing or cadence validation
Use this for TPS, movement-cadence, or packet-cadence work:
- `MinecraftClient/config/sample-script-tick-counter.cs`
- `MinecraftClient/config/sample-script-packet-capture.cs`
Run them against a real server with a temp config and summarize counts from the captured logs.
## Preconditions
Before running any scenario:
1. configure the target server for offline testing
2. ensure `eula=true`
3. ensure RCON is enabled
4. build MCC unless the task explicitly reuses a fresh build
Offline configuration helper:
```bash
.skills/mcc-integration-testing/scripts/ensure_offline_server.sh 1.21.11-Vanilla
```
## Scripts and tools
- `.skills/mcc-integration-testing/scripts/ensure_offline_server.sh`
- configures persistent offline mode and RCON
- `.skills/mcc-integration-testing/scripts/run_full_spectrum_test.sh`
- single-version deep smoke with built-in assertions
- `.skills/mcc-integration-testing/scripts/summarize_test_run.sh`
- summarize the latest full-spectrum run
- `tools/run-creative-e2e.sh`
- ordered creative-mode E2E regression scenario
## What to report back
Always summarize:
- which version or versions were tested
- which scenario was used
- whether the run was sequential or single-version
- pass or fail per major phase
- concrete evidence from MCC and server logs
- the saved log directory
## Troubleshooting
- If the first RCON command fails, retry it before assuming the setup is broken.
- If multiple versions are being tested, do not start them in parallel unless the harness isolates tmux sessions and input files.
- If a test assertion fails, inspect the real MCC output before changing the code or weakening the assertion.
- If an older server behaves oddly on Linux, check `use-native-transport=false` in `server.properties`.
- If a test should be repeatable, avoid mutating the repo-root `MinecraftClient.ini`.

View file

@ -3,36 +3,38 @@
"evals": [
{
"id": 1,
"prompt": "Configure the local 1.21.11 MCC test server for persistent offline mode, then run a deep MCC integration test covering chat, operator actions, creative inventory, entity tracking, sounds, particles, and TNT.",
"expected_output": "The server is left in offline mode with RCON enabled, MCC joins successfully, and the run reports clear pass or fail evidence from both MCC and server logs.",
"prompt": "Run a real 1.21.11 MCC regression test in creative mode covering connect, send messages, send commands, receive messages, movement, physics, mobs, effects, and inventory, in that order.",
"expected_output": "The workflow uses the ordered creative-mode E2E harness on a real server, reports pass or fail for each phase, and points to the saved logs.",
"files": [],
"expectations": [
"The workflow sources tools/mcc-env.sh or calls tools/start-server.sh and tools/mc-rcon.sh directly.",
"The server is configured with online-mode=false and enable-rcon=true.",
"The run uses both mc-rcon and mcc-cmd.",
"The result includes evidence from MCC output and server logs."
"The workflow uses a real 1.21.11 server.",
"The workflow uses the ordered creative E2E harness instead of improvising the whole scenario.",
"The result reports phase-by-phase outcomes in the requested order.",
"The result includes the log directory for the run."
]
},
{
"id": 2,
"prompt": "Validate that MCC still works after a runtime or framework change by performing a repeatable offline smoke test against the local vanilla server and exercising entity and inventory handling.",
"expected_output": "The response runs the repeatable local workflow, checks for a successful join, verifies inventory and entity commands, and calls out any configuration or protocol regression.",
"prompt": "Validate that MCC still works after a runtime or protocol change by running a deep single-version 1.21.11 integration test with chat, creative inventory, entity tracking, sounds, particles, TNT, and kill/respawn coverage.",
"expected_output": "The workflow uses the full-spectrum test runner on a real server and returns a concise pass or fail summary backed by MCC and server log evidence.",
"files": [],
"expectations": [
"The workflow builds MCC before running the server scenario.",
"The workflow checks inventory and entity handling explicitly.",
"The response flags config reload failures as regressions."
"The workflow builds MCC before the scenario unless a fresh build is explicitly reused.",
"The workflow uses the full-spectrum runner instead of only manual spot checks.",
"The result includes evidence from both MCC output and server logs.",
"The result points to the saved run directory."
]
},
{
"id": 3,
"prompt": "Use the local MCC testing workflow to run a full-spectrum client/server exercise and summarize the important evidence only.",
"expected_output": "The response runs the scripted scenario and returns a concise summary with pass/fail status, affected commands, and log evidence.",
"prompt": "Validate a timing-sensitive MCC change on a real 1.21.11 server by collecting tick-rate and outbound packet-cadence evidence, then summarize the results clearly.",
"expected_output": "The response uses a real server, a temp config, and the provided sample scripts to capture tick-rate and packet evidence instead of relying on intuition.",
"files": [],
"expectations": [
"The workflow uses the scripted test runner.",
"The summary includes join status, MCC command coverage, and server-side effects.",
"The summary points to the saved log locations."
"The workflow uses the real 1.21.11 server.",
"The workflow uses the tick counter and packet capture scripts or clearly equivalent targeted instrumentation.",
"The workflow keeps the run isolated with a temp config.",
"The summary reports concrete counts or cadence evidence."
]
}
]

View file

@ -7,6 +7,10 @@ REPO_ROOT="$(cd "$SCRIPT_DIR/../../.." && pwd)"
source "$REPO_ROOT/tools/mcc-env.sh"
VERSION="${1:-1.21.11-Vanilla}"
MC_VERSION="${VERSION%-Vanilla}"
if [[ "$MC_VERSION" == "$VERSION" ]]; then
MC_VERSION="$VERSION"
fi
RUN_ROOT="${TMPDIR:-/tmp}/mcc-integration-testing"
RUN_ID="$(date +%Y%m%d-%H%M%S)"
RUN_DIR="$RUN_ROOT/$RUN_ID"
@ -16,6 +20,7 @@ BUILD_LOG="$RUN_DIR/build.log"
SERVER_TMUX_LOG="$RUN_DIR/server-tmux.log"
SERVER_FILE_LOG="$RUN_DIR/server-latest.log"
INPUT_FILE="$REPO_ROOT/mcc_input.txt"
CFG="$RUN_DIR/MinecraftClient.$MC_VERSION.ini"
MCC_PID=""
mkdir -p "$RUN_DIR"
@ -32,6 +37,27 @@ cleanup() {
}
trap cleanup EXIT
prepare_config() {
cp "$REPO_ROOT/MinecraftClient.ini" "$CFG"
sed -i \
-e 's/Account = { Login = "test", Password = "-" }/Account = { Login = "CursorBot", Password = "-" }/' \
-e "s/MinecraftVersion = \"auto\"/MinecraftVersion = \"$MC_VERSION\"/" \
-e 's/TerrainAndMovements = false/TerrainAndMovements = true/' \
-e 's/InventoryHandling = false/InventoryHandling = true/' \
-e 's/EntityHandling = false/EntityHandling = true/' \
-e 's/AutoRespawn = false/AutoRespawn = true/' \
"$CFG"
sed -i '/^\[ChatBot.ScriptScheduler\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
sed -i '/^\[ChatBot.DiscordRpc\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
sed -i '/^\[ChatBot.AntiAFK\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
sed -i '/^\[ChatBot.AutoDig\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
sed -i '/^\[ChatBot.AutoAttack\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
sed -i '/^\[ChatBot.PlayerListLogger\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
sed -i '/^\[ChatBot.ReplayCapture\]/,/^\[/ { s/^Enabled = true/Enabled = false/; }' "$CFG"
}
wait_for_file_pattern() {
local file="$1"
local pattern="$2"
@ -119,8 +145,15 @@ assert_not_contains() {
run_server_command() {
local cmd="$1"
local attempt
echo "SERVER> $cmd"
mc-rcon "$cmd" >/dev/null || fail "Server command failed: $cmd"
for attempt in 1 2 3 4 5; do
if mc-rcon "$cmd" >/dev/null 2>&1; then
return 0
fi
sleep 1
done
fail "Server command failed: $cmd"
}
run_mcc_command() {
@ -131,6 +164,7 @@ run_mcc_command() {
}
"$SCRIPT_DIR/ensure_offline_server.sh" "$VERSION"
prepare_config
: > "$INPUT_FILE"
@ -142,11 +176,10 @@ mc-start "$VERSION" >/dev/null
wait_for_server_ready || fail "Server did not become ready"
echo "Starting MCC..."
mcc-run 25565 \
--advanced.terrainandmovements=true \
--advanced.inventoryhandling=true \
--advanced.entityhandling=true \
> "$MCC_LOG" 2>&1 &
(
cd "$REPO_ROOT"
MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release --no-build -- "$CFG" > "$MCC_LOG" 2>&1
) &
MCC_PID=$!
wait_for_file_pattern "$MCC_LOG" "Server was successfully joined." "MCC join success" 90 || fail "MCC failed to join"

View file

@ -3,7 +3,16 @@
# Source this file to get helper functions: source $MCC_REPO/tools/mcc-env.sh
# Or add to ~/.bashrc: source "$HOME/Minecraft/Minecraft-Console-Client/tools/mcc-env.sh"
TOOLS_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
if [[ -n "${BASH_SOURCE[0]:-}" ]]; then
_mcc_env_source="${BASH_SOURCE[0]}"
elif [[ -n "${ZSH_VERSION:-}" ]]; then
_mcc_env_source="${(%):-%N}"
else
_mcc_env_source="$0"
fi
TOOLS_DIR="$(cd "$(dirname "$_mcc_env_source")" && pwd)"
unset _mcc_env_source
export MCC_REPO="$(cd "$TOOLS_DIR/.." && pwd)"
export MCC_SERVERS="${MCC_SERVERS:-$MCC_REPO/MinecraftOfficial/downloads}"