Mod integration

Raknetify2 lets mods declare which Minecraft traffic must remain ordered with their custom payloads. Use this when handling a payload requires an entity, chunk, inventory, or other state established by earlier packets.

Ordering groups

Group	Related traffic
ui	World-independent menus and interactions
entity	Entity spawn, removal, and movement
world_interaction	Inventories and other world-dependent interactions
effects	Sounds and particles
chunk	Terrain, block, and lighting updates

All groups retain reliable ordered delivery within their channel. Packets in different groups can arrive in a different relative order. Choose the group matching the payload's dependency.

Optional Fabric integration

Add a provider under the raknetify:packet_channels entrypoint in your mod's fabric.mod.json. The provider implements Consumer<BiConsumer<String, String>> using JDK types. It receives a registrar that accepts a custom payload identifier and an ordering group.

Merge this entry into your existing metadata, replacing the class name with your provider's fully qualified name:

{
  "entrypoints": {
    "raknetify:packet_channels": [
      "com.example.mod.OrderingProvider"
    ]
  }
}

Retain the rest of your fabric.mod.json, including its existing entrypoints. This is a fragment of the metadata file.

For example, an entity movement extension can register example:entity_path with the entity group. The PacketOrdering API documentation includes the provider implementation.

Fabric leaves this entrypoint uninvoked when Raknetify2 is absent. Providers should declare identifiers and groups during initialization without relying on another mod having finished its own initialization.

Registration behavior

Forge and NeoForge mods, and server or proxy plugins, can call PacketOrdering.register(identifier, group) during initialization when Raknetify2 is available. The class is com.ishland.raknetify.api.PacketOrdering. Register before accepting player connections, and keep optional integration code from loading Raknetify2 classes when the dependency is absent.

Declarations apply to new connections. Existing connections retain the rules they received at setup. Repeating an identical declaration is allowed. Conflicting groups for the same identifier are rejected.

Payload identifiers must use a valid custom namespace. The minecraft namespace is reserved. The endpoint-wide limit is 128 declarations, including built-in rules and registrations from other mods. Identifiers can contain up to 255 ASCII characters using the API's namespaced identifier syntax.

Updated RakNet peers exchange declarations during connection setup. A server or proxy can use a peer's declaration when it has no local rule for that payload. Local rules take precedence, and a peer's declarations remain scoped to that connection.