1.20.6 + 1.21 + 1.21.1 - Work in progress#2820
1.20.6 + 1.21 + 1.21.1 - Work in progress#2820milutinke wants to merge 16 commits intoMCCTeam:pre-releasefrom
Conversation
milutinke
changed the title
Fix session cache serializer failure
|
Is their an ETA on this ? |
Nope, I most likely won't be able to finish this any time soon, I work full time while attending an university. |
|
Really appreciate all the work you have done on the MCC, I have used it for almost a year now. Is there any chance you could merge it for 1.21+ and disable inventory as you mentioned? |
|
@milutinke , is it possible to get 1.21.x (preferrably 1.21.7) support by just disable inventory? I second @jpcinqmars request, as something is better than nothing. i hope all is well! |
|
Is there any chance this PR will be completed? |
Heeeey, any news on this buddy? Dying for 1.21.4 :( |
|
@milutinke can you instead merge this on a new branch just so we can consolidate all changes made from both our ends? I already have a repo that merges both our changes so I can continue working on it, although I want to know if you still want to merge this PR on your end. |
Sure, I've created a I've finished my uni year, so I should have more time to work on the MCC again. |
|
Do you have a rough outline on how you implement new versions (new components, new ents/blocks etc.) so we can get 1.21.2+ up and running? I think archive.org has wiki.vg archived, so we can still use that for reference. To be honest with you, I'm still racking my brain on how to implement terminal support that doesn't break all the time 😵💫 (couldn't find libraries that can handle input and output at the same time, not to mention popover support for autocomplete) Was thinking of separating the entire application from the ui layer (mcc will become a library, essentially), and we just have an interface to stdin/stdout. This will make autocomplete a little harder to implement, but will make our life easier in the long run (this will also improve support for docker/ptero since it becomes a first-class citizen essentially) I've also been thinking on how to better resolve issues, maybe we can add a packet comparison with vanilla (matches against expected response) or by unit testing? Would like to have more input on this. |
|
For the inventory crash, I've used SniffCraft for 1.21 to check the root cause. Seems like we're crafting a broken packet as per SniffCraft: A container click packet looks like this on a left click: and after another left click to another slot: This moves the item from slot 22 to slot 22 (clicked twice on the same slot). This is certainly useful information, but it's something that I don't know how to fix myself as I don't know how the system is implemented. I vaguely remember you having notes on implementation somewhere but I couldn't find it. SniffCraft also revealed more information for us, as we seem to be sending way too many MovePlayerPosition when idle, to the point where it seems like it's spamming the server (we seem to send it per tick, as opposed to the vanilla client that sends it at a rate of about 1 per second when idle.) There are also palette issues on 1.21, as a I've been thinking about this for a while, but how about we drop the entire item id system in exchange for namespaces? Compatibility layers can be added for converting pre-flattening ids. Older versions adapt to the newer versions, while the latest version is always the ground truth for data. This would mean a little more work as we'll have to coerce all the old stuff into modern equivalents, but would save us a lot of headaches with compatibility, since we won't need to deal with palettes anymore. |
Hello, sorry for the late reply, I had some health issues. The rough outline would be:
If I can't understand or get some changes from Wiki, I check out other implementations such as |
Thanks for the info, I'll try to fix this issue and merge it. |
|
Personally, I agree about starting from scratch due to the monolithic nature of the code, but I don't know how that would run against the other contributors on the project. Can't have technical debt if you don't have code to begin with 😉 |
|
I agree we should start a new project from ground and deprecate old mcc. We have MCCTeam organization it's easy to start another repository and still under MCC name. But unfortunately I might not have enough free time and motivation to continue contribute on a Minecraft related project, and I don't play Minecraft now. |
|
Hi everyone, long time no see! It's really great to see this project is still being maintained. I'd like to chip in and help out with the maintenance in my spare time. @milutinke , could you give me a quick update on which versions and protocols still need to be adapted? I'm thinking I could spend some time this weekend to push this PR forward. As for a complete refactor to support all these versions, it sounds like a massive amount of work. Since there's already a |
|
I've been doing some additional adaptation work for the 1.20.6 protocol support with the help of AI. The changes are pushed to https://github.com/BruceChenQAQ/Minecraft-Console-Client-1.19dev/commits/1.20.6/ and include fixes for RegistryData parsing, KnownDataPacks negotiation, dynamic attribute registry, StructuredComponent serialization correctness (ContainerComponent, ChargedProjectilesComponent, BundleContentsComponent, FoodComponentComponent, PotionContentsComponent, InstrumentComponent), and enchantment name mapping/display. Each commit message contains detailed background info on what was wrong and why. One useful resource I'd like to share: you can use the tools listed at https://minecraft.wiki/w/Tutorial:See_Minecraft%27s_code#Navigation to browse/decompile the official server code, which is very helpful for verifying protocol details like |
|
@BruceChenQAQ Hello and welcome back. Sorry for replying this late, I've been traveling, did not check the notifications. As for starting from 0, it can be done with the help of AI, if we set it up properly and give it good documentation, it needs a bit of up-front work setting up all the AGENTS.md/CLAUDE.md, skills, rules, documentation, examples, and hooks, but once those are in place, we can use TTD and get this up in no time. I've spent 3 years trying our various AI tools and patterns, and refactoring some massive code bases at work, so I have the expertise for this. Once you merge your PR, let's do 1.21.4 to 1.21.10 in order, I'll use Claude Code and Codex to create Markdown documentation for those protocols first. |
|
@milutinke Welcome back and glad to hear you're doing better! No worries about the late reply at all. Yes — all changes have been tested. Let me walk you through how I set up the AI-assisted development workflow, since I think this approach could be very useful for the future adaptation work you mentioned. AI-Assisted Debugging Workflow — "Harness Engineering"The key idea is to give the AI agent (Cursor) a closed-loop environment where it can compile, deploy, test, and inspect results autonomously, without needing interactive terminal access. Here's what I built: 1. Fix Non-Interactive Terminal CrashesThe first blocker was that MCC (specifically 2. Server Management AliasesI set up bash aliases so the AI can start/stop/query Minecraft test servers with single commands, and use RCON to execute server-side commands (like # Start server in tmux with named pipe for stdin
mc-start 1.20.6-Vanilla
# Send server commands via RCON (no interactive terminal needed)
mc-rcon "give CursorBot diamond_sword{Enchantments:[{id:sharpness,lvl:5}]} 1"
mc-rcon "summon minecraft:armor_stand ~ ~ ~ {Tags:[\"test\"]}"
# Build and run MCC
mcc-build && mcc-run3. FileInputBot — Command Injection for AISince AI agents can't type into an interactive console, I added a simple # AI writes commands to the file, MCC picks them up within ~500ms
echo "inventory player list" >> mcc_input.txt
echo "/gamemode creative" >> mcc_input.txtThis gives the AI a complete compile → run → test → inspect loop without any human interaction. 4. Decompiled Server Source as Ground TruthI provided decompiled official Minecraft server source code for each target version under 5. Version Adaptation SkillI wrote a reusable "skill" (structured instructions for the AI) for cross-version protocol adaptation. It guides the AI through: running registry diffs between versions → generating updated palettes → updating version routing → handling new serializer types → compile & verify. This made the 1.21 → 1.21.2 jump largely automated. Testing MethodologyWith the above infrastructure, the AI autonomously performs testing like:
All three versions (1.20.6, 1.21, 1.21.2) pass these tests on vanilla offline-mode servers. Regarding Next StepsCompletely agree with your plan — let's get this merged first, then tackle 1.21.4 → 1.21.10 incrementally. The workflow I described above should make that much faster. Having Claude Code / Codex generate protocol documentation first is a great idea; combined with the decompiled source and the diff tooling, each version jump should be fairly mechanical. I also strongly agree about the long-term rewrite approach: get it working first, then refactor, then eventually rebuild as a clean library. The decade-old codebase definitely shows its age, but it works, and there's a lot of institutional knowledge embedded in it. Appendix: Tooling Files~/.bashrc — MCC Development Utilities# ============================================================
# MCC (Minecraft Console Client) Development Utilities
# ============================================================
export MCC_REPO="$HOME/Minecraft/Minecraft-Console-Client-milutinke"
export MCC_SERVERS="$HOME/Minecraft/Servers"
# Helper: convert version to tmux session name (dots -> underscores)
_mc-session() { echo "mc-${1//\./_}"; }
# --- Minecraft Server Management ---
mc-start() { "$MCC_SERVERS/start-server.sh" "${1:-1.20.6-Vanilla}"; }
mc-stop() { local v="${1:-1.20.6-Vanilla}"; echo "stop" > "$MCC_SERVERS/$v/stdin.pipe"; }
mc-cmd() { local v="${2:-1.20.6-Vanilla}"; echo "$1" > "$MCC_SERVERS/$v/stdin.pipe"; }
mc-log() { local s; s=$(_mc-session "${1:-1.20.6-Vanilla}"); tmux capture-pane -t "$s" -p -S "-${2:-50}"; }
mc-kill() { local v="${1:-1.20.6-Vanilla}" s; s=$(_mc-session "$v"); tmux kill-session -t "$s" 2>/dev/null; rm -f "$MCC_SERVERS/$v/stdin.pipe"; echo "Killed $s"; }
mc-list() { tmux list-sessions 2>/dev/null | grep "^mc-" || echo "No running MC servers"; }
# --- RCON ---
mc-rcon() {
local cmd="$1" port="${2:-25575}" pw="${3:-test123}"
python3 -c "
import socket,struct,sys
s=socket.socket()
s.settimeout(5)
try:
s.connect(('localhost',$port))
except Exception as e:
print(f'Connection failed: {e}',file=sys.stderr); sys.exit(1)
def send(i,t,b):
b=b.encode()
s.send(struct.pack('<iii',10+len(b),i,t)+b+b'\x00\x00')
def recv():
l=struct.unpack('<i',s.recv(4))[0]
d=b''
while len(d)<l: d+=s.recv(l-len(d))
return d
send(1,3,'$pw');r=recv()
rid=struct.unpack('<i',r[:4])[0]
if rid==-1: print('Auth failed',file=sys.stderr); s.close(); sys.exit(1)
send(2,2,\"\"\"$cmd\"\"\");r=recv()
body=r[8:-2].decode(errors='replace')
if body: print(body)
s.close()
"
}
# --- MCC Build/Run ---
mcc-build() { dotnet build "$MCC_REPO/MinecraftClient.sln" -c Release; }
mcc-run() { cd "$MCC_REPO" && MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release -- CursorBot - "localhost:${1:-25565}" 2>&1; }
mcc-cmd() { echo "$1" >> "$MCC_REPO/mcc_input.txt"; }
mcc-kill() { pkill -f "MinecraftClient" 2>/dev/null && echo "MCC killed" || echo "No MCC process found"; }
mcc-reload() {
mcc-kill
sleep 1
mcc-build && mcc-run
}start-server.sh — Tmux-based Server Launcher#!/bin/bash
# Start a Minecraft server in a tmux session with named pipe for stdin
VERSION="${1:-1.20.6-Vanilla}"
DIR="$HOME/Minecraft/Servers/$VERSION"
PIPE="$DIR/stdin.pipe"
SESSION="mc-${VERSION//\./_}"
if [ ! -d "$DIR" ]; then
echo "Error: Server directory $DIR does not exist"
echo "Available versions:"
ls "$HOME/Minecraft/Servers/" | grep -v '\.sh$' | grep -v '\.pipe$'
exit 1
fi
if tmux has-session -t "$SESSION" 2>/dev/null; then
echo "Server $VERSION already running in tmux session '$SESSION'"
echo "View output: tmux capture-pane -t '$SESSION' -p -S -50"
echo "Send command: echo 'say hello' > $PIPE"
exit 0
fi
rm -f "$DIR/world/session.lock"
[ -p "$PIPE" ] || mkfifo "$PIPE"
tmux new-session -d -s "$SESSION" -c "$DIR" \
"tail -f $PIPE | java -Xmx2G -Xms2G -jar server.jar nogui 2>&1"
echo "Server $VERSION started in tmux session '$SESSION'"
echo "Send commands: echo 'say hello' > $PIPE"
echo "View output: tmux capture-pane -t '$SESSION' -p -S -50"mcc-dev-workflow SKILL.md — AI Agent Instructions# MCC Development Workflow (WSL)
## Project Overview
- Repo: `~/Minecraft/Minecraft-Console-Client-milutinke` (env var `$MCC_REPO`)
- Solution: `MinecraftClient.sln` (projects: `MinecraftClient` + `ConsoleInteractive`)
- Build: `dotnet build MinecraftClient.sln -c Release`
- Servers: `~/Minecraft/Servers/` (env var `$MCC_SERVERS`)
## Typical Debug Workflow
1. `~/Minecraft/Servers/start-server.sh 1.20.6-Vanilla` (background)
2. Wait for "Done" in server output
3. Build: `dotnet build $MCC_REPO/MinecraftClient.sln -c Release`
4. Run MCC: `cd $MCC_REPO && MCC_FILE_INPUT=1 dotnet run --project MinecraftClient -c Release -- CursorBot - localhost 2>&1`
5. RCON: `mc-rcon "op CursorBot"`
6. MCC cmd: `echo "inventory player list" >> $MCC_REPO/mcc_input.txt`
7. Read terminal file to see output
8. Kill MCC → rebuild → repeat
## Timing Reference
| Operation | Typical Duration |
|-----------|-----------------|
| MCC startup → join server | ~1s |
| FileInput command → response | <500ms |
## Official Minecraft Server Source (Decompiled)
`$MCC_REPO/MinecraftOfficial/` contains decompiled official server code for protocol reference.
When investigating protocol details (packet structure, field order, NBT format, etc.),
look at the corresponding version's decompiled source as authoritative reference. |
|
@BruceChenQAQ Awesome, I like it very much. I had a similar idea, but never got around to doing it. Check if there is a MCP plugin for a Minecraft server, might be better than rcon. We also could implement a MCP into the MCC later on. Btw, one thing I forgot about was the Declare Commands packet, it was broken in 1.20.4, was crashing and I spent hours debugging it and not being able to figure out why it crashed due to the number of information sent. This is the piece of code I added: Edit: |
|
@milutinke Thanks, that makes a lot of sense. I can imagine the amount of work needed to properly adapt About RCON, the main reason I chose it is that it’s supported by vanilla servers out of the box, so there’s no need to install any extra plugin. After wrapping it in a helper function, using it is also quite straightforward — from the shell you can just do something like: mc-rcon "give Bot test_block 1"And about AI — things are moving incredibly fast now. Top models are evolving so quickly that I really do write much less code by hand than before. For a project like MCC, where both input and output are mostly text-based, it feels like a very good fit for LLMs. As models keep getting stronger and cheaper, I think maintenance will become much easier for us. Beyond MCP, I also have another idea: allowing users to give MCC tasks directly in natural language, with inputs coming from different sources, and then letting AI use MCC’s capabilities to execute them. Right now the command set we expose is still not complete enough, but I think that could be a very interesting direction in the future. |
10 participants
Heavy work in progress.
The current state:
✅ 1.20.6
✅ 1.21 (in works)
❌ Full Inventory support (Work in progress)