Repository navigation
Animation Events
An Animation Event is a single action hooked onto a point (or points) in an animation's timeline. Every event, regardless of what it does or when it fires, shares the same base shape:
{
"type": "teleport",
"side": "server",
"params": {
"offset": [0, 0, 0],
"mode": "target_front"
}
}| Field | Type | Description |
|---|---|---|
type |
String | Identifies which event runs. Each type maps to its own event class with its own params see the individual event pages (e.g. Entity Events). |
side |
String | Where the event executes: server, client, or both. |
params |
Object | Fully defined by the event type structure differs per event and is documented on that event's own page. |
This base object never appears on its own, it's always placed inside one of the containers below, which decide when it fires.
| Container | Fires | Extra fields |
|---|---|---|
on_process_events |
At a named lifecycle point in the animation, rather than a specific timeline position. |
process the lifecycle point (e.g. on_begin). |
in_time_events |
Once, at a specific point in the timeline. |
start where in the timeline it fires. |
in_period_events |
Continuously, across a window of the timeline. |
start and end the window's bounds. |
in_interval_time_events |
Repeatedly, on a fixed cadence starting from a point in the timeline. |
start and interval when it begins, and how often it repeats afterward. |
in_time_events is by far the most common container reach for the others only when the behavior genuinely needs a lifecycle hook, a sustained window, or a repeating tick.
on_process_events fires on a lifecycle point instead of a timeline position:
"on_process_events": [
{
"process": "on_begin",
"type": "laser_floor_world_damage",
"side": "both",
"params": {
"damage": 20,
"radius": 20,
"count": 30
}
}
]in_time_events fires once at start:
"in_time_events": [
{
"type": "teleport",
"side": "server",
"start": 0.15,
"params": {
"offset": [0, 0, 0],
"mode": "target_front"
}
}
]in_period_events fires continuously between start and end:
"in_period_events": [
{
"type": "joint_particles",
"side": "client",
"start": 0.0,
"end": 0.2,
"params": {
"joint": "Tool_R",
"particle": "minecraft:crit",
"offsets": [
[-0.3,-0.1,-1.6]
],
"step": 4.0,
"volume":[0.15,0.15,0.15],
"motion":[0,0,0],
"amount":1.2
}
}
]-
typeandparamsmean exactly the same thing no matter which container holds the event only the container decides the timing, not the event's own behavior. -
side: "both"runs the event on server and client independently, each doing its own execution it isn't a sync mechanism by itself. - Whether a given
typeis actually valid inside every container (e.g. a one-shot event placed inin_period_events) depends on that event check its own page.
EF: Extended Datapacks
📦 Data
🧰 Core
👁️ Visuals
- Zoom Types
- Weapon Models per Style
- Advanced Swing Trails
- Weapons Passive Particles
- Shader Effects I
- Shader Effects II
- Shader Effects III
⚔️ Combat
🗝️ Skill Builder
🛠️ Innate Builder
- Simple Innate Skills
- Holdable Innate Skills
- Conditional Innate Skills
- Conditional Data Innate Skills
- Conditional Holdable Innate Skills
- Sequential Innate Skills
- Per Combo Innate Skills
- Combo Innate Skills
🗡️ Animation Operations
- Animation Operations
- Animation Properties
⚙️ Third-Party