skills: align physics, UI and pooling with the source; fix the platformer's dead z

[obiot]

Checked the platformer example against the skills, taking the engine source as the authority. Three skill gaps, one correction to a claim I made earlier, and one real defect in the example.

Correction to a claim in #1665

A commit in that PR claimed melonjs-performance's pool.pull("me.Tween") named something that was never registered, and rewrote the line to state that registered names carry no me. prefix.

Both claims are false. legacy_pool.js:87-97:

this.objectClass[className] = entry;
if (!className.startsWith("me.")) {
    this.objectClass["me." + className] = entry;   // same entry
}

Every pool.register aliases its name under an me. prefix pointing at the same entry — in the pool and in the Tiled object factory. That is why a map authored against melonJS 1.x still resolves its classes, and why the platformer's pool.register("me.Trigger", …) correctly matches its map object of that name. Both spellings work; the unprefixed one is canonical. The skill now says so, and says not to "correct" an me.-prefixed name.

setMaxVelocity / setFriction were in no skill

maxVel is what turns body.force into a speed, and the movement section already showed this.body.force.x = this.body.maxVel.x — with nothing on how maxVel gets set. Both setters are current (no @deprecated), and both take an optional third argument for the depth axis, left unchanged when omitted.

UISpriteElement handlers were undocumented

The skill's description promises UISpriteElement/UITextButton; its body never named the handlers. Now documents onClick / onRelease / onOver / onOut / onHold, that a false return stops propagation, and that the pointer only reaches an element whose isKinematic is false — which UIBaseElement and UISpriteElement clear themselves (uibaseelement.ts:86, uispriteelement.ts:95).

The example demonstrated the opposite of the ui skill

this.z = Number.POSITIVE_INFINITY on the HUD container and the virtual joypad, commented "make sure our object is always draw first". Renderable has no z property — the accessor is depth, an alias for pos.z — so both assignments created an expando nothing read, and the containers were ordered by the world's autoDepth. It looked right by accident. Both now take their order from an explicit addChild(child, HUD_Z) in play.ts.

Verified in Chrome: HUD controls and minimap render over the level, no page errors.

Deliberately not propagated from the example

The platformer is legacy in two further places the skills already get right, so the skills were left alone:

• its platform/slope handling uses response.overlapV / response.overlap, which the physics skill correctly marks deprecated in favour of depth / normal
• game.world / game.viewport, where the migration skill already documents parentApp and the Application parameter

🤖 Generated with Claude Code

https://claude.ai/code/session_01NGvtaUNATVCVxD2qcbiY4t

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.