Skip to main content
Glama

scene_add_skill

Destructive

Define instant or normal character skills in a save copy by linking key-triggered client graphs to server-side actions, animations, effects, and hit boxes.

Instructions

Define a skill (技能) in a copy of a save: the platform's way for a player to act beyond walking and the "press F" prompt. A key press runs the skill's client graph, which tells the server, and a server graph on the character does the work. Two types are made. "instant" (瞬发技能, the default): no animation, the graph runs the moment the key is pressed. "normal" (普通技能): the character plays one animation (animation = its id: 1001 one-handed sword attack, 1006 raking the ground, 1023 watering, 1025 reaching out a hand; these are the ones the official samples use) and the graph runs at the start of it or graphAtMs milliseconds in (a sword swing that hits when the blade comes down); animationPortion is the number the editor stores for the clip (1 in most samples; the three tools of the farming sample have 0.167, 0.96 and 0.25); effect shows an effect asset at an attach point of the character for some milliseconds of the animation (the official attack skills show the sword 10002152 at "GI_WeaponR" for 1833 ms). The long-press, combo and aiming types, cooldowns and use counts are not made. To make the skill hit things, its client graph triggers a hit box, f.triggerSectorHitboxAtSpecificLocation(...) at the character's own place and rotation: read_knowledge {id:"example-strike"} has the call with the values of the official attack (a sector 3 m long, 50 damage, once per target); it damages creatures, and objects that have a hurtBox (scene_add_components). graphId is a client skill graph made first with scene_add_graph {kind: "characterSkill"}; its source is g.characterSkill({id, name, prefix:false}).on('start',(evt,f)=>{f.notifyServerNodeGraph('word','','');}) (a client graph cannot create or change things). A server graph hands the skill to a character at run time, f.addCharacterSkill(character, skillId, CharacterSkillSlot.Skill1E, TopOfStackSkillDestructionType.Destroy): slots are NormalAttack (the attack button), Skill1E, Skill2Q, Skill3R, Skill4T and CustomSkillSlot1 to 15; f.deleteCharacterSkillBySlot takes it away. A server graph on the character template (scene_add_graph attachToPrefab "character") hears whenSkillNodeIsCalled with evt.callerEntity and evt.parameter1 to 3. The records written are byte for byte those of the official samples: the instant skill 放下工具 and the normal skill 耙子-开垦 of 耕种-采集流程, and the timed attack with a sword of 命中与受击. Writes a new .gil in the workspace; the official save is not touched. Verified in play: the instant type on 2026-10-10 (given on the E key, pressed, heard by the character graph); the normal type on 2026-10-11 (examples/skills: the three animations play, the sword shows in the hand, each graph reaches the server; the sword attack carries the character 0.65 m forward and the raking 0.55 m). A skill has no cooldown of its own here; a graph gives it one: when the skill has been used (whenSkillNodeIsCalled on the character's graph), f.setCharacterSkillCd(character, CharacterSkillSlot.Skill1E, seconds, false) makes the slot wait that long, and a press during the wait is refused (verified in play on 2026-10-12, examples/skills/skills_cd_test.json; with the last argument true nothing happens, because the skill has no longest cooldown to be held to). Slots on a PC: Skill1E the E key, Skill2Q Q, Skill3R R, Skill4T the Z key (not T).

Input Schema

NameRequiredDescriptionDefault
nameYes
typeNoinstant
effectNo
graphIdYes
mapPathNo
animationNo
graphAtMsNo
outputNameNo
animationPortionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With annotations marking this as destructive and non-read-only, the description adds critical context: it writes a new .gil in the workspace and does not touch the official save. It also discloses client/server graph behavior, slot assignment, animation behavior, effect display, and cooldown mechanics with verified examples.

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?

The purpose is front-loaded, but the description is a very long single block dense with sample names, exact dates, slot key mappings, and verification details. Much of it is useful for a complex tool, but it exceeds what is needed for concise selection and invocation.

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?

For a complex 9-parameter mutation tool with no output schema, the description covers the creation flow, graph requirements, hit-box integration, server-side skill assignment, cooldown behavior, and output artifact. An agent has enough information to call it correctly and understand its side effects.

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?

Schema description coverage is 0%, so the description must carry parameter meaning; it explains type, graphId, animation, graphAtMs, animationPortion, and the nested effect fields with concrete examples. It leaves mapPath, outputName, and name semantics largely unexplained, so it does not fully compensate for the coverage gap.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Define a skill (技能) in a copy of a save.' It also scopes the tool to player/character skills, distinguishing it conceptually from creature-skill siblings even though it does not name them directly.

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 two supported skill types and explicitly excludes long-press, combo, aiming, cooldowns, and use counts. It also states the prerequisite that graphId must be a client skill graph made first with scene_add_graph. It does not explicitly name when to use this versus scene_add_creature_skill or scene_list_skills.

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