Tags
Creators
Details
Licensed MIT
Published 4 years ago
Updated 10 hours ago
All versions
1.1.5
Release
azurelib-stationapi-b1.7.3-1.1.5.jar5 days ago 5
Compatibility
Minecraft: Java Edition
b1.7.3
Platform
Babric
Supported environments
Client and server
Required content
Any compatible version
Changes
v1.1.5
Additions
- N/A
Fixes
- Fixed item and armor animations randomly snapping to their rest pose and restarting mid-animation. The item animator cache was keyed weakly, so live animators were being discarded on garbage collection.
- Fixed all item stacks without an Az ID sharing a single animator.
- Fixed the client giving stacks its own Az ID when rendering them, which could disagree with the server's ID for the same stack. Rendering no longer writes to stacks, including stacks of items that aren't registered for identity.
- Fixed client-side animation commands being skipped for stacks that hadn't received an Az ID yet.
- Fixed arm, leg and boot pieces of AzureLib armor on AzureLib entities being placed at the wrong position (for example, gauntlets rendering at the entity's feet), depending on the order the entity's bones rendered in.
Changes
- Az IDs are now assigned on the server when a stack first ticks in an inventory, or the first time an animation command is sent for it, instead of whenever a stack is created.
- Item animators now stay cached for 5 minutes without being rendered or dispatched to.
Developer Notes
- Added
AzItemIdentity, the single place stack identity is decided:peekreads the persistent ID,resolvereturns the ID animators are keyed by (persistent, or a temporary per-instance ID),getOrCreateassigns one, andadoptapplies a server-sent ID on the client.AzItemIdsremains the low-level reader and writer of the StationAPI NBT. AzItemIdentity.getOrCreateis server-only. Calling it on the client gives that stack a different ID from the server's.- On the server,
AzCommand.sendForItemassigns the Az ID if the stack has none, so pass the stack that lives in the inventory rather than a copy. - Worn armor doesn't tick in the inventory, so it gets its Az ID the first time an animation command is sent for it.
- When a dispatch arrives for a stack whose NBT hasn't synced yet, the client adopts the server's ID and moves the stack's existing animator to it, so the animation continues instead of restarting.
- Added
getOrNull(ItemStack, AzItemAnimatorView),add(ItemStack, AzItemAnimator),add(UUID, AzItemAnimatorView, AzItemAnimator),remove(UUID),clear()andANIMATOR_IDLE_SECONDStoAzIdentifiableItemStackAnimatorCache. Callclear()on disconnect or world unload to release cached animators.
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:7zlUOZvb:i3dyaVBi"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:7zlUOZvb:i3dyaVBi"
}

