Project goals

[fenhl]

Edit: Updated project goals can be found in the discussion below, starting with this comment. Original opening comment follows:

Before we do any actual coding, we should define the project goals. Here are some of my ideas, in decreasing priority:

1. The most important goal should imo be feature parity with the “Notchian” vanilla Minecraft server, specifically the latest stable release of the standalone minecraft_server.jar. That is, anything which is considered a feature (as opposed to a bug or implementation detail) of the Notchian server is (in 20XX) also a feature of the Hematite server.
2. Custom features which are not present in Notchian (see below for examples) should be disabled by default. For example, the presence of a hematite.json config file in the server directory could trigger custom features.
3. Besides a standalone binary, there should also be a library crate which can be used by the Hematite client for the local singleplayer server.
4. A branch which tracks the latest snapshots and pre-releases.
5. As a custom feature, an implementation of a future version of the Wurstmineberg Minecraft API or perhaps even a superset capable of replacing wurstminebot is something I would like to see.
6. Multi-world support as a custom feature.
7. Performance, obviously.
8. A way to detect Hematite clients and use a more performant variant of the protocol for them (e.g. chunk caching), perhaps as a custom feature. I'm not sure if this is worth the additional code complexity.

What do you think about these? And do you have any other suggestions for project goals?

[toqueteos]

It would be a good thing to share as much as possible with hematite itself. This would lead to cleaner code and also a better approach for a possible modding API (server-side modding should be possible without much hassle, some sort of "Bukkit-like" API).

• Common crate (lib, both client and server functionality)
• Client crate (lib, client specific API)
• Server crate (lib, server specific API)
• Vanilla crate (bin, like minecraft_server.jar but no JVM dependency 👍)

That's the approach I'm following on my upcoming rewrite of https://github.com/minero/minero-go in Rust. I already have some parts of the protocol working (some hours into the project). I did fork hematite because I want to use it as the client (and I'm almost finished updating it for 1.0-alpha).

My goal is to have a nice moddable server and also a moddable client like Spout did some time ago.

[fenhl]

Is there enough server-specific code to warrant the Common/Server split? The way the project is set up right now, the server lib would be a dependency of the client, which needs most of the server code anyway for singleplayer.

[toqueteos]

@fenhl Well.. it depends. Modding is the key here. Server has some events, client has others. Mods could even add custom events to both. Will hematite support mods?

[fenhl]

@toqueteos whatever mods you can apply to the standalone server should also be applicable to the embedded server used in singleplayer, no?

[indiv0]

@fenhl perhaps, but that precludes the use of client-specific mods (e.g. GUI modifications).

[fenhl]

@indiv0 How so?

[indiv0]

@fenhl well from your phrasing I gathered that if mods are built against the server API, wouldn't that mean that there is no client API (and hence no client mods)?

[fenhl]

@indiv0 no, I'm not ruling out a separate client mod API. (However, given the potential complexity I'm not sure if any modding API should be a project goal.)

[toqueteos]

Brief intro to MC modding.

• Bukkit does did? work only on the server so it was FULLY compatible with vanilla clients.
• Forge does monkey patching on the vanilla client to add client specific mods (which most of the time leads to server mods too), not compatible at all with vanilla clients.

So, there's THREE approaches:

1. The Vanilla approach. Easiest one. Replicate minecraft_server.jar. Doesn't add anything.
2. The Bukkit approach. As "easy" as Vanilla + exposing API for server-side modding. This allows Hunger-Games, Factions and the-like. No need to touch the client at all.
3. The Forge approach. "Hardest"; requires Java monkey patching or building a new client. We already have hematite, almost building (I'm working hard on that).

Now it's time to discuss what path we may follow. No matter what is chosen, we are gonna build some kind of API in order to be compatible with vanilla clients, doing it right ™️ gives us "modding for free", which is the big thing about MC.

[fenhl]

I suggest an approach between Bukkit and Forge: the protocol allows the client to register a plugin channel which we could use for a modding infrastructure which has both backwards-compatibility with vanilla and support for client mods. In short:

1. Hematite client sends the server a REGISTER Hematite plugin message.
2. If the server doesn't respond, it is not compatible, and vanilla behavior is continued.
3. Hematite server responds on this channel, any custom features requiring client support are enabled.

[toqueteos]

No one complained about @fenhl 's proposal so it seems everyone is happy with it.

[fenhl]

Okay, so here is a list of goals updated for the discussion above:

1. Feature parity with Notchian.
2. Separating custom features from vanilla behavior by requiring explicit activation in a hematite.json config file.
3. A library crate which can be used by the Hematite client for the local singleplayer server. This should have most of the codebase.
4. A branch which tracks the latest snapshots and pre-releases.
5. A modding API of some sort.
6. A REST API as a custom feature, exposing a subset of the modding API.
7. Multi-world support as a custom feature.
8. Performance.
9. Detecting Hematite clients using plugin channels, enabling custom features requiring client support (e.g. chunk caching or some mods).

The question is, how will modding work? Rust is a compiled language so as far as I understand any server mods would have to be included in the server at compile time. Perhaps a helper tool to compile the server with a given set of mods?

[bvssvni]

Cargo supports features that can be activated through the command line. For example:

cargo build --features multi-world

Perhaps a helper tool to generate a Cargo.toml?

[toqueteos]

1. 100% ok with it. I, almost, have finished implementing MC protocol.
2. Would like to know which custom features, but ok.
3. Not just one library crate, there's packets for client, for server and for both.
5. Must do. Just watch numbers on https://lab.xpaw.me/snoop.html
6. Not entirely sure why we could want this... This should be an external crate. If there's events throwing which users can use then doing this should be easy (whenever hyper is more stable).
7. Easy to do.
8. Performance is a nice way of bringing users to us.
9. Ok but same concerns as of 2.

---

Are .dll/.so files discarded? std::dynamic_lib may be a suitable option. They are gonna be using one crate of ours anyways, we could check if it has certain methods and only accept those.

EDIT: No matter what, bad people will always find a way to annoy users.

EDIT2: This approach allows using more than one server-mod, which is desirable. Drop all your .dll/.so inside mods/ folder and done.

EDIT3: There's also Rust's .rlib which should be easier to deal with (not entirely sure about this).