Addon Development: Parts

Parts are things that can be attached to Integrated Dynamics cables. This page gives a brief introduction on how new part types can be created.

Creation

All parts implement the IPartType interface (PartTypeAdapter provides an abstract adapter implementation of this interface).

Part types are like blocks in Minecraft. They are only created once, and do not keep state by themselves. If you want to maintain state, you can make use of IPartState or PartStateBase.

If you want to create a part that exposes read or write aspects, you can reuse the PartTypeReadBase and PartTypeWriteBase from Integrated Dynamics. In this case, your main mod class MUST extend from ModBase and you must override getMod in your part type to refer to your mod instance.

For example:

public class PartTypeExporterEnergy extends PartTypeWriteBase<PartTypeExporterEnergy, PartStateEmpty<PartTypeExporterEnergy>> {
    public PartTypeExporterEnergy(String name) {
        super(name, new PartRenderPosition(0.25F, 0.25F, 0.375F, 0.375F));
        AspectRegistry.getInstance().register(this, Lists.<IAspect>newArrayList(
                TunnelAspects.Write.Energy.BOOLEAN_EXPORT,
                TunnelAspects.Write.Energy.INTEGER_EXPORT
        ));
    }

    @Override
    public ModBase getMod() {
        return IntegratedTunnels._instance;
    }

    @Override
    protected PartStateEmpty<PartTypeExporterEnergy> constructDefaultState() {
        return new PartStateEmpty<PartTypeExporterEnergy>();
    }
}

Registration

It is recommended to register your part during Forge's RegistryEvent.NewRegistry event:

@Mod(Reference.MOD_ID)
public class MyMod {
    public MyMod() {
        FMLJavaModLoadingContext.get().getModEventBus().addListener(this::onRegistriesCreate);
    }

    public void onRegistriesCreate(RegistryEvent.NewRegistry event) {
        IPartTypeRegistry registry = IntegratedDynamics._instance.getRegistryManager().getRegistry(IPartTypeRegistry.class);

        registry.register(new PartTypeExporterEnergy("exporter_energy"));
    }
}

More part type examples can be found here.

Models and Localization

When extending from base implementations from IPartType such as PartTypeReadBase, PartTypeAspects, or PartTypeBase, then your assets must be structured as follows:

Model

Each part must have their blockstate file defined at the path assets/<mod-id>/blockstates/part_<part-name>.json. This file must contain model variants for each facing. For example, the file assets/integrateddynamics/blockstates/part_audio_reader.json looks as follows:

{
  "variants": {
    "facing=north": { "model": "integrateddynamics:block/part_audio_reader", "y": 180 },
    "facing=east":  { "model": "integrateddynamics:block/part_audio_reader", "y": 270 },
    "facing=south": { "model": "integrateddynamics:block/part_audio_reader"           },
    "facing=west":  { "model": "integrateddynamics:block/part_audio_reader", "y": 90  },
    "facing=up":    { "model": "integrateddynamics:block/part_audio_reader", "x": 90  },
    "facing=down":  { "model": "integrateddynamics:block/part_audio_reader", "x": 270 }
  }
}

If you follow this blockstate format, then your part's model must exist at the path assets/<mod-id>/models/block/part_<part-name>.json. The corresponding item model for your part must exist at assets/<mod-id>/models/item/part_<part-name>.json.

For example, assets/integrateddynamics/models/block/part_audio_reader.json looks as follows:

{
    "parent": "integrateddynamics:block/part_reader",
    "textures": {
        "back": "integrateddynamics:part/audio_reader_back",
        "front": "integrateddynamics:part/audio_reader_front"
    }
}

And assets/integrateddynamics/models/item/part_audio_reader.json can look as follows:

{
  "parent": "integrateddynamics:block/part_audio_reader"
}

Localization

Your language file must contain your part name as parttype.<mod-id>.<part-name>.

For example:

"parttype.integrateddynamics.audio_reader": "Audio Reader",