PluginBench
Skill
Pass
Audit score 90

msw-defaultplayer

msw-git/msw-ai-coding-plugins-official

Manage DefaultPlayer character model, components, movement, physics, HP, and camera settings.

What is msw-defaultplayer?

MSW DefaultPlayer skill provides tools to inspect and modify the player character model in MapleStory Worlds Maker. Use the msw-general ModelBuilder to configure movement speed, jump force, HP, camera tracking, gravity, and add/remove player components across different map modes.

  • Inspect and patch DefaultPlayer.model and Player.model files
  • Configure movement speed, jump force, gravity, and walk acceleration
  • Manage player HP, death/revive, and respawn settings
  • Adjust camera tracking (dead zone, soft zone, damping, offset)
  • Add or remove player components (native and script-based)
  • Set per-map-mode movement components (RectTile, SideViewRectTile)

How to install msw-defaultplayer

npx skills add https://github.com/msw-git/msw-ai-coding-plugins-official --skill msw-defaultplayer
Prerequisites
  • msw-general skill installed (for ModelBuilder access)
  • MapleStory Worlds Maker workspace set up
  • Access to ./Global/Player.model and ./Global/DefaultPlayer.model files
Claude Code
Cursor
Windsurf
Cline

How to use msw-defaultplayer

  1. 1.Use ModelBuilder.read() to load DefaultPlayer.model or Player.model
  2. 2.Call .value() to change property values (speed, jumpForce, gravity, camera settings)
  3. 3.Use .component() to add new components or .removeComponent() to remove them
  4. 4.Call .snapshot() on Player.model to view the base component list
  5. 5.Apply changes through ModelBuilder and save the model files
  6. 6.Test in-game to verify movement, camera, and physics behavior

Use cases

Good for
  • Adjust player movement speed and jump height for game balance
  • Set up camera tracking behavior to follow the player smoothly
  • Configure player HP and respawn mechanics for different game modes
  • Add custom script components like PlayerHit or PlayerAttack logic
  • Tune physics properties (gravity, acceleration) for different map styles
Who it's for
  • Game designers tuning player mechanics and camera behavior
  • Developers implementing custom player logic and components
  • Level designers configuring player settings per map or game mode
  • Gameplay programmers adjusting physics and movement parameters

msw-defaultplayer FAQ

What's the difference between Player.model and DefaultPlayer.model?

Player.model is the base model defining all default components and property links. DefaultPlayer.model inherits from Player and overrides specific values. Both are in ./Global/.

How do I change player movement speed?

Use ModelBuilder.read('./Global/DefaultPlayer.model').value('speed', <number>) to set the InputSpeed property on MovementComponent.

Where do I add custom player logic like attacks or hit handling?

Add script components to DefaultPlayer.model (e.g., script.PlayerHit, script.PlayerAttack). Custom scripts are created under ./RootDesk/MyDesk/.

Can I configure different movement for different map types?

Yes. DefaultPlayer supports per-map-mode movement components: KinematicbodyComponent for RectTile maps and SideviewbodyComponent for SideViewRectTile maps.

How do I adjust camera tracking?

Modify camera properties via ModelBuilder: cameraDeadZone, cameraSoftZone, cameraDamping, cameraScreen, cameraOffset, and cameraDutch control camera behavior.

Full instructions (SKILL.md)

Source of truth, from msw-git/msw-ai-coding-plugins-official.


name: msw-defaultplayer description: "MSW DefaultPlayer (character) management. Use the msw-general ModelBuilder to inspect/patch DefaultPlayer.model and Player.model, add/remove components, configure movement speed / jump force / HP / camera, and per-map-mode movement components. Use for DefaultPlayer model, player components, movement speed, jump force, HP, camera, physics. Keywords: player, DefaultPlayer, speed, jump, HP, camera, gravity, revive, respawn, character."

MSW DefaultPlayer

Use the msw-general ModelBuilder to inspect/patch the DefaultPlayer model file, manage components, and configure movement / physics / HP / camera.

For costume / avatar equipment, see the msw-avatar skill. Costumes apply not only to DefaultPlayer but to any entity, so they live in a separate skill.


DefaultPlayer overview

What is DefaultPlayer?

The player character model provided by default in the MapleStory Worlds Maker workspace.

  • When any user enters a world, a player entity is created based on this model.
  • The model ID to use is specified by the PlayerUri property of DefaultUserEnterLeaveLogic.

File location and structure

DefaultPlayer is made up of two .model files:

