Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

Minor announcement - NMS code (blogpost) (Patreon)

Published:
2023-03-23 16:32:50
Imported:
2026-06

Content

Hello everyone,

Today, for the first time in the nearly 6 years EliteMobs I’ve been working on EliteMobs for and for the first time in the 7 years I’ve been doing Minecraft plugins, I’ve released a set of features which depend on NMS code.

This is a landmark moment for me, and one that I wanted to make note of in a blogpost. That I have not written NMS code in the last 7 years is not a coincidence, it has been a sticking point, a line in the sand beyond which things would take “too much effort” to justify doing.

However, thanks to your support, and years of bettering myself as a developer, today I crossed that line.

As such, I’ve created a library which I am currently calling SimpleMinecraftPathfinding, and which I might later rename to SimpleMinecraftGoalManager or something like that.

For those confused about what NMS code is: NMS is the source code of Minecraft, in this case of the server software part of Minecraft. Spigot and Paper have APIs based on this code, which are documented, maintained and supported by the community of which I am a part of.

APIs like Spigot and Paper do not cover every possible feature Minecraft has, and it would be unreasonable to expect them to have full 100% coverage. However, there are some key things that are simply impossible to do. To name two relevant here: custom entities and influencing pathfinding.

Using the Spigot API (which I do, since I make Spigot plugins), it is simply impossible to make custom entities and to influence where they go. You can make entities and change things about them, and you can do a few tricks to nudge them into a spot or teleport them, but fully custom entities with fully custom AI is not possible. It is marginally more possible with Paper, but I really did not want to force people to switch to Paper while still publishing on Spigot.

However, writing NMS code is like making a deal with the devil; with this great power, comes a great headache. Each Minecraft server version has to be maintained individually, including upgrades from minor versions such as 1.19 to 1.19.1. NMS code is much more powerful, but also entirely undocumented, very easy to use incorrectly and very easy to crash servers with.

Hence my refusal to use it up until now. A good NMS setup requires a very robust project structure, and I don’t think it can be much better than the one that I ended up using thanks to some advice from the Spigot community.

For those wondering, it is a multi-module project with a core for the interface, a dist for the packaging and each individual Minecraft version using Minecraft remappings which get reobfuscated on compile. I would say this is the modern standard way of approaching this issue, perhaps a little better than the average as I am using the Mojang remappings. I am shading this library in and will be uploading the repository on a sonatype maven repo. As with everything else, it will be open source for the public release.

Which brings me to how this will be used:

NMS code has one big weakness, that being that it requires updating with every Minecraft server version. I do not want to limit your ability to update your Minecraft servers due to EliteMobs being on an older version that is no forwards compatible, which has always been the biggest selling point of only using the API.

You will notice that I did not add the NMS code to EliteMobs but rather to a library that I created. This is intentional, and the objective will be to make the features that this library allows us to implement to be “optional”, and still have the plugin work mostly normally even if it has not updated.

As for the actual uses of what I just released: to test the implementation, the first feature and currently the one on 8.4.5-SNAPSHOT-1 is a new soft leash for regional bosses. This makes sure that if the boss is detected to be over 1/3 of the maximum range that it is allowed to go and not in combat it will start walking back to its spawn point, instead of the slow teleportation they used to do.

As you might imagine, I will also be adding this to the Elite Scripts as a possible action, and I also plan to implement a patrol routine for some of the bosses in some of the dungeons to make those dungeons feel more alive and populated with smarter creatures.

Most of all, this will be used in more than just EliteMobs. After releasing the next set of dungeons, I plan to focus my efforts on developing and releasing EternalTD, a tower defense game in Minecraft, the prototype for which is already available on Patreon.

This tower defense system will be using the same pathfinding library to make the mobs move around the world.

It is also my hope that one day I will develop a free alternative to ModelEngine. If that comes to pass, I plan to use that and the pathfinding library I created to create fully unique new mobs with their own custom behavior, integrating them seamlessly into the world like a mod. Think a version of the Mo’ Creatures Mod for Minecraft servers.

But those are just potential plans for the future. For now, I hope you enjoy the new feature, I’m off to work on the dungeons.

Happy adventuring,

- MagmaGuy

Comments

Anonymous

thank you very much for this explanation, I really like the direction that the project is taking, I think it is becoming more solid and you can create very customizable things. The only thing I don't fully understand is why not stop using spigot, being able to use the Paper API, paper servers are already a majority and as you say maybe it would give you less trouble in the long run using the paper API, then I don't see why not use it and leave spigot, it is a difficult decision but I think it can be understood.

magmaguy
>>104733305

Great question. Let's talk about discoverability, barrier to entry and the state of Paper’s documentation and support. First off, discoverability: Right now, most admins find out about EliteMobs from the recently updated section of plugins on Spigot. To the best of my knowledge, though alternatives exist, Spigot remains the one of the biggest and most widely known platforms. Most admins that use other platforms also use Spigot, and few admins that use Spigot use other platforms. Depending on PaperMC features may run afoul of their rules, and simply does not feel right to post projects that rely on PaperMC features on the Spigot plugins. PaperMC does not provide a platform for posting plugins. Secondly, barrier to entry: According to Bstats Spigot accounts for 25% of servers out there, and paper accounts for 58%. These stats are actually massively biased, as only Spigot servers that use plugins which use Bstats contribute towards the Spigot count, whereas PaperMC ships with Bstats integration natively. If I had to guess what the actual numbers are, I would guess that Spigot is actually ahead by maybe 5-10%. But even if the 25% number is correct, that is 1 in 4 servers that uses Spigot. The question then becomes: do I want to exclude 25% (or 60% in my estimates) of servers because they use a version which has a slightly less complete API, when I am able to implement these features myself? Asking tens or hundreds of thousands of servers to switch to PaperMC is not only a massive waste of time but also something a lot of people wouldn’t be willing to do just to try an unknown plugin out. Thirdly, documentation: While PaperMC offers Javadocs, which I would say is the bare minimum, very few community-made resources are out there to guide you through some complex implementations. This means that if I get stuck trying to figure out the details of how something is meant to work, if I search it online, finding a solution to my question will be an exceedingly rare event. This is not the case with Spigot; the community – including myself – has, throughout the years, asked and answered questions on forums and provided guides on how to implement particularly tricky systems – and this includes guides on how to pathfind with NMS, although those guides are hopelessly outdated now, which is something I am seriously considering contributing to offset that. And finally: support. PaperMC has an active discord, but getting straight answers to complex questions is not easy. The universe of people who has ever done complex implementations of the pathfinding solutions PaperMC provides in their API is almost certainly under 50 people; of those people, only a fraction has done anything like what I might need an answer to, and the odds one of those people is looking at the PaperMC chat when I ask a question and is willing to answer is reduces this pool of people to 0, more often than not. As an example, when I was working on EternalTD, I could not get the pathfinding for most flying entities to work. I asked on their support several times, but at the end of the day very few people – if any ! – have every come up with custom pathfinding for flying entities in Minecraft using the PaperMC API. Obviously, if I was the one who made the system in the first place, I won’t need any support. The initial time investment to reverse engineer the NMS implementation may take a little while, but once I provide an API over that I will never need any further help, and I can adapt the API to fit any of my needs without being restricted by an API.