Open fenhl opened 9 years ago
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).
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.
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.
@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?
@toqueteos whatever mods you can apply to the standalone server should also be applicable to the embedded server used in singleplayer, no?
@fenhl perhaps, but that precludes the use of client-specific mods (e.g. GUI modifications).
@indiv0 How so?
@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)?
@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.)
Brief intro to MC modding.
So, there's THREE approaches:
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.
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:
REGISTER Hematite
plugin message.No one complained about @fenhl 's proposal so it seems everyone is happy with it.
Okay, so here is a list of goals updated for the discussion above:
hematite.json
config file.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?
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?
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).
Have you seen hyper? It's pretty good IMO, and even Servo switched to it, last month.
Not actually a fork because I started this for another project but you get the idea: https://github.com/toqueteos/hematite_server
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?
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.
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:
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.hematite.json
config file in the server directory could trigger custom features.What do you think about these? And do you have any other suggestions for project goals?