root
b6a609ae24
Ports that vary per node already existed, but only for the three nested-behavior
types, and the rule for them sat as a switch on type names in nested.ts – the
one place in the project that knew node types by name. It dissolves into two
optional contracts on NodeDef, so a type carries its own rule:
declaresPorts the node holds an editable list, shown as a section in the
inspector – behavior start/end, and now Pack/Expand
derivePorts the node computes them from its settings – Sequence from a
count, Run behavior from the behavior it names
Sequence gains an Outputs setting (2 to 26). Its keys stay a, b, c and count on
with d, e, so the edges of the sequences already out there survive.
A param can now take a port away, and the edge on it would stay: it draws as
nothing yet survives every save, and comes back to life if the port returns.
SetNodeParamCommand takes those edges with it, which also closes the same leak
that switching a Run behavior node's target has always had.
The port editor addresses its node by id rather than by type, so two Pack nodes
can live in one graph, and it calls the rows Fields when they are not a
behavior's signature.
57 lines
1.8 KiB
JavaScript
57 lines
1.8 KiB
JavaScript
/**
|
||
* Small factories for writing project documents by hand (the seed scripts). They produce the
|
||
* exact shape `src/core/store/serialize.ts` reads; optional fields get their defaults.
|
||
*/
|
||
|
||
/** A scene object (also a container template entry). Position defaults to the origin. */
|
||
export const sceneObject = (
|
||
id,
|
||
assetId,
|
||
{ name = '', x = 0, y = 0, z = 0, overrides = {}, parentId = '', instanceEdits, editorOffset } = {},
|
||
) => ({
|
||
id,
|
||
assetId,
|
||
name,
|
||
position: { x, y, z },
|
||
overrides,
|
||
parentId,
|
||
...(instanceEdits ? { instanceEdits } : {}),
|
||
...(editorOffset ? { editorOffset } : {}),
|
||
});
|
||
|
||
/**
|
||
* The id an object of a placed container resolves to: `<instance>~<template ids>`. A placed
|
||
* container stores nothing but itself, so this is how its content is addressed – in the editor,
|
||
* in a running game and in the check scripts alike (see `src/core/model/instance.ts`).
|
||
*/
|
||
export const instanceChild = (instanceId, ...templatePath) => `${instanceId}~${templatePath.join('/')}`;
|
||
|
||
/** A graph edge from `from.fromPort` to `to.toPort`. */
|
||
export const edge = (id, from, fromPort, to, toPort) => ({
|
||
id,
|
||
from: { node: from, port: fromPort },
|
||
to: { node: to, port: toPort },
|
||
});
|
||
|
||
/** A graph node; `params` holds settings and inline input values alike. `ports` only on the types that declare them. */
|
||
export const node = (id, type, x, y, params = {}, ports) => ({
|
||
id,
|
||
type,
|
||
x,
|
||
y,
|
||
params,
|
||
...(ports ? { ports } : {}),
|
||
});
|
||
|
||
/** A port a behavior's start or end node declares. */
|
||
export const port = (key, kind) => ({ key, kind });
|
||
|
||
/** A behavior variable declaration. `items` is the item kind of a `list`, ignored otherwise. */
|
||
export const variable = (key, kind, value, items) => ({
|
||
key,
|
||
label: key,
|
||
kind,
|
||
default: value,
|
||
...(items ? { items } : {}),
|
||
});
|