1.20.6 + 1.21 + 1.21.1 - Work in progress

[milutinke]

Heavy work in progress.

The current state:
✅ 1.20.6
✅ 1.21 (in works)
❌ Full Inventory support (Work in progress)

How even you can do this?

[andy01745]

Is their an ETA on this ?

[milutinke]

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.
I hope other Maintainers or someone else can take over and finish the inventory part.
I could merge it but without the inventory part (I'd disable it).

[jpcinqmars]

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?

[zerofelero]

@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!

[marcopaggioro]

Is there any chance this PR will be completed?

[Xantam-13]

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. I hope other Maintainers or someone else can take over and finish the inventory part. I could merge it but without the inventory part (I'd disable it).

Heeeey, any news on this buddy? Dying for 1.21.4 :(

[breadbyte]

@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.

[milutinke]

@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 pre-release branch and assigned it as the target branch for this PR.
Let me check all the changes in the following days to see if everything works.
If I'm not mistaken the inventory crashes on click, I need to figure out how to fix it, the issue is that it has been so long since I've worked on this and the wiki.vg has been merged into Minecraft Wiki, but some specific pages for older versions got lost, so I'll have to figure out what is the issue.
Could use some help with it if you have some time.

I've finished my uni year, so I should have more time to work on the MCC again.

[breadbyte]

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.

[breadbyte]

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:

Client --> Server: PARSING EXCEPTION for message Container Click(: 14)While reading carried_item (6th field) in ServerboundContainerClickPacket
While reading components (2th field) in Slot
Not enough input in ReadData<VarType>

A container click packet looks like this on a left click:

    "button_num": 0,
    "carried_item": {
        "components": {
            "map": []
        },
        "item_count": 1,
        "item_id": 843
    },
    "changed_slots": {
        "22": {
            "item_count": 0
        }
    },
    "click_type": 0,
    "container_id": 0,
    "slot_num": 22,
    "state_id": 1
}

and after another left click to another slot:

{
    "button_num": 0,
    "carried_item": {
        "item_count": 0
    },
    "changed_slots": {
        "22": {
            "components": {
                "map": []
            },
            "item_count": 1,
            "item_id": 843
        }
    },
    "click_type": 0,
    "container_id": 0,
    "slot_num": 22,
    "state_id": 1
}

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 Netherite Sword is being incorrectly identified as a Netherite Shovel.

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.

[milutinke]

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.

Hello, sorry for the late reply, I had some health issues.

The rough outline would be:

1. Check the Wiki changes for the newest version, and diff them with the previous protocol page, I note all the changes that differ in the protocol versions into a TODO file.
2. Start by updating the ProtocolHandler, then PacketTypesIn and PacketTypesOut, then ConfigurationPacketTypesIn and ConfigurationPacketTypesOut
3. Then I use Burger to obtain JSON with material, entity and block palettes, and then I use generators we have to generate palettes in our format and add them in.
4. Then I start updating Protocol18 packet by packet, implementing all the changes as I go, changing utility classes as I got and implementing Entity Metadata palette if needed.
5. I also update the structured components (not yet merged)
6. Then I test changes by booting up a local server and trying all the stuff manually, terrain movement, spawning a ton of different entities to test metadata, inventory handling fully, potions, etc..
7. Then I test it on online servers.

If I can't understand or get some changes from Wiki, I check out other implementations such as BotCraft and I consult the Minecraft Protocol Discord server, in the worst case scenario I needed to decompile the latest server jar and check out the changes manually in Mojang's code.

[milutinke]

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:

Client --> Server: PARSING EXCEPTION for message Container Click(: 14)While reading carried_item (6th field) in ServerboundContainerClickPacket
While reading components (2th field) in Slot
Not enough input in ReadData<VarType>

A container click packet looks like this on a left click:

    "button_num": 0,
    "carried_item": {
        "components": {
            "map": []
        },
        "item_count": 1,
        "item_id": 843
    },
    "changed_slots": {
        "22": {
            "item_count": 0
        }
    },
    "click_type": 0,
    "container_id": 0,
    "slot_num": 22,
    "state_id": 1
}

and after another left click to another slot:

{
    "button_num": 0,
    "carried_item": {
        "item_count": 0
    },
    "changed_slots": {
        "22": {
            "components": {
                "map": []
            },
            "item_count": 1,
            "item_id": 843
        }
    },
    "click_type": 0,
    "container_id": 0,
    "slot_num": 22,
    "state_id": 1
}

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 Netherite Sword is being incorrectly identified as a Netherite Shovel.

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.

Thanks for the info, I'll try to fix this issue and merge it.
As for refactoring, I think it's just not worth building on top of this old code, it's over a decade old and convoluted.
In my opinion, we're just better off starting from zero, and dropping all the older versions of Minecraft, and we start from the latest, as due to Wiki Vg being merged into the Minecraft Wiki, a lot of information was lost, and links are broken.
We could design the whole system to be very modular, to be fully asynchronous and easy to re-use in different clients, eg. GUI, TUI, Mobile, headless, etc..

[breadbyte]

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 😉

[ReinforceZwei]

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.