Tags
Creators
Details
Licensed MIT
Published 4 years ago
Updated 2 days ago
All versions
1.1.3
Release
1.1.35 days ago 16
Compatibility
Minecraft: Java Edition
1.12.2
Platform
Forge
Supported environments
Client and server
Changes
v1.1.3
Additions
- Sequence stages can now set their own animation speed, transition length, easing, start offset, freeze point and repeat count. These only apply while that stage plays and no longer stick to the controller afterwards.
- Added
AzSequence#freeze(name, tick)for stages that freeze partway through. - Added stage-anchored sequence events:
eventAt(name, keyframeTick),eventOnStart(name)andeventOnEnd(name). They follow playback speed, transitions, start offsets, repeats and stage lengths instead of a fixed game-tick count. - Added
AzSequenceTimingandAzSequenceTimelinefor working out when stages and events happen, plusAzSequencePlayer#withTimingandAzAnimationController#sequenceTiming()(client side, reads lengths from the animation file). - Molang: assignments anywhere in an expression, multiple
;-separated statements,{}blocks,return,loop(count, body),breakandcontinue. - Molang: binary conditional (
a ? b), null coalescing (??), short-circuiting&&/||, andtrue/false. - Molang:
variable.*/v.*values are now stored per animatable, so each entity, block entity or item keeps its own copy. Code can read and write them throughAzAnimationContext#molangScope().
Fixes
- Fixed bone hitboxes (and other bone matrix consumers) ignoring the renderer's
setScalewhen the entity had a render layer that re-renders the model. Hitboxes now scale with the model on versions without the scale attribute. - Fixed animations getting stuck after a freeze point was set on a controller (e.g. through the full
AzCommand.createoverload). The freeze point now only applies toFREEZE_ON_FRAMEanimations, so later loops, ping-pongs and sequence stages play normally. - Fixed a freeze point shorter than the transition length holding the transition open forever.
- Fixed changing direction during a transition skipping the blend and snapping to the new animation.
- Fixed
FREEZE_ON_FRAMEpausing on the first frame when the freeze point came from the animation file. - Fixed
REPEAT_X_TIMESplaying one extra time and ignoring the animation file's authoredrepeat_times. - Fixed the start tick offset being multiplied by animation speed and shortening transitions. Transitions now blend towards the pose playback actually starts on.
- Molang:
piandenow resolve to their constants instead of 0. - Molang: fixed a possible race when animation files are parsed in parallel.
Changes
- Reduced log spam: the "Replaying queued command(s)" message from pending animation dispatches now only appears in development environments.
REPEAT_X_TIMESnow plays exactlyrepeatXTimestimes in total, matching its documentation. Animations tuned around the old behavior will repeat once less.- Molang expressions are now compiled by a new parser. Anything it can't handle is retried with the old parser and logged as a warning ("Falling back to the legacy parser").
- Molang:
temp.*/t.*values now reset on every evaluation instead of carrying over between entities. - Molang: assigning to
query.*,context.*,math.*or a constant is now rejected and logged, and the expression evaluates to 0.
Developer Notes
- Sequence events added with
event(name, tick)keep their existing meaning (game ticks afterplay()). - Stage-anchored events need the animation lengths they depend on. On the server, pass them through
AzSequenceTiming.builder().length(name, ticks). Events whose time can't be worked out are skipped with a single warning instead of firing early. - Global variables driven from code with
MolangParser#register,setValueorsetMemoizedValuestill work: animations read them until an animatable assigns its own value. AzQueuedAnimationhas a newstagePropertiescomponent; the existing constructors are kept.
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:8rjduZ58"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:7zlUOZvb:8rjduZ58"
}

