Migrating

Moving from ItemsAdder

RP Engine reads ItemsAdder's config files as they are, so you can move an ItemsAdder pack (including one bought on a marketplace) to RP Engine without converting anything.

1. Copy the pack's folder out of ItemsAdder's contents/ into plugins/RPEngine/content/, everything in it included: configs/, textures/, models/, resourcepack/.
2. You do not need a pack.yml (RP Engine's own pack file). Leave one out.
3. Start the server, or run /rp reload, and read the console for warnings.

plugins/RPEngine/content/
  my_content/            ← straight out of ItemsAdder's contents/
    configs/             ← read at any depth
      items.yml
    textures/            ← older layout: art at the pack root
    models/
    resourcepack/        ← ItemsAdder 4 layout
      assets/my_content/
        textures/
        models/

Both layouts work, and art kept in folders of its own (textures/<set>/ rather than textures/item/) is found too. There is nothing to turn on: a file is recognised by its own shape (an info: block beside items:, font_images: or recipes:). So one of their files also works inside a pack of yours, which is a handy way to move over a piece at a time.

The folder's name becomes the namespace: the first half of every item's ID, as in my_content:ruby. Keep the folder name ItemsAdder used and your existing IDs keep working.

What comes across#

A recipe's bare lowercase ID (base: my_sword) is the file's own namespace, as ItemsAdder reads it. A recipe's permission is not carried across: RP Engine recipes are open to everyone.

Events become actions#

Inside an event, play_sound, execute_commands (as_console: true runs as the console, otherwise as the player), potion_effect, give_item, decrement_amount, cancel, and ItemsAdderAdditions' message and actionbar come across, in order. play_particle and shoot_particle are a particle step, a shot particle drawn as a puff where it happens. {player} means the same thing in both plugins. A permission that every action in an event asks for becomes one permission step at its front.

What does not#

Each of these is a warning naming the ID when the pack loads, so nothing is dropped silently.

Their entities do not translate. Write them as entities/ definitions, which are short. Recipe groups other than the ones above are skipped by name.

Events and actions with nothing to land on: holding, wearing, fishing, a sneaking click, guns and books have no trigger here; damage and dropping experience have no step. An action with a delay, or with a permission only some of its event's actions share, is skipped too, since a step runs when its trigger does and a permission step stops everything after it. The rest of the event still comes across.

Blocks drawn with an entity: a TILE or FIRE placed_model.type draws with a spawner's or fire's entity, which RP Engine blocks do not, so it comes across as a full block. A placed model draws any shape.

Loot by chance, and mob and fishing loot. A block gives back one thing, so a table that might drop its item leaves the block dropping itself, and says so.

Some of a sound. A sound that picks one of several files at random keeps the first, because an RP Engine sound plays one file, and weight, attenuation_distance, preload and jukebox have no equivalent here. Your audio stays where it is: their sounds/ folder and resource pack folder are both packed where an RP Engine sound looks.

If the console warns#

info.namespace says galaxy_set but the folder is galaxyset, and the folder wins

The pack's configs declare one namespace and its folder has another name (a pack is often unzipped into a folder named differently). The items load as galaxyset:..., and their models and textures are still found under resourcepack/assets/galaxy_set/, so they look right. If other plugins, shops or commands name the items as galaxy_set:..., rename the folder to galaxy_set and /rp reload. Otherwise the warning is harmless.

An item shows the missing texture (black and pink)

Check the warning above it for the path RP Engine looked at. The usual causes are a folder renamed after the pack was made (see above), or a pack whose art was left out when it was copied. Copy the whole pack folder, resourcepack/ included.

Good to know#

Their art can stay where it is. ItemsAdder keeps art at the pack root or in resourcepack/assets/, and RP Engine reads both, so textures/item/ruby.png and models/lamp.json need no moving. For new content you write beside it, use assets/, as the content folder page describes.

Armour art stays where it is. A set's layer_1 and layer_2 are exactly the two pictures vanilla's equipment path draws (body and leggings), so the build serves them there for you. That needs Minecraft 1.21.4; on an older server the armour is still worn but draws with vanilla art, and the build names every piece that will.

What does not come across from a set, each a warning naming the item: an animated layer, which is a strip of frames a worn layer cannot play (save one frame as assets/textures/entity/equipment/humanoid/<id>.png, or humanoid_leggings/ for legs); a use_color tint and emissive layers, which needed ItemsAdder's shaders; and colour-only armour, which has no art and is worn as plain leather.