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 :+1:)

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 :tm: 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.
4. -
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).

[fenhl]

• re 1: If you're already coding, why not push to the project?
• re 2 and 9: For example multi-world support, chunk caching, or custom features provided by a mod.
• re 3: Yes but all packets are used by both sides. It makes little sense to implement each packet twice, especially considering that the entire serialization and deserialization steps can be skipped for singleplayer.
• re 6: The reason behind this is that it could provide the functionality of http://api.wurstmineberg.de/ and more. I agree that it could easily be implemented as a mod.

[toqueteos]

• re 1: @eddyb is reviewing what i do, also guiding me to the rust way of doing things. Yesterday packets were hand-written, heavily commented and over 5k lines of code. After his review packets are now 500 lines tops, declarative style. Still not ready to push.
• re 3: Singleplayer is just a server on listening on localhost, de/serialization is still required.
• re 6: still http library required, rust not there yet.

[eddyb]

Have you seen hyper? It's pretty good IMO, and even Servo switched to it, last month.

[fenhl]

• re 1: I've read the backlog now. Current state of the code would still be nice to have (doesn't have to be pushed to the project), since there are some things I might want to discuss.
• re 3: It's not required if both use the same types for packets, and it should actually be a performance gain if memory is shared and serialization overhead is lost. This is similar to how Notchian does it. For them it leads to weird bugs which happen only in singleplayer or only in multiplayer, but avoiding this kind of thing should be easy with Rust's memory safety features.

[toqueteos]

Not actually a fork because I started this for another project but you get the idea: https://github.com/toqueteos/hematite_server

[ghost]

Does the project goal include running hematite_server in cluster server? If not, I am afraid I will do my own project. because I want a such thing could be support 1000+ players playing, and it is important for we.

and, i18n support?

[fenhl]

I18n is a vanilla feature, so that's a given. And running with 1000+ players falls under performance I believe, we'll see how far we'll get with that.