lethalethan / honeybee

HoneyBEE is a Minecraft server implementation written in go, with help from wiki.vg (huge thanks to them), that aims to be fast by utilising go-routines and being optimised for a low cpu/ram footprint. (Pre-Alpha)

HoneyBEE

HoneyBEE is a Minecraft server written in GO, with help from wiki.vg (Huge thanks to them and I suggest helping them out with a donation for the awesome resources that they publish for free <3).

Join my discord for support and to ask questions :) here

This software is still being developed so expect bugs and issues now and then, also remember that feedback and disclosure of issues is welcomed but please don't send any hateful or spam issues :). HoneyBEE as of now is considered pre-alpha it is very early in development and has only been released publicly on github since 25/4/2020

Disclaimer: All code is completely original and is not based off of Mojang's code, any PR's must not be based off of or have any of Mojang's copyrighted code as it will not be accepted nor be encouraged as it would be obviously illegal, please see the Terms and Conditions of Mojang for familiarisation. I am not in any way affiliated with Mojang, HoneyBEE is not endorsed nor approved by Mojang.

This project is a cleanroom project meaning that I have to reverse engineer and read documentation that others and have wrote to understand how the network protocol works along with any other kind of necessary data, world generation will be completely be based off my own work along with AI and other ideas

To people who want to contribute: If you would like to contribute to HoneyBEE or HoneyComb you'll need to create a fork and submit a Pull Request (PR), The code will be reviewed and potentially be merged (no guarantees). I will also add your name to the contributors list. Any PR's and commits must use the same license and a CLA must be signed

As of now we only have basic features to start off with but as development continues we will have more features along with a custom plugin system (HoneyComb, will be available later in the future) and perhaps a way to get forge support although that would be WAYY in the future and I'm not too sure how that would be implemented especially with licensing.

I am very supportive of open-source and free software, for that reason this project will be free forever for personal use only. You can copy, modify and redistribute my code as long it is under the terms of the license and credit is given to proper authors. If you would like to donate to support HoneyBEE that would be much appreciated and you will be added to the donator list (Donators.md)

I would like to give a massive thanks to: @lynxplay @MiniDigger @magiccheese1 @mrsherobrine @Felenov @fahlur and @SNokerYT

Checklist

• 1.17 protocol support (Handshake, Status, Login, Play)
• Entities and Tile entities
• Mobs and Animals
• Simple Terrain Generation
• Chunk/Region Handling
• Configurable Terrain Generation
• HoneyBEE Plugin API (HoneyComb)
• Commands
• Block/Entity Data
• Actually logging in and being able to play to some degree
• NBT
• Bedrock Support
• Server Configuration
• HoneyHive (A proxy linking multiple HoneyBEE servers muchlike waterfall/bungee)

Suggestions

For General use, I suggest Paper it is stable, bukkit compatible, fast and is the go to standard for most servers.

