Events

An event is a special object that is fired on an event bus to inform registered listeners about some type of action or state. This is the primary way by which Forge allows mods to hook into vanilla and game behavior; Forge has an array of different events which are fired when different actions happen within the game, and mods may act upon receiving these events.

Cancellable Events

An event may be marked as cancellable, which allows event listeners to cancel the event.

A cancellable event may be cancelled by using Event#setCanceled(true). Attempting to call this method on a non-cancellable event will result in a UnsupportedOperationException. A cancelled event behaves similarly to a regular noncancelled event, with one main difference: an event listener will not receieve cancelled events unless they are explicitly registered to listen for cancelled events.

To mark an event as cancellable, the event class should be annotated with @Cancelable. This will automatically make Event#isCancelable() return true. Modders may check if an event has a result through the presence of the annotation or by calling the given method.

Events with Results

An event may have a result, which is an enum of Event.Result.

The Event.Result enum has three values: ALLOW, DEFAULT, and DENY. The meaning of these result values is entirely dependent on the event itself.

An event's current result can be retrieved through Event#getResult(). The result on an event can be set through Event#setResult(Event.Result). You can set the result for an event which is not marked as having a result, however this will cause nothing to happen if the event does not use the result value.

To mark an event as having a result, the event class should be annotated with @Event.HasResult. This will automatically make Event#hasResult return true. Modders may check if an event has a result through the presence of the annotation or by calling the given method.

Forge uses an event bus that allows mods to intercept events from various vanilla and mod behaviors.

Example: An event can be used to perform an action when a Vanilla stick is right clicked.

The main event bus used for most events is located at MinecraftForge.EVENT_BUS. There is another event bus for mod specific events located at FMLJavaModLoadingContext.get().getModEventBus() that you should only use in specific cases, more information about this bus can be found below.

Every event is fired on one of these busses, most events are fired on the main event bus but some are fired on the mod specific events bus.

Sub Events

Many events have different variations of themselves, these can be different but all based around one common factor (e.g. PlayerEvent) or can be an event that has multiple phases (e.g. PotionBrewEvent). Take note that if you listen to the parent event class, you will receive calls to your method for all subclasses.

Registering Event Handlers

Annotated Event Handlers

public class MyForgeEventHandler {
    @SubscribeEvent
    public void pickupItem(EntityItemPickupEvent event) {
        System.out.println("Item picked up!");
    }
}

This event handler listens for the EntityItemPickupEvent, which is, as the name states, posted to the event bus whenever an Entity picks up an item.

To register this event handler, use MinecraftForge.EVENT_BUS.register(<instance>) and pass it an instance of your event handler class. If you want to register this handler to the mod specific event bus you should use FMLJavaModLoadingContext.get().getModEventBus().register(<instance>) instead.

Static Event Handlers

An event handler may also be static. The handling method is still annotated with @SubscribeEvent with the only difference from an instance handler is that it is also marked static. In order to register a static event handler, an instance of the class won’t do, the Class itself has to be passed in. An example:

public class MyStaticForgeEventHandler {
    @SubscribeEvent
    public static void arrowNocked(ArrowNockEvent event) {
        System.out.println("Arrow nocked!");
    }
}

which must be registered MinecraftForge.EVENT_BUS.register(MyStaticForgeEventHandler.class).

Using @Mod.EventBusSubscriber

A class may be annotated with the @Mod.EventBusSubscriber annotation. Such a class is automatically registered to MinecraftForge.EVENT_BUS when the @Mod class itself is constructed. This is essentially equivalent to adding MinecraftForge.EVENT_BUS.register(AnnotatedClass.class); at the end of the @Mod class's constructor.

The mod ID must be specified unless your class is already annotated with an @Mod annotation. You can pass the bus you want to listen to to the @Mod.EventBusSubscriber annotation. You can also specify the Dists to load this event subscriber on. This can be used to not load client specific event subscribers on the dedicated server.

An example for a static event listener listening to RenderWorldLastEvent which will only be called on the physical client:

@Mod.EventBusSubscriber(modid = "examplemod", dist = Dist.CLIENT)
public class MyStaticClientOnlyEventHandler {
    @SubscribeEvent
    public static void drawLast(RenderWorldLastEvent event) {
        System.out.println("Drawing!");
    }
}

Important

This does not register an instance of the class; it registers the class itself (i.e. the event handling methods must be static).

Non-Annotated Event Handlers

Event handlers do not need to be annotated if they are directly referred to using IEventBus::addListener or IEventBus::addGenericListener for generic events.

@Mod("examplemod")
public class MyMainModClass {

  public MyMainModClass() {
    FMLJavaModLoadingContext.get().getModEventBus().addGenericListener(Entity.class, this::entityCap);
  }
  
  private void entityCap(AttachCapabilitiesEvent<Entity> event) {
    System.out.println("Capability attached!");
  }
}

Important

The generic passed into the event must be referenced directly within the code itself. Otherwise, the event will not be called whatsoever. For example, if you use AttachCapabilitiesEvent<LivingEntity>, the event will never be called as no call of this event uses LivingEntity, only Entity.

Canceling

If an event can be canceled, it will be marked with the @Cancelable annotation, and the method Event#isCancelable() will return true. The cancel state of a cancelable event may be modified by calling Event#setCanceled(boolean canceled), wherein passing the boolean value true is interpreted as canceling the event, and passing the boolean value false is interpreted as “un-canceling” the event.

Important

Not all events can be canceled! Attempting to cancel an event that is not cancelable will result in an unchecked UnsupportedOperationException being thrown, which is expected to result in the game crashing. Always check that an event can be canceled using Event#isCancelable() before attempting to cancel it.

Results

Some events have an Event.Result as denoted by @HasResult. A result can be one of three things: DENY which stops the event, DEFAULT which uses the Vanilla behavior, and ALLOW which forces the action to take place, regardless of if it would have originally. The result of an event can be set by calling setResult with an Event.Result on the event.

Information

Different events may use results in different ways, refer to the event's JavaDoc before using the result.

Priority

Event handler methods have a priority. You can set the priority of an event handler method by setting the priority value of the annotation or the listener. The priority can be any value of the EventPriority enum (HIGHEST, HIGH, NORMAL, LOW, and LOWEST). Event handlers with priority HIGHEST are executed first and from there in descending order until LOWEST events which are executed last.

Mod Event Bus

The mod event bus is primarily used for listening to lifecycle events in which mods should initialize. Many of these events are also ran in parallel so mods can be initialized at the same time. This does mean you cannot directly execute code from other mods in these events. Use the InterModComms system for that.

These are the four most commonly used lifecycle events that are called during mod initialization on the mod event bus:

• FMLCommonSetupEvent
• FMLClientSetupEvent & FMLDedicatedServerSetupEvent (These events are only called on their respective physical side.)
• InterModEnqueueEvent
• InterModProcessEvent

These four lifecycle events are all ran in parallel. If you want to run code on the main thread during these events you can use the enqueueWork methods within the events to do so.

Next to the lifecycle events there are a few miscellaneous events that are fired on the mod eventbus where you can register, set up, or initialize various things. Most of these events are not ran in parallel in contrast to the lifecycle events:

• ColorHandlerEvent
• ModelBakeEvent
• TextureStitchEvent
• RegistryEvent

A good rule of thumb: events are fired on the mod eventbus when they should be handled during initialization of a mod.