View Finders on sub-levels don't track position — no sub-level ReferenceFrame implementation (rotation works, translation doesn't)

[polycitrine-glitch]

Summary

Sable's Vista compatibility mixin no longer applies, because its target class was removed/refactored in current Vista. The failure is silent (a startup WARN, no crash), and the user-visible result is that View Finders placed on a sub-level do not move their virtual camera with the sub-level — the camera stays at the world position where the View Finder was originally placed.

Environment

Minecraft	1.21.1
NeoForge	21.1.243
Sable	2.0.3 (sable-neoforge-1.21.1-2.0.3.jar)
Vista	5.4.4 (vista-1.21.1-5.4.4-neoforge.jar)
Create Aeronautics	1.3.0

Evidence

Startup log:

[main/WARN]: @Mixin target net.mehvahdjukaar.vista.common.view_finder.ViewFinderAccess$Block
    was not found sable.mixins.json:compatibility.vista.ViewFinderAccessMixin from mod sable

[main/WARN]: Error loading class: net/mehvahdjukaar/vista/common/view_finder/ViewFinderAccess$Block
    (java.lang.ClassNotFoundException: net.mehvahdjukaar.vista.common.view_finder.ViewFinderAccess$Block)

ViewFinderAccess$Block is not present in vista-1.21.1-5.4.4-neoforge.jar. The package now contains:

net/mehvahdjukaar/vista/common/view_finder/
    ViewFinderBlock.class
    ViewFinderBlockEntity.class
    ViewFinderMenu.class
    ReferenceFrame.class
    WorldReferenceFrame.class
    EntityReferenceFrame.class
    YawPitchRestraint.class
    EndermanLookResult.class

Vista appears to have moved to a ReferenceFrame abstraction (WorldReferenceFrame / EntityReferenceFrame).

Reproduction

1. Install Sable 2.0.3 + Vista 5.4.4 on 1.21.1 / NeoForge 21.1.243
2. Assemble a sub-level
3. Place a View Finder on the sub-level and link it to a TV
4. Move the sub-level

Expected: the virtual camera moves with the sub-level.
Actual: the camera remains at the original world position; the TV shows a static view of where the View Finder used to be.

Probable cause

With ViewFinderAccessMixin failing to apply, the View Finder falls back to WorldReferenceFrame (fixed world coordinates) rather than being given a sub-level-relative frame. A ReferenceFrame implementation backed by the sub-level's transform looks like the natural fix against the current Vista API.

[polycitrine-glitch]

Correction — this is likely not Sable's bug

I filed this after seeing the stale mixin warning and matching it to the symptom. Further digging shows the mixin is real dead code but not the cause, and the View Finder tracking gap lives on Vista's side. Posting the full findings so the report is accurate.

The stale mixin is genuine, but inert

sable.mixins.json:compatibility.vista.ViewFinderAccessMixin targets net.mehvahdjukaar.vista.common.view_finder.ViewFinderAccess$Block. Checking every tag of MehVahdJukaar/cameramod:

Tag	ViewFinderAccess.java
1.21.1-5.4.4 … 1.21.1-5.0.0	absent
1.21.1-4.5.0 … 1.21.1-4.4.5	absent
1.21-3.1.2	present
1.20-3.1.3	present

So the class was removed before the 1.21.1 line began, and this mixin has never applied on 1.21.1. Worth deleting or retargeting regardless, but it isn't what breaks View Finder tracking.

The actual mechanism (Vista 5.4.4)

Vista resolves camera position through ReferenceFrame. Only three implementations exist:

• WorldReferenceFrame — Vec3.atCenterOf(blockEntity.getBlockPos()), velocity() == Vec3.ZERO
• EntityReferenceFrame
• integration/create/ContraptionReferenceFrame(Entity contraption, BlockPos localPos)

ViewFinderBlockEntity constructs WorldReferenceFrame. ContraptionReferenceFrame is constructed only from ContraptionBroadcastLocation and CreateClientCompat — i.e. only for Create contraption entities.

There is no sub-level ReferenceFrame, so a View Finder on a Sable sub-level reports a fixed world position and zero velocity. That is exactly the reported symptom.

