> For the complete documentation index, see [llms.txt](https://wiki.mypet-plugin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.mypet-plugin.com/setup-guide/getting-started/systems/custom-pet-models.md).

# Custom Pet Models

Give your pets custom BlockBench models using ModelEngine, BetterModel, or ItemsAdder.

By default a MyPet pet looks like the vanilla mob it is — tame a wolf, you get a wolf. Custom pet models let your pets wear **custom BlockBench models** instead: a dragon, a mech, a fox-spirit, whatever your modelers can build — while still behaving like normal MyPet pets underneath.

{% hint style="info" %}
Every custom model rides on top of a real mob. That is why modeled pets still pathfind, fly, swim, take damage, sit, follow, level up, and use skills normally. The model is the costume; the pet is still a full MyPet pet. Nothing about leveling, the backpack, or skills changes.
{% endhint %}

## Requirements

You need exactly **one** of the following rendering plugins installed:

* **ModelEngine** — long-established standard, large model ecosystem (paid).
* **BetterModel** — free, open-source alternative. Requires a **Java 25** server.
* **ItemsAdder** — all-in-one content plugin with a built-in model engine (paid). Requires **ProtocolLib**.

**MythicMobs** is optional — only needed for Path C, **Custom Creature — MythicMobs** (spawning/adopting real MythicMob creatures).

If none of these are installed, MyPet behaves exactly as it does without this feature — everything is additive and provider-gated.

## Two models come with MyPet

MyPet 4 bundles two finished BlockBench models in the jar — **`capybara`** and **`chameleon`**. You do not download or install them: reference `Id: capybara` (or `chameleon`) with `Provider: BetterModel` or `ModelEngine`, and MyPet copies the `.bbmodel` into that plugin's folder on load.

They are **models, not ready-made pet types** — you still define the creature once (Path B below), which also lets you pick its host, HP, and speed. Step-by-step, including the exact `pet-config.yml` section and the names the bundled skilltrees expect: [Bundled Models — Capybara & Chameleon](/setup-guide/getting-started/systems/custom-pet-models/bundled-pet-models.md).

## Three ways to get a modeled pet

### Path A — Re-skin existing pets (easiest)

Add a `Model:` block to any pet type's section in `pet-config.yml` — for example, "every Wolf renders as `dragon`." From that point on, any wolf pet a player tames looks like a dragon. It is pure configuration: no per-pet setup, no special items, works the moment you save the file. Great for theme servers ("all cats are robot-cats") or giving a premium skin to an existing pet type.

See [pet-config.yml → Custom Pet Models](/setup-guide/getting-started/configuration/pet-config.yml.md#custom-pet-models) for the `Model:` block syntax.

### Path B — Brand-new creatures

Define a creature that has no vanilla equivalent — a "Dragon" pet that, from the player's side, simply *is* a dragon. You choose how it moves (flying, walking, or swimming via the `Host:` field) and its health and stats. Players get one three ways — because **the model is the identity**, any mob wearing the creature's model is that creature:

* An admin runs `/petadmin create <player> mypet:<creature>` (custom creatures use the `mypet:` namespace; vanilla types use `minecraft:`).
* A player buys one from a [pet shop](/setup-guide/getting-started/configuration/pet-shops.yml.md), if you list it there.
* A player **leashes any mob wearing that model** — one you `/meg summon` / `/bm spawn` into the world, or one MyPet left behind when a pet of this type was released — using the normal [leash requirement rules](/setup-guide/getting-started/systems/leash-flags-requirements.md).

Releasing a custom creature leaves a wild mob still wearing its model, so it can be re-leashed back into the same pet. See [pet-config.yml → Custom Pet Models](/setup-guide/getting-started/configuration/pet-config.yml.md#custom-pet-models) for the syntax.

### Path C — Custom Creature — MythicMobs

MythicMobs is a **fourth custom-creature provider** — same shape as ModelEngine/BetterModel/ItemsAdder, just spawned differently: instead of MyPet drawing a model on a vanilla host, MyPet spawns (or adopts) the **real MythicMob**, model and all. Define a custom creature with `Model: { Provider: MythicMobs, Id: <mythicmob-internal-name> }` — the section name is arbitrary, exactly like the other three providers; the mob's identity lives in `Id:`. See [pet-config.yml → Custom creature definitions](/setup-guide/getting-started/configuration/pet-config.yml.md#custom-creature-definitions-host).

Players get one the same three ways as any custom creature:

* An admin runs `/petadmin create <player> mypet:<creature>` — MyPet spawns the actual MythicMob and adopts it as the pet.
* A player buys one from a [pet shop](/setup-guide/getting-started/configuration/pet-shops.yml.md) — same result.
* A player **leashes a wild MythicMob** with the matching internal name — using the normal [leash requirement rules](/setup-guide/getting-started/systems/leash-flags-requirements.md).

When the player later releases it, **it turns back into the real MythicMob** — its own AI, abilities, drops, and model intact, not a bare vanilla animal.

{% hint style="warning" %}
**Creation parameters that change the host mob are ignored for MythicMobs creatures.** MythicMobs — not MyPet — spawns the entity, so parameters such as `baby`, `variant:`, `saddle`, or `tamed` have nothing to apply to and are skipped; the server log lists which ones were dropped. `skilltree:` and `name:` still work, because those are MyPet's own pet data rather than properties of the mob. Set the creature's appearance in its MythicMobs config instead.

This applies to the `Options:` list in [`pet-shops.yml`](/setup-guide/getting-started/configuration/pet-shops.yml.md) as well, and to **any** custom creature whose `Model.Provider` plugin is not currently installed.
{% endhint %}

To allow taming, set `Disable-Leashing: false` in the `MythicMobs:` section of `hooks-config.yml`.

## The six methods

Each row is a different `pet-config.yml` shape — pick the one that matches what you have.

| # | Method                             | Config shape                                             | Obtained by                                                           |
| - | ---------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------- |
| 1 | Re-skin a pet with **ModelEngine** | `Model: { Provider: ModelEngine, Id }` on a vanilla type | taming that vanilla mob                                               |
| 2 | Re-skin a pet with **BetterModel** | `Model: { Provider: BetterModel, Id }` on a vanilla type | taming that vanilla mob                                               |
| 3 | Custom creature — **ModelEngine**  | `Host:` + `Model: { Provider: ModelEngine, Id }`         | `/petadmin create`, pet shop, **or** leashing a mob wearing its model |
| 4 | Custom creature — **BetterModel**  | `Host:` + `Model: { Provider: BetterModel, Id }`         | create / pet shop / leash a mob wearing its model                     |
| 5 | Custom creature — **ItemsAdder**   | `Host:` + `Model: { Provider: ItemsAdder, Id }`          | create / pet shop / leash a mob wearing its model                     |
| 6 | Custom creature — **MythicMobs**   | `Host:` + `Model: { Provider: MythicMobs, Id }`          | `/petadmin create` / pet shop / leashing the MythicMob                |

{% hint style="info" %}
Every method now carries a `Model.Id`, so **`Model.Id` is not the discriminator** between rendered and source-driven. That split is decided by the **provider's plugin type**: ModelEngine/BetterModel/ItemsAdder are renderers (MyPet draws the model on its host), MythicMobs is source-only (MyPet spawns/adopts the real creature and its model rides along). Method 6 is the **only source-driven** one, because MyPet can't draw a MythicMob's model itself — release respawns the real MythicMob.
{% endhint %}

## Which provider gives you which features

|                                     | ModelEngine         | BetterModel         | ItemsAdder          | MythicMobs                       |
| ----------------------------------- | ------------------- | ------------------- | ------------------- | -------------------------------- |
| Draws custom models                 | ✅                   | ✅                   | ✅                   | — (uses ModelEngine/BetterModel) |
| Re-skin existing pets (A)           | ✅                   | ✅                   | ✅                   | —                                |
| Brand-new / adopted creatures (B/C) | ✅ (rendered)        | ✅ (rendered)        | ✅ (rendered)        | ✅ (source-driven)                |
| Create / leash → its pet            | ✅ (custom creature) | ✅ (custom creature) | ✅ (custom creature) | ✅ (custom creature)              |

**ModelEngine, BetterModel, or ItemsAdder** power the visual rendering; **MythicMobs** is an optional layer.

## Animations

Across all six methods, MyPet plays a handful of **animations** on the model automatically — on spawn, despawn, sit/unsit, and attack. If your models name those animations the MyPet defaults (`spawn`, `despawn`, `sit`, `sit_loop`, `unsit`, `attack`) they work out of the box; otherwise you can remap the names per pet type. Walking, idling, and other movement animations are handled by the rendering plugin itself, not by MyPet. See [pet-config.yml → Model animations](/setup-guide/getting-started/configuration/pet-config.yml.md#model-animations) for the full list and how to override names.

## What doesn't change

A modeled pet is still a MyPet pet in every way that matters: experience and leveling, the skill tree, sit/follow/aggression behavior, the backpack, naming, riding — all of it works as it does now. The custom model is purely visual.

## Configuration

All custom model settings live in [`pet-config.yml`](/setup-guide/getting-started/configuration/pet-config.yml.md#custom-pet-models) under `MyPet.Pets`. Re-skinned types add a `Model:` block to their existing section; custom creatures add a new section with a `Host:` key plus `Model:`.

The only hooks-config.yml setting relevant to this feature is `MythicMobs.Disable-Leashing` (Path C) — see [hooks-config.yml](/setup-guide/getting-started/configuration/hooks-config.yml.md#custom-pet-models).

Custom creatures — Path B (rendered) and Path C (MythicMobs) alike — can be sold in a [pet shop](/setup-guide/getting-started/configuration/pet-shops.yml.md) by listing the creature id in `pet-shops.yml` just like any other pet type.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.mypet-plugin.com/setup-guide/getting-started/systems/custom-pet-models.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.