Unsupported bones permanently affect subsequent animations
@kylelinden is already working on this.
Since Jul 14, 2026.
Assessment
This issue has not been assessed yet.
Description
Test content is in a box at https://maps.secondlife.com/secondlife/Danger!%20Danger!/66/40/39
The animation uploader currently allows animations to include additional Bento body bones that are not part of the supported body animation skeleton for standard human avatars, such as Spine1–Spine4.
Because these bones are not reset by Second Life's default animation system, they remain in their last animated state after the animation ends.
As a result, subsequent, perfectly valid animations can appear broken, even though the problem actually originates from a previous animation. This makes the issue extremely difficult to diagnose and causes creators of correct animations to receive support requests for problems they did not create.
Because the animation uploader accepts these unsupported body animation bones without any warning, creators may not even realize they are exporting animation data that can affect subsequent animations.
This is not just an issue for individual animations. Full-perm animation packs are widely reused by furniture creators throughout Second Life. A single incompatible animation pack can therefore affect a large number of products created by different people, while the resulting support requests are often directed at the wrong creator.
Possible solutions
-
Reject unsupported body animation bones during upload.
-
Warn creators when unsupported body animation bones are detected during upload.
-
Automatically reset unsupported body animation bones when an animation ends.
Addressing this would significantly improve compatibility between animations from different creators.
- Dominant language
- C++
- Stars
- 299
- Forks
- 146
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 88
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from secondlife/viewer
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
secondlife/viewer#6293 · 2 comments ·
-
enhancement stale
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
secondlife/viewer#5969 · 4 comments ·
-
enhancement stale
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
secondlife/viewer#5875 ·
-
bug triage
Difficulty 3/5 1-2 days Newbie friendliness 65/100
secondlife/viewer#6348 ·
-
bug triage
Difficulty 4/5 3-5 days Newbie friendliness 55/100
secondlife/viewer#6345 ·
All issues in secondlife/viewer
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·