Blog
Full Body Tracking Troubleshooting Checklist
Jul
Do not troubleshoot every full body tracking problem with the same reset. First identify what fails first: a tracker is absent, motion follows late, a body point shakes while you are still, alignment changes after starting correctly, the pose is wrong immediately after calibration, or a tracker moves on your body. Then use only the specialist route for that symptom.
This full body tracking troubleshooting checklist is a decision tree, not six repair guides compressed into one page. Run one controlled observation, decide which layer failed, and stop changing unrelated settings. That preserves useful evidence and prevents a small local fault from turning into a whole-system reconfiguration.
Start with the first thing that failed
Describe the first visible failure before restarting software, recalibrating, or moving every strap. The first symptom is more useful than the final avatar pose because later layers can hide the original cause. A tracker that never appears is different from one that appears and reports motion late. A point that shakes in place is different from a skeleton that begins correctly and slowly loses alignment.
Also note where you first see the problem. Start in the tracker server or setup view, then check the application, and judge the avatar last. If the tracker point is already wrong before VRChat opens, the application is not the first failed layer. If every point looks correct in the server but one avatar is wrong, do not return to network or strap changes by default.
Keep the current setup still while you observe it. Do not change charging state, Wi-Fi, tracker roles, mounting, proportions, and avatar calibration in one attempt. One change at a time lets you tell whether the fault stayed local, moved with the system, or existed only in the application.
Use the six-route decision table
| First visible symptom | One confirmation | Specialist route |
|---|---|---|
| A tracker is absent from the view where it should appear. | Other trackers appear, but the expected device or virtual point is missing rather than merely still. | Open the connection-path article. It owns the device, server, and application visibility checks. |
| Movement appears, but it follows your body late. | The path is reasonably smooth and recognizable, yet the virtual point trails the physical movement. | Use the response-delay guide. Do not classify smooth delay as shake or drift. |
| A body point makes small rapid movements while you hold still. | The error looks like fast noise around one position, not a steady time offset or a gradual heading change. | Continue with the motion-noise guide. This router does not repeat its isolation steps. |
| The setup starts aligned and becomes less aligned during the session. | The initial pose passes, but a limb or heading progressively separates from your real position. | Follow the alignment-loss guide. A result that is wrong from the first frame belongs elsewhere. |
| The whole pose or one limb is wrong immediately after calibration. | The bad result appears as soon as the calibration finishes, before time or active movement could change it. | Use the calibration recovery guide. It owns reset choice and verification. |
| The hardware changes position on your body during movement. | The error begins after a step, bend, turn, or dance motion, and the tracker or strap no longer sits where it started. | Go to the strap-fit guide. Physical movement should be corrected before software conclusions are trusted. |
Choose the row that describes the earliest reproducible observation, not the row with the most familiar name. If two symptoms appear together, begin with the one that occurs closest to the hardware. For example, a strap that rotates can make the avatar look poorly calibrated, but the physical movement happened first.
Confirm the route with one controlled test
- Return to a neutral starting position. Stand safely, keep the trackers in their current assigned locations, and open the lowest layer where movement is visible.
- Watch while still. Confirm whether every expected point exists and whether any point moves without your body moving.
- Move one side once. Lift or bend one limb, return to the starting position, and watch whether the correct point responds at the correct time.
- Repeat the motion without changing a setting. Look for the same absence, delay, shake, progressive alignment change, immediate wrong pose, or physical shift.
- Open only the matching guide. Record the result before applying its deeper checks.
The purpose is classification, not proof of a final cause. A single test can show that motion is late, but it does not by itself prove which network, device, or application condition created the delay. That deeper diagnosis belongs to the destination page.
Separate local, shared, and application-layer faults
A local fault stays attached to one tracker, one strap, or one assigned body role. One point is absent, rotates on the body, shakes, or moves differently while the others remain stable. Record its role and side before changing the rest of the setup.
A shared fault affects several points in the same way. The whole skeleton may respond late, face the wrong direction immediately after calibration, or lose a common reference over time. That pattern may require a system-level guide, but it still does not justify applying every possible reset at once.
An application-layer fault appears after the tracker-server view has already passed. If roles, directions, and movement look correct there but one VRChat avatar stands or bends incorrectly, keep the lower layers unchanged while checking application calibration and the avatar. If you cannot get far enough to isolate one symptom because the basic sequence is incomplete, use the full setup reference instead of guessing from this router.
Know when the first-pass check is finished
Stop the router as soon as one symptom is repeatable and one destination owns it. Do not continue down all six branches for reassurance. That creates new variables and makes the original observation harder to reproduce.
Before requesting help, write down the affected tracker or body point, the layer where the fault first appears, whether it starts immediately or develops over time, and the exact movement that reproduces it. Add the last setting, strap, tracker-role, software, network, or avatar change you made. A screenshot of the tracker-server view is more useful than a general statement that the avatar feels wrong.
Stop active testing if you cannot move safely, a strap or cable could catch, hardware is damaged, a device becomes unusually hot, or the movement space is no longer clear. Troubleshooting accuracy does not justify an unsafe repetition.
Check current hardware details after routing
If you use FBTKit hardware, the current FBTKit kit page is the source for current tracker-count options, included parts, and setup notes. Those facts can identify what should be present, but pack size alone does not diagnose absence, delay, shake, alignment loss, calibration failure, or strap movement.
FAQ
What observation should I make before touching any FBT setting?
Notice what fails first and where you can see it. Record whether a tracker is absent, motion is late, a point shakes while you are still, alignment changes over time, the pose is wrong immediately after calibration, or the hardware moved on your body. That first observation chooses the specialist route.
Can a tracker that still appears online have a physical mounting fault?
Yes. A tracker can remain connected while its strap slides or the device rotates on the body. If the error begins after a step, bend, or turn and the hardware is no longer in the same place, route the problem to strap fit before changing network or calibration settings.
Why can a problem appear in VRChat but not in the tracker server?
The tracker server and VRChat are separate layers. If tracker roles, directions, and movement look correct in the server but one avatar is wrong in VRChat, the next check belongs to the VRChat calibration or avatar layer. Repeating connection changes is unlikely to explain an already correct server view.
What should I write down before I ask for FBT help?
Record which tracker or body point is affected, where the fault is first visible, whether it starts immediately or develops over time, the last change you made, and one repeatable motion that shows the issue. Add a screenshot of the tracker-server view when possible.
Official sources
- SlimeVR common issues
- SlimeVR tracker configuration
- SlimeVR quick setup
- VRChat full body tracking documentation
Official documentation and current FBTKit product details were checked on August 10, 2026. This router does not claim a measured FBTKit troubleshooting result or customer outcome.
