To-DO list

[LethalEthan]

• Basic play state Handling
• Flat terrain generation
• Chunk/Region stuff
• NBT
• update Blocks and Items
• Player location/Co-ordinates

[LethalEthan]

Currently on a small hiatus due to college

[LethalEthan]

Another note: Minecraft 1.17 may introduce an increase in chunk height, package world and chunks need to be integrated. I need to make changes to facilitate a future change in chunk height and if the change never occurs officially we can leave it up to the modders to play around with.

[LethalEthan]

1.17 height change has been confirmed, I need to also finish the Packet analyser or use an external tool to gather more information.

[LethalEthan]

Update
I'm also working on an event-based system that other packages internally can use and that HoneyCOMB API can use (externally). For the HoneyCOMB API, I thought of using the golang shared library method of calling plugins and loading them but this is far from a perfect system; one major problem is security for example a random untrusted shared library that a user loads in can do malicious things when called on initialisation.

So I'd rather use another way even if that may be detrimental to performance, it could be a custom scripting language that then compiles into bytecode that HoneyCOMB can use, or using RPC/REST-API to allow languages such as python to communicate with HoneyCOMB so it's easier for developers to make plugins. At first, with HoneyCOMB API, I think I'll introduce all these ideas and allow the user/developer to select what they want then after when HoneyGO/COMB matures the shared library plugin system will be deprecated and disabled for security (I'll also warn the user of the security implications of shared library usage). I personally think the RPC or bytecode system will be much better for security and for developers to make plugins easier to create in their preferred language but will be harder to develop and maintain (we'll see how it goes) and along with potential synchronisation and deadlock issues.