ChangeLog: Epic Fight - Extended Datapacks V2.3 (Forge & NeoForge)

Bug Fixes

● Fixed an issue where Skill Conditionals and Stack Conditionals only accepted attack animations; they now support all animation types.

● Attempting to register a non-attack animation in a context intended for attacks will now display a warning, but the registration will still complete correctly.

● A bug caused by the offhand in NeoForge 1.21.1 has been fixed. When attacking with the empty hand or executing an attack that required context from the offhand, if the offhand was empty, a crash would occur.

● Several registration behavior and priority issues were resolved

● A problem in NeoForge 1.21.1 has been fixed. Previously, if an Innate Skill failed to build via JSON, the game would not crash, instead throwing a runtime exception when leaving any world. Now, errors prevent the game from loading and indicate where the error occurred.

● Forge 1.20.1, a reference and subscription issue that caused some visual and client-side features to be registered multiple times or incorrectly was resolved.

Minor Changes

● Removed invalid references, unused/dead code, and minor code-level errors.

● The process initialization class has been decentralized and cleaned of errors.

Added

This update introduces a full JSON-driven animation system, allowing animations to be registered, configured, and virtually extended entirely from data, without touching Java code. The system is organized into three core segments:

● Animation Registry: registers brand-new animations from JSON so they behave exactly as if they had been created in Java.

● Animation Configuration: modifies properties, events, and (for attack animations) phase properties on an animation that already physically exists in the registry.

● Animation Virtualization: applies the same configuration logic, but to a re-referenced/virtual animation instead of a physical one already registered.

All three segments share a common temporal Event system, are backed by a lightweight Armature resolution system, and are fed through a unified JSON loading pipeline (In-JAR/ SL Data Driven).

 

Added I — Accessors, Properties, Phases & Phase Properties (Attack only) → Registry

Animation Registry

The Animation Registry is the entry point for creating new animations purely from JSON. Its function is to let an animation be fully defined in data: transition timing, movement behavior, armature, events, and (for attacks) combat phases.

● Static Animations

● Movement Animations

● Attack Animations

● Combo Attack Animations

● Dash Attack Animations

● Air Attack Animations

 

Accessors

Every animation type supported by the Registry is represented by an Accessor  the JSON-facing counterpart of the animation's Java constructor. The Accessor is responsible for reading the raw JSON fields and building the actual animation instance, and it is also what applies that animation's Properties (see below) once the instance is created.

● Static Animation Accessor: transition_time, is_repeat, animation, armature, and events (In Time / In Period Time / In Interval Time).

● Movement Animation Accessor:  shares the exact same structure and logic as the Static Animation Accessor, adapted to its own type.

● Action Animation Accessor: transition_time, delay (entry delay), animation, armature, and events.

● Attack Animation Accessor (and its heirs) —  Attack, Combo Attack, Dash Attack, and Air Attack Animations. Fields: transition_time, animation, armature, events, and phases (see Phases below).

 

Important regarding “Accessors”

The animation path cannot contain the namespace; the location where the configuration file is stored is, in effect, its namespace. You cannot register animations in other namespaces.

 

 

Properties

Once an Accessor builds the animation instance, a matching set of Properties is applied to it. Properties are grouped by animation type, and each group inherits everything from the group below it, forming a single inheritance chain: Static → Action → Attack.

Static Properties (base of every animation):

○ No Physics — disables physics during the animation.

○ Fixed Head Rotation — locks head rotation.

Action Properties (inherit Static):

○ Stop Movement — stops the player's movement.

○ Remove Delta Movement — clears movement delta.

○ Move Vertically — allows vertical movement.

○ Move During Link — allows movement while linking into the next animation.

○ Movement Speed-Based Distance — scales traveled distance based on movement speed.

○ Cancellable Movement — allows the movement to be cancelled.

○ Death Animation — flags the animation as a death animation.

○ Reset Combo Counter — resets the player's combo counter.

○ Sync Camera — synchronizes the camera with the animation.

Attack Properties (inherit Action):

○ Fixed Move Distance — fixes the distance traveled during the attack.

○ Attack Speed Factor — factor affecting attack speed.

○ Base Attack Speed — base attack speed value.

○ Extra Colliders — additional colliders for the attack.

