When it comes to setting up a server with a list of mods, there is always a chance there’s some errors with mods not being able to work. In most cases, the reason a mod crashes the server is because it is a client-side mod. We know that, but how do we find out that’s what it is?

What makes a Mod Client-side?

Minecraft is split between two logical sides, the client, and the server. Your server will be running only server-side logic, so if a mod that is client-side tries to run on the server, it will simply be able to. However that looks will depend on how the mod handles it.

We have an in-depth discussion about what a client-side mod is, so for a full reading on what a client-side mod is, go check out our blog on client-side mods.

Can a Client-side mod be on a Server?

For the most part, a client-side mod does not need to be on the server, so if you are assembling a modpack, you shouldn’t need to include them in the server files.

What happens if a client-side mod is installed on the server? One of two things can happen. In the ideal case, a client-side mod will notice that it’s on a server and stop running any logic. Any code it does have simply does not run, even though it will appear as installed on the server. If that is the case, then the mod is simply benign and won’t do anything. In some cases, a mod stops itself from loading.

On the other hand, not all client-side mods take care to identify if it’s on a client or server. When this happens, the logic will attempt to run, but because the code does not exist on the server, it will often crash. Either because the mod loader detected it, or that the mod continued to run. Now, this does not mean the server cannot be used, far from it. All you have to do is delete the mod from the server.

How do I spot a Client-side mod?

How a mod can be identified can widely vary, because how client-side code is run will depend on when the mod will crash.

Cause 1: Attempted to load class for invalid dist DEDICATED_SERVER

This is the easiest way to identify a client-side mod. If the server crashes, we will have a section in our crash report that shows a list of mods that failed to load. If we see a mod has failed to load with this RuntimeException error, it means that the mod loader has detected the use of client-side code.

Cause 2: NoClassDefFoundError

Similar to Cause 1, this can also indicate a client-side error. Of course, this could also indicate a missing mod, or a mod requires a different version of another mod, so how does this identify a client-side mod? The answer depends on where that class comes from.

In cases where it is a client-side mod, you will see that the class path reads net/minecraft/client/…. Anything that belongs in this class package is client-side code, which does not exist on the server. Another class that may show up that is also client-side is com/mojang/text2speech/…, which is how Minecraft’s Narrator works. The server doesn’t need a Narrator for itself, so it’s client-side.

Cause 3: ExceptionInInitializerError: null

This will also show up just like in Cause 1 and Cause 2, but unlike these last two, this error doesn’t actually have any concrete evidence that it is client-side. If we can’t tell what class it is, or if it’s looking in a place that has client-side code, what can we use?

We will have to deduce that the mod is client-side. The easiest way to do this is to check where you downloaded the mod and check if the page description mentions if the mod is client-side, or if the project has only the Client tag. If we are unable to do that, we can always shelf the mod from the server files and check if we can still load into a server. A mod that needs to be installed on both client and server will have warnings to indicate this requirement.

Cause 4: Sodium

For these next few causes, these are not specifically identifying a client-side mod, rather these are errors that show up unlike Causes 1, 2, or 3. Sodium is a client-side mod, but when installed on the server, it will show a very different error. It is too early in the server loading stage to generate a crash report, but it will have a specific error message.

The message to look out for is related to finding the version of LWJGL. This is a library used by Minecraft to render the very game to your screen. Since Sodium is trying to find the version of LWJGL on a server, and because this is a rendering library, it can cause a server to crash.

Cause 5: Entity Model Features and Entity Texture Features

This is another case specific to EMF and ETF. When these mods are loaded on the server, they try to apply some client-side code to the server-side. Unlike Sodium which will show itself in the error message, EMF and ETF will be tucked away.

These mods apply what is called a “mixin”, which is how some mods tweak the behaviour of Minecraft. In this case, EMF and ETF will try to help load specific features with more lenient rules. However, these rules need client-side code, so it will crash on a server. Because of this, you have to look very closely at the error message to find out these mods.

Cause 6: Unidentifiable client-side mods

However, not every mod will make itself clear that it is the problem. It could be how the code is run that it simply hides away from all crash reports and error messages. We could be looking at a crash unrelated to a client-side mod, but it’s still a very real chance.

If we can’t find which client-side mod is stopping the server and we have deduced every mod that could be a client-side mod, then it’s time for the ultimate test: Binary Testing. It’s an efficient method of narrowing down mods, and we also wrote about how it works.