Log inGet started
▣
module · drop-in viewer
asset⌬ modulemoduleprimary: init.luau·part ofpackage skate_physics.package·originates fromworld 3d0fe004-d…

Board

`require("skate_physics.Board").build(worldEntity, options)` authors the native physics assembly in edit mode: seven physical parts, an explicit noncolliding hook target, six joints, two truck drives and a zero-strength hook drive. There is no rider simulation, camera, input cont…

by◐Deata·posted 13d ago
What it does

Board construction

require("skate_physics.Board").build(worldEntity, options) authors the native physics assembly in edit mode: seven physical parts, an explicit noncolliding hook target, six joints, two truck drives and a zero-strength hook drive. There is no rider simulation, camera, input controller or hidden plugin world. The returned root/bodies/joints/drives/volumes are ordinary synchronized entities. Use result.deck as the moving board reference, not the organizational root.

Options: parent, name, position/rotation (relative to parent), collisionGroup, orderBase, temporary, definition, neutralPose, and visuals. Parent scale must be one. Defaults allocate a free collision group and an order range after existing World members, avoiding unintentional collision suppression between separate boards. definition() returns a fresh editable copy of the construction data. Modify it before building or edit the resulting components/transforms afterward, all inside Zero.

The construction data is generated from the preserved Rust constructors. Contact materials are explicit host defaults (0.6 friction), truck collisions default off, and World gravity/iterations remain the caller's settings. The test configuration uses 60Hz and32 iterations. Wheel drives are not part of the stock assembly.

Default visuals are ordinary Model children on the physical parts. Pass visuals=false for physics only, or a BoardVisuals binding map to use your own meshes/materials. No rider is created; avatar attachment remains separate. Saved-scene, cold-load and full multiplayer acceptance are still being verified.

Default construction uses a neutral pose derived from the native joint frames, so wheel/truck visuals are aligned before simulation starts. neutralPose=false preserves the raw native constructor poses. Supplying a custom definition also preserves its poses unless neutralPose is explicitly true. The pure definition() data is unchanged. This is spawn placement policy, not a solver alteration.

build also supports an already-owned physics World in play. Construction is synchronous and refuses an ownership/world/mode change. synced=false keeps the created assembly local; combine with temporary=true for session-only inspection. Normal construction retains the existing synchronized default.

Interface

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

conforms to

zero/source-extract/v2

definition( ) → void

validate(definition: ?) → void

argtypedescription
definition?

frame(t: ?, prefix: ?, q: ?) → void

argtypedescription
t?
prefix?
q?

rotation(columns: ?) → void

argtypedescription
columns?

build(world: ?, options: ?) → void

argtypedescription
world?
options?

spawn(name: ?, owner: ?) → void

argtypedescription
name?
owner?
⌬ Metadata
descriptionAuthor the reconstructed board as editable Zero bodies, collision volumes, joints and motors, without rider simulation.

Sub-parts

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

Showing up to 3 levels deep. Open a part to see what it holds further down.

