Included content
| Name | |
|---|---|
This update redesigns the overall Emote workflow and Animation format.
The web converter, Animation and Sequence formats, cooldown and permission management, random Emotes, two-player collaborative Sequences, the client-side Emote Wheel, and many other areas have been significantly changed. The internal playback system has also undergone a major overhaul.
Important: Starting with v2.0.0, the server uses the new Schema 3 format.
Existing Schema 1 Animations and Sequences can be imported into the web converter and exported again in Schema 3 format.
The web converter has been redesigned from the ground up.
Instead of the previous single-page interface, it now uses the following step-based workflow so that you can more easily understand where you are in the process:
Review → Settings → Export
.ajblueprint and .json projects.Project state management has been improved for projects containing multiple Animations.
standalone: false.The Animation conversion process has also been significantly improved.
Instead of simply snapping original Keyframes to Minecraft Ticks, the converter now analyzes the original Animation's easing and interpolation curves to preserve the original motion as closely as possible.
Important points in the following interpolation and easing types are taken into account:
Even when an original Keyframe falls between Minecraft's 20 TPS frames, the converter automatically selects the Tick placement that produces the smallest positional, rotational, and scale error.
This reduces cases where important frames are lost or where Animations containing easing behave significantly differently from the original.
The schema version used by Animations and Sequences has been changed from Schema 1 to Schema 3.
Settings that were previously located in multiple places have also been consolidated under settings.
"settings": {
"standalone": true,
"cooldown": "5s",
"player": {
...
},
"playback": {
...
}
}
Major changes include:
standalone → settings.standaloneplayer → settings.playersettings.playbacksettings.cooldownminecraft_versiontick_ratetransform_spacePlayback modes have been reorganized into:
onceholdloopserver_syncExisting Schema 1 Animations and Sequences can be imported into the web converter and exported again in Schema 3 format.
Settings that represent time now consistently use the Minecraft Time format.
20
20t
5s
1d
t → Tickss → Secondsd → Minecraft Days1s is equivalent to 20t.
This format is shared across time-related settings such as cooldowns, loop_delay, Sequence wait, and collaborative Sequence timeout.
Animations and Sequences now support settings.cooldown.
"cooldown": "5s"
emote.bypass permission can bypass cooldowns.Random selection in Sequences and Idle Emotes in emotes.json has been improved.
When only IDs are listed, every candidate has an equal probability of being selected.
"emote": [
"example:idle_1",
"example:idle_2",
"example:idle_3"
]
Alternating IDs and numbers enables weighted random selection.
"emote": [
"example:idle_1", 50,
"example:idle_2", 40,
"example:idle_3", 10
]
The sum of all weights must equal 100.
In Sequences, a new candidate is selected for every repeat.
When multiple actual Animation candidates are available, the previously selected Animation is excluded whenever possible so that the same Animation is not immediately selected twice in a row. The probabilities of the remaining candidates are recalculated automatically.
Sequence functionality has been significantly expanded.
A new wait step can be used to pause between Sequence steps.
{
"wait": "1s"
}
After the specified amount of time passes, the Sequence proceeds to the next step.
Two special IDs have been added for controlling repetition in random Sequences.
emote:continueConsumes one iteration of the current repeat and proceeds to the next random selection.
No Animation or loop_delay is added, and it may be selected multiple times consecutively.
emote:breakEnds repetition for the current Animation step and moves to the next Sequence step.
It does not terminate the entire Sequence or the entire branch of a two-player collaborative Sequence.
{
"emote": [
"example:idle_1", 50,
"example:idle_2", 30,
"emote:continue", 15,
"emote:break", 5
],
"repeat": 10
}
A new Collaborative Emote system allows two players to play a single Sequence together.
Collaborative Sequences can be constructed using the following flow:
await_partner — Waits for another player.matched — Runs when a partner has successfully been matched.timeout — Runs when no partner is matched within the specified time.When two players start the same collaborative Sequence, they can be linked together after distance, orientation, and other conditions are checked.
The default matching conditions are:
If multiple matching candidates are available, the closest initiator is given priority.
While waiting for a match, the collaborative Emote now tracks changes in the player's facing direction, allowing playback to use a more natural orientation when a match actually occurs.
New coordinate spaces have been introduced for two-player collaborative Animations.
scene — Shared scene space used by both players.initiator — Space relative to the player who initiated the collaborative Emote.partner — Space relative to the partner player.Each node can use one of these spaces.
Player skins can also independently use initiator and partner, allowing each player's own skin to be used.
If a collaborative Animation does not contain dedicated partner nodes, the initiator Animation is automatically duplicated for the partner, allowing it to be used as a mirrored collaborative Animation.
If partner nodes are explicitly defined, the initiator and partner can instead perform different actions, allowing asymmetric collaborative Animations.
A handshake example Animation and Sequence has been added so that the two-player collaborative Sequence system can be tested immediately.
The editing capabilities of the Emote Wheel available when the mod is installed on the client have been significantly improved.
Instead of using a fixed Wheel layout, players can now configure the Emotes they want to use independently for each server.
The permission system has been reorganized, and new administrative permissions have been added.
emote.manageAllows access to Emote administration commands and features.
It is used for:
/emote list/emote reload/emote enable/emote disable/emote stop-allBy default, this permission is granted to Operators with Game Master-level privileges.
emote.bypassAllows players to bypass the following server policies:
disabledHowever, it does not bypass system-level restrictions such as:
standalone: falseemote.manageThe behavior of disabled has been changed.
Disabled Emotes are still loaded normally, but they are hidden from regular players in menus, search results, command suggestions, the client-side Wheel, and direct playback.
As a result, a disabled Animation can still be used internally by another Sequence.
/emote reload results and error diagnostics.The Mod API and internal Emote information structures have been reorganized.
The API provides functionality for:
EmoteInfo has also been expanded to expose:
Additional Metadata is also preserved and can be accessed through the API.
yes, no, and cry Emotes.clap Emote.The web converter now includes experimental Bedrock Edition (BE) Emote import support.
This feature is currently Experimental, and some Animations, Molang expressions, or data may not convert perfectly.
The project documentation has also been extensively reorganized for v2.0.0.
Installation and server operation, permissions, playback policies, Sequences, Animation and Sequence formats, and the Mod API have been separated into dedicated documents so that relevant information is easier to find.
Separate Reference JSON files are also provided for Animations and Sequences.
| Name | |
|---|---|
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:qUF0jygw:IjvIpy89"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:qUF0jygw:IjvIpy89"
}