PerlandFailure catalogue

A mod failed while reacting to something in the game

Errormod_event_error

A mod's handler of a Forge or NeoForge event threw an error; the event bus logged it and the server kept running, but that mod's reaction did not happen.

What the log shows

Written example9 lines
[21:14:52] [Server thread/ERROR] [ne.mi.ev.EventBus/EVENTBUS]: Exception caught during firing event: Cannot read field "level" because "owner" is null
	Index: 2
	Listeners:
		0: NORMAL
		1: ASM: class com.example.graves.GraveEvents onDeath(Lnet/minecraftforge/event/entity/living/LivingDeathEvent;)V
		2: ASM: class com.example.keepsake.DeathHandler onLivingDeath(Lnet/minecraftforge/event/entity/living/LivingDeathEvent;)V
java.lang.NullPointerException: Cannot read field "level" because "owner" is null
	at TRANSFORMER/[email protected]/com.example.keepsake.DeathHandler.onLivingDeath(DeathHandler.java:58)
	at TRANSFORMER/[email protected]/com.example.keepsake.__DeathHandler_onLivingDeath_LivingDeathEvent.invoke(.dynamic)

Your log will have other names, versions and times. Search a line of it from all failures.

What it means

Forge and NeoForge tell mods what happens in the game through events: a player right-clicks an entity, a mob dies, the server starts. Each mod registers handlers for the events it cares about. When a handler throws an error, the event bus prints Exception caught during firing event, the list of handlers with the index of the one that failed, and the error with its stack trace.

The server usually goes on running. What is lost is that one mod’s reaction to that one event: an item not given, a block not placed, a death not recorded. The error comes back each time the event fires, so the same issue can repeat many times in a run.

Why it happens

  • A bug in the mod. Most often a value the mod expected is missing (a NullPointerException), for example after another mod changed or cancelled the same event.
  • Two mods handle the same event in ways that clash. One mod changes what the next one reads.
  • The mod is made for another version of Minecraft, of the loader or of a mod it builds on.
  • Corrupt or unexpected data in the world, such as an entity or item another mod left in a state the handler does not expect.

How to fix

  1. Find the mod: the first lines of the stack trace under the error name it (TRANSFORMER/[email protected]/... in the example). The Index: line points at the handler that failed in the Listeners: list.
  2. Update that mod to the newest release for your Minecraft and loader version; handler bugs are often fixed there.
  3. Note what players were doing when it happened (event names it: a death, an interaction, a block break), and check whether the bug only appears together with another mod listed for the same event.
  4. If it keeps happening and the mod is not needed, remove it. Back up the world first: removing a mod removes its blocks and items from the world.
  5. Report the error to the mod’s author with the full log excerpt.

In Perland

The issue appears in the server’s Diagnosis tab with the event that failed and the excerpt the server printed, whose stack trace names the mod. On a server whose mods come from a modpack, Mod Studio is where you update or remove the pack’s mods; otherwise replace the jar in the mods folder in the Files tab.

References

Details the diagnosis reports

Perland's server diagnosis returns this failure as the code mod_event_error with these parameters, each present only when the log names it.

ParameterMeaning
eventThe event whose handler failed, by its class name (such as `LivingDeathEvent` or `PlayerInteractEvent$EntityInteract`), when the log lists the bus's listeners.

Log lines this page covers

  • Exception caught during firing event: