Editing One Spine Character Changes Another? Check Bone vs BoneData

You intend to adjust character A's arm, yet character B changes too. Before exporting new artwork, identify whether the write targets A's runtime bone or setup-pose data used by multiple characters.

A shared filename does not establish shared object identity

The official loading guide describes reading JSON or binary data into SkeletonData. How the receiving application caches and instantiates it depends on its runtime and integration layer. Two matching filenames alone do not prove that two characters hold the same in-memory data object.

Ask the integrator to record the actual A and B instances, affected bone objects and their data references. Object identifiers must come from real debugging evidence; this article does not invent a trace for your project.

Setup-pose data can have a broader scope than a runtime bone

The Runtime Skeletons guide explicitly describes BoneData edits affecting animations and skeletons that use that data. It distinguishes changing a runtime bone's rotation from changing its data.rotation. Similar property names do not imply the same ownership.

For an adjustment intended only for A, first establish that the selected object belongs to A's instance. If the actual design is to change every character's common setup pose, the shared effect may be intentional rather than a bug.

Run one bounded two-instance comparison

1. Use a fixed export batch and known A and B instances. Record the baseline.
2. Identify the exact property, its owner and any confirmed shared data reference.
3. In a test copy, trigger only A's change and observe both characters. Record whether animation also writes the property.
4. If shared setup data was modified unintentionally, restore the test baseline and let the owner choose the correct instance property and application stage.

This is a proposed diagnostic experiment, not a measured multi-character result. If the data references are independent, investigate actual shared application variables or updates broadcast to multiple characters instead of forcing a BoneData explanation.

Respect the receiving project's update order

The official guide explains that animation commonly changes local bone transforms while rendering uses world transforms. Confirm when animation is applied, when the intended local adjustment occurs and when world transforms are updated.

Method signatures and physics-related update requirements depend on the runtime version. No universal engine loop is supplied here, and repeatedly editing shared setup data is not a substitute for controlling a single instance's pose.

Preserve useful sharing while isolating mutable state

Caching reusable data or textures does not require sharing every character's mutable pose. Disabling all caches or deep-copying every resource can increase loading and memory costs without identifying the incorrect write. Establish ownership first, then isolate only the state that requires it.

Keep a matched resource and export batch from Spine Workbench using the public guide. A good source preview is not proof of correct game-instance management. Exchange the A/B roles and retest the required animations, not just initial loading.