Problem code 'unsupported-spec' ​

Contract 2.0.0 · package sha256 a857eca95b35921109faf997094bb4192f12527d9d0fcd4be7e97f06425bad6e · generated from configurator-runtime.d.ts, tables/problems.json and services/onsite-scripter/scripts/contract-docs-what-to-do.json by services/onsite-scripter/scripts/build-contract-docs.mjs; edit the source, not this file.

A member of ProblemCode · stable · since 2.0.0

A value this runtime or device can't apply (a UV channel, sizeM without uvMetres, a shading node, a linked light past the limit, a material ref no apply() defines), or an unknown spec field from a page whose declared contract is newer than this runtime's (spec section 3.4); it was ignored. Also CameraLimits.gestures: 'cooperative' under an ancestor of el whose touch-action excludes pan-y: its touch half can't apply there (path '/camera/limits/gestures').

What to do ​

The value was ignored on this runtime or device, and message names it: drop it, or guard it with session.supports(id) or has(session, id) first. TextureSpec.sizeM needs a slot whose asset declares uvMetres (else use scale); a material ref must name a material in the look's materials (session.apply({ materials })); an unknown field from a newer declared contract needs a runtime of that contract, so leave it out.

await session.apply({ materials: { oak }, rules: [{ query: { tag: 'top' }, set: { material: { ref: 'oak' } } }] });

Where the declaration names it ​

• ApplyReport.problems: A value this runtime can't carry yet: 'unsupported-spec' with its path.
• CameraLimits.gestures: Turning it on under such an ancestor records 'unsupported-spec' (path '/camera/limits/gestures', the element in message); the wheel half applies.
• Labs.lightLinking: A link past the limit links nothing, records 'unsupported-spec' and returns a no-op unlink, so that light reaches every part: compare the limit with your light count before linking.
• Labs.shading.graph: build runs at the call; a node, input or output outside ShadingNodes' set records 'unsupported-spec' naming it, and materials wearing the graph draw their base fields.
• LightSpec: Among such items the first casts, collections in creation order and items in their spec's order; each other one lights unshadowed and records 'unsupported-spec' at its item's path, at the commit that leaves it so.
• MaterialSpec.variant: A name the mesh's model doesn't declare records 'unsupported-spec' with path 'patch.material.variant' (a find(q).set or node(id).set; 'scene.rules[i].set.material.variant' for a rule apply lists), naming the meshes and the names it declares, and the fields lay over what the mesh wears.
• ModelDescription.manifest: The server stamps no upload yet, and no backfill has run, so today every GLB answers null unless its author stamped it: then TextureSpec.sizeM records 'unsupported-spec' and checkAsset has nothing to read here.
• ShadingNodes: Any other node or input name, other standard-library ones included, records 'unsupported-spec' naming it when the graph is built, and materials wearing the graph keep their base fields.
• TextureSpec.sizeM: On a slot without uvMetres it records 'unsupported-spec' and leaves the placement as it was; a collection model item's GLB counts as one (its manifest's slots aren't read).
• TextureSpec.uv: A channel the mesh's geometry lacks, or one this device can't bind, records 'unsupported-spec' with path 'patch.material.maps.<slot>.uv' ('scene.rules[i].set.material.maps.<slot>.uv' for a rule apply lists) and the slot shows no map there; on the fake, where its FakeModel mesh entry declares uvChannels.
• testing.FakeModel.variants: The GLB's KHR_materials_variants names, as the runtime reads them from the loaded file, stamped or not: a MaterialSpec.variant this list lacks records 'unsupported-spec' at 'patch.material.variant', as on the runtime.

The set is open: handle a code you don't know ('other').

Recorded by ​

• the table row failure-matrix/errorCases/unknown-spec-field-newer-contract (tables/failure-matrix.json)