Animation Event Keeper
Reimport-proof Animation Events
Animation Events that survive FBX reimport. A small editor database remembers your events, and a postprocessor re-applies them through Unity's import pipeline automatically. Ships with a visual timeline (draggable markers, scrub preview, color-coded drift visualization, footstep auto-detection), a function picker that browses your receiver components, batch apply across many clips, a validation dashboard with one-click repair, and receiver stub generation. Editor-only and safe to remove. Writes standard Unity events.
A small tool with a big job: it remembers what Unity forgets.
Animation Events on FBX clips vanish.
Author a hitbox event on a clip imported from an FBX. Walk away, come back tomorrow, hit Reimport. The event is gone. The standard workaround is to duplicate the clip out of the FBX so it lives in a free-standing .anim file. That fragments your animation pipeline, breaks Mecanim setups, and bloats your project. Keeper fixes it at the source.
Events disappear silently
AnimationUtility.SetAnimationEvents writes to the in-memory runtime clip only. The next time the FBX
reimports, Unity regenerates the AnimationClip sub-asset from scratch and the events are wiped. Your receiver
methods stop firing. Nothing tells you. The Console stays clean. You find out from a tester.
Events come back, automatically
Apply once. The recipe lands in a small database; the postprocessor re-applies it on every future import through Unity's official pipeline. Reimport, source-control swap, Mecanim refresh, CI build, six months later: events stay put. No babysitting.
Authoring and persistence are separate.
You author the recipe in the editor window. The database stores it. The postprocessor enforces it on every import. Unity reads standard Animation Events at runtime, the same as it always has. Remove Keeper and your applied events stay on disk.
the editor window
in user-data folder
every FBX import
Animation Events
Author one, or apply to dozens.
Tune a single clip visually
Drop a clip onto the Author tab, scrub the preview to find the pose, double-click the timeline to add events, drag markers to retune. Pick functions from the receiver component dropdown. Apply writes only to the clip you are editing, so loading multiples for comparison is safe.
Apply one recipe to many clips
Switch to the Batch tab, drop an FBX or select a folder of clips, see a Create / Update preview per clip, and apply with one click. The same recipe writes to all listed targets. Per-row remove buttons trim the list down when an FBX has more clips than you actually need.
Everything event authoring needs.
Reimport-proof persistence
The core promise. Apply a recipe once, and your events survive every FBX reimport, source-control swap, Mecanim refresh, Unity restart, and CI build. A small editor database remembers what you authored, and a postprocessor re-applies it through Unity's official import pipeline automatically. No duplicating clips out of the FBX, no fragile workarounds.
Visual clip timeline
Draggable markers across the clip length. Cyan for events in your edit session, gray for events already saved on the clip, amber for drift, red for missing. A thin connector line draws between a managed marker and its saved twin the moment you drag, so drift is an at-a-glance read instead of something you discover later in validation.
Animation preview with scrub
See the pose at any event without leaving the editor window. Scrub the playhead to scrub the preview live. Play / pause at 0.25x to 2x speed, step a single frame at a time, orbit the camera, scroll-zoom. Auto-detects the source FBX rig, falls back to Unity's default mannequin for Humanoid bone-only clips like Mixamo "Without Skin" downloads.
Function picker
Drop your receiver Prefab into the Pick From field, and every Animation-Event-compatible method on its components shows up in a one-click dropdown grouped by component. Picking one fills both the function name AND the parameter type, so signature mismatches die at authoring time instead of at runtime in someone else's Console.
Footstep auto-detection
Point at a Humanoid walk or run clip, click "Suggest Footsteps", and Keeper samples the foot bones, detects each contact phase via edge detection, and proposes one event per step at the most-planted moment. Results land as suggestions in the edit session for you to review, not on disk. Skips idle clips so you do not get noise.
Batch apply
Apply the same recipe to dozens of clips in one click. Drop an FBX with 20 sub-clips, drop a folder of .anim files, or select clips in the Project window. The Batch tab shows a Create / Update preview per clip before you commit, with per-row remove buttons so you can trim the list down to exactly the targets you want.
Built-in templates and custom Recipes
Ships with six gameplay templates (Hitbox Window, Combo Window, I-Frames, Footsteps L/R, SFX Cue, VFX Cue) so common patterns are one click. Save your own edit session as a portable Recipe ScriptableObject and reuse it across clips. Recipes are clip-agnostic (normalized time, so the same recipe works on a 0.4s attack and a 1.2s heavy attack).
Validation dashboard
Scans the entire database in one pass. Surfaces drifted events, missing events, lost clips, and broken receiver methods. Repair All re-applies every recipe to every target clip with one click. Per-row repair on the Database tab for surgical fixes.
Receiver stub generation
The Receiver tab shows every function name in your recipe with a green / amber / red status against your receiver components. Copy Stub on any row gives you a method signature ready to paste. Save Receiver Script generates a whole MonoBehaviour with every method scaffolded, parameter types and all.
GUID-backed move resilience
Rename or relocate an FBX and the recipe follows it. Keeper looks up entries by path first, then falls back to the asset GUID. The postprocessor uses the same fallback on import, so moves survive the auto-restoration path, not just manual repair. The recipe catches the new path up automatically the first time the GUID lookup wins.
Skip writing receiver MonoBehaviours by hand.
The Receiver tab knows every function name in your recipe and every parameter type. Click Save Receiver Script and Keeper writes a complete MonoBehaviour with every method scaffolded, ready to drop on your character. No typos, no signature drift, no chasing missing handlers in the Console at runtime.
// Generated by Animation Event Keeper. Paste onto your character.
using UnityEngine;
public sealed class AttackEventReceiver : MonoBehaviour {
public void EnableHitbox() {
// TODO: Handle Animation Event 'EnableHitbox'.
}
public void DisableHitbox() {
// TODO: Handle Animation Event 'DisableHitbox'.
}
public void PlaySFX(AudioClip value) {
// TODO: Handle Animation Event 'PlaySFX'.
}
}No surprises in the box.
Editor-only. No runtime DLL, no third-party dependency, no required render pipeline. If your project runs on Unity 2022.3 LTS or newer, Keeper runs. The database is a single ScriptableObject that lives outside the package folder, so updates can never overwrite your recipes.
Get it on the Asset StoreAnimation Event Keeper is an editor authoring and persistence tool for standard Unity Animation Events. It does not replace Mecanim, Animator Controllers, Animancer, Timeline, or Final IK; it writes the events those systems already read. It does not run at runtime. It does not modify your FBX source files (only Unity's import metadata). Suggest Footsteps is Humanoid-only because Generic rigs would need fragile bone-name heuristics I would rather not ship. You bring the receiver MonoBehaviour (or let Keeper generate it for you), and your gameplay code stays yours.
Questions, answered.
How does Animation Event Keeper actually persist events through FBX reimport?
A ScriptableObject database stores the recipe (your events, their normalized times, and their parameters), and an AssetPostprocessor hook re-applies that recipe on every FBX import through Unity's official AnimationUtility API. The database is declared as an import dependency via context.DependsOnSourceAsset, so Unity knows to rerun the postprocessor when the recipe changes. No proprietary runtime, no DLL voodoo.
Will my events break if I uninstall the package?
No. Keeper writes standard UnityEngine.AnimationEvent objects through Unity's public APIs. Uninstalling the asset leaves every applied event on disk, exactly where Unity expects to read it at runtime. Your project keeps working. The thing you lose is the ability to author new events visually and re-apply them through the postprocessor on future reimports.
Does it work for .anim clips, or just FBX clips?
Both. The reimport-proof postprocessor pipeline is the headline because that is the case Unity does not solve natively. .anim files write through cleanly without it; Keeper still tracks them in the database so validation, drift detection, batch apply, and receiver stub generation all work the same way.
What happens if I move or rename an FBX?
The recipe follows it. Keeper stores both the asset path and the asset GUID for every entry. On lookup it tries the path first, then falls back to the GUID, so moves and renames survive both manual repair AND the auto-restoration that fires on import. The first time the GUID lookup wins, Keeper catches the recipe's stored path up to the new location automatically.
Does it interfere with Mecanim, Animator Controllers, Timeline, Animancer, or Final IK?
No. Keeper writes Animation Events directly onto AnimationClip assets, the same place the Inspector writes them. Everything that reads Animation Events at runtime (Mecanim state machines, Animancer, Playables, Timeline tracks driven by AnimationClip) sees them the same way. Keeper is an editor-only authoring tool; it never runs at runtime and never touches your animation system.
Humanoid only, or Generic too?
Both for authoring, validation, batch, recipes, and persistence. The Suggest Footsteps auto-detection is Humanoid-only because it relies on standard bone slots (LeftFoot, RightFoot). Generic rigs would need fragile bone-name heuristics, which I deferred rather than ship something flaky.
Is the database safe to commit to source control?
Yes. It is a single ScriptableObject asset that lives at Assets/AnimationEventKeeperData/ (outside the package folder, so package updates can never overwrite it). Standard Unity YAML serialization, plays nicely with Unity's Smart Merge. Multiple authors editing different clip entries should merge cleanly.
Stop losing Animation Events to FBX reimport.
Full source, an editor-only footprint, and a developer who actually answers.