Vista already does this correctly for Mirrors

Vista bundles sable-companion-common-1.21.1-1.6.0 and uses it in several places:

MirrorTextureManager       -> ClientSubLevelAccess, SableCompanion, Pose
MirrorBlockEntityRenderer  -> ClientSubLevelAccess, SableCompanion, Pose
ServerCameraChunkManager   -> SableCompanion
LevelBEBroadcastLocation   -> SableCompanion

Mirrors are fully sub-level aware. CompatSableTrackingMixin covers chunk tracking only (ExtraChunkViewData.containsChunk), not the camera transform. So the missing piece is a ReferenceFrame implementation backed by the sub-level's Pose via the same SableCompanion API the mirror code already uses.

Why it used to work

When Create Aeronautics built airships as Create contraptions, View Finders tracked via ContraptionReferenceFrame. Aeronautics 1.3.0 moved to Sable sub-levels, which are not contraption entities, so that path no longer applies and the frame silently falls back to static world position.

Environment

Minecraft 1.21.1 / NeoForge 21.1.243 / Sable 2.0.3 / Vista 5.4.4 / Create Aeronautics 1.3.0 / Sable Companion 1.6.0

---

Happy for this to be closed and re-filed against MehVahdJukaar/cameramod if that's the right home — the actionable fix (a sub-level ReferenceFrame) is Vista-side. Leaving it here in case the stale mixin is still worth cleaning up.

[polycitrine-glitch]

Root cause confirmed: no sub-level ReferenceFrame exists

Follow-up with the decisive evidence. Vista selects a View Finder's camera anchor via ReferenceFrame, and there are only two construction sites in vista-1.21.1-5.4.4:

ViewFinderBlockEntity          → WorldReferenceFrame        (static world position)
ContraptionBroadcastLocation   → ContraptionReferenceFrame  (Create contraptions)
CreateClientCompat             → ContraptionReferenceFrame
EntityReferenceFrame           → never constructed by the View Finder

A Sable sub-level is neither a Create contraption nor an entity, so a View Finder placed on one falls through to WorldReferenceFrame and stays pinned to its original world coordinates. That is the entire bug — the camera has no way to learn it is attached to something that moves.

Not a Vista regression

I checked older Vista jars against the same Sable/Aeronautics pair:

Vista	frames present
4.4.11	World, Entity
5.1.2	World, Entity, Contraption
5.2.2	World, Entity, Contraption
5.4.4	World, Entity, Contraption

No 1.21.1 Vista has ever had a sub-level frame, and 4.4.11 lacked even the contraption one. Nothing was lost; the case was never implemented.

For reference, a known-working-feeling setup (It's Not Rocket Science, MC 1.21.1) runs Sable 1.2.2 / Aeronautics 1.2.1 / Vista 4.4.11 / Moonlight 3.0.14 — same absent frames.

Orientation already works; only position is missing

ViewFinderControllerMixin does apply cleanly (no mixin warning) and operates on ClientSubLevel and Camera.rotation() via a sable$orientation field. So the camera already rotates correctly with the sub-level — it simply never translates. That asymmetry is a strong hint that the remaining work is small.

Suggested fix

ReferenceFrame is a small interface:

public interface ReferenceFrame {
    Vec3 position(float partialTick);
    Quaternionf getRotation(float partialTick);
    Vec3 velocity();
    TileOrEntityTarget makeNetworkTarget();
    boolean isStillValid(Player player);
    default void syncToServer(...);
    default void syncToCLients(...);
}

Sable already exposes everything it needs. Each sub-level persists a pose with position (x/y/z) and orientation (quaternion) — visible directly in the sublevels/*.slvls records — and ActiveSableCompanion.getVelocity() supplies velocity(). A SubLevelReferenceFrame mirroring ContraptionReferenceFrame, transforming the View Finder's plot-local position through the sub-level pose, should be sufficient.

This could land on either side — Vista adding the implementation, or Sable providing one through Sable Companion (which Vista already bundles at 1.6.0). Happy to test a build against Sable 2.0.3 / Vista 5.4.4 / Aeronautics 1.3.0 on 1.21.1.