○ Attack Reach — reach of the attack.

 

Phases & Phase Properties (Attack only)

Attack-type animations (Attack, Combo Attack, Dash Attack, Air Attack) have an additional layer that no other animation type has: Phases. A Phase describes one strike within the attack : anticipation, pre_delay, contact and recovery timing, which hand is used, and its joint colliders  and each Phase can carry its own set of Phase Properties, letting a single attack animation have different combat behavior per strike.

● Max Strikes: modifier applied to the phase's maximum strike count.

● Damage Multiplier: multiplier applied to the phase's damage.

● Armor Negation: armor negation value for the phase.

● Impact Modifier: multiplier applied to the phase's impact.

● Stun Type: stun type applied by the phase.

● Swing Sound: sound played when the phase is executed.

● Hit Sound: sound played on impact.

● Hit Particle: particle spawned on impact.

 

Important notes

● The type field declared in the JSON must correspond exactly to one of the animation classes supported by the Registry; unsupported/unlisted types will not register correctly.

● Phases and Phase Properties only exist for, and only apply to, Attack-type animations (Attack, Combo Attack, Dash Attack, Air Attack). Static, Movement, and Action animations do not have phases.

 

Added II — Config Animations & Virtual Animations

Configuration and Virtualization do not work with individual animation types like the Registry does. Instead, they operate on Groups, using set/fuzzy logic rather than strict type matching: instead of targeting one exact class, a group targets any animation that is that type or inherits from it, within a defined range of the inheritance chain.

● Static Group: any animation above Dynamic Animation but below Action Animation, that is Static or inherits from Static.

● Action Group: any animation above Static Animation but below Attack Animation, that is Action or inherits from Action.

● Attack Group: any animation above Action Animation, with no upper bound i.e. anything that is Attack or inherits from Attack.

 

Each group Config Static Animation Group, Config Action Animation Group, and Config Attack Animation Group can apply the following to an animation:

● The Properties of its corresponding group (with the same inheritance chain described above).

● Events (In Time, In Period Time, In Interval Time).

○ Attack Group only — a list of Attack Phase Properties, distributed across the animation's phases. If there are fewer entries than phases, the last entry in the list is reused for all remaining phases.

 

Configuration and Virtualization share this exact group logic — Virtualization is effectively a divergence of Configuration. The distinction between them is conceptual, not mechanical:

● Virtualize: re-references and creates an animation virtually, configuring it without requiring it to physically exist in the registry beforehand

○ Real Animation: Real Animation Path.

○ Virtual Animation: New Animation Path

● Configure:  modifies a real, physical animation that already exists in the registry.

○ Animation: Animation Path

Both accept the same properties, events, and  for the Attack Group and its heirs phase properties.

 

Important regarding “Config & Virtual Animations”

Unlike accessors, here YOU must declare the full animation path, including its namespace. Furthermore, you can configure or virtualize any target animation; you are not limited to its namespace.

 

Added III — Time Events, Time Interval Events, Time Period Events & Playback Speed

A shared temporal Event system was added, available to every animation type (Static Animation and everything above it). It lets custom logic run at specific points during an animation's playback. There are three trigger types, each defining its own timing structure:

● In Time Event — fires once, at an exact point in time (start).

● In Period Time Event — fires continuously across a range (start → end).

● In Interval Time Event — fires repeatedly between start and end, spaced by a fixed interval.

All three accept a Side (client/server) that determines where the event executes, and all three validate their required fields before applying: if any required field is missing or invalid, a detailed error is logged naming the exact field that failed, and the event is simply skipped, it will not stop the rest of the animation from registering.

Available events (selected via JSON through the AnimationsEventsList type):

● White Afterimage Event: Generates a replica of the user model

● Entity Afterimage Event: Generates a replica of the user model

● Fracture Ground Event: Breaks the ground on impact.

● Play Animation Event: Run an animation

● Command Payload Event: Execute a command

● Invulnerability Event: Return the player to intangible status for attacks

● Thunder Event: It summons a lightning bolt that impacts nearby entities based on the number of impacts the weapon can make.

● Camera Transition (Temporal Only work in Forge 1.20.1): Modify the camera's state

● Joint Particle Event: It allows generating particles, based on the position of the Joint in the world.

