Quest Home Editor v0.10.12

The simplest fix for all the vista trouble: cooked homes now ship as combined — no vista is paired at all.

No more vista

Ported homes now cook as a combined environment by default. The shell loads it standalone with no companion vista — so there's nothing to make black, nothing to neutralize, and your home never depends on a vista loading correctly. This is the cleanest path and sidesteps every vista issue from the last few builds.

• Footprint mode (pairs an invisible vista) is still there as a toggle — "Spoof as footprint" — for anyone who specifically wants it.
• Neutralize vistas and auto-fix on connect stay on as a safety net, in case a particular headset pairs a vista anyway.

What to do

1. Update to v0.10.12.
2. Re-cook + install (COOK + SIGN + INSTALL).
3. Your home loads standalone — no vista, no black.

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.11

If your home loads but everything is black — this is the fix.

The vista was overriding your home's scene

Your home and the empty vista both loaded fine (no fallback), but everything rendered black. The cause: the empty vista still carried a scene config (fog + clip planes), and that config applies to the whole view regardless of which layer it came from — so the vista's dark fog overrode your home's own settings and blacked out everything.

Now the empty vista is fully inert: it has no scene config at all — no fog, no clip planes, no skybox, no lighting. Just an empty valid package that loads and contributes nothing. Your home's own scene settings apply unchanged, so it renders exactly as it should with no vista interference.

What to do

1. Update to v0.10.11.
2. Re-cook + install (or plug in the Quest and let the auto-fix re-neutralize the vista with the inert version).
3. Your home renders normally, the vista contributes nothing.

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.10

Builds on v0.10.9's vista fix. If your ported home shows a black/empty environment or "the vista neutralized but my home didn't show" — this is for you.

Why the home showed black / didn't appear

A footprint home is loaded together with its paired vista. So if the vista's scene fails to load, the shell rejects the whole environment and falls back to nuxd — which renders as a dark/black void. That's what "neutralized the vista but my custom home didn't show" actually was: the older, broken empty vista was still rejecting and dragging your home down with it. v0.10.9 fixed the empty vista; this release makes sure a broken one gets repaired automatically.

Auto-fix a broken vista on connect

When you plug in your Quest, the editor now checks the recent logcat for a vista that rejected on load and, if it finds one, automatically re-installs the current (fixed) invisible vista and reloads your home — no button press. It runs once per device, and only reloads the headset if it has to. New toggle "Auto-fix a broken vista when the Quest connects" (on by default).

What to do

1. Update to v0.10.10.
2. Re-cook + install your home (COOK + SIGN + INSTALL), or just plug in the Quest and let the auto-fix run.
3. Your footprint home loads with an empty (invisible) vista behind it — no scenery, no black void.

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.9

This is the fix if the empty vista kept failing with "No entities" even after re-installing.

Why it kept failing: a stale cached template

The empty vista shipped its scene at a fixed asset path. The headset's asset manager caches parsed templates by that path across reloads — so once the old (broken, 0-entity) empty vista was installed, re-installing the corrected template at the same path just re-served the cached broken copy. The fix looked like it wasn't taking because the device never actually loaded the new bytes.

Now the empty vista's asset path is tagged with a hash of its contents, so the corrected template has a fresh key the cache has never seen — the headset loads it for real.

Verified against libshell (IDA): the validator rejects a template with zero entities ("No entities" → error), and requires exactly one root entity with valid components — which the corrected empty vista satisfies (one Root transform, no meshes → loads fine, renders nothing).

Also