FilePathRole
Player.model./Global/Player.modelBase model. Defines the Components list and Properties links
DefaultPlayer.model./Global/DefaultPlayer.modelInherits Player (BaseModelId: "player"). Overrides Values

Important: both files are located in ./Global/. Custom script files are created under ./RootDesk/MyDesk/.

DefaultPlayer is patched through ModelBuilder

DefaultPlayer is managed through the sibling msw-general/scripts/model/msw_model_builder.cjs, not raw JSON edits.

  • Change a property value: ModelBuilder.read("./Global/DefaultPlayer.model").value(...)
  • Add/remove a component: component() / removeComponent()
  • Check the base component list: ModelBuilder.snapshot("./Global/Player.model")

File structure detail

Player.model (base)

Path: ./Global/Player.model
EntryKey: model://player
  • Components: the full list of default components on the player (MOD.Core.* native components)
  • Properties: model property → component property link definitions (properties editable from the inspector)
  • Values: empty (defaults are provided by the engine)

DefaultPlayer.model (override)

Path: ./Global/DefaultPlayer.model
EntryKey: model://defaultplayer
BaseModelId: "player"
  • Components: only the components added on DefaultPlayer (e.g. script.PlayerHit, script.PlayerAttack)
  • Values: the array of overridden setting values

DefaultPlayer default component list

Native components inherited from Player.model:

ComponentRole
TransformComponentPosition, rotation, scale
MovementComponentMovement speed and jump force control
RigidbodyComponentPhysics (gravity, footholds), MapleStory-style movement
KinematicbodyComponentUp/down/left/right movement on a RectTileMap
SideviewbodyComponentSide-scrolling movement on a SideViewRectTileMap
StateComponentState machine (Walk, Jump, Dead, etc.)
AvatarRendererComponentAvatar rendering, color, emotion
AvatarStateAnimationComponentState → avatar animation mapping
CostumeManagerComponentEquipment / costume management → see the msw-avatar skill for details
CameraComponentCamera tracking settings
PlayerControllerComponentInput-to-action mapping, condition handling
PlayerComponentHP, death/revive, PVP, map travel
ChatBalloonComponentChat balloon
NameTagComponentName tag
DamageSkinSettingComponentDamage skin
DamageSkinSpawnerComponentDamage skin spawn
HitEffectSpawnerComponentHit effect spawn
TriggerComponentCollision detection
InventoryComponentInventory

Script components added in DefaultPlayer.model:

ComponentRole
script.PlayerHitPlayer hit-handling logic
script.PlayerAttackPlayer attack logic

Quick reference — key components

ComponentRoleKey properties / methods
PlayerComponentHP, death/revive, PVP, map travelHp, MaxHp, PVPMode, RespawnDuration, RespawnPosition, UserId, IsDead(), ProcessDead(), ProcessRevive(), MoveToMapPosition()
PlayerControllerComponentInput → action mapping, conditional controlSetActionKey(key, actionName), ActionAttack(), ActionJump(), LookDirectionX
MovementComponentHigh-level movement speed / jump interfaceInputSpeed (default 1.0), JumpForce (default 1), Jump(), Stop()
RigidbodyComponentMaple side-view physics (gravity / footholds)Gravity, WalkAcceleration, WalkSpeed, AddForce(), IsOnGround()
KinematicbodyComponentTop-view up/down/left/right movement on RectTile(RectTile map-mode only)
SideviewbodyComponentSide-view on SideViewRectTile(SideViewRectTile map-mode only)
AvatarRendererComponentAvatar rendering / color / emotionSetColor(), SetAlpha(), PlayEmotion(), PlayRate
StateComponentState machine (Walk/Jump/Dead)CurrentStateName, ChangeState(), DeadEvent/ReviveEvent
NameTagComponentName tagName, FontSize, FontColor, NameTagRUID
ChatBalloonComponentChat balloonMessage, ChatModeEnabled, ShowDuration
CameraComponentCamera trackingDeadZone, SoftZone, Damping, ScreenOffset
TriggerComponentCollision detectionBoxSize, Offset, CollisionGroup

DefaultPlayer Values structure

Format of each entry in the Values array of DefaultPlayer.model:

{
  "TargetType": "<component name> or null",
  "Name": "<property name>",
  "ValueType": {
    "$type": "MODNativeType",
    "type": "<type info>"
  },
  "Value": <value>
}

TargetType rules

  • null: a model property defined in Player.model's Properties (linked through Properties to the actual component property)
  • "MOD.Core.<ComponentName>": directly override a property on a specific native component
  • "script.<ScriptName>": a property of a custom script component