HoneyBEE is in pre-alpha and with that could come major changes that may break/corrupt worlds (We'll try not to). HoneyBEE at the moment will only suitable for a simple creative/lobby server as the terrain generation and entity AI is nowhere near completion and could take some time.

If HoneyBEE isn't what you needed you could look at some other projects that are popular and are recommended from me. The projects listed are actively developed and support modern-ish versions of Minecraft (1.12 - 1.17):

Wanting a lightweight C# minecraft server? Starfield (C#)

Wanting a Java based Minecraft server? Visit Spigot (Java)

Wanting a fast java based Minecraft server? Visit Paper (Java)

Wanting a scalable, experimental server in C#? visit Mincase (C#)

Wanting a server with forge mods and bukkit plugins? Visit Magma (Java)

Wanting a fast Minecraft 1.8 - 1.12.2 server in C/C++? Visit Cuberite (C++)

Wanting a multithreaded Minecraft server built for redstone? MCHPR (Rust)

Wanting a Minecraft server with a stable, high level API? Visit Prismarine (Js)

Wanting a C# implementation of the Minecraft server protocol. Obsidian (C#)

Wanting a fast, lightweight Minecraft server written in Kotlin? Krypton (Kotlin)

Wanting a paper server with some added gameplay features ? Visit Purpur (Java)

Want to create your own server with an API other than bukkit? Visit Minestom (Java)

Wanting an experimental Minecraft Server implementation in Rust? Visit Feather (Rust)

Wanting a Minecraft server that supports the SpongeAPI? Visit Sponge and Lantern (Java)

Wanting a fast, cleanroom based server implementation with bukkit? Visit Glowstone (Java)

Wanting a fast multithreaded and async implementation of a minecraft server? MotorMC (C)

Wanting a high performance minecraft server written in golang, soley made for PvP? gogs (GO)

Wanting a high performance paper-fork server with additional performance patches? airplane (Java)

honeybee's Issues

HoneyBEE wen?

Finish compression packets and then move onto implementing more play logic and also fixing the play logic I already have

Re-use packet writers and readers for each client

Instead of creating new objects for every single packet and client, only use 1 set of PR's and PW's per client that can be reused which makes memory allocations lower.

When possible make encode and decode functions concise

Deprecate and remove old server package

• Move status handling to npacket or separate package
• Re-work vartool for gnet or just ignore parsing from connections as I don't really need to do that.
• Move authentication and re-do hash

NBT To-Do performance/usability improvements

• Store the next TCompound's within the previous compound tag to better traverse in a []*TCompund slice. TCompound will likely still exist in its value array as it tells the encoder the order of the objects which is very important.
• Create AddToList function, users can just manually add tags to the []interface{} value but will be useful to have functions for it anyway.
• Create search feature so users can backtrack to tags and change them in writer
• Create ReaderAndWriter pair?
• Use generics when they come out, it will make the code a lot cleaner and readable
• Add support for SNBT

PacketReader causes crash because of a slice out of bounds error

The reason I'm opening this issue is because the error happened on a public test server I had created, I also want to document my reasoning and possible fixes I implement, it panicked due to:

`panic: runtime error: slice bounds out of range [:45] with capacity 2

goroutine 37 [running]:
Packet.(*PacketReader).ReadString(0xc000061f78, 0xc000000000, 0x0, 0x0, 0x246)
/home/ethan/Documents/CodeProjects/Go/HoneyGO/src/Packet/PacketReader.go:234 +0x23c
Packet.HandshakePacketCreate(0xc000000002, 0xc000061f78, 0x2, 0x2, 0x0)
/home/ethan/Documents/CodeProjects/Go/HoneyGO/src/Packet/PacketHandshake.go:22 +0x7c
server.HandleConnection(0xc00030ef00)
/home/ethan/Documents/CodeProjects/Go/HoneyGO/src/server/Server.go:155 +0x2d9
created by main.main
/home/ethan/Documents/CodeProjects/Go/HoneyGO/main.go:94 +0x915
`
Just before the panic a handshake was initiated and the CCH (ClientConnectionHandler) was initiated. It shows that there was an issue with reading a string from the packet which is the server address in the Handshake packet.
Possible fixes:

• Check that the stringSize and seek doesn't go past pr.end
• Do a simple handshake packet size check that drops it if it's too low (not ideal)
• Scrap the old packet read/write system and redesign a new one with support for interfaces

To-DO list

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

Switch out MITM to HoneySmoke

World loading

• BEEYard Save format
• Locate region files and world level data
• Region file compression, using zstd. Debating whether the chunks should use the same palette system as the protocol
• Send Update view position when a chunk border is crossed
• Keep track of which regions and chunks are loaded

anymore things that I think of will be appended to this message.

Add macos build action

Rework network and server

I am running into issues with these packages as they will randomly fail, and I personally think it's quite janky in design and it's due to be re-done for a nicer system. For every packet, I will have a struct that is used to define what the packet contains as we already know that from wiki.vg, based off that I can just use an interface with 2 methods for Decode() and Encode() that will of course link to the corresponding packet encode and decode functions. This makes the code a lot cleaner and allows me to split up the handling instead of all being in one giant clump (lots of boilerplate in the server package rn). Here is the design I've made (https://imgur.com/a/cTR7mM9). Edit: In the image, I didn't mean interface, I meant struct methods since interfaces can be used for the purpose, but it is unnecessary and makes the code more convoluted.

• Create packet Structs - Handshake and Status
• Create packet Structs - Login
• Create packet Structs - Play
• Create struct methods for each packet
• Switch to gnet for more efficient networking (if possible since the documentation ain't great, either that or I'm dumb)