RequestPrefixesComposer (REQUEST_PREFIXES=7011) and DeletePrefixComposer
(DELETE_PREFIX=7013) are used by the client's useInventoryPrefixes but were
never registered in NitroMessages, so SendMessageComposer(new RequestPrefixesComposer())
resolved to composer id -1 ("Unknown Composer") and the packet was dropped — the
Prefixes panel never even requested its list, so the incoming registrations from
the previous commit had nothing to decode. Both headers align with the emulator
(RequestUserPrefixesEvent / DeletePrefixEvent = 7011 / 7013).
Completes the previous incoming-side fix; the prefix list + delete flow now goes
out end-to-end.
UserPrefixesEvent (7001), PrefixReceivedEvent (7002) and
ActivePrefixUpdatedEvent (7003) were defined and exported but never mapped in
NitroMessages, so the client's useInventoryPrefixes listeners could never fire:
opening the Prefixes inventory tab sends RequestUserPrefixes, the emulator
replies with UserPrefixesComposer (7001) and the client had no decoder for it
(panel stayed empty); purchase (7002) and active-prefix changes (7003) likewise
didn't update live. Only the sibling USER_NICK_ICONS (7004) was registered,
which is why this went unnoticed.
Register the three incoming headers next to USER_NICK_ICONS.
Arcturus' Habbo.connect() runs when the SSOTicket packet is handled and needs the machineId, which is set by the UniqueID packet. Sending the SSO ticket first made such servers reject the login (WS closed with "Bye") because the fingerprint hadn't arrived yet. Send UniqueID before the SSO ticket so the machineId is available when the server processes the login.
Add FurniEditorImportTextComposer (outgoing 10049) + FurniEditorImportText
ResultEvent/Parser (incoming 10049: found, name, description, classname),
register both in NitroMessages and export from the furnieditor barrels.
Lets the editor pull official names/descriptions from a server-fetched
Habbo furnidata URL.
Append optional sort field + direction to FurniEditorSearchComposer so
the server can order the full result set (not just the visible page).
Defaults id/asc keep existing callers working.
Add SessionDataManager.mergeFurnitureDataFromUrl() + FurnitureDataLoader.mergeFromUrl()
to merge a single furnidata chunk (e.g. a custom tier) into the live floor/wall maps at
runtime, returning the added entries so callers can also refresh the RoomContentLoader.
Lets newly added furniture appear without a full client reload.
tryFetchManifestPair sceglie l'estensione in base a resolveJsonMode():
json5 -> .json5, legacy -> .json, auto -> entrambi. Evita le richieste
manifest.json fallite a ogni avvio in modalita json5.
FurnitureBrandedImageVisualization now adds offsetZ to the branded layer (z-index for the MPU/billboard editor). The room background uses offsetZ as an inverse depth push (the 'play with Z to hide floor/walls' trick); its getLayerZOffset subtracted offsetZ assuming the parent did not add it, so the two cancelled out and the effect was lost. Cancel the parent's +offsetZ for the branded layer to restore the original net (base - offsetZ).
Renderer support for the in-client image position editor:
- FurnitureBrandedImageVisualization applies offsetX/Y to the branded image
layer only (offsetZ stays as z-index/depth), so the image can be moved
without shifting the furni frame
- new `scale` branding key + FURNITURE_BRANDING_SCALE: zooms the image via a
real per-sprite scale (RoomObjectSprite.scale, default 1, applied in
RoomSpriteCanvas) — NOT by writing the read-only width/height
- AssetManager loads external raster images (png/jpg/…) via a CORS <img> +
Texture.from instead of Assets.load (which didn't load cross-origin images);
branding image download failures are now surfaced instead of swallowed
After dispose() nulls out the internal _planeParser /
_backgroundSprite refs, any further updatePreviewModel call
crashed with 'this._planeParser is null'. React 19 StrictMode
in dev double-mounts effects (setup, cleanup, setup again),
which can briefly leave a consumer holding a stale reference
to a disposed previewer between the two setup runs. Bail
silently in that window instead of crashing the editor.
The first cut updated wallGeometry + RoomMapData (so the
visualization rebuilt) but NOT the FurnitureStackingHeightMap.
The stacking map is what governs whether the room treats a
tile as 'a room tile you can stack furni on' vs. 'blocked'.
Without rebuilding it, every newly-painted tile in the live
preview looks walkable but rejects furniture placement -
user reported exactly that.
Mirror the structure of onRoomHeightMapEvent: build a fresh
FurnitureStackingHeightMap from the parsed floor (height +
isRoomTile from FloorHeightMapMessageParser.TILE_BLOCKED),
default stackingBlocked=false, then setFurnitureStackingHeightMap
+ refreshTileObjectMap so the room object map picks up the
new tile set.
Adds a public method that rebuilds the active room's floor
geometry from an in-memory model string + wallHeight without
touching the server. Same pipeline as the wire-driven
onRoomModelEvent (FloorHeightMapMessageParser ->
_planeParser -> wallGeometry), but instead of going through
RoomEngine.createRoomInstance (which is a no-op on a room
that already exists) it routes the resulting RoomMapData
through the room object's ObjectRoomMapUpdateMessage channel
- the same mechanism RoomPreviewer.updateRoomPlanes uses for
its iso preview. Result: the visualization rebuilds in place
and existing furniture/avatars are preserved.
Refactor: extracted the parser->planeParser->wallGeometry-
>RoomMapData work from onRoomModelEvent into a private
_rebuildFloorGeometry(parser) helper so the wire handler and
the new public method share an implementation.
Intended use: tools that need a live in-room preview of a
floor edit before committing it server-side (e.g. the React
floor-plan editor's live-preview mode). The wire
UpdateFloorPropertiesMessageComposer remains the source of
truth - call applyFloorModelLocally only for transient
client-side preview.
Outgoing 9127-9129: send-hotel-alert (message string), get-dashboard
(no args), list-action-log (limit int).
Incoming 9206 HousekeepingDashboardEvent + 9207 ActionLogEvent with
matching parsers and data classes. Dashboard is a flat one-shot
parse — no count prefix; action log uses the standard "count + N
entries" list pattern.
Closes the HK packet surface — yarn compile:fast clean.
OutgoingHeader 9117-9120: give-credits, give-currency (generic across
duckets/diamonds/seasonal via a currencyType int), grant-item,
set-hc-subscription. All four ride the existing
HousekeepingActionResultEvent — no new parser needed.
`yarn compile:fast` clean.
* Outgoing 9110-9116: find-room-by-id, search-rooms (exact|prefix),
room-state (open|close toggle), mute-room, kick-all-from-room,
transfer-room-ownership, delete-room.
* Incoming 9202 HousekeepingRoomDetailEvent + 9203 RoomListEvent.
* HousekeepingRoomData parser data class with the 11 IHousekeepingRoom
fields. Single-room and list events share the same data class via
composition.
`yarn compile:fast` clean.
Three composers closing out the users-domain HK actions:
* OutgoingHeader 9107 HousekeepingSetUserRankComposer (userId, rankId)
* OutgoingHeader 9108 HousekeepingTradeLockUserComposer (userId, hours, reason)
* OutgoingHeader 9109 HousekeepingResetUserPasswordComposer (userId)
All three ride the existing HousekeepingActionResultEvent for the ack.
OutgoingHeader 9104 HousekeepingMuteUserComposer — (userId, reason,
minutes). 9105 HousekeepingKickUserComposer — (userId, reason). Both
ride the existing HousekeepingActionResultEvent for the ack, so no
new parser is needed.
vitest 138/138, `yarn compile:fast` clean.
HousekeepingUnbanUserComposer (OutgoingHeader 9103) carrying a single
userId int. Response side reuses HousekeepingActionResultEvent — no
new parser needed because the ack shape is action-agnostic.
`yarn compile:fast` clean.
* HousekeepingBanUserComposer (OutgoingHeader 9102): (userId,
reason, hours).
* HousekeepingActionResultEvent + Parser (IncomingHeader 9201):
generic ack carrying (actionKey, ok, actionId, message). Same
parser will back mute / kick / give-credits / room-close / etc.
callers — adding a new HK action only needs a new outgoing
composer plus the right ACTION_KEY constant on the server side.
vitest 138/138, `yarn compile:fast` clean.
OutgoingHeader.HOUSEKEEPING_FIND_USER_BY_ID = 9101 with a one-int
payload. The response side reuses HousekeepingUserDetailEvent (no new
parser) — find-by-id and find-by-name converge on the same shape
because the server has nothing different to say about a user found
via numeric id vs. via username lookup.
vitest 138/138, `yarn compile:fast` clean.
simoleo89