Model properties (TargetType: null)

Mapped to actual component properties through the links defined in Player.model's Properties.

Model property nameSource component.propertyDescriptionDefault
speedMovementComponent.InputSpeedMovement speed1.0
jumpForceMovementComponent.JumpForceJump height1.0
walkAccelerationRigidbodyComponent.WalkAccelerationAcceleration / deceleration1.0
gravityRigidbodyComponent.GravityGravity1.0
cameraDeadZoneCameraComponent.DeadZoneCamera dead zone{x: 0.052, y: 0.08}
cameraSoftZoneCameraComponent.SoftZoneCamera soft zone{x: 0.268, y: 0.7}
cameraDampingCameraComponent.DampingCamera smooth-follow{x: 2.5, y: 3.9}
cameraScreenCameraComponent.ScreenOffsetDead-zone center point{x: 0.5, y: 0.655}
cameraDutchCameraComponent.DutchAngleCamera rotation0.0
cameraOffsetCameraComponent.CameraOffsetCamera position offset{x: 0.0, y: 0.0}
messageChatBalloonComponent.MessageChat balloon message""
chatModeEnabledChatBalloonComponent.ChatModeEnabledWhether chat is processed (e.g. balloon shown)true
nameTagNameTagComponent.NameName tag""
damageSkinIdDamageSkinSettingComponent.DamageSkinIdDamage skin typeDataRef
damageDelayPerAttackDamageSkinSettingComponent.DelayPerAttackDamage delay0.05
triggerBodyBoxSizeTriggerComponent.BoxSizeCollision detection area size{x: 0.66, y: 0.7}
triggerBodyBoxOffsetTriggerComponent.BoxOffsetCollision detection area offset{x: 0.0, y: 0.35}
triggerBodyColliderOffsetTriggerComponent.ColliderOffsetCollider offset{x: 0.0, y: 0.35}
maxHpPlayerComponent.MaxHpMax HP1000

Direct component override (TargetType: specific component)

Values that directly override a component property rather than going through a model-property link:

TargetTypeNameDescriptionDefault
MOD.Core.CameraComponentZoomRatioMaxCamera max zoom ratio500.0
MOD.Core.MovementComponentJumpForceJump force (direct override)1.0
MOD.Core.MovementComponentInputSpeedMovement speed (direct override)1.0
script.PlayerHitCollisionGroupHit collision groupCollisionGroup ID
script.PlayerHitBoxSizeHit collision area size{x: 0.45, y: 0.7}
script.PlayerHitColliderOffsetHit collision offset{x: 0.0, y: 0.35}

Movement components per map mode

See msw-general/references/platform.md §4 for the TileMapMode↔Body mapping table. Depending on the map mode, one of RigidbodyComponent / KinematicbodyComponent / SideviewbodyComponent is active.


Identifying a player (for script reference)

  • entity.PlayerComponent ~= nil → whether the entity is a player
  • _UserService.LocalPlayer → my player entity (client-only)
  • _UserService:GetUserEntityByUserId(userId) → player entity for a specific user

Player entity runtime structure (root vs children)

A spawned player is not a single flat entity. At runtime the engine builds a small hierarchy under the player root, and avatar action selectors live on grandchild entities — not on the root. This affects how you look up components and how you trigger avatar poses.

Component → entity mapping

ComponentWhere it livesLookup
PlayerComponentRootplayer:GetComponent("PlayerComponent") (or player.PlayerComponent)
StateComponentRootplayer:GetComponent("StateComponent")
MovementComponentRootplayer:GetComponent("MovementComponent")
AvatarRendererComponentRootplayer.AvatarRendererComponent
AvatarStateAnimationComponentRootplayer:GetComponent("AvatarStateAnimationComponent")
PlayerControllerComponentRootplayer.PlayerControllerComponent
AvatarBodyActionSelectorComponentBody grandchild of root (under the avatar root)not reachable via player:GetComponent(...) — see below
AvatarFaceActionSelectorComponentFace grandchild of rootnot reachable via player:GetComponent(...) — see below

player:GetComponent("AvatarBodyActionSelectorComponent") returns nil and the LSP does not warn (the signature is Component, not nilable). The failure is only visible at runtime.

How to reach the selectors

-- ClientOnly context (recommended — the direct API)
local body  = self.Entity.AvatarRendererComponent:GetBodyEntity()
local face  = self.Entity.AvatarRendererComponent:GetFaceEntity()
local bodySelector = body and body:GetComponent("AvatarBodyActionSelectorComponent")
local faceSelector = face and face:GetComponent("AvatarFaceActionSelectorComponent")

