FriendsComposer only serialized a buddy's look when online, sending an
empty string for offline friends. The look is already loaded from the DB
for every friend in Messenger.loadFriends (SELECT users.look), so the
gate just discarded valid data: offline friends rendered with the
anonymous/standard avatar in the friend list and messenger, while their
profile (fetched separately) showed the real figure.
Always serialize row.getLook(). StaffChatBuddy keeps a non-null look
("ADM") so there is no NPE risk, and UpdateFriendComposer already sent
the look unconditionally, so this only aligns the initial friend list.
FurniEditorImportTextEvent (incoming 10049, ACC_CATALOGFURNI): resolves
the classname, fetches the admin-configured furnidata URL via HttpClient
with a TTL cache (furni.editor.import.url / .cache.ms, default habbo.it),
finds name/description by classname and returns them via
FurniEditorImportTextResultComposer (outgoing 10049). URL is DB-configured
only (no client-supplied URL -> no SSRF); serves stale cache on failure.
Read sortField/sortDir from the search packet and ORDER BY a whitelisted
items_base column (id/sprite_id/item_name/public_name/type/interaction_type)
with a stable id tie-break, so sorting orders the whole result set instead
of just the page the client received. Column names come from a fixed
whitelist (never raw input) so the dynamic ORDER BY stays injection-safe.
On a successful furnidata name update (10046), after the JSON write +
10047 broadcast, also UPDATE items_base.public_name to the new
(sanitized) name and refresh the in-memory Item cache via loadItems()
so Item.getFullName() stays consistent without a restart. Guarded by
name != null (description-only edits never blank the column), runs only
on the success path, outside FurnidataLock, with a parameterized
statement.
- resolveHabbo() falls back to a hotel-wide online lookup so a direct @nick
mention reaches the target even when they are in a different room (was
resolved only within the sender's room).
- HabboMention now carries the sender figure (live from the sender Habbo,
history from a users.look JOIN); MentionReceived/MentionsList composers
append it so the client can render the sender avatar in the notification.
- 009: add users_settings.mentions_enabled / mass_mentions_enabled columns
so :disablementions / :disablemassmentions actually persist.
Thanks to @Bop:
There's a group bug where you can accept anyone into a group within MS. There's no packet validation for accepting members if the group is invite only.
This is crucial because if you allow users to have rights who are group members, your rooms can be trashed. AKA YOUR EVENT ROOMS
The prize editor could only update existing rows; savePrize was UPDATE-only,
so the admin panel had no way to add a new slice or remove an old one.
- WheelManager.savePrize now takes a sortOrder and inserts when id <= 0
(returning the generated id) or updates + re-enables when id > 0, so a
previously removed prize can be brought back. sort_order is persisted to
match the editor's display order.
- New WheelManager.disablePrizesNotIn(keptIds) soft-deletes (enabled = 0)
any prize absent from the saved authoritative list. Non-destructive: rows
stay in the table and loadPrizes already filters enabled = 1.
- WheelAdminSavePrizesEvent collects the saved ids and disables the rest
before reloading.
No schema change (wheel_prizes already has enabled + sort_order) and no
packet change (id = 0 / omission express insert / delete on the existing
wire). Pairs with the Nitro-V3 client editor add/remove buttons.
getBubble() fell back to NORMAL (bubble 0) for any id not in the registered
BUBBLES map, so custom client-side chat bubbles (e.g. ids 253+) rendered as
the default bubble for everyone. Now unknown positive ids (<=1000) pass
through as a transient bubble carrying that id, so the server relays it and
clients render their own .bubble-<id> style. No need to enumerate each one.
The Nitro client already sends a strong machine fingerprint (Thumbmark,
"IID-<hash>") via the UniqueID packet (header 2490 -> MachineIDEvent), but
the emulator only stored it on the GameClient and never copied it onto the
Habbo's HabboInfo, so it was never written to users.machine_id. As a result
machine/super bans (which read users.machine_id) matched nobody.
- MachineIDEvent: when the fingerprint arrives and the Habbo is already
loaded, copy it onto HabboInfo and persist (run the Habbo save).
- SecureLoginEvent: if the fingerprint arrived before login, copy it onto
HabboInfo right before the login save.
This makes machine/super bans effective without changing the client.
DuckieTM