Each event defines its own specific parameters, resolved dynamically based on the type declared in the JSON.

 

Playback Speed

It allows you to modify the speed at which an animation plays, since this is a Lamnda, like events, you can use a pre-designed list that offers some useful qualities in a generic way.

 

Currently there are the following "type" to control the animation playback speed

● Air Loop: Allows an animation to "almost" freeze when in the air; This allows the production speed to wait for an impact on the ground.

● Constant: Sets the playback speed to a constant number, if there are no parameters then it is set to 1

● Chargin: Based on the current load of your skill/innate skill, it modifies the playback speed of the animation, it is required to set an elapsed cap in the parameters, that is, until when the effect of "reducing" the playback speed will be applied.

● Charging Linked: Similar to the previous one, it works for bound animations, use it for a static loading type animation

 

Added IV — Entity State & Move Coord Functions

Entity State

These states control how the entity behaves while an animation is playing for example whether movement or turning should be locked, whether skills remain executable, whether item usage is allowed, or what combat phase level the animation should expose.

This functionality is provided through AnimationEntityState, a codec-serializable record that exposes optional entity-state flags and values, allowing state definitions to be serialized from JSON and applied directly to StaticAnimation Group and Uppers.

 

Currently supported fields include:

● Turning lock

● Movement lock

● Attacking

● Combo Attack Doable

● Skill Executable

● Item Use / Switch

● Inaction

● Knockdown

● Look Target

● Update Living Motion

● Hurt Level

● Phase Level

Because every field is optional, state definitions only need to declare the values they intend to override, leaving the remaining behavior untouched.

 

Move Coord Functions

Rather than hardcoding how an animation computes movement, destinations, or rotation, an animation now references a predefined movement function. These functions encapsulate common movement behaviors such as root motion, tracing a target, following an attached entity, or dynamically rotating toward a destination and can be freely reused across different animations.

 

Currently available presets include:

● Model Coord: computes per-frame movement from the animation's root motion, converting it into world space while respecting movement-speed modifiers.

● World Coord: interprets animation coordinates directly as world-space offsets.

● Attached: moves relative to an attached or grappled target, falling back to root motion when no attachment exists.

● No Dest: destination provider that always returns no destination.

● Attack Target Location: destination provider using the current attack target.

● Synched Dest Variable: destination provider backed by synchronized animator variables.

● Synched Target Entity Location Variable: resolves a synchronized entity ID into its live position.

● Look Dest: smoothly rotates the entity toward the resolved destination.

● Mob Attack Target Look: mob-specific rotation provider that faces the current attack target.

● Raw Coord: applies the animation coordinate sheet without modification.

● Raw Coord Qith X Rot: applies raw coordinates while accounting for the entity's pitch.

● Trace Origin As Destination: remaps animation coordinates so their endpoint matches the real destination.

● Trace Target Distance: rescales movement to match the actual distance to the target.

● Trace Target Location Rotation: extends the previous preset by incorporating target-facing rotation.

● Vex Trace: movement preset designed for flying attacks, steering toward the target's eye position.

 

Added V — Armature Support & Registry Integration

Armature Support

A lightweight, enum-based armature resolution system (ArmatureType) was added, mapping an identifier (epicfight:entity/...) to its corresponding Epic Fight armature. This is what lets every Accessor serialize/deserialize the armature used by an animation directly from JSON.

● Biped

● Creeper

● Enderman

● Skeleton

● Spider

● Iron Golem

● Ravager

● Vex

● Piglin

● Hoglin

● Ender Dragon

● Wither

 

Registry Integration (JSON Loading)

A loading system was added to feed all three segment. Registry, Configuration, and Virtualization from JSON files, each with its own dedicated builder: AnimationsRegistryBuilder, AnimationsConfigBuilder, and AnimationsVirtualBuilder.

 

In-JAR / JSON Loading: the primary loading path, using SL Library, which collects every .json file under:

● <file.jar>/data_driven/<mod_id>/animations/registry/  →  Animation Registry

● <file.jar>/data_driven/<mod_id>/animations/config/  →  Animation Configuration

● <file.jar>/data_driven/<mod_id>/animations/virtualizate/  →  Animation Virtualization

Each file can contribute its own definition files under its own mod_id, and they are parsed and registered independently per file.