-- Server or "either side" context (GetBodyEntity / GetFaceEntity are ClientOnly)
local bodySelector = self.Entity:GetFirstChildComponentByTypeName(
    "AvatarBodyActionSelectorComponent", true)

AvatarRendererComponent:GetBodyEntity() and GetFaceEntity() are declared @ExecSpace("ClientOnly") — calling them from a server-side method returns nil. Use GetFirstChildComponentByTypeName(name, recursive=true) as the cross-side fallback.


Triggering avatar poses — use StateComponent, never write the selector directly

A live player has a state machine running every tick: PlayerControllerComponent evaluates input/movement → StateComponent transitions (IDLE / MOVE / etc.) → AvatarStateAnimationComponent.ReceiveStateChangeEvent translates that into BodyActionStateChangeEvent → the selector's ActionState is rewritten.

This means writing AvatarBodyActionSelectorComponent.ActionState directly is a silent overwrite: the value applies for one frame, then the next state-machine tick maps the current StateComponent state back onto the selector and your write is gone. Logs print ActionState=Attack immediately after the assignment, but in play mode the pose flickers for one frame and disappears.

Correct entry point

local state = self.Entity:GetComponent("StateComponent")
state:ChangeState("ATTACK")   -- ActionSheet keys are UPPERCASE

State keys come from the player's ActionSheet. The DefaultPlayer ships with 11 UPPERCASE keys, each mapped to a default animation:

StateComponent:ChangeState(...) keyDefault animation
"IDLE"stand
"MOVE"walk
"ATTACK"attack
"HIT"hit
"CROUCH"crouch
"FALL"fall
"JUMP"fall
"CLIMB"rope
"LADDER"ladder
"DEAD"dead
"SIT"sit

The state machine auto-returns to IDLE once the action finishes — no manual restore timer needed.

Casing pitfall: the string key passed to ChangeState is UPPERCASE ("ATTACK"). The enum value written to selector.ActionState directly (NPC path — see below) is MapleAvatarBodyActionState.AttackPascalCase, separate API surface, same underlying state. Wrong casing on the string side ("attack" / "Attack") misses the ActionSheet mapping silently — no warning.

When can you write the selector directly?

Only on entities without a running PlayerControllerComponent + StateComponent + AvatarStateAnimationComponent stack — e.g. NPCs / monsters that use the avatar renderer for visuals but have no input controller driving a state machine. On those, selector.ActionState = MapleAvatarBodyActionState.<Pose> sticks. On DefaultPlayer-shaped entities, route through StateComponent:ChangeState(...) instead.

Key services at a glance (for script reference)

ServiceRoleKey API
_UserServiceUser management, enter/leaveLocalPlayer, UserEntities, GetUserEntityByUserId(), UserEnterEvent/UserLeaveEvent
_TeleportServiceTeleport / map travelTeleportToEntity(), TeleportToMapPosition(), WarpUserToWorldAsync()
_CameraServiceCamera controlSwitchCameraTo(), ZoomTo(), ZoomReset()
DefaultUserEnterLeaveLogicUser enter/leave logicPlayerUri (player model ID), StartPoint (starting map)

How to modify DefaultPlayer

Changing property values (Values)

Load ./Global/DefaultPlayer.model with ModelBuilder.read(), then update values with value().

Example: set movement speed to 2.0

const { ModelBuilder } = require("../msw-general/scripts/model/msw_model_builder.cjs");

const b = ModelBuilder.read("./Global/DefaultPlayer.model");

b.value(null, "speed", 2.0, "float")
  .value("MovementComponent", "InputSpeed", 2.0, "float")
  .write("./Global/DefaultPlayer.model");

Note: both the model property (TargetType: null, Name: "speed") and the direct component override (TargetType: "MOD.Core.MovementComponent", Name: "InputSpeed") can exist. Set both consistently through value().

Example: jump force 1.5 + HP 2000

const b = ModelBuilder.read("./Global/DefaultPlayer.model");

b.value(null, "jumpForce", 1.5, "float")
  .value("MovementComponent", "JumpForce", 1.5, "float")
  .value(null, "maxHp", 2000, "int")
  .write("./Global/DefaultPlayer.model");

Adding a new Values entry

Use ModelBuilder.value(targetType, name, value, typeKey). The builder generates the ValueType descriptor; do not hand-write type strings.

