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

warmup

`asset.warmup` — a **read-only closure inspector**.

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

asset_warmup

asset.warmup — a read-only closure inspector.

Returns the transitive set of assets that the CPU-residency system would load when the given asset enters /runtime/ — i.e. the asset plus everything reachable through its declared content references. It does not itself change residency or touch bytes:

local closure = asset.warmup("@builtin::meshes.cube")
-- → the asset + every texture/material/mesh it transitively references

Residency is owned by the engine's reference-counted CPU-residency system, which acquires the closure on a /runtime/ enter (usage 0→1) and releases it on the last drop (→0), loading/unloading bytes at the per-node 0↔1 boundaries so a texture shared by two materials stays resident until BOTH are gone. This helper just lets scripts/agents inspect that closure (debugging, "what would loading X pull in?") without any side effect — it avoids asset.resolve (which fires the BlobStore prefetch) and uses the side-effect-free asset.guid / asset.deps / asset.identity.

The closure is the generic .refs graph, so this is fully type-agnostic — material/mesh/user-types all resolve the same way with zero per-type knowledge. By default it follows asset_ref / component (content) edges and skips asset_type (structural) / require (code); opts.vias overrides. Deduped by guid via an explicit work-stack so diamonds appear once and cycles terminate.

Installed onto the FFI asset namespace by the prelude.

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_warmup.module/init.luau `asset.warmup` — READ-ONLY closure inspector. Returns the transitive set of assets that the CPU-residency system WOULD load when the given asset enters `/runtime/` — i.e. the asset plus everything reachable through its declared content references. It does NOT itself change residency or touch bytes: residency is owned by the engine's reference-counted CPU-residency system, which acquires the closure on a `/runtime/` enter (usage 0→1) and releases it on the last drop (→0), loading/unloading bytes at the per-node 0↔1 boundaries so a texture shared by two materials stays resident until BOTH are gone. This helper just lets scripts/agents INSPECT that closure (debugging, "what would loading X pull in?") without any side effect — hence it avoids `asset.resolve` (which fires the BlobStore prefetch) and uses the side-effect-free `asset.guid` / `asset.deps` / `asset.identity`. The closure is the generic `.refs` graph, so this is fully type-agnostic — material/mesh/user-types all resolve the same way with zero per-type knowledge. By default it follows `asset_ref`/`component` (content) edges and skips `asset_type` (structural) / `require` (code); `opts.vias` overrides. Deduped by guid via an explicit work-stack so diamonds appear once and cycles terminate. Installed onto the FFI `asset` namespace by the prelude.

warmup(ref: any, opts: WarmupOpts?) → WarmupResult

Inspect the content closure of `ref`. Returns the visit order as identity strings and the count. No side effects.

argtypedescription
refany
optsWarmupOpts?
⌬ Types
WarmupOpts = { vias: { [string]: boolean }?, max: number? }WarmupResult = { closure: { string }, count: number }

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
This part has no composite children. See the Files segment for its leaf payloads.
backing path · modules/api/engine/asset.module/warmup.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.