Frostbite in skate.

skate. stores its world in Frostbite superbundles: TOCs locate bundles, bundle manifests describe EBX documents, typed resources and chunks, and CAS archives hold their compressed bytes. EBX supplies the object graph; resources hold such data as MeshSets, textures and shader state; chunks hold bulk geometry and pixels. Observed

The scope here is the PC executable build 20260929, with separately identified ReSkate and ReSkate Studio versions. These rules are not established for other Frostbite games. Observed

A resource has several identities, used by different systems. A distinct manifest name or resource id does not prevent two meshes from colliding in the renderer’s 32-bit name-hash cache. Texture streaming instead deduplicates by a 64-bit identity, and materials resolve through 64-bit keys across loaded shader depots. Observed See resource identity.

San Vansterdam streams a hierarchy of cells and distant vista geometry. The compiler used by community maps produces a related hierarchy but differs in collision residency, placement representation and vista construction. Observed See WorldPartition and Studio compilation.

Hard capacities include texture handles, spatial cull ids and ids for each class of light. ReSkate raises some capacities and guards others; its version is therefore part of the content’s runtime requirements. Sourced · ReSkate See limits and the crash catalogue.

Pages

Archives and files

• Bundle manifests — EBX, resource and chunk records, their parallel tables and their CAS file references.
• CAS compression blocks — Physical block framing and codec selection inside skate.'s CAS archives.
• Data folders and superbundle TOCs — Install chunks, CAS locations, TOC indexes and bundle file tables in skate.
• Native DB object trees — Tagged binary trees used by layout.toc and bundle chunk metadata.

Data model

• EBX documents and reflection — RIFF chunks, object instances, typed fields and references in skate.'s EBX data.
• Resource identity and name hashes — The distinct identities used by manifests, mesh caches, texture streaming and material depots.

World and streaming

• WorldPartition, cells and vistas — San Vansterdam's streaming hierarchy, static groups, distant geometry and pause-map references.

Geometry

• MeshSets and vertex declarations — MeshSet LOD pointers, sections, geometry chunks and stored versus draw vertex layouts.

Materials

• ShaderBlockDepots and material parameters — Material-key lookup, relocatable depot containers, typed parameters and texture bindings.

Shaders

• Binding sets and input layouts — Constant-buffer and texture register mappings, vertex inputs and unresolved render-state fields.
• Measured program behaviour — Scoped G-buffer encodings, the instance and matrix tables of instanced vertex programs, and those of character hat vertex programs.
• Shader lookup tables and compiled programs — The three material tables, program decision trees, permutations and DXIL bytecode resources.

Textures

• Texture resources and mip chunks — The extended texture header, pixel formats, layered storage and streaming identity.

Lighting and sky

• Lighting, GI and time of day — Visual environments, local lights, emission, GI modes, exposure and delayed light retirement.

Terrain

• Terrain and layer graphs — San Vansterdam's native terrain layers and their distinction from mesh materials.

Vegetation

• Foliage instances and LOD tiers — Measured stock vegetation and the Studio foliage material domain.

Water

• Ocean and canal surfaces — San Van's water geometry, material sharing and physics surface identity.

Effects and decals

• Decals, vertex opacity and overlay order — Distinct decal systems, stock opacity semantics and bounds-dependent overlay ordering.

Collision and physics

• Collision, physics pools and grinds — Stock collision streaming, Studio collision grouping, surface resources and grind geometry.

Animation

• Render skeletons, animation rigs and ECLP — Character bone identities, DOF mapping and the stored keyed animation codec.

Gameplay data

• Quick Drop items — The assets that make one placeable Quick Drop object, the superbundles they live in and how added items are registered.
• Skater camera — Where the third-person camera sits relative to the skater right after spawn, how reproducible its framing is, and where its framing height is stored.

Runtime and limits

• Known crash signatures and causes — Build-specific failure addresses, triggers, causal evidence and validated data corrections.
• Runtime capacities and allocator layouts — Stock and ReSkate capacities, spatial and light allocators, memory pools and diagnostics.
• Runtime type registry — The static type records of skate.'s executable, the runtime objects built from them and the field entries, tied to the EBX reflection tables.

Mod loading

• Costume packages and registration — Native costume assets, build stamps, bundle registration, render skeleton and mesh constraints.
• Luau plugins and Throwdown modes — ReSkate 2.1.2 plugin manifests, VM lifetime, permissions, limits and mode state.
• ReSkate loading, merging and profiles — Mod discovery, shared shader-table merging, world layers, memory sizing and persistent state.
• ReSkate Studio compilation — Map inputs, generated bundles, compiler-specific representation and known content traps.
• Studio FBMOD containers — The legacy Frosty version-six intermediate emitted by ReSkate Studio.