Skip to main content
Glama

scene_add_components

Destructive

Attaches platform components—collision triggers, motions, projectiles, loot, and more—to prefabs or placed entities in a copied save, enabling interaction and behavior without position polling.

Instructions

Give a prefab (and every placed copy of it) or the placed entities of one name the platform's own components, in a copy of a save. This is how interaction is done on this platform, instead of comparing positions on a timer. collisionTriggers: zones that raise whenEnteringCollisionTrigger / whenExitingCollisionTrigger in a graph attached to the same prefab or entity when a character (or object, creature) walks in or out: pickups, pressure plates, shop areas, "inside the base". The enter event comes once for each entity, at the moment it walks in: a thing that has to act again while the entity stays inside (a tower that reloads, a shop with a cooldown) asks again itself when it is ready, with f.getAllEntitiesWithinTheCollisionTrigger(self, triggerIndex) (examples/kingdom5 does this for its archery range). A zone that lies on the ground has to stand at least 0.45 m high to catch a standing character: one of 0.3 m passed under a character that stood still, eight times out of eight (the shape of a character that triggers does not reach its feet). For a thing to be jumped over make it 0.45 to 0.6 m; from 0.8 m a jump does not clear it. Areas grow with the scale of the prefab. When a hazard is meant to be dodged, check both halves in play: that it hits a player who does nothing, and that it misses one who dodges. optionTab: the native "walk up and press F" prompt with one or several options; choosing one raises whenTabIsSelected with the option id: paying, opening, talking, switching. variables: custom variables (自定义变量) with a type and a start value, the place where an entity keeps its own state; any graph reads and writes them by name, and whenCustomVariableChanges fires on the entity that holds them. motions: basic motion devices (基础运动器) that a graph starts by name with f.activateBasicMotionDevice, or that run from the moment the piece appears (active true). Either a straight move, {name, move: [x, y, z] metres, seconds} (a gate that rises, a wall that comes up; the metres are those of the world, whatever the scale of the piece; a motion can be started again after it has run, so a gate with the motions open, [0, 4, 0], and close, [0, -4, 0], opens and closes as often as a graph starts them in turn: examples/doors, seen in play 2026-10-13), or a path, {name, path: [{position relative to the piece, rotation in degrees, seconds from the point before}...], loop}: loop "backAndForth" with one waypoint and active true is the moving platform of platform games (it goes there and back for ever), "restart" with waypoints that only turn ([0,180,0] then [0,360,0]) spins a thing on the spot, "once" stops at the end. Objects only, creatures move by themselves. follow: a follow motion device (跟随运动器), "attach" to stick to a target or "chase" to fly to it, for things carried by or drawn to a player; a graph names the target. minimapMarker: an icon for the entity on the minimap, with a name and a description (the icon shows where to go without any text on screen). textBubbles: what the thing says, words over it shown a line after another to a character who comes within radius: [{lines: [{text, seconds}], above, active, loop, endEvent, radius, fontSize}]; above is how many metres over the foot of the thing it hangs (before the scale of the prefab; give it: at the foot the thing itself hides the bubble); the first shows from the start when active is true, a graph switches to another with f.switchActiveTextBubble(entity, its number from 1); the lines are said again and again unless loop is false, and endEvent: true tells the graph of the thing when the last was said (whenTextBubbleIsCompleted). nameplates: what stands over the thing, [{items: [...], above, radius, active}], an item being {text} (a label; {1:s.NAME} in it is a custom variable of the thing, {2:HpCur} and {2:HpMax} its health), {icon: id}, {bar: {current, min, max}} (a bar that follows three custom variables of the thing) or {health: true} (the health bar of the thing: {numbers: true} writes the numbers on it, {colour: red} colours it), each with size and an offset in screen units from where the nameplate hangs (a second item 40 lower: offset [0, -40]); indicator: {text, icon, min, max} adds the navigation indicator, a mark that points to the thing from wherever the character looks while the thing is between min and max metres away, with words of its own ({2:PDist} in them is the distance) and an icon: where to go next; f.setEntityActiveNameplate(entity, f.assemblyList([1n], 'config_id')) says which show. attachPoints: [{name, offset: [x, y, z]}] names places on the thing, in metres from its foot, that a bubble or a nameplate hangs on by attach: the name (above makes such a point by itself). Both are the platform's own way to label an NPC or an enemy (the player's own character too: prefab "character"); seen in play 2026-10-14 (examples/talk), and their words show on an account of 奇匠 level 2 and up. hurtBox: the areas where the piece can be hit; an object has none of its own, so a wall, a target or a crate that enemies or players should be able to attack needs one. abilityUnits: ready-made abilities the piece owns, each with a name a graph uses it by: attack {coefficient, added} hits a target for coefficient x the attack of the piece plus the added damage (a thorn bush, a trap), heal restores an amount of health (a spring); this list replaces the units the piece had. What the target loses is less than that number: the attack of an ability unit is not absolute damage (是否是绝对伤害 is off), so the defence of the target takes its share: a creature or an object of level 1 with the attributes it comes with loses 0.45 of it (measured with coefficient 0: +80 takes 36, +55 takes 24 or 25, +40 takes 18). A hit box triggered from a skill graph with absoluteDamage true takes exactly its increment. The tool cannot switch absolute damage on for an ability unit yet (no official sample has one to copy the field from): give the unit 2.2 times the damage that is wanted, or use a hit box. solid false lets characters walk through the piece (pickups). motions (straight and path), follow, minimapMarker, the attack kind of abilityUnits and a trigger for creatures were verified in play on 2026-10-10; hurtBox was verified on 2026-10-11 (examples/strike: a crate with a hurt box is hit and broken by the hit box of a sword skill, which passes through objects without one); the heal kind of abilityUnits too (f.recoverHp(character, 1500, unitName, false, source): the health on the screen went from 8492 to 9992 and whenHpIsRecovered fired on the character with 1500; the attack unit of 1 x attack + 3000 before it took 1508, less the character's defence). projectile makes the thing fly from the moment it is created (a bullet, an arrow, a thrown stone): {type: "straight", velocity: [x, y, z] metres a second in its own axes with z forward and y up, acceleration, accelerationSeconds}, {type: "parabola", velocity, gravity (9.8)} or {type: "tracking", velocity, turnDegreesPerSecond (9999: it turns at once), targetAttachPoint (the point of the target it flies at: "GI_RootNode" its feet; creatures also have "GI_ChestMark"), snapRange and snapSeconds (within that many metres it closes in on the target in that time; 1 and 1)}: an arrow or a spell that follows whoever it was shot at, so that a target that walks is still hit; a graph launches one with f.createProjectile(prefabId, position, rotation, owner, target, false, 1n, [] as bigint[]), the fifth argument being the entity a tracking one follows. hitDetection tells when it touches something: {areas, trigger: "once" or "oncePerEntity", delaySeconds: how long after it appears it starts to detect, so that it does not hit whoever shot it, abilityUnit: the name of one of this prefab's abilityUnits, launched at what it hits, layers: what counts as a touch, of hurtBox, scene and objectCollision (all three when left out; ["hurtBox"] for a bullet that should only notice things that can be hurt), factions: "hostile" for one that only notices enemies of its own faction, so that it flies past friends (give the thing its shooter's faction with f.modifyEntityFaction), continuous: {speedAbove, radius} switches on continuous detection (连续碰撞检测) above that speed, for a fast thing that would otherwise be on one side of a target in one moment and on the other in the next}; whenOnHitDetectionIsTriggered fires in a graph on the prefab. Both records are byte for byte those of the official sample 投射运动器; verified in play on 2026-10-11 (examples/shoot: a bolt shot by a skill breaks a crate with two hits; do not remove the bolt in the very moment it hits, or that hit does no damage: remove it a third of a second later). loot is what the thing leaves behind when it is destroyed: {dropPrefab: a drop prefab from scene_add_prefab {drop}, items: [{item, amount}]} (the platform's way to have a defeated creature or a broken crate drop something; verified in play on 2026-10-11 with a chest that a graph destroys: the drop appears where it stood and gives the items listed here). An area is a box {size: metres or [x,y,z], offset} or a sphere {radius, offset}, relative to the entity. Called again on the same target, each kind that is given replaces what the target had of that kind (the whole collisionTriggers list, the option tab, the motions and so on: to change the size of one trigger give the whole list again), kinds that are not given stay as they are, and variables are merged by name (one given again gets the new start value). Target: prefab (name or id, or "player" / "character" for the built-in templates, which take variables only) or entity (a placed name). Static pieces carry no components. Writes a new .gil in the workspace; the official save is not touched. launcher {areas, speed, direction}: makes the thing fling the characters that touch it (the platform's 角色扰动装置, kind 弹射器): a character entering an area gets that many metres a second of extra speed in the direction ([0, 1, 0], straight up, when left out: a bounce pad; sideways: a bumper or a gust that pushes off a ledge). The official bounce mushroom is {areas: [{radius: 1.5, offset: [0, 0.5, 0]}], speed: 7}. It works by itself, without a graph, and only on characters that walk into the area (one teleported into it is not flung). Verified in play on 2026-10-12 (examples/walls): a flat pad of speed 14 threw the player 8.6 m up, again each time it came down on it. The direction of a launcher may also be "away": the character is pushed straight away from the piece, wherever it touched it, which is what a bumper, a swinging hammer or a blast does; holdSeconds is how long the push lasts at full strength (0.25) and fadeSeconds how long it then takes to fade (0) (verified in play on 2026-10-13, examples/hazards: a big coin with speed 10 threw a player who kept walking into it back two or three metres every time). extraCollision {areas}: shapes that stop characters and creatures whatever the model looks like (the platform's 额外碰撞). On a prefab of the empty model (asset 10005018, 空模型, which shows nothing) it is a wall nobody sees: {areas: [{size: [0.5, 4, 12]}]} is a pane four metres high and twelve long, the way to keep players inside an arena or on a path without building a visible wall. Verified in play on 2026-10-13 (examples/hazards): the player stopped 0.2 m before the pane with nothing to be seen there. A blind test walled an arena this way that night: with its top 2.0 m above the ground a wall was still climbed over, with 2.4 m and more it held (3.2 m where a bale of 0.8 m stood beside it). The camera of the game does not pass through it either: when such a wall comes between the camera and the character, the camera jumps close to the character (seen with a camera that looks down from the south at a player by the south wall), so keep the walls on the side the camera looks from further out than the play needs, or let that side be open ground with a visible edge. "toward" pulls the character to the piece instead. forceField {areas, direction, speed}: the same component in its other kind (力场器), which pushes for as long as a character is inside instead of once on entering: a wind across a bridge, a current, a conveyor; innerRadius and outerRadius with innerSpeed and outerSpeed make the push differ between the core of its sphere and beyond it. A piece carries a launcher or a force field, not both. Both were read from devices configured by hand on 2026-10-13. The force field was tried in play that night (examples/hazards, second lane): walking through a field of radius 2.5 that blows sideways at 6 m/s put the player three metres off its line. "toward" pulled in the same run: on entering the area the player was carried 2.3 m towards the piece (speed 8, holdSeconds 0.3), once, like every launcher. The areas of a component grow with the scale of the prefab: on a piece of scale 2.5 an area of radius 3 reached 7.5 m, so the pull came much earlier than where the area was thought to be.

Input Schema

NameRequiredDescriptionDefault
lootNo
solidNo
entityNo
followNo
prefabNo
hurtBoxNo
mapPathNo
motionsNo
launcherNo
optionTabNo
variablesNo
forceFieldNo
nameplatesNo
outputNameNo
projectileNo
textBubblesNo
abilityUnitsNo
attachPointsNo
hitDetectionNo
minimapMarkerNo
extraCollisionNo
collisionTriggersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavior beyond the annotations: it says it writes a new .gil in the workspace and leaves the official save untouched, explains replacement and merge semantics, and documents many verified play-test caveats and failure modes. These details are fully consistent with readOnlyHint=false and destructiveHint=true; there is no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single enormous block of prose, roughly thousands of words, with many narrative asides and repeated verification dates. It front-loads the purpose, but the length and lack of structure make it far from concise and hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 22-parameter nested schema, no output schema, and destructive write behavior, the description is more than complete enough: it covers targets, replacement semantics, persistence, component behavior, and practical caveats an agent needs to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 22 nested parameters and 0% schema description coverage, the description carries the full semantic burden and largely succeeds, explaining collisionTriggers, motions, nameplates, textBubbles, projectiles, hitDetection, loot, launcher, forceField, and many others with units, examples and defaults. While a few parameters such as mapPath and outputName are not explicitly explained, the overall compensation for the schema gap is exceptional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: adding the platform's own components to a prefab or placed entity in a copy of a save. It is unambiguous about scope, though it does not explicitly distinguish itself from sibling tools such as scene_update_prefab or scene_add_prefab.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the intended usage pattern extensively, including that this is how interaction is done instead of comparing positions on a timer, that static pieces carry no components, and that calling it again replaces each supplied component kind while leaving other kinds intact. It lacks explicit when-not-to-use guidance versus sibling tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools