msw-avatar

MSW Avatar (Costume · Animation)

An avatar is managed along two axes.

• Costume (appearance): MOD.Core.CostumeManagerComponent — which items are equipped (17 slots).
• Animation (motion): AvatarStateAnimationComponent + AvatarRendererComponent — which state clip is played (14 default states + custom actions).

Edit workspace files directly, then call the refresh tool of msw-maker-mcp so the editor picks up the change.

This document covers costume (file-edit based) first, then animation (script based) at the end.

Workspace path rule: maps ./map/, UI ./ui/, scripts and other assets ./RootDesk/MyDesk/, global models such as DefaultPlayer/Player ./Global/.

Where to edit, by target

Read (equivalent to get): read the file above and inspect the CostumeManagerComponent-related fields / Values entries. If Maker MCP is connected, you can use get_component as a runtime/editor snapshot helper (see the msw-maker-mcp skill).

Apply (equivalent to set): write values into the file, then call refresh.

Applying changes: MCP refresh

After saving the file you must call the refresh tool of the msw-maker-mcp server to sync Maker and its visual state. (See the tool list in the msw-maker-mcp skill.)

RUID (resource unique ID)

The string written into a costume is an avatar item RUID (typically a 32-character hex string).

• Never guess or fabricate an RUID. Look it up with the msw-search skill — for the avatar RUID workflow (default body/head, item detail, render composition) see ../msw-search/references/resource/avatar.md; for generic search see ../msw-search/references/resource/search.md; for single-item detail see ../msw-search/references/resource/detail.md.
• The script API SetEquip(MapleAvatarItemCategory, itemRUID) and the value stored in the editor/model are the same RUID string.
• Custom*Equip slots only accept a plain Guid. Any prefixed form — including thumbnail://<ruid> — is silently rejected and the slot is left unequipped (no error, no warning). RUIDs returned by msw-search are already plain Guids; do not prepend a scheme. See the msw-sprite-ruid skill for the broader thumbnail / icon rule.

CostumeManagerComponent overview

Attached to entities that use an avatar (player, NPC, etc.). Equipment slots are exposed as 17 string properties named Custom*Equip, and from scripts you access them via GetEquip / SetEquip with the MapleAvatarItemCategory enum.

Other synced properties

17 slots ↔ property ↔ MapleAvatarItemCategory

The 17 equipment string fields of CostumeManagerComponent map to the engine enum MapleAvatarItemCategory as follows. (Enum definition: see Environment/NativeScripts/Enum/MapleAvatarItemCategory.d.mlua.)

Enum values without a direct 17-field counterpart

Mutual exclusion / slot occupancy rules (must understand)

1. Longcoat ↔ Coat + Pants
   Longcoat is designed to occupy both the Coat and Pants slots. When equipping a longcoat, put the longcoat RUID in CustomLongcoatEquip and resolve the combination with coat/pants logically — normally when a longcoat is in use, leave coat/pants empty or avoid conflicting visuals.

2. Two-handed weapon ↔ One-handed weapon + sub-weapon
   TwoHandedWeapon uses both the one-handed weapon slot and the sub-weapon slot. When using a two-handed weapon, center on CustomTwoHandedWeaponEquip and make sure values are not also set for one-handed/sub-weapon — avoid double equipping.

3. Shield ↔ Sub-weapon
   Shield uses the sub-weapon slot. Do not expect another sub-weapon to coexist with CustomSubWeaponEquip.

4. Empty string = unequip
   Just like SetEquip(category, "") in script, leaving the field as "" in a file means the slot is unequipped.

DefaultPlayer.model — putting costume into Values

Add or modify an entry in the ContentProto.Json.Values array of ./Global/DefaultPlayer.model.

• TargetType: "MOD.Core.CostumeManagerComponent"
• Name: a property name from the table above (e.g. CustomCapEquip, UseCustomEquipOnly)
• ValueType: follow the same pattern as other Values entries already in DefaultPlayer.model. Strings use System.String, mscorlib, ..., booleans use System.Boolean, mscorlib, ...
• Value: the RUID string or true / false

