Great Idea

[DrMasik]

Do you have any description link about blockhandler?

[NiLSPACE]

No, I'm afraid not. You can see how they are used in C++ though: https://github.com/cuberite/cuberite/blo...kHandler.h

A blockhandler simply overrides a function if it needs to.

[SamJBarney]

I am currently working on getting a lot of Cuberite up to date with vanilla minecraft, specifically tree and biome generation.

There was a discussion about lua bindings for block handlers: https://github.com/cuberite/cuberite/issues/2390

However, I have been looking at the forge source code for a while, and it looks like we would have to have a separate branch specifically for Forge that could never be merged. The issue is that in vanilla minecraft, block ids are a single byte, while in Forge minecraft they are an int (4 bytes), and probably encoded as a VarInt when sent across the network. I don't know for certain about the network encoding, though.

I don't have time to do it right now, but perhaps you could test current compatibility. Create a cuberite server and connect to it with a client that has forge installed, along with a few mods that provide blocks. Then place a few blocks, log out, shutdown the server, start the server and reconnect. If the blocks are still there, maybe I am worrying for nothing.

[worktycho]

From what I've heard, vanilla mine-craft uses four byte ids internally, then serializes them down to one byte ids for the network. There is nothing saying we can't do that to.
So the biggest issues I can see with forge block compatibility is increased memory usage (cChunkSegment would grow by 120%), and protocol detection.

Memory usage can be mitigated by making blockids an opaque class, then adding a compile time flag as to whether to support forge.