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.
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.
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.
TS counterparts to Arcturus' new HK packet pair. Adds
HousekeepingFindUserByNameComposer (OutgoingHeader 9100) and
HousekeepingUserDetailEvent (IncomingHeader 9200) with a parser that
wraps an optional HousekeepingUserDetailData. The data class follows
the flat optional-trailing-field pattern (isMuted / isTradeLocked
read under bytesAvailable guards) so the renderer stays compatible
with a server that hasn't surfaced those manager APIs offline yet.
The parser exposes `found: boolean` and `user: HousekeepingUserDetailData | null`
so a callsite that gets a "user not found" reply can branch without
having to read into an unpopulated data object — the composer writes
`appendBoolean(false)` and stops, the parser sees the false and leaves
`user` null.
Headers 9100..9199 / 9200..9299 reserved for the rest of the HK
packet surface. Composer + event registered in NitroMessages alongside
the existing YouTube-room overrides. `yarn compile:fast` clean, vitest
138/138 green.
- add ClickUserMessageComposer and outgoing header wiring\n- send the user click packet from RoomObjectEventHandler for avatar single clicks\n- support wf_trg_click_user in the linked Nitro UI/emulator flow
- add ClickUserMessageComposer and outgoing header wiring\n- send the user click packet from RoomObjectEventHandler for avatar single clicks\n- support wf_trg_click_user in the linked Nitro UI/emulator flow
simoleo89