Skip to main content
Glama

scene_set_creature_logic

Destructive

Configures a complex creature's behavior in a copied save by assigning its decision graph, skills, cooldowns, and enemy-detection logic so it can wander, work, flee, or fight.

Instructions

Give a complex creature its behaviour, in a copy of a save: the decision graph it runs all the time, the skills it can use and how it notices enemies. This is how a unit is made to do things on this platform (walk to a place, wander, work, flee, fight): an ordinary creature only reacts to enemies the way its asset was built to, a complex creature (an asset of the group "怪物(AI版)") does what its graphs say. prefab is a creature prefab made from a placed complex creature (scene_add_prefab {fromEntity}); every placed copy is changed too; entity names placed creatures instead. decisionGraphId is a graph made with scene_add_graph {kind:"creatureDecision"}: it looks at the situation and switches to one of several status graphs (kind "creatureStatus"), each a short list of tactics and skills with a condition on each: move to a point or to an entity, wander, stand still, pursue, flee, patrol, turn, execute a skill. These graphs read custom variables, so a server graph steers the creature by writing variables on it (where to go, what its job is, whether it is night). skills lists creature skills (scene_add_creature_skill) by name or id; they get the numbers 1, 2, ... in this order, which a status graph passes to f.executeSkill. cooldownSeconds of a skill is the wait after one use before the next, a number or [from, to] for a random wait (the editor's default is [0, 3]); firstCooldownSeconds the wait before its first use in a fight; sharedCooldownSeconds the wait every skill of the creature shares. logic is how the creature comes to fight (自主逻辑参数): noticeRadius, metres around it within which it notices an enemy whichever way it looks (范围感知; off when left out); sightDistance, how far it sees in front of it (视锥距离, 10); leaveCombatDistance, the distance to its target beyond which it gives up (脱战距离; the editor's 5 is less than its sight, so with logic it defaults to the larger of the two distances plus 6); leaveCombatDelaySeconds; territoryRadius, metres around the place it was created that it does not leave (领地, 50); chainRadius, within which its fellows join the fight (连锁入战距离). An enemy it notices becomes its aggro target (TargetEntity.AggroTarget in its graphs; f.queryIfEntityIsOnTheField tells whether there is one). Without logic the creature keeps its templates; one without any gets the template the editor makes. Writes a new .gil in the workspace; the official save is not touched. Without cooldowns and logic, byte for byte the two creatures of the official sample 复杂造物; the cooldown and logic numbers were each changed in the editor and read back on 2026-10-11.

Input Schema

NameRequiredDescriptionDefault
logicNo
entityNo
prefabNo
skillsNo
mapPathNo
outputNameNo
decisionGraphIdYes
sharedCooldownSecondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already flag destructive=true and openWorld=false, and the description adds far more: every placed copy of the prefab is changed too, a NEW .gil is written to the workspace, and the official save is untouched. It also surfaces non-obvious consequences (graph numbering of skills drives f.executeSkill indices, editor-vs-tool defaults for leaveCombatDistance and cooldown [0,3]) that no annotation or schema conveys.

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

Conciseness3/5

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

It is front-loaded correctly — the first clause says what the tool does — but the body is a single dense run-on paragraph mixing parameter semantics, domain theory about decision/status graphs, and editor defaults. The closing provenance sentence (byte-for-byte comparison against the official sample, read back on 2026-10-11) is testing evidence rather than guidance an agent can act on.

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

Completeness4/5

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

For a destructive 8-parameter mutation with nested objects and no output schema, the description covers the critical unknowns: it writes a new save file rather than mutating the official one, changes propagate to all placed copies, and unit-bearing numbers have stated defaults. It is thin on how to target a map/output and on failure modes when the prefab or graph id is invalid.

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

Parameters4/5

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

With 0% schema description coverage the description carries the full burden, and it defines most parameters well: decisionGraphId's required graph kind, prefab vs entity addressing, skill identifiers and how they become indices 1, 2, ..., and all six logic fields with units, defaults and semantics. Two parameters (mapPath, outputName) are never explained, so the coverage is strong but not complete.

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 states a specific verb and resource: it assigns behaviour to a complex creature by setting its decision graph, skill list and perception/combat logic, and it distinguishes complex creatures (group "怪物(AI版)") from ordinary asset-driven ones. That makes the tool's effect unambiguous despite the name suggesting only 'logic'. It loses a point only because the name/title mismatch (it also sets skills, prefab/entity targeting and output naming) takes a few sentences to untangle.

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 explicitly scopes applicability ('a complex creature ... does what its graphs say', prefab must come from scene_add_prefab {fromEntity}, graph must come from scene_add_graph {kind:"creatureDecision"}), which tells the agent the prerequisites. It also says what happens if logic is omitted (creature keeps its templates). It never states a negative case, e.g. what to do for ordinary creatures, so there is no true when-not-to-use rule.

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