Frequently Asked Questions

The main reason is that it's simply the right tool for the job. An ECS excels at managing high numbers of entities with complex interactions, which is exactly what a Minecraft server needs to do. The ECS approach wasn't super popular when Minecraft was first developed and the JVM makes it much harder for the ECS's cache hits to shine since the JVM can get in the way with its own memory management and optimizations, but Rust's lack of a runtime makes it a perfect fit. Even Mojang sees the value in it, since Bedrock Edition uses an ECS architecture as well. In the end, Java is more designed for OOP architectures, and Rust lends itself better to an ECS design, so it just made more sense to go with an ECS for Temper rather than trying to shoehorn an OOP design in there just for the sake of familiarity or tradition.

We use a proper key-value database for storage, called LMDB. It has a lot of upsides like massive performance, memory-mapping, fault tolerance and being developed by people way smarter than us. It's not compatible with Minecraft's world format called Anvil sadly, but we figured that utilizing 15 years of software breakthroughs since Minecraft's inception was worth trading out drop-in compatibility for, especially since we have a world importing tool that can import existing worlds.

It's very much on the roadmap, but we want to get it right first try instead of having a half-assed API that needs changing every 3 months. Plugins will be written in Rust and compiled to binary libraries that Temper will be able to run. This allows for high-performance plugins that can comfortably interface with the rest of the Rust ecosystem. This will however come with some downsides; namely plugins being platform dependant so you'll likely have to download a version of each plugin for your server's OS, and the barrier to entry for plugin development being higher since Rust is a more complex language than Java which is used for plugins in other Minecraft servers. We think the performance and ecosystem benefits are worth it though, and we're working on making it as easy as possible to develop plugins in Rust with good documentation, examples and tooling.

Long story short, no. Completely different languages, implementations and architectures make it almost impossible for Java plugins to work with Temper. A compatibility layer would be possible in theory, but it'd be a massive headache to implement, extremely sketchy and having to pass everything to a Java runtime and back would obliterate performance. More complex plugins would also require a deeper compatibility layer and it'd eventually get to the point where reliably running popular plugins like WorldEdit or Dynmap would require us to basically re-implement Paper/Bukkit on top of Temper, at which point there isn't much reason to be doing this project in the first place. When feature-completeness is on the horizon we might revisit, but for now it's very unlikely it'll happen.

I know the software world is saturated with stuff being rewritten in Rust for no good reason, but I promise it's actually the tool for the job here. If we want solid performance improvements, we need to pick the right language for the job, and native code is almost always faster than VM languages like Java, C# or Go. The main contenders for natively compiled options are C, C++, Rust and Zig. I'm not doing this is C because it's an ancient language with memory safety boiling down to "get gud", abysmal tooling and is miserable to work with. C++ is slightly better, but is plagued with decades of bloated features and still has considerable memory safety concerns. Zig is certainly cool and I would be interested in seeing if it could at some point be integrated in the project, but ultimately it's very young and has a much smaller ecosystem and community than Rust, which would make it harder to find contributors and libraries for things like networking, databases and other stuff we need. Rust on the other hand has a fantastic ecosystem, great performance, memory safety guarantees and is generally a joy to work with once you get past the learning curve. I've also found that the rust community is extremely welcoming and inclusive, which is important for getting new contributors and building a positive community around the project. So yeah, Rust is the best choice for this project in my opinion, and I think the "BlAzInGlY fAsT" stigma is a fair price to pay for safe, high-performance code and a great community.

If I'm going to be honest, the name sounded cool and I had the think of a reason after. Tempering is the process of hardening metal by heating and cooling it, which could be a metaphor of what we're doing with Minecraft server software; taking something that already exists and making it stronger, faster and more resilient through a lot of hard work and iteration. Honestly, up to interpretation, the domain was cheap, name sounded cool and wasn't used by anything else notable so I just went for it.

I wanted to carry on the proud tradition among Minecraft server projects of forking over management issues and splitting the community in half. In all seriousness, we just didn't agree on how to run the project. There was no major falling out or anything and we are still on good terms, but we had different visions for the project's direction and management style that ultimately led to us parting ways.

We welcome contributions of all kinds, whether it's code, documentation, bug reports or just spreading the word. Hopping in the Discord is a good first step, since you can ask what needs working on we can discuss how to best help you contribute. If you want to dive right into the code, the GitHub usually has some issues open for what needs doing, feel free to pick one up and start working on it, and if you have any questions or need help don't hesitate to ask in the Discord or open an issue on GitHub. If you want to work on something that someone else has already picked up, chuck a comment on the issue or in the Discord to see if you can collaborate with them rather than stepping on their toes.

Yes, but simply providing quantity over quality won't do you any favours. AI can be helpful yes, but you are still expected to understand what you are submitting and be able to explain it if asked. If you just dump a wall of AI generated code that doesn't work or isn't up to our standards, it's not going to get merged and it's just going to waste everyone's time. If you consistently submit poor quality AI generated code without being able to explain or fix it, future PRs from you will likely be ignored. In short, if you wouldn't be able to write the code without an AI, then you probably shouldn't be submitting it with an AI. If you are of the opinion that throwing a wall of unchecked AI slop at the PRs page is the right way for the project to be developed, you should probably go find another vibe-coded project that shares that vision, or start your own.

I am such a kind and generous person that I will take some of that pesky money off your hands. Jokes aside, donating money is in no way expected or required, but if you really do want to support the project financially, there is a buymeacoffee page here. The money goes towards hosting costs, domain registration and other expenses related to running the project, and any excess funds will be put towards future development and improvements. There are some small benefits for donors such as having your name listed on the website and a special role in the Discord, but the main motivation for donating should be just wanting to support the project and help it succeed rather than any specific perks. We appreciate any support we get, whether it's financial or just spreading the word about the project, and we're grateful to have such an amazing community behind us.

The logo was designed by a super cool artist who goes by the name of Star. You can check them out here: https://starcomissions.carrd.co/. I have worked with them previously on some work for another project and they always deliver high quality work very fast with extremely reasonable prices, I'd highly recommend them if you need any art or design work done.

Discord is our main hub for community interaction and updates, but we understand it's not everyone's cup of tea. We also have a presence on GitHub where you can follow the project and see updates, but for most communication Discord is where it's at. If you really, really don't want to use Discord, let us know in the GitHub discussions page and if there's enough demand for alternatives, we can look into something like Matrix or other platforms.

Most likely yes. We are trying to avoid using decompiled code so we don't get sued by Microsoft/Mojang and this ultimately means that some of the game's internal workings won't be easy to replicate. For most things the community has well documented so we can simply consult the wiki or chat to Minecraft experts in the community to figure out how to replicate it, but for some more obscure mechanics we might have to make educated guesses based on testing and observation. Stuff like terrain generation for example will be nearly impossible to perfectly replicate without decompiling the code, but we can get very close with enough testing and iteration. We also want to take this opportunity to fix some of Minecraft's longstanding issues and inconsistencies, so there will likely be some intentional differences as well. Our goal is to make a server software that is compatible with vanilla Minecraft clients and provides a solid foundation for plugins and mods, but that doesn't necessarily mean we have to replicate every single quirk and bug of the vanilla server.

There is a pretty solid chance that we just haven't gotten around to implementing it yet, especially if it's a more obscure or less popular feature, or it requires other unimplemented features to be added first. If it's important to you, come have a chat and we can discuss how it's being handled. It might be further down the roadmap than you'd like, in which case you can either wait for us to get to it, or if you have the skills and motivation to work on it yourself, we would welcome contributions. If it's a bug rather than a missing feature, definitely report it in the Discord or on GitHub so we can get it fixed as soon as possible. We are still in early development and there are bound to be a lot of missing features and bugs, but we are working hard to get them all ironed out and we appreciate the community's patience and help in getting there.

Maybe? We aren't sure if we want to do it or not, so come and let us know your thoughts. Replicating vanilla terrain generation is a huge pain, but not impossible, so if it's something the community really wants we can make it happen. On the other hand, this is a great opportunity to implement better terrain generation with more features and less bugs than vanilla, so if there's enough interest in that we might go that route instead. Let us know what you think in the Discord or GitHub discussions, and if you have any ideas for cool terrain generation features or improvements over vanilla, we'd love to hear those as well.

Yup! Currently we have a nice dashboard that is hosted alongside the server that lets you easily see performance stats, player counts and other useful info about your server, and stuff like interactive console and chat is planned for the dashboard. We also have an updating list of known IP addresses belonging to botnets/scanners that are blocked by default to avoid servers getting scanned and players being tracked across servers by malicious actors. If you have any ideas for QoL improvements or new features that you'd like to see, let us know in the Discord or GitHub discussions! We want to make a server software that not only replicates vanilla Minecraft but also improves on it.

Yes! You will likely need to turn down the database map size in the config since we've had some reports of it being too big for the Pi at default values, but other than that it should run just fine. We haven't done extensive testing on ARM devices yet, but since Rust compiles to native code for a wide variety of platforms and our CI testing and builds run on ARM64 runners as well, it should work just fine on the Pi. If you have a Raspberry Pi and want to test it out, we'd love to hear about your experience and any performance metrics you can share!