Import a single-animation glTF into Godot, enable Save to File on the animation, and the resulting `.tres` points at bones that don't exist. A track that should read `Skeleton3D:Door` comes out as `Skeleton3D:Door_2`, Godot invented a bone that was never in the file, and your `AnimationPlayer` silently fails to find it. This is a confirmed Godot bug, not a Blender export mistake — it reproduces on both 4.5.1 and 4.6 stable, nobody has a patch scheduled, and the fix is something you apply yourself today.
Why Godot's glTF import renames your bones
Godot's scene tree auto-renames any node that collides with an existing sibling, appending `_2`, `_3`, and so on to keep names unique. The glTF importer's "save this animation as its own resource" path builds an internal scene graph to resolve each track's node path, and that process collides with itself — even with one armature, one animation, and zero naming conflicts anywhere in the source file. Whatever collision it thinks it found gets baked into the `.tres` permanently: every bone in every track carries the phantom suffix, while the real `Skeleton3D` sitting in your actual scene keeps its clean, correct names.
It's filed as issue #115792 on the godotengine/godot repository, labeled `bug`, `topic:animation`, and `topic:import`, sitting in the Asset Pipeline Issue Triage project with no milestone attached. It reproduces on commit `f62fdbd` (4.5.1 stable) and `89cea14` (4.6 stable) — the bug crossed a full minor version bump without anyone touching it.
Reproduce it in under a minute
Export a rig from Blender with exactly one action baked into its own glTF file — no other animations in the file, no naming collisions to speak of. In Godot's FileSystem dock, double-click the `.glb` to open the Import tab, then click Advanced Import Settings. Select the animation under the Animation category, enable Save to File, point it at a `.tres` path, and hit Reimport. Open the saved `.tres` in any text editor and compare the `tracks/0/path` line — something like `NodePath("Skeleton3D:Door_2")` — against the bone names actually present in your `Skeleton3D`. If that suffix doesn't exist on the real skeleton, every track built the same way in that file has the identical problem.
The one-line fix for files you've already exported
`.tres` is plain text, so patching a handful of already-broken files doesn't need the Godot editor open at all.
```bash
# strips the bogus _2 suffix from every bone track in one .tres
sed -i 's/_2"/"/g; s/_2:/:/g' animations/door_open.tres
```
This fixes that one file. It does not survive the next reimport — Godot regenerates the `.tres` from the glTF source and reintroduces the same suffix, which is the part that catches teams re-exporting from Blender every time an animator tweaks a pose.
The fix that survives reimports
For a pipeline where animations get re-exported repeatedly, hand-editing `.tres` files after every reimport isn't a workflow, it's a chore that eventually gets skipped. Attach a post-import script instead: in Advanced Import Settings, set the Script field to a script extending `EditorScenePostImport`, and correct the paths before Godot ever writes the file.
```gdscript
extends EditorScenePostImport
func _post_import(scene: Node) -> Object:
for player in scene.find_children("", "AnimationPlayer", true, false):
for lib_name in player.get_animation_library_list():
var lib := player.get_animation_library(lib_name)
for anim_name in lib.get_animation_list():
var anim := lib.get_animation(anim_name)
for i in anim.get_track_count():
var np := anim.track_get_path(i)
var bone := np.get_concatenated_subnames()
if bone.ends_with("_2"):
anim.track_set_path(i, NodePath(str(np.get_concatenated_names()) + ":" + bone.trim_suffix("_2")))
return scene
```
Assign it once per import preset and every future reimport comes out clean, whether it's an animator re-exporting by hand or a CI job pulling fresh `.blend` files on every commit.
Test it on a rig with more than one bone
A single "Door" bone is easy to eyeball; a character skeleton with thirty-plus bones is where the phantom suffix actually costs time, since some tracks land on real names by coincidence while others quietly no-op. Elven Ranger ships with a full humanoid skeleton and works as a stand-in for this test — export one action for it, reimport with Save to File on, and diff the track paths before deciding whether the post-import script is worth setting up. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships (pricing).
Which fix fits your pipeline
| Approach | Fixes files already exported | Survives the next reimport | Setup required |
|---|---|---|---|
| `sed` on the `.tres` | Yes | No | None — one command |
| Manual edit in a text editor | Yes | No | None, but slow past a handful of files |
| `EditorScenePostImport` script | No — new imports only | Yes | Attach once per import preset |
Gotchas
Godot doesn't throw an error when a track path fails to resolve — it logs a quiet warning to the output panel and keeps running, so a broken bone track ships to players as "that door just doesn't open," with nothing in the crash logs pointing at why. The bug only triggers on the Save to File path specifically; animations left embedded in the imported scene, which is the default when you skip that toggle, don't show the phantom suffix at all, so if you don't need the animation as a standalone resource, not saving it to file sidesteps the entire issue. And because the suffix gets rebaked on every reimport, a file you fixed by hand looks correct right up until someone touches the source `.blend` again and the pipeline runs — which is why the `sed` fix is fine once and the post-import script is the only real answer past two or three reimports.
Two related Godot import bugs worth knowing if you're building rigged characters: Godot's GLTF importer flattening normal maps and the red X on GLB imports after a clean checkout both hit the same import pipeline from different angles, and glTF's 4-bone weight limit is the other common way a rig comes in looking wrong.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*