Common typeKey values: bool, int, float, double, string, vector2, vector3, data_ref, collision_group.

Adding a component

Use component() on ./Global/DefaultPlayer.model.

Adding a custom script component:

const b = ModelBuilder.read("./Global/DefaultPlayer.model");

b.component("script.MyCustomComponent")
  .write("./Global/DefaultPlayer.model");

Custom scripts (.mlua) must be created under ./RootDesk/MyDesk/. Write the script first, Maker refresh, then add "script.<ScriptName>" with the builder.

Adding a native component (e.g. SpriteRendererComponent):

const b = ModelBuilder.read("./Global/DefaultPlayer.model");

b.component("SpriteRendererComponent")
  .write("./Global/DefaultPlayer.model");

Removing a component

Use removeComponent() on DefaultPlayer.model. Related Values entries are removed by the builder.

Caution: components inherited from Player.model (the base) are not in DefaultPlayer.model's Components. Removing base components requires patching Player.model through ModelBuilder, and is generally not recommended.


Pitfalls (Common Pitfalls)

Common pitfalls when adding to Components and changing Values in DefaultPlayer.model.

Component list pitfalls

#PitfallSymptomResolution
C1A script.XXX you added disappears or doesn't applyA script component that isn't registered in the matching .codeblock metadata in the same directory is silently dropped at load time; if saved in that state, it's lost permanentlyAfter writing the .mlua, use Maker Refresh so the .codeblock is auto-generated. Or attach at runtime right after spawn via entity:AddComponent("Name")
C2Duplicate-adding a native component already on Player.model (e.g. MOD.Core.MovementComponent)Only a duplicate-component warning is emitted, not blocked → workspace warnings accumulate, behavior becomes non-deterministicCheck the base component list (§65-89) before adding. If it's already there, just change settings via Values
C3Removing script.PlayerHit / script.PlayerAttackThese are the only extra scripts DefaultPlayer ships with. Removing them eliminates hit immunity / attack logicIf the goal is to disable, toggle the logic inside the script, or use Enable=false in Values
C4Disabling AvatarRendererComponent and adding SpriteRendererComponent (or other renderer swap)If Avatar and Sprite renderers are active at the same time, you get z-fighting / costumes not appliedOnly add Sprite after disabling Avatar (see the pattern at §395)
C5Custom damage path only decrements an HP property (or only broadcasts a damage-skin event) — the engine hit/death pipeline never firesThe avatar state machine reacts to StateChangeEvent, not to property writes. Damage numbers / particles render fine but the avatar stays idle through hit / dead / revive — silent visual miss with no error logFirst choice: route damage through HitComponent:OnHit(attacker, damage, isCrit, attackInfo, hitCount). script.PlayerHit then handles the hit / death / respawn transitions automatically. When you must drive damage manually (channeled / aura / scripted): pair StateComponent:ChangeState("HIT") for the hit pose with PlayerComponent:ProcessDead() / ProcessRevive() for the death and revive cycle. Don't only edit HP — the avatar won't react.
C6Setting SpriteRendererComponent.Color / FlipX on an entity where AvatarRendererComponent is active (e.g. DefaultPlayer)The component is present and GetComponent returns non-nil, but the sprite output is hidden behind the avatar renderer's own pipeline — color/flip writes are silently no-op. The same pattern works on plain sprite-rendered entities, so first-try copy-paste fails without any warningUse AvatarRendererComponent:SetColor(r, g, b, a) (0–1 floats) for tint and :SetAlpha(a) for fade. Both are ClientOnly. For facing, drive the character through MovementComponent.MoveDirection (or the facing API of your game logic) instead of sprite.FlipX

Values change pitfall — only jumpForce / speed need extra care

Most Values entries are in the TargetType=null (alias) form and can be set through ModelBuilder.value(null, ...). Only the two fields below are exceptions — both an alias and a native entry (TargetType="MOD.Core.MovementComponent") exist at the same time:

Fieldalias entrynative entry
Jump forcejumpForce (TargetType=null)JumpForce (TargetType="MOD.Core.MovementComponent")
Movement speedspeed (TargetType=null)InputSpeed (TargetType="MOD.Core.MovementComponent")

On entity spawn, Values are applied in array order and both write to the same native field; the native entry appears later in the array, so the native value wins.

  • Wrong: editing only the alias side (jumpForce / speed) → overwritten by the later native entry and ignored
  • Right: edit both consistently to the same value, or edit only the native side (JumpForce / InputSpeed)

