Migrating

Moving from ItemsAdder

RP Engine reads ItemsAdder config files as they are. Copy a folder out of their contents/ — the configs at its root, textures/ and models/ beside them, no pack.yml — into plugins/RPEngine/content/ and start the server.

plugins/RPEngine/content/
  my_content/            ← straight out of ItemsAdder's contents/
    my_config.yml
    textures/
    models/

There is nothing to turn on. A file is recognised by its own shape — an info: block beside items: or font_images: — which nothing of ours looks like, since our top-level keys are IDs. One of their files also works inside a pack of yours, which is the useful shape for moving over a piece at a time.

What comes across#

ItemsAdder	RP Engine
`items.<id>`	an item
`resource.material`	`material`
`resource.textures` / `texture`	`texture` — the first one; a flat item has one picture
`resource.model_path`	`model`
`display_name` or `name`	`name` — both, since 4.0.9 renamed it
`lore`, `permission`	the same
`enchants`, `attribute_modifiers.mainhand`	`enchantments`, `attributes`
`durability.max_durability`, `unbreakable`	`durability`, `unbreakable`
`max_stack_size`	`stack`
`specific_properties.armor.slot`	`armor`
`behaviours.liquid_bucket`	`liquid`
`behaviours.furniture`	`place:`, with its light, solidity and seat
`blocks.<id>`	a custom block, with its model, hardness, light and tool
`font_images.<id>`	an icon
`enabled: false`	skipped, as it is there

What does not#

Each of these is a warning naming the ID when the pack loads, never a silence — a migration that quietly drops a third of somebody's pack is worse than one that refuses out loud.

A world of blocks does not come across

Block definitions translate. The blocks already standing in a world do not: the vanilla state each one hides in was allocated by ItemsAdder against its own numbering, so this engine reads them as whatever it gave that state. A pack migrates; a world has to be rebuilt or remapped by hand.

Note also that the pool here is smaller — 49 per note block base rather than 800 — because the instrument cannot be part of a block's identity. A pack with hundreds of blocks will not fit as it stands.

Their entities and recipes are a different feature rather than a different spelling, and want writing as entities/ and recipes/ definitions. Both are short.

events, drop and item_flags are ItemsAdder's own plugin behaviour rather than properties of an item. Actions cover most of what events did.

Two things worth knowing#

The folder name is the namespace. A file whose info.namespace says something else loads under the folder's name and warns you: the folder is what the engine claimed, and IDs written elsewhere have to resolve to something.

Their art lives at the pack root, ours under assets/. Both are read, so their textures/item/ruby.png and models/lamp.json need no moving — but if you are writing new content beside it, assets/ is the documented home and is what the content folder page assumes.

Armour art is the one file you do have to move. ItemsAdder draws armour its own way; RP Engine uses vanilla's equipment path, which arrived in 1.21.4 and is a different picture in a different place. Put yours at assets/textures/entity/equipment/humanoid/<id>.png (or humanoid_leggings/ for legs) and the item is otherwise unchanged. The build warns with the exact path when it is missing.