If the same (TargetType, Name) already exists, update that entry only; otherwise append a new object to the array.

String slot example (structure only; replace the RUID via search)

{
  "TargetType": "MOD.Core.CostumeManagerComponent",
  "Name": "CustomCapEquip",
  "ValueType": {
    "$type": 

UseCustomEquipOnly example

Map entities — edit in the .map file

Open the entity record of the target map under ./map/.

1. Find the target entity (by name/path/id) in the ContentProto.Entities array.
2. In jsonString["@components"], find the object with "@type": "MOD.Core.CostumeManagerComponent".
3. Edit Custom*Equip, UseCustomEquipOnly, DefaultEquipUserId, etc. on that object directly.
4. Confirm that MOD.Core.CostumeManagerComponent is also listed in the componentNames string list, and that this list is consistent with the components array.

If the map uses binary-only format, the editing tool may differ depending on workspace policy. When the file opens as JSON text, follow the structure above.

Mapping GET /v3/avatars results to slots

Map the category field of an item returned by GET /v3/avatars to a Custom*Equip property. For the search method, see the msw-search skill → references/resource/avatar.md.

Avatar resource search reference

• msw-search skill → references/resource/avatar.md: details on GET /v3/avatars (costume search), default body/head, GET /v3/avatars/{ruid}, render composition, etc.
• Combine the category search and detail API to collect equipment RUIDs.

Avatar tint / alpha (visual recoloring)

For color and transparency effects (hit flash, ghost fade, palette swap, etc.) on any entity that has AvatarRendererComponent attached — DefaultPlayer, avatar-bearing NPCs, monsters — use the renderer's own methods. SpriteRendererComponent.Color and FlipX are a silent no-op on an avatar entity (the avatar renderer paints over the sprite renderer's output even though isvalid(spriteRenderer) returns true).

For avatar facing/flip, use the facing API on MovementComponent (e.g. MoveDirection) instead of writing the sprite-level flip — same silent-no-op reason.

Avatar animation — overall structure

Avatar animation flows through a 3-layer pipeline. Working on only one layer leads to the other layers overwriting your changes and producing unintended motions.

Key distinctions:

Common confusion: "attack" is not a State. The State is the uppercase ATTACK, the mapping Value is the lowercase attack (= MapleAvatarBodyActionState.Attack), and that Value is then resolved into a sprite action ID such as swingO1 / shoot1 depending on the weapon. From script, the call that triggers the state is StateComponent:ChangeState("ATTACK") (UPPERCASE string) — "Attack" or "attack" silently misses (no error, the state simply does not change).

AvatarStateAnimationComponent — state ↔ motion mapping

MOD.Core.AvatarStateAnimationComponent holds both systems.

StateToAvatarBodyActionSheet default mapping (the 11 default keys when IsLegacy=false)

Note that State keys are uppercase while AvatarBodyActionStateName values are lowercase.

Default resolution table: MapleAvatarBodyActionState → actual action ID

An AvatarBodyActionStateName string ("attack", "stand", etc.) is cast to the enum MapleAvatarBodyActionState, and the engine then resolves it into the following defaults, synthesizing an ActionStateChangedEvent.

When a weapon is equipped, Attack is automatically replaced with the sprite action ID matching the weapon type (see the next table). Holding a one-handed sword produces a sword swing; holding a bow produces a bow shot.

Per-weapon attack resolution — candidate sprite action IDs

When ATTACK is triggered, the engine looks at the equipped weapon (MapleAvatarItemCategory) and plays one of the following action IDs.

Even within the same class, the set of action IDs used may differ per item metadata. The table above lists the representative candidates used by the SDK guide (_ActionNameLogic).

PlayerControllerComponent and auto state addition

When MOD.Core.PlayerControllerComponent is attached to a player entity, the following States are added automatically to StateComponent and transition automatically on key input:

MOVE, CLIMB, LADDER, CROUCH, JUMP, FALL, ATTACK, ATTACK_WAIT, SIT

So when a DefaultPlayer presses Ctrl, the ATTACK state activates automatically and the mapped attack body motion (= the per-weapon sword/bow/staff swing) plays automatically — even with no extra scripting, the sword still swings.

Auto playback ↔ manual ActionStateChangedEvent collision (★ common pitfall)

Symptom: Even after sending a custom action like shoot1 via ActionStateChangedEvent from script, the sword swing (or the weapon's default attack) still plays, or your custom action shows for a single frame and is immediately overwritten.

Cause: While ATTACK is active, AvatarStateAnimationComponent continuously re-sends the mapped attack body motion. Your single-shot event is immediately overwritten.

Resolution strategies

Strategy A example — turn off sword swing, replace with bow shot

RemoveActionSheet / SetActionSheet must be called on the server for the change to sync, because StateToAvatarBodyActionSheet is a @Sync property.

Strategy D example — equip a bow via CostumeManagerComponent

If you add a bow RUID to Values in ./Global/DefaultPlayer.model, the engine will automatically pick the shoot1 motion during ATTACK without changing the mapping.

14 states vs custom actions — which do you trigger yourself?

The 14 body motions already known to AvatarStateAnimationComponent / MapleAvatarBodyActionState and arbitrary sprite action IDs outside that set (e.g. swingO2, shoot1, dance, cast1) go through different paths.

The 14 body motions the engine handles automatically (= members of MapleAvatarBodyActionState)

These are the names usable as the Value of StateToAvatarBodyActionSheet/ActionSheet. Once you map a State to one of these, it plays automatically.

Anything else — play directly via ActionStateChangedEvent

For arbitrary sprite action IDs outside the 14 enum members (e.g. shoot1, swingO2, cast1, throw1, dance, cheer), use the following procedure.

Playback pipeline

1. From the entity's AvatarRendererComponent, call GetBodyEntity() to obtain the body entity of the avatar. Animation events go to the body entity, not the avatar root.
2. Create an ActionStateChangedEvent and fill its fields.
3. Send it to the body entity via body:SendEvent(event).
4. Animation only needs to be seen by each client, so this is typically scoped to @ExecSpace("Client"). Game logic (damage, projectile spawn, etc.) belongs on the ServerOnly side.

Main fields of ActionStateChangedEvent (constructor: ActionStateChangedEvent(coreActionName, partsActionName, playRate=1, playType=Loop, startFrameIndex=0, endFrameIndex=2147483647))

SpriteAnimClipPlayType:

BodyActionStateChangeEvent — high-level event for the 14 built-in states

Directly specifies a MapleAvatarBodyActionState enum value. You don't have to memorize per-weapon action IDs, and you can force-restart the same state via needResetAction=true.

Unlike ActionStateChangedEvent, SendEvent targets the avatar root entity (self.Entity), not the body entity.

Choosing between them

• Arbitrary sprite action ID (shoot1, swingO2, dance, etc.) → ActionStateChangedEvent (send to body entity)
• One of the 14 enum states (Stand/Walk/Attack/...) → BodyActionStateChangeEvent (send to root entity)

Example — playing the arrow-firing (shoot) animation

A typical pattern: on the server, the attack input spawns a projectile; on the client, the shoot1 action plays.

Decision flow

1. Is the motion you want to play one of the 14 built-in states (stand, walk, attack, hit, crouch, fall, rope, ladder, dead, sit, heal, alert, fly, blink)?
   • YES → Just assign the clip in the matching slot of AvatarStateAnimationComponent. No script needed.
   • NO → continue below.
2. For custom actions (e.g. shoot1, cast1, dance), create an ActionStateChangedEvent and SendEvent it to the body entity returned by AvatarRendererComponent:GetBodyEntity().
3. Split execution spaces: input handling and damage resolution on the server (ServerOnly), animation playback on the client (Client).

Common mistakes

• Confusing the State key with AvatarBodyActionStateName (=the enum). State keys are uppercase (ATTACK); mapping Values are lowercase (attack). If you swap Key/Value in StateToAvatarBodyActionSheet, the mapping silently fails.
• Sending only ActionStateChangedEvent without disabling auto playback. When Ctrl is pressed the ATTACK state activates automatically, and the mapped attack body motion immediately overwrites your event. To use a custom attack motion you must clean up the mapping with RemoveActionSheet("ATTACK") or SetActionSheet("ATTACK", "<desired motion>").
• Wrong SendEvent target for ActionStateChangedEvent: it must be the body entity returned by AvatarRendererComponent:GetBodyEntity(). Sending it to self.Entity (the avatar root) or to a component does not play. (Conversely, BodyActionStateChangeEvent goes to the root entity.)
• Writing AvatarBodyActionSelectorComponent.ActionState directly on a DefaultPlayer-shaped entity (running PlayerControllerComponent + StateComponent + AvatarStateAnimationComponent). The controller re-evaluates ground/move/input each tick and calls ChangeState on transitions; the resulting StateChangeEvent → BodyActionStateChangeEvent repaints the selector, silently dropping your write. Use StateComponent:ChangeState("UPPERCASE_KEY") instead. Direct selector writes only stick on NPCs/monsters without that controller stack.
• Trying to put arbitrary state names into AvatarStateAnimationComponent. Values outside the 14 enum members (MapleAvatarBodyActionState) — e.g. shoot, cast, dance — are ignored. Custom IDs must go through ActionStateChangedEvent.
• Forgetting PartsActionName. If you set only CoreActionName, the sub-parts (weapon, hat, cape, etc.) won't be resolved, so you can end up with the upper body moving while the weapon stays frozen. Use the same value as CoreActionName.
• Leaving PlayType unset. The default is Loop, which causes one-shot actions to repeat forever. For one-shot actions, set SpriteAnimClipPlayType.Onetime explicitly.
• Calling RemoveActionSheet/SetActionSheet on the client. StateToAvatarBodyActionSheet is a @Sync property — these must be called on the server to reach all clients.
• Forgetting to separate server/client execution spaces. Game logic (damage, projectiles) = ServerOnly; animation playback = Client. Mixing them in one place leads to duplicated playback per client or missing visuals.
• Expecting a bow motion without equipping a bow. Firing shoot1 puts the body in the bow pose, but if no bow RUID is set in CustomTwoHandedWeaponEquip, no bow is drawn in the hand. For a natural visual, set the motion and the weapon together.

Related skills

Summary checklist

Costume

1. Obtain the RUID via the resource search / avatar reference docs.
2. DefaultPlayer / Player → Values in ./Global/*.model (or the base model definition).
3. Map entities → @components of the target entity inside ./map/*.map.
4. Respect the Longcoat / two-handed weapon / shield ↔ sub-weapon exclusion rules.
5. Decide whether to ignore the user's account default costume via UseCustomEquipOnly.
6. After saving, call msw-maker-mcp → refresh.

Animation

7. Distinguish State keys (uppercase) from body motion names (lowercase). Form: StateToAvatarBodyActionSheet["ATTACK"] = AvatarBodyActionElement("attack", 1.33).
8. If the desired motion is among the 14 enum body motions (stand·walk·attack·hit·crouch·fall·rope·ladder·dead·sit·heal·alert·fly·blink), just define the mapping — done.
9. For other action IDs (shoot1, swingT3, dance, etc.), create an ActionStateChangedEvent and SendEvent it to the result of AvatarRendererComponent:GetBodyEntity(). To restart a state inside the enum, use BodyActionStateChangeEvent + the root entity.
10. Fill all four fields — CoreActionName / PartsActionName / PlayRate / PlayType — and use SpriteAnimClipPlayType.Onetime for one-shot actions.
11. Check for conflicts with auto state transitions. On entities that have PlayerControllerComponent, MOVE/ATTACK/JUMP/... fire automatically on input — to use a custom attack, clean up the conflicting key with RemoveActionSheet or SetActionSheet (call on the server).
12. Split game logic into @ExecSpace("ServerOnly") and animation playback into @ExecSpace("Client").
13. If your goal is only to change the weapon variant of the attack motion, the simplest path is to swap the weapon-slot RUID of CostumeManagerComponent (Strategy D).