Testing in Minecraft
The plugin
Vanilla Minecraft can't do most of what a pack made here is for. It has no concept of an animated block model, no way to play an emote on a player, and no way for a server to hand one person a pack without handing it to everybody.
The ResourcePack AI plugin is the half that makes those work. It's what our test server runs — the models you see standing around and moving on are this plugin doing it — and it's the same jar you can put on your own server.
You don't need it to use a pack
A pack made here is an ordinary resource pack. Export the .zip, point
server.properties at it, done — nothing of ours installed. The plugin is
for the things a resource pack alone can't do, which is the list below.
What it adds#
| Without the plugin | With it | |
|---|---|---|
| Models | The model renders, standing still | Place it, pick it up, and it animates |
| Animations | Nothing — the keyframes sit in fields vanilla ignores | Plays on loop, on click, on approach, or from code |
| Emotes | Nothing | /emote plays one on a player, wearing their own skin |
| Custom GUIs | The art ships, but nothing opens a screen with it | /gui opens the screen with your art drawn over it |
| HUD overlays | Same | /hud draws a meter or a frame over the world |
| Pack sounds | /playsound works, if you're an operator | /sound works for anybody, so the person testing can hear their own sound |
| Live testing | Re-export, re-upload, rejoin | The Studio pushes a pack to one player in seconds |
| Distribution | One pack for everybody, one version | Every player gets the build for the version they're on |
Installing it#
Requirements
A Paper or Spigot server on 1.21.4 or newer, running Java 21+, and permission to install plugins on it. Placed models use display entities and string-valued custom model data, neither of which exists on older versions — so there's no build for 1.8, because the features it exists to deliver aren't there to use.
- 1
Download the jar
https://cdn.resourcepack.ai/resourcepackai.jar - 2
Drop it in /plugins
Alongside everything else. It has no dependencies and no required configuration.
- 3
Restart the server
A
/reloadwon't do it — plugin jars are only picked up on a real restart. Check the console for the plugin's startup line.
Using it#
Two things it does, and they're independent — a server can do either without the other.
Pushing a pack to one player#
For building. A player runs /link with the 8-digit code the Studio shows,
and from then on Sync in the editor pushes the pack straight to them, in
seconds, without anybody touching server.properties. /party shares your
pushes with the people building alongside you.
That's per player on purpose: it's how you and your builders see a pack while it's being made, not how a public server serves one.
Serving your published pack to everyone#
For launch. /rpai bind <code> ties the server to a pack from the
Distribution tab, and from then on every joining player is served the build
for the Minecraft version they're actually on. That's the
Distribution feature, and it needs no /link from anybody.
Commands#
Every command is operators-only until you say otherwise. The plugin runs on your server, so nothing it adds reaches a player until you grant it.
| Command | Permission |
|---|---|
/link <code> | resourcepackai.link |
/party invite|accept|deny|leave|kick|list|disband | resourcepackai.party |
/emote [name] | resourcepackai.emote |
/emote <name> <player…> | resourcepackai.emote.multi |
/emotereply <accept|deny> <token> | none — see below |
/gui <player> <screen> <escapes> | resourcepackai.gui |
/hud <player> <bar> <escapes> [secs] | resourcepackai.hud |
/sound <player> <event> […] | resourcepackai.sound |
/rpai bind|unbind|refresh|status|reconnect | resourcepackai.admin |
resourcepackai.* grants all of them at once.
The three that reach other players#
/gui, /hud and /sound all take a target player, so granting them lets
that player draw a screen, an overlay or a sound onto somebody else's client.
Grant them to the people building your pack, not to everyone.
resourcepackai.emote.multi is the same idea and is deliberately not a
child of resourcepackai.emote: an emote with a cast teleports the players it
names and holds them for its length, so granting "emotes" must not quietly
include the half that moves other people.
Nobody is pulled into an emote without agreeing#
/emote <name> <player…> doesn't start anything. Everyone it names gets a line
in chat with [accept] and [deny] buttons, and the emote runs only once
all of them have accepted. A deny calls the whole thing off, and so does
thirty seconds of silence.
Answering is /emotereply, which the buttons run for you. It is the one
command here that needs no permission, on purpose: it answers a question
somebody else asked, its token is unguessable and is checked against that
invitation's own cast, and gating it would mean showing two buttons to a player
who cannot click either. You never need to type it.
Solo emotes are unchanged — /emote <name> on yourself still plays
immediately, because there is nobody to ask.
Under the hood: the engine is a library#
Everything above — the animation engine, the emote director, screens, HUD overlays, sounds, skins — lives in a separate library that the plugin is built on top of. The plugin is the ResourcePack AI part: talking to the Studio, pairing codes, parties, distribution, and the branded messages in chat.
That split is why your own plugin can do all of it too:
- Reach what the plugin already runs. With
ResourcePackAI.jarinstalled, any plugin on the server can take our API off Bukkit's services manager and place models, play emotes, open screens and listen for our events. Start at Plugin API. - Or build on the engine directly. The library can be embedded in your own plugin, with your own pack content and no ResourcePack AI plugin on the server at all — same engine, none of our plumbing. Ask in Discord if that's what you're doing.