Other alias-only entries (walkAcceleration, gravity, camera-related except cameraDeadZone, nameTag, damageSkinId, damageDelayPerAttack, triggerBody*, maxHp, etc.) can be modified through the alias as-is.


Hiding DefaultPlayer

DefaultPlayer's components are inherited from the base model, so they cannot be deleted. Disabling them via Enable=false is the only option.

Component keep/disable classification

ComponentFully hideHide avatar onlyNotes
TransformComponentkeepkeepRequired
PlayerComponentkeepkeepRequired — disabling causes enter failures
StateComponentkeepkeepDisabling causes other components to error
MovementComponentkeepkeepKeep when movement is needed
CameraComponentkeepkeepKeep when camera is needed
AvatarRendererComponentdisabledisableKey — disabling this alone hides it
AvatarStateAnimationComponentdisabledisable
CostumeManagerComponentdisabledisable
PlayerControllerComponentdisablekeepDepends on whether movement should be blocked
ChatBalloonComponentdisabledisable
NameTagComponentdisabledisable
DamageSkinSettingComponentdisabledisable
DamageSkinSpawnerComponentdisabledisable
HitComponentdisabledisable
HitEffectSpawnerComponentdisabledisable
TriggerComponentdisabledisable
InventoryComponentdisabledisable
RigidbodyComponentdisablekeep per map modeWhen on a MapleTile map
SideviewbodyComponentdisablekeep per map modeWhen on a SideViewRectTile map
KinematicbodyComponentEnableShadow=falseEnableShadow=falseRemoves the shadow only

Builder edit — add Enable=false to Values

Set the component values through ModelBuilder.value(). For components that don't yet have an Enable entry, the builder adds one.

const { ModelBuilder } = require("../msw-general/scripts/model/msw_model_builder.cjs");

const b = ModelBuilder.read("./Global/DefaultPlayer.model");

b.enable("AvatarRendererComponent", false)
  .value("KinematicbodyComponent", "EnableShadow", false, "bool")
  .write("./Global/DefaultPlayer.model");

After saving, Maker Refresh is required.


DefaultPlayer component extension patterns

  • Non-avatar player: disable AvatarRendererComponent → add SpriteRendererComponent → set SpriteRUID.
  • Collision setup: tweak ColliderType and CollisionGroup in TriggerComponent's Values.
  • SpawnLocation: place a Special → SpawnLocation in the map (.map) file (revive position).

Workflows

Modifying basic player properties (movement speed, jump force, HP, etc.)

1. Load ./Global/DefaultPlayer.model with ModelBuilder.read()
2. Update values with value(targetType, name, value, typeKey)
3. If both the model property (TargetType: null) and the direct component override exist, set both consistently
4. write("./Global/DefaultPlayer.model")

Adding a custom script to the player

1. Write a new .mlua script under ./RootDesk/MyDesk/ (see the msw-scripting skill)
2. Maker refresh so the script type is registered
3. Load ./Global/DefaultPlayer.model with ModelBuilder.read()
4. Add "script.<ScriptName>" with component()
5. If needed, add default property values for the script with value()
6. write("./Global/DefaultPlayer.model")
7. Request Maker Refresh

Changing camera settings

1. Load ./Global/DefaultPlayer.model with ModelBuilder.read()
2. Set cameraDeadZone, cameraSoftZone, cameraDamping, cameraScreen, cameraDutch, cameraOffset with value()
3. write("./Global/DefaultPlayer.model")

Boundaries and caveats

In scope

  • Inspect/patch the DefaultPlayer/Player model files through ModelBuilder
  • Add/remove components through component() / removeComponent()
  • Movement / physics / HP / camera settings through value()

Out of scope

  • Costume / avatar equipment → msw-avatar skill
  • UI editor → .ui files under ./ui/ (dedicated skill)
  • Map editing → .map files under ./map/ (dedicated skill, including NPC/monster spawn)
  • General scripts / resources → each dedicated skill

Constraints

  1. Careful with Global/: DefaultPlayer.model and Player.model live in ./Global/. This folder is reserved for engine default templates, so creating new files here is not recommended.
  2. Custom script location: new script files must be created under ./RootDesk/MyDesk/.
  3. Map mode caveat: the active movement component differs depending on the map mode (MapleTile/RectTile/SideViewRectTile).
  4. ValueType correctness: when adding a Values entry, use ModelBuilder.value() with an explicit typeKey; do not hand-write ValueType.
  5. Maker Refresh: after adding/modifying scripts, Maker Refresh is required (.codeblock is auto-generated).