25+items
❒
package · born here
❒asset
# Skate 3 physics engine for Zero `skate_physics` integrates a reconstructed Skate 3 physics engine into Zero. Use this package for Skate 3-style skateboard and rider physics, or use its custom rigid-body solver components independently. It exposes a reconstructed Skate 3-derived Rust solver through editable entities, components and assets: physical bodies, collision volumes, joints, constraints, motors, forces and simulation state. It is a reusable simulation system, not just a skateboarding controller or a park scene. ## Why use it? Build and tune connected physical assemblies without first writing the integration between a custom solver and Zero. Inspect velocities and forces, change mass and inertia, configure joint limits, and drive mechanisms with spring/damper or hard motors. Motors apply impulses through the solver rather than teleporting bodies. The general body/joint/drive layer does not require a rider or animation clips. The package connects physics authoring, fixed-step simulation and entity presentation. Use it to experiment with constrained bodies, motor-driven mechanisms and vehicle assemblies; the skateboard and rider are included applications of the system, not its definition. ## What it provides - `World`: authority-gated fixed-step simulation and publication of solved entity state. - `Body` and `CollisionVolume`: editable mass, inertia, forces, velocities, primitive/compound collision geometry and bounded static-mesh collision. - `Joint` and `Drive`: body references, local frames, linear/angular limits and independently configurable motors. - `API`: in-engine authoring helpers and an explicit-state solver interface. - Input and actuator components for device-driven or scripted physical assemblies. - An integrated skateboard/rider system with control maps, rig mapping, visual bindings and animation-slot overrides. - Example scenes, a modular park, an authored skateboard, and the `GettingStarted` guide. ## Where to start Read **GettingStarted** for the distinction between the general physics components and the specialized rider integration. The low-level **Demo** workbench illustrates bodies, joints and a vehicle assembly. **SampleScenes** exposes rider, vehicle-only, self-propelled, scripted-control and physics-tuning examples. The world's default **RiderFidelity** scene demonstrates the coupled rider/board system with Zero's avatar and the authored park. ## Integration boundaries Static mesh collision has documented size limits; see `Body`. The specialized native rider/board integration requires a fixed body layout; that restriction is distinct from authoring assemblies with the general body/joint/drive API. The rider demo retains converted reference animations for testing, replaceable through normal Zero assets and animation bindings. These are not required by the general motor component. The default showcase uses the authored skateboard and Zero avatar; unused reference character and board models are excluded from publication. See the component documentation for supported shapes, units and solver-specific conventions.
▲ 1↑ born
▣
module · born here
❒asset
# API.module In-engine authoring helpers for attaching World, Body and Joint, plus a direct explicit-state solver call. `attachBoneBody(target, skin, body, settings)` and `attachPoseTarget(target, world, source, body, settings)` expose the two directions of rig binding. References are assigned through normal component setters so Zero can replicate them. These are the same components the Avatar physical-rig helper assembles; users can author, inspect, or replace them individually. `attachVolume(child, settings)` adds a CollisionVolume to a direct child of a compound Body, chooses the next free order when omitted, and marks the child entity synchronized. Create the parent with `attachBody(parent, world, {shape="compound", mass=...})`, then author its volume children inside Zero. `attachBoardSteering(target, world, feedback, frontDrive, backDrive, settings)` binds the native steering component to explicit existing entities. Steering owns the two Drive frame targets while active; it creates no bodies. Its readable profile/history live inside Zero. It is not the complete ground controller. `attachNativeGround(target, world, feedback, frontDrive, backDrive, settings)` binds the native ground execution boundary. It is inactive until complete native records and entry state are supplied. It is not the unfinished live input producer.
▲ 0↑ born
◇
component · born here
❒asset
# Drive An editable Skate solver motor between Body A and Body B in the selected World. Local anchors and frame quaternions describe frames the motor tries to align. Animate either frame to drive a limb, suspension or steering assembly. The motor applies impulses through the same solver as contacts and joints; it never teleports the bodies. Linear and angular drives have independent disabled, soft and hard modes. Soft mode uses spring and damping. Hard mode uses maximum correction velocity. MaxStrength limits each solver axis; zero provides no motor force. Disabled ignores the saved tuning values, so toggling it preserves tuning without applying impulses. The reconstructed solver retains its original drive coefficient conventions. All fields synchronize through Zero. No rider or animation clip is required. Strength values retain the Rust engine's native coefficient convention. They are not a direct force in newtons or torque in newton-metres. The solver limits each row using `dt * dt * maxStrength * inverseEffectiveMass`; the latter is the reciprocal of the row's inverse-mass/inertia denominator. In particular, a small-inertia body needs a larger angular strength number to support an offset load. Check the complete connected assembly, not just a free body. A native regression uses a 2kg, radius-0.15m root supporting a fixed 10kg load 0.5m to its side. At 120Hz/64 iterations, angular hard strength 1000 saturates; 10000 holds the orientation. This is an explanatory test, not a universal humanoid tuning preset. Changing collider dimensions changes inertia as well as contacts; tune limits against the mass properties of the intended body.
▲ 0↑ born
◇
component · born here
❒asset
# World.component Authority-gated fixed-step driver; reads and publishes ordinary Zero entities. Bodies, joints and drives sort by their editable `solverOrder`, then entity ID. Existing default-zero orders retain the prior behavior. Presets can preserve native registration order across clones instead of depending on generated IDs. ## Fixed-step publication `maxSubsteps` (1..16, default8) bounds fixed steps per publication. Entered NativeGround `body_commands` updates can batch because each step derives fresh native observations from the preceding state. Entry, exit, observe and externally supplied Ground observations stay single-step. Animation/other external targets are sampled before the request and held through its batch; choose1 when a caller requires new external targets each step. New live body command values apply to the next request and do not invalidate already solved motion. Changes to body state, geometry, configuration, topology or authority still reject stale work. `receivedSeconds`/`simulatedSeconds` reset with restoreState; `droppedSeconds` and `rejectedResults` remain cumulative. `lastStepCount` names the last publication's step count. `onStep` fires once per publication, and readContacts returns the final substep's contacts.
▲ 0↑ born
▣
module · born here
❒asset
# Board visuals `attach(assembly, bindings?, options?)` attaches normal synchronized Model children to the physics bodies returned by Board.build. Defaults use original, replaceable deck/grip/truck/wheel meshes adapted from the MIT NIGHTGRIND geometry module. No rider is created and no visual drives physics. Parent transforms provide the binding, so changing a Model mesh/material or child transform requires no plugin change. Meshes/materials are ordinary saved Zero assets, not runtime-only handles. Bindings map body names to lists of `{mesh, material?, position?, rotation?, scale?, name?}`. Pass actual asset references. A supplied map replaces the complete default map; omitted bodies have no new visual. `defaults()` returns a fresh map for selective edits. `options.temporary=true` is for disposable checks. The return value lists created visual entities; ownership stays with normal Zero entities.
▲ 0↑ born
◇
component · born here
❒asset
# Joint.component Typed body references, local frames and angular/linear constraint limits. `separateLinearFrame` enables an independent parent orientation for the three linear constraint axes: `linearFrameBX/BY/BZ/BW` is a unit quaternion in body B's authored frame. The angular axes still use `frameBX/BY/BZ/BW`. When disabled, linear axes follow the angular frame, preserving existing joints. JSON callers use optional `linear_rotation_b`; omission uses `rotation_b`. Both frames are converted through the body's mass frame before solving. The reconstructed character requires this distinction for all22 skeleton joints. The private121frame reference comparison checks every consumed frame word and the full96word constraint workspace for all2662joint states. Two unused anchor padding lanes are excluded from frame-byte comparison (native signed zero there does not enter the decoder); constraint workspaces still match bit-for-bit. This verifies joint-frame representation, not complete character simulation. ## Angular modes and independent speed limits `free` permits all angular directions selected by the joint. Native swing mode 3 is exposed as `hinge`, not `free`: it retains a constrained perpendicular axis. `limited_hinge` preserves native swing mode 2. Stock board wheel joints explicitly use `hinge` and retain their original speed allowances. Angular velocity allowances are independent relative-speed limits in radians per second. Zero is a zero-speed limit, not an unlimited value. New generic joints default to 1,000,000 rad/s so an open angular limit does not accidentally act as a brake. Explicitly authored values (including zero) remain authoritative. Migration: stock-board definitions using the former `free` spelling for native mode 3 must use `hinge`. Rebuild the provided scene after changing the kernel and component together. Old generic joints with explicit zero velocity allowances must be reviewed; do not overwrite intentional speed limits automatically. ## Native rider slots A Joint beneath NativeRiderDriver.constraintsRoot may reference two rider NativeActorPart entities from the same physicsRoot. Set world to that physicsRoot and nativeRiderSlot to 0..21. readRiderJointDefinitions() on a ready driver returns the current slot, endpoints, anchors and frames for authoring. Body A is the native child and body B its parent. Preserve the separate linear frame when copying definitions. Each slot may have one override; other slots remain native. nativeRiderAngular defaults to native: mode-dependent normal/ragdoll angular settings still come from the native owner. Select authored to use this Joint's angular fields instead. nativeRiderEnabled=false suppresses that slot's rows. Deleting the override restores the native slot. These edits survive R recovery. Animation drives remain active and can resist contradictory anchor edits. Mixed board/rider endpoints are explicitly unsupported by this adapter. A copied default slot passed the full 520-frame Zero replay unchanged. A 20 mm anchor edit produced approximately 19.1 mm in the ragdoll test; native mode limits, authored angular values, disabling, reset and restoration were checked.
▲ 0↑ born
◇
component · born here
❒asset
# CollisionVolume Put this component on a direct child of a Body whose shape is `compound`. Edit the child's local position and rotation with Zero's normal transform tools. Positive uniform scale on the body and child is included in collision dimensions; nonuniform/mirrored scale is rejected. Shape fields define sphere, rounded-box core, Z-axis capsule, or triangle geometry. Triangle transforms are baked into vertices when the Body reads its state, preserving native mass conventions. Give each child a unique integer `order`. It preserves the authored accumulation order independently of entity IDs. `collisionEnabled=false` suppresses contacts but retains mass. Delete a child to remove both its geometry and mass contribution. The Body supplies material and total mass. It may have at most64 volume children. Use `API.attachVolume(child, settings)` to attach this component and automatically choose the next free order; the child's parent must already be a compound Body. All properties and transforms are ordinary synchronized Zero entity data. ## Native actor bodies CollisionVolume can also be a direct child of a NativeActorPart with role=board or role=rider. One or more volume children replace that body's native contact geometry; parts without volume children inherit their defaults. Removing the last child restores the defaults. Disabled children suppress contacts; use a disabled child when the intent is no contacts rather than inherited defaults. Child local transforms are in the body entity's centre-of-mass frame. No host files are needed. For native bodies, geometry editing does NOT recalculate mass or inertia: those remain separate NativeActorPart fields. It also does not alter the animation or wheel-probe/controller profile. Materials and controller collision gating stay native. Rider shapes retain native mode-dependent enable flags, collision groups and materials. A shape cannot enable a body the current native mode disables. The ready NativeRiderDriver:readColliderDefinitions() method reads current body-local native geometry, including disabled children, for inspection or in-engine authoring. Spheres were checked with actual Zero physical response, reset and restoration. Rounded boxes, capsules with offsets/rotation, and two triangle volumes were also checked against their calculated support height. Disabling the triangles removed their support; deleting them restored all 15 default deck children. Rider sphere authoring, disable/reset/restore and native masking have been checked. Additional rider multi-volume/self-contact scenarios remain to verify. The ready driver readRiderColliderDefinitions() method returns each rider body with its current native enabled flag, volume_group, and body-local shapes. Vehicle-only mode returns an empty rider list and rejects rider shape input.
▲ 0↑ born
◇
component · born here
❒asset
# Body.component Editable collider, mass, forces and complete velocity state on an ordinary Zero entity. For static mesh collision, select shape=mesh, enable isStatic and assign a normal Zero mesh asset to mesh. meshScale sets the positive local collision scale; entity position/rotation place it in the world. Primitive sizes remain explicit. Changes to stored mesh geometry refresh collision automatically. No CPU-resident render copy or host files are required. Use the same mesh and corresponding scale for the visual Model when matching rendered and collision geometry. Meshes currently support up to8192 vertices/4096 triangles, static only; triangle winding determines the front face. Large-terrain acceleration remains unfinished. `collisionEnabled` defaults to true. Disable it for an explicit animation/motor target or other noncolliding body. Mass, integration, joints and drives continue to work; only contact generation is disabled. This differs from collisionGroup, which suppresses pairs sharing the same nonzero group. The WASM state field is `collision_enabled`; omitted means true for existing saved states. For `shape="box"`, `halfExtents` describes the unrounded core and `rounding` adds the radius outside that core. An axis's total outer size is `2 * (halfExtents[axis] + rounding)`. The rounding radius may exceed the core's half-height (as it does for the stock deck). Core extents must be nonnegative, and every outer extent must be positive. These are the reconstructed engine's rounded-box conventions; rounding does not subtract from the entered core. For `shape="compound"`, add CollisionVolume components to direct child entities. Their local transforms and shape fields supply the ordered collision volumes; use unique integer orders. The Body's mass is the total compound mass. Changing child transforms or dimensions updates the submitted shape, and collision-disabled children retain their contribution to mass. Positive uniform body/child scales are supported. Position/rotation remain in the authored body frame while linear velocity describes its center of mass. Leave `authoredMassFrame=false` for normal compounds; true is an explicit source-specific override used by the stock deck. `maximumLinearVelocity` and `maximumAngularVelocity` pass the native speed caps through to integration. Defaults remain1000000 for existing bodies; stock board construction carries its native unbounded/ wheel-specific values. Caps must be finite and nonnegative. `solverOrder` controls registration order within the World; entity ID breaks ties. Give assembly parts distinct orders when matching a source construction sequence. The same ordering field exists on Joint and Drive. Enable `customMassProperties` to supply `inverseMass`, principal `inverseInertia`, and `rotationalEnergyCoefficient` explicitly. These replace inferred mass/inertia while retaining the selected collision geometry. All must be finite and positive; `isStatic` still suppresses inverse mass and inertia in the solver. With the switch off, existing geometry-derived behaviour remains unchanged. `massFramePosition` and `massFrameX/Y/Z/W` describe the authored body frame in center-of-mass coordinates, using a unit quaternion. Entity transforms, collision geometry and Joint/Drive anchors remain in authored coordinates; linear velocity is the center-of-mass velocity. The kernel converts input/output poses and constraint frames consistently. This supports the reconstructed skeleton's independently adjusted inertia rather than forcing it into primitive estimates. The JSON field is `mass_properties: {inverse_mass, inverse_inertia, spherical, frame_position, frame_rotation}`; omission preserves old behaviour. This is a body capability, not a completed native character preset or animation controller. Native ground probes now include static boxes with positive half-extents. Rounding uses the original query fatness path. Solid box contacts remain native primitive-pair contacts, so a box does not need a TerrainQuery component; that component is for static triangle meshes. The visible Model and collision definition are independent. This does not add probe support for degenerate rounded boxes, static spheres or capsules.
▲ 0↑ born
backing path · skate_physics.package/Board.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 on this asset or on the parts this page shows. Parts it leaves out are not counted here.
⌬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.