[obiot]

Three generic additions that make melonJS read what Tiled shows a tile object inheriting from its tile, without changing how any existing map loads or any existing TypeScript code compiles.

A tile object is matched by its tile's class

In Tiled, a tile object with no class takes its tile's class (MapObject::effectiveClassName(): the object's own, else its template's, else its tile's). melonJS now does the same for dispatch: give the chest tile the class "Chest" in the tileset editor, and every chest placed in the map is built by registerTiledObjectClass("Chest", Chest).

To keep existing maps loading as before:

• it comes after the object's own class and its registered name, before the structural fallbacks;
• it only selects a class or factory the game registered itself: a tile classed like a structural type (shape, text, tile) or an engine built-in (Sprite, Trigger, Collectable...) stays a plain tile;
• settings.class is left as it was.

TMXTileset#getTileClass(gid) returns the class, read from type (Tiled 1.10 and older) or class (1.9).

resolvedProperty() / resolvedProperties()

Tiled shows a tile's custom properties on every object placed from it. TMXObject#resolvedProperty(name) and resolvedProperties() return the object's custom properties merged over its tile's, named after the methods that do the same in Tiled's scripting API.

The tile's properties are deliberately not set on the object by name. The built-in tile factory hands the whole object to the sprite as its settings, so a tile property called flipX or tint would have changed how existing maps draw (a test pins this: flattening them flips the sprite). The object's own properties are still set on it by name, exactly as before; they are now parsed once into a private bag first, so an eval: property is still evaluated only once.

TMXObject type

TMXObject was internal and stripped from the declarations, so every TypeScript game redeclared the settings its Tiled classes receive. It is now exported as a type and documented, with tile: Tile | undefined and gid: number | null. Declare custom properties by extending it:

interface DoorSettings extends TMXObject {
    locked?: boolean;
}
class Door extends Sprite {
    constructor(x: number, y: number, settings: DoorSettings) { ... }
}

Both registration functions are now generic over the settings, defaulting to TMXObject: an unannotated factory's settings is typed, and a class or factory annotated with its own settings type keeps compiling. A non-generic signature broke exactly that, which the type spec pins.

Docs

JSDoc on TMXObject (with an example), the new methods, getTileClass and both registration functions; the tilemaps skill gets a section on classes and properties set on tiles, the matching order, and two symptom rows.

Verification

• New tests in tmxtilemap.spec.js (18), tmxtileset.spec.js (5) and a type-level tiled-object-types.spec.ts (7, checked by tsc): both class spellings, flipped gids, precedence, built-ins left alone, resolved properties (precedence, fresh object, fields excluded, non-tile objects), a TMX file end to end, and the two backward-compatibility guards.
• Mutation testing: 18 of 19 mutations caught (dispatch removed or reordered, raw gid, built-ins allowed, class mutated, precedence flipped, the tileset's object handed out, flattening, typings reverted or made non-generic). The one missed, dropping the JSDoc type on tile, is equivalent: tsc infers the same type.
• Full suite: 8,334 passed, 10 skipped. Lint, declaration build (consumer fixture) and docs build clean; the examples' registration calls type-check unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SeWCkETjW35ZbXDRswV1hx

[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.