DOCSEARCHbyAlgolia
Submit Docs

NeoForge Documentation

website·Indexed 34 days ago

https://docs.neoforged.net/

Developer documentation for the NeoForge modding framework for Minecraft, covering versions 1.21.4 and 1.21.5. Includes guides on networking with Stream Codecs, resource management for models and particles, item and block implementation, data components, registries, and the SavedData system.

Tokens
1.3M
Snippets
4.8K
Records
6.9K
Agent score
51%

What's inside NeoForge

  1. Overview of NeoForge Capabilities

    Capabilities allow blocks, entities, and item stacks to expose features via interfaces without requiring direct implementation of many classes. This separates what an object can do from how it does it. Use capabilities when a behavior is only available for some objects and the implementation depends on the specific object type.

  2. Overview of NeoForge Capabilities

    Capabilities allow blocks, entities, and item stacks to expose features (interfaces) in a dynamic way. They separate what an object can do from how it does it, enabling cross-mod compatibility without requiring objects to implement numerous interfaces directly. Use capabilities when a behavior is only available for some objects and the implementation depends on the specific object type.

  3. Overview of BakedModel in NeoForge

    BakedModel is the in-code representation of a shape with textures. Model JSONs are deserialized into UnbakedModel and then resolved into a BakedModel via UnbakedModel#bake. These models are stored in the ModelManager, accessible via Minecraft.getInstance().modelManager. To retrieve a specific model, use ModelManager#getModel with a ModelResourceLocation.

  4. Overview of Stream Codecs

    Stream codecs are serialization tools used to describe how an object should be stored in and read from a stream, such as a buffer. They are primarily used by Vanilla's networking system to synchronize data. A StreamCodec uses encode to write an object to a stream and decode to read an object back from a stream. The stream is typically a ByteBuf, FriendlyByteBuf, or RegistryFriendlyByteBuf.
    // Let exampleStreamCodec represent a StreamCodec<ExampleJavaObject>
// Let exampleObject be a ExampleJavaObject
// Let buffer be a RegistryFriendlyByteBuf

// Encode Java object into the buffer stream
exampleStreamCodec.encode(buffer, exampleObject);

// Read Java object from buffer stream
ExampleJavaObject obj = exampleStreamCodec.decode(buffer);

  5. Overview of the Value I/O system

    The Value I/O system is a standardized serialization method used to manipulate data in a backing object (such as NBT CompoundTags). It consists of two primary components: ValueOutput for writing data during serialization and ValueInput for reading data during deserialization. The system expects the backing object to be a dictionary of string keys mapped to object values.
    // Example for BlockEntity
@Override
protected void saveAdditional(ValueOutput output) {
    super.saveAdditional(output);
    // Write data using output
}

@Override
protected void loadAdditional(ValueInput input) {
    super.loadAdditional(input);
    // Read data using input
}

// Example for Entity
@Override
protected void addAdditionalSaveData(ValueOutput output) {
    super.addAdditionalSaveData(output);
}

@Override
protected void readAdditionalSaveData(ValueInput input) {
    super.readAdditionalSaveData(input);
}

  6. Overview of Loot Tables

    Loot tables are JSON data files used to define randomized loot drops. When rolled, they return a list of item stacks based on pseudo-randomness. Loot tables are stored at data/<mod_id>/loot_table/<name>.json.

    Common associations include:

    • Blocks: Default location is <block_namespace>:blocks/<block_name>. Use #noLootTable on block Properties to disable drops.
    • Entities: Default location is <entity_namespace>:entities/<entity_name>. This can be overridden by overriding #getLootTable (e.g., for color-coded sheep wool).
    • Chests: Specified in block entity data, typically located in minecraft:chests/<chest_name>.
    • Fishing/Other: Retrieved via level.getServer().reloadableRegistries().getLootTable(lootTableKey).

    Note: To modify existing loot tables rather than creating new ones, use Global Loot Modifiers (GLMs).

  7. Overview of Blockstates in NeoForged

    Blockstates allow a single block to have multiple visual or functional variations (e.g., growth stages of a crop or the facing direction of a slab) without requiring separate block classes. Blockstates are represented as a combination of properties. For example, a block with a facing property (4 options) and an eye property (2 options) results in 8 unique blockstates.

    Key technical details:

    • BlockState is a final class and cannot be extended.
    • Every unique BlockState exists exactly once in memory; therefore, they should be compared using ==.
    • All logic for blockstate behavior must be implemented in the corresponding Block class.

  8. Overview of NeoForge Capabilities

    Capabilities in NeoForge allow blocks, entities, and item stacks to expose specific features (interfaces) in a dynamic way. This decouples what an object can do from how it implements that behavior. Use capabilities when a behavior is only available for some objects and the implementation varies by object type. For example, use capabilities for fluid/item containers or energy storage, but use helper methods for simple checks like distance/range.

  9. Overview of Living Entity Attributes in NeoForge 1.21.4

    Attributes are double-value fields associated with living entities that define core properties such as maximum health, movement speed, and armor. These values are automatically synchronized between the server and client. While many default attributes are provided by Minecraft, developers can also implement custom attributes. Note that some attributes are entity-specific due to legacy implementation; for example, jump strength affects horses but not players, and flying speed is ignored by ghasts.

  10. Overview of Loot Tables in NeoForge 1.21.1

    Loot tables are JSON data files used to define randomized item drops. They are located at data/<mod_id>/loot_table/<name>.json. Loot tables are used for block drops, entity drops, chest loot, and fishing.

    Default behaviors include:

    • Blocks: Default loot table at <block_namespace>:blocks/<block_name>. Use #noLootTable on block Properties to disable drops.
    • LivingEntities: Default loot table at <entity_namespace>:entities/<entity_name>. This can be overridden via #getLootTable (LivingEntity) or #getDefaultLootTable (Mob).
    • Chests: Specified in block entity data, typically following the minecraft:chests/<chest_name> pattern.
    • General Retrieval: Use level.getServer().reloadableRegistries().getLootTable(lootTableId) to retrieve tables manually.

    Note: To modify existing loot tables rather than creating new ones, use Global Loot Modifiers (GLMs).

  11. Overview of Global Loot Modifiers (GLMs)

    Global Loot Modifiers (GLMs) provide a data-driven way to modify loot drops. Unlike standard loot tables, GLMs are stacking (not 'last-load-wins'), allowing multiple mods to modify the same loot table. They operate by rolling the associated loot table first and then applying the GLM to the result. To implement a GLM, you need: 1) A registration file in the neoforge namespace, 2) A JSON definition for the modifier, 3) A Java class implementing IGlobalLootModifier or extending LootModifier, and 4) A MapCodec for serialization.

  12. Overview of Data Components in Minecraft 1.20.5+

    Data components are key-value pairs stored on an ItemStack. Unlike CompoundTag or JsonElement, components are stored as actual objects, making them directly operable without dynamic transformation. Each component is associated with a DataComponentType<T>, where T is the value type. These types act as keys and contain the codecs necessary for disk persistence and network synchronization.