Log inGet started
▣
module · drop-in viewer
asset⌬ modulemoduleprimary: init.luau·originates fromworld 07158574-5…

asset_residency

Compute backends for the **lazy** residency properties on every `AssetRef` (`has_backing_asset`, `has_runtime_changes`, `cpu_resident`, `gpu_resident`). The AssetRef metatable's `__index` dispatcher (`assetType.shared.ref`) calls these only when a caller actually reads a flag — n…

byzero-proxy @ DESKTOP-DB3UJOJ·posted 2mo ago
What it does

asset_residency

Compute backends for the lazy residency properties on every AssetRef (has_backing_asset, has_runtime_changes, cpu_resident, gpu_resident). The AssetRef metatable's __index dispatcher (assetType.shared.ref) calls these only when a caller actually reads a flag — nothing is computed at resolve time, so an asset costs nothing for residency until it is observed.

The three backing/runtime states:

has_backing_assethas_runtime_changesMeaning
truefalseUSED, UNMODIFIED
truetrueUSED, MODIFIED (copy-on-write fork)
falsetrueRUNTIME-GENERATED

cpu_resident and gpu_resident are orthogonal to those three, and to each other. cpu_resident asks "is this asset referenced from a live script-component context, so its bytes are warmed in memory?" (the /runtime/assets/ CPU layer); gpu_resident asks whether the device holds a texture or mesh under the asset's guid. They are separate pools and an asset can be in one and not the other — asset.observe() lists both. See docs/specs/runtime-asset-copying.md — "CPU residency vs GPU residency".

The backing/runtime flags are derived from where the asset lives — source under /zero/source/… (backed), a copy-on-write fork / runtime-generated asset under /zero/runtime/assets/<identity>.<category>/ (runtime change) — using the canonical <identity>.<category>/ suffix shape, generic over any category. cpu_resident and gpu_resident are live queries through asset.cpuResident and asset.gpuResident.

Interface

What this asset declares: the schema it conforms to, what it exposes, and the rendered structured payload.

conforms to

zero/source-extract/v2

asset_residency.module/init.luau Compute backends for the LAZY residency properties on every `AssetRef` (`has_backing_asset`, `has_runtime_changes`, `cpu_resident`, `gpu_resident`). The AssetRef metatable's `__index` dispatcher (`assetType.shared.ref`) calls these only when a caller actually reads a flag — nothing is computed at resolve time, so an asset costs nothing for residency until it is observed. The three backing/runtime states: * has_backing_asset = true, has_runtime_changes = false → USED, UNMODIFIED * has_backing_asset = true, has_runtime_changes = true → USED, MODIFIED (CoW fork) * has_backing_asset = false, has_runtime_changes = true → RUNTIME-GENERATED `cpu_resident` and `gpu_resident` are orthogonal to those three, and to each other. `cpu_resident` asks "is this asset referenced from a live script-component context, so its bytes are warmed in memory?" (the `/runtime/assets/` CPU layer); `gpu_resident` asks whether the device holds a texture or mesh under the asset's guid. They are separate pools and an asset can be in one and not the other. See `docs/specs/runtime-asset-copying.md` — "CPU residency vs GPU residency". The backing/runtime flags are derived from where the asset lives — source under `/zero/source/…` (backed), a copy-on-write fork / runtime-generated asset under `/zero/runtime/assets/<identity>.<category>/` (runtime change) — using the canonical `<identity>.<category>/` suffix shape, generic over any category. `cpu_resident` is a live query through the `asset.cpuResident` FFI.

residencyState(ref: any) → void

Compute (backed, changed) in one pass; the two getters surface one half.

argtypedescription
refany

hasBackingAsset(ref: any) → boolean

`ref.has_backing_asset` — a source asset under `/zero/source/` backs this ref.

argtypedescription
refany

hasRuntimeChanges(ref: any) → boolean

`ref.has_runtime_changes` — a copy-on-write fork / runtime-generated copy of this asset exists under `/zero/runtime/assets/`.

argtypedescription
refany

cpuResident(ref: any) → boolean

`ref.cpu_resident` — referenced from a live script-component context, so its bytes are warmed in CPU memory (the `/runtime/assets/` layer). Live query via `asset.cpuResident`; like `asset.meta`, the FFI coerces its first arg as a string, so pass a guid / identity / path (not the handle table).

argtypedescription
refany

gpuResident(ref: any) → boolean

`ref.gpu_resident` — the device holds a texture or mesh under this asset's guid. The device pool is a different pool from the CPU one, so an asset can be in one and not the other. Live query via `asset.gpuResident`.

argtypedescription
refany

Sub-parts

Everything contained inside this part. Assets are composite children (clickable cards). Files are leaf payloads. Expand any row to view its source.

2items
Assets0Files2
This part has no composite children. See the Files segment for its leaf payloads.
backing path · modules/asset_residency.module

Problems

Everything affecting this asset right now: its own problems, anything wrong inside it, and problems on its direct dependencies.

0problems
No problems reported. This asset, its contents, and its direct deps are clean as of the latest commit.
⌬ZeroMind agent review · awaiting first pass
Findings
Reviewer findings (handle · model · tag · quoted note) appear here once the per-pass review log lands. Today only the rolled-up agent_score is exposed.
usability—
did it work as advertised
quality—
authoring polish + cohesion
performance—
frame & memory budget held
agent review score
—
/ 100
awaiting first pass
usability × 0.40
+ quality × 0.35
+ performance × 0.25
± compat factor

Usability ratings

Did the part work as advertised when consumers tried to drop it in. Separate from upvotes: those are taste; this is "did it function".

—%no reports yet
Sign in to report whether this part worked for you.
Discussion

Scoped to this part · feeds back into the world's score.

0comments
Sign in to post.sign in
No comments yet. Be the first.