Tags
Creators
Details
1.0.0+26.2
Compatibility
Changes
1.0.0 Update
This update improves emote playback performance and stability, adds a command for measuring real server load, and enhances file handling and resource pack merging in the web converter.
Emote Playback Improvements
- Emotes now smoothly rotate to follow the player’s viewing direction during playback.
- Rotation interpolation and update thresholds make movement smoother while reducing unnecessary rotation updates.
- Playback plans and transformation data are precomputed to reduce work performed every tick.
- Unchanged transformations and rotations are no longer reapplied.
- In a high-load simulation with 100 emotes, transformation applications were reduced by approximately 37%, and playback computation became approximately 2.2 times faster.
These results measure only the emote playback computation path. Display entity processing and network transmission costs are not included.
Server Load Testing
Added the administrator-only /emote load-test [count] command.
- Runs multiple emotes simultaneously to measure their impact on server TPS and MSPT.
- Creates 100 emotes when the count is omitted, with a maximum of 1,000.
- Randomly selects registered emotes, places them in a grid, and distributes their playback start times.
- Use
/emote load-test stopto stop the test and view the number of created Displays, failed instances, and the following performance statistics:- TPS before the test, average TPS, and minimum TPS
- MSPT before the test, average MSPT, and maximum MSPT
- Emote creation and cleanup time
- Average and maximum emote tick processing time
- Number of measured server ticks
- Emote instances that encounter errors during the test are automatically removed and counted as failures.
Animation Stability
- Added complexity limits to prevent excessively complex animations from affecting server performance.
- The same limits apply to animations loaded from files and animations registered through the runtime API.
- Text Display parsing failures are now treated as errors instead of continuing playback with empty text.
- Player skin settings are now validated to ensure they are used only with player head items.
- Active emotes and related resources are now properly cleaned up when the server shuts down.
The current limits are:
- File size: 8 MiB
- Total nodes: 48
- Display nodes: 32
- Playback duration: 10 minutes
- Average transformations per tick: 24
- Average visibility changes per tick: 8
- Commands executed at the same time: 16
- Total commands: 4,096
MineSkin Improvements
- Fixed an issue where cancelled MineSkin tasks could be scheduled again later.
- Improved task lifecycle handling so tasks from a previous generation cannot run after a server shutdown or configuration reload.
Web Converter Improvements
- Animated Java animation start delays and keyframe timing are now preserved correctly.
- Duplicate Animated Java keyframes at the same timestamp are now detected to prevent invalid conversion results.
- Supported formats can now be detected by inspecting file contents even when the file extension is incorrect.
- BD Engine projects that would generate an excessive amount of transformation data are now rejected before conversion.
Resource Pack Merging Improvements
- ZIP extraction and creation are now processed asynchronously to reduce browser freezing.
- Reduced unnecessary memory copying during resource pack merging.
- Excessively large or malformed ZIP files and resource packs are now rejected before processing.
- Strengthened validation against unsafe file paths, including absolute paths and parent-directory traversal.
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.
Maven coordinates:
Version ID:
build.gradle:
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:qf2GC9If"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:qUF0jygw:qf2GC9If"
}