• The diagnostic report was blaming a harmless streamables.zip line (an optional asset that's missing even from working environments) instead of the real cause. The verdict now skips that and reports the actual template failure.

To use: update to v0.10.9, then run Neutralize vistas (or re-cook + install). The vista loads empty and your home shows with no scenery.

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.8

Fixes the invisible vista getting rejected (which dropped the home to the nuxd fallback).

The empty vista needed a root entity

The invisible vista shipped a scene with zero entities, and the shell rejects that outright:

[meta/empty_vista@content.hstf] No entities
ErrorUnexpected -3 : Failed to validate ECS template
-> Asset ptr error loading vista.calming -> falls back to nuxd

A scene template has to contain at least one entity. The empty vista now ships a single Root entity (an identity transform with no mesh) — it validates and loads fine, and still renders nothing. Same fix for the 8 home_c25 vista-shadow templates the footprint cook ships.

Good news from the same device log: the rest of the design is working — your home resolved as a footprint, the shell paired the vista, and the app's empty vista is what loaded. The only thing failing was the empty-scene validation, which this release fixes.

Re-run Neutralize vistas (or re-cook + install) on v0.10.8 and the home should load with no vista scenery.

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.7

Safety fix for non-rooted headsets.

Never installs an unspoofed home without real root

The rooted flow installs your home under its own package and selects it — which only works with actual root. The root check had a false positive: a ro.debuggable=1 (userdebug) build was treated as rooted even when adb root/su don't actually work. On such a headset the app would install the unspoofed home, fail to select it (no root), and skip the spoof — so your home wouldn't change at all.

Root is now detected only when it's actually usable (adb root gives uid 0, or su does). Otherwise the app installs the spoof (Haven 2025 replacement), which is the correct no-root path. If it can't confirm root, it will never install an unspoofed home.

(Vista-neutralize still runs without root — it replaces store-app vista packages, not homes.)

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.6

Small but important follow-up to v0.10.5 (footprint spoof). Get this if you cook footprint homes.

Footprint spoof is now self-sufficient (no nux, even without the neutralize step)

A footprint home makes the shell pair the calming vista, and that vista's content nests home_c25 templates from your package. If those aren't present, the whole environment is rejected and you drop into nux. The "Neutralize vistas" step avoids this on-device by emptying the vista — but a hand-installed or shared cooked APK never runs that step.

So the cook now also ships those 8 home_c25 templates empty under Meta's exact stock keys. The paired vista's nested load then succeeds with zero entities (no scenery, no nux), while your home renders normally. Your cooked footprint APK now loads correctly on its own, whether or not the vista-neutralize ran.

(HSR_NOVISTASHADOW disables it. Harmless when no vista pairs — the templates are just unreferenced.)

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.5

Builds on v0.10.4 (which fixed cooking producing 4 KB APKs — you need that fix, make sure you're on v0.10.4+).

Cooked spoof now pairs an (invisible) vista

Ported homes were shipping as a combined environment, which makes the shell drop the companion vista entirely. That was the old "no vista" approach — but it meant the spoof had no vista at all, and on some headsets the home still didn't sit right.

This release ships the spoof as a footprint (the native Meta home type), so the shell pairs a companion vista the way it does for a real home — and the "Neutralize vistas" step fills that pairing with an empty, invisible vista. Net result: your home loads as a proper footprint home, with no vista scenery behind it.

• "Spoof as footprint (pairs an invisible vista)" — new Cook toggle, on by default.
• Pairs with "Neutralize vistas" (also on by default), which pulls each installed vista, empties its scene, and reinstalls it — so whatever vista the shell pairs renders nothing.
• Turn the footprint toggle off to fall back to the old combined spoof (no vista paired) if vista-neutralize can't run on your headset.

Verified against libshell in IDA: a footprint env pairs a vista, and the shell accepts our empty vista (it only checks the vista package is installed and has a scene, never that the scene has content).

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh).

Quest Home Editor v0.10.4

⚠️ Critical: cooking was broken since v0.10.1 — this fixes it

If you're on v0.10.1–v0.10.3, every cook produced a ~3.5 KB APK that wouldn't install. The built-in APK signer (added in v0.10.1) was gutting every cooked APK — it read each zip entry's size from the wrong place (miniz writes those sizes to the central directory, not the local header), so it copied zero file data into the signed APK. Update to v0.10.4 and re-cook — output APKs are full-size again (verified: a dome cook is now 21 MB, not 3.5 KB).

🫥 Invisible vistas — home loads with no vista scenery

Ported homes spoof as a footprint, so the shell always force-pairs a companion vista behind your home. New this release: neutralize every installed vista by replacing its scene with an empty one.

• Pulls the real vista off your headset, keeps its exact manifest/package/resources, and swaps only its scene for a 0-mesh empty one — then re-signs and reinstalls. So the paired vista loads fine (no crash, no fallback) but renders nothing.
• Verified against libshell in IDA: the shell accepts a vista as long as its package is installed and assets/scene.zip exists — it never checks the scene has content. An empty scene is accepted, not rejected.
• On by default in the Cook tab ("Neutralize vistas"), plus a standalone "Neutralize vistas now" button (no re-cook) with a per-vista progress bar. Works without root (vistas are store apps). Restore a vista anytime by reinstalling it from the store.

Fixes

• Tooltip text no longer overflows its box (every line was drawn one text-height too low).

Linux/macOS: build from source (bash QuestHomeEditor/build_linux.sh) — the cook fix is in shared C++ and applies to every OS.

Quest Home Editor v0.10.3

Follow-up to v0.10.2, driven by three fresh field reports. Linux users: rebuild from source (bash QuestHomeEditor/build_linux.sh) — the biggest fix here is Linux-only.

Linux: adb devices finally show up

The device picker piped the adb path through a Windows backslash conversion on every OS — on Linux/macOS that turned /home/you/.../platform-tools/adb into an unrunnable path, so the editor listed zero devices while SideQuest saw your Quest just fine, and no error ever showed. Fixed. The editor now also reuses SideQuest's own adb if you have it (~/.config/SideQuest/platform-tools), and repairs a downloaded adb that lost its executable bit.

AMD: "stuck at init: graphics pipeline" fixed

An RX 6600 (Windows) hung forever in the driver's first pipeline compile — in an empty session, compiling pipelines nothing would ever use, against a needlessly-multiview render pass:

• multiview is now only enabled when shaders that need it exist (env skinned / V203 per-material),
• an empty session builds no 3D pipelines at all — it opens instantly on any driver,
• a disk pipeline cache beside the exe makes every later launch skip the driver's shader JIT,
• if a driver still stalls >25s, the log now says which phase and what to try (HSR_NO_MULTIVIEW=1).

"0 devices from every driver" now diagnoses itself

For the Manjaro report where the loader was fine but every ICD enumerated nothing: the log now dlopen-probes each driver library (prints the exact loader error of a broken .so), checks /dev/dri + /dev/nvidia* + the loaded kernel-module version, and spells out the usual cure — you updated the driver and haven't rebooted (or nvidia-dkms isn't built for the running kernel). Software fallback hint: vulkan-swrast.

Cleanup

Removed leftover dev-machine shader search paths (the Working (Current Env)/... probe spam in everyone's logs). Shader fallback is now: HSR_SHADER_APK → system_shaders.apk/.zip beside the exe → the built-in V79 shader.