Shockless Documentation

Console Commands

Index

Backtick Console Command Reference

The backtick console opens with ` `` unless focus is already inside a text

input. Commands are parsed by the shared command bus first, then renderer-only

game commands run when direct webview/runtime access is required.

Target Prefixes

Prefix any routed command with a target:

  • @1, @2, @3: route to one client id.
  • @main: route to the configured main/summoner client.
  • @all: route to all known clients.
  • @visible: route to visible clients.
  • @headless: route to hidden/headless clients.
  • @Label: route to a client label.

Examples:


@2 say hello from client two
@all room
@headless fps
@headless gpu
@main mimic status

Session Commands

Implemented in the main-process command bus:

  • help or ?: show short in-console help.
  • list, clients, sessions: list client id, label, status, mode, user,

and profile.

  • select <id|label>: select a client.
  • client <id|label>: alias for select.
  • rename <id> <label>: rename a session label.
  • main <id|label>: set the main/summoner client.
  • summoner <id|label> or summoner set <id|label>: set the

main/summoner client.

  • newclient [--label <name>]: start a new visible client from the selected

ready profile, select it, and leave it at the game login flow for manual

login. Alias: addclient.

  • enterroom <flat-id>: ask targeted clients to enter a private room through

the Shockless enterPrivateRoom helper. Aliases: private, goto, flat.

  • start: start the selected client through the same profile/relay/static

server path as the UI Start button. Alias: launch.

  • @2 start, @all start: start a specific client or all known clients.
  • close <id|label>: stop one client.
  • stop <id|label>: alias for close.
  • close all [--keep-main]: stop all clients, optionally preserving main.
  • load <file> <count> [--headless] [--summon] [--concurrency <n>]: start

clients from the local two-line account file shape. Headless load defaults to

bounded concurrency so multiple accounts do not start one-by-one or all spike

the machine at once.

  • login <email:password> [--headless] [--label <name>]: start one client

from a credential pair kept in memory only.

  • accounts import <file> --key-env <ENV_NAME>: import the local two-line

account file into the encrypted app-data account store. The encryption key is

read from the named environment variable so the key is not typed into console

history.

  • accounts list --key-env <ENV_NAME>: decrypt the account store and list

labels only, never emails or passwords.

  • accounts load <count> --key-env <ENV_NAME> [--headless] [--summon] [--concurrency <n>]:

load clients from the encrypted app-data account store through the same

runtime path as load.

  • load-store <count> --key-env <ENV_NAME> [--headless] [--summon] [--concurrency <n>]:

short form for accounts load.

  • accounts clear: remove the encrypted app-data account store.

The account file shape is:


Habbo name
loginemail:password

Credentials are not hardcoded into source or command docs. login echo output

is redacted; load and encrypted account commands print labels/status only.

The top session strip and Multi Account session list both select the active

client. Running visible sessions mount their GameHost webviews automatically,

then only the selected client is shown and interactive. Switching away hides

the inactive stage surface instead of unmounting it, so switching back keeps

the same logged-in game runtime. The + button in the top session strip runs

newclient, creating a switchable manual-login visible client when a ready

profile is selected. The Multi Account list also has per-session close buttons

for additional clients, backed by close <id>.

Quick Start: Two Users

Use this when you want the visible main client plus two extra headless users.

If you are using the local test account file directly:


load "C:\Shockless\accounts.txt" 2 --headless --concurrency 2
wait 8000
list

If you want to use the encrypted app-data store instead, set an environment

variable before launching Shockless, then run:


accounts import "C:\Shockless\accounts.txt" --key-env HABBPY_V4_ACCOUNT_STORE_KEY
accounts list --key-env HABBPY_V4_ACCOUNT_STORE_KEY
accounts load 2 --headless --key-env HABBPY_V4_ACCOUNT_STORE_KEY --concurrency 2
wait 8000
list

After loading two accounts, list should show client2 and client3 as

headless,running. You can target them by id:


@2 say hello from client two
@3 requests
@2 message dek "sorry this is just a test message"
@3 adduser dek

To switch the selected client for plugin panels:


select 2
select 3
select 1

To inspect packet logs:


packets all
packets client 2
packets client 3
packets selected

Summon

Summon is implemented for live sessions through source-backed routes:

  • Visible private-room entry: if a main private room id is known and the target

is a visible client, Shockless returns a renderer action and the renderer asks

that visible Shockless webview to enter the private room directly. This

avoids treating a server-accepted FOLLOW_FRIEND [262] packet as success

when Origins later rejects the follow.

  • Hidden friend-follow first: if the target hidden client's parsed friend list

contains the main user, Shockless sends the mapped v3 FOLLOW_FRIEND [262]

packet through that target client's relay.

  • Hidden private-room entry fallback: if a main private room id is known, Shockless

asks the target hidden Shockless runtime to enter that private room through

Navigator Component.prepareRoomEntry(flatId, #private).

  • v3 visit fallback: if a hidden target reaches room metadata but does not

become room-ready, Shockless sends the v3 private-room packet sequence through

that target client's relay:

GETFLATINFO [21], GETINTERST [182], ROOM_DIRECTORY [2],

TRYFLAT [57], and GOTOFLAT [59].

Commands:

  • summon <id|label|all|headless>: summon matching clients to the configured

main/summoner client.

  • summon <id|label> --room: skip friend-follow and use direct private-room

entry when a main private room id is available.

  • summon <id|label> --main-name <name> --main-room-id <flat-id>: explicit

context for scripts or non-renderer automation.

  • load <file> <count> --headless --summon: summon newly loaded clients to an

already configured main room context.

  • accounts load <count> --headless --summon --key-env <ENV_NAME>: encrypted

store version of the same flow.

If your visible main client is already logged into a private room, the renderer

adds --main-name, --main-room-id, and --main-room-name automatically.

For account load and login commands it also adds every known active visible

username as --active-name, so the loader can skip already-active visible

accounts instead of starting a duplicate session. Account labels with

parenthetical notes, for example dek (main test account), are matched

against the live username dek generically.

Visible target clients do not have hidden-runtime webContents. For direct-room

summon, the command bus returns a renderer action and the renderer runs the

private-room entry helper against that visible client's mounted webview without

switching the selected stage. For summon this is fire-and-return after routing

the room-entry helper, so the console does not wait for a full room-ready state.

Hidden clients still use the hidden runtime helper.

If the main account is one of the accounts you are loading, use a two-step

flow because the main does not exist until the load completes:


accounts import "C:\Shockless\accounts.txt" --key-env HABBPY_V4_ACCOUNT_STORE_KEY
accounts load 3 --headless --key-env HABBPY_V4_ACCOUNT_STORE_KEY --concurrency 2
wait 20000
main "dek (main test account)"
summon shockless
summon shockless1 --room
list

To close the extra users:


close 2
close 3

or:


close all --keep-main

Multi-Client Mimic

Implemented through decoded relay logs plus scoped relay control packets:

  • mimic status: show enabled state, source client, target clients, counters,

and last error.

  • mimic on [--source <id>]: enable mimic from the main client or explicit

source.

  • @2 mimic on: enable mimic using client 2 as the source.
  • mimic source <id>: change source client and start from new relay-log tail.
  • mimic set movement on|off: toggle movement forwarding.
  • mimic set speech on|off: toggle chat/shout/whisper/typing forwarding.
  • mimic set actions on|off: toggle wave/dance/carry/sign/look forwarding.
  • mimic set rooms on|off: toggle private-room join forwarding.
  • mimic off: disable mimic.

Mimic forwards only whitelisted outgoing client packet families such as avatar

movement, Origins avatar movement (ORIGINS_MOVE [1269]), chat/shout/whisper,

dance, wave, carry, sign, look, figure/motto-style updates, swim, and typing

state. It refuses sensitive login, key exchange, and unique-id packets even if

an old v3 fallback header overlaps.

Packet Log Commands

Implemented in the renderer console and Packet Log module:

  • packets: show current packet filter status.
  • packets all or packets clients: show packet rows from all clients.
  • packets selected: filter to the selected client.
  • packets client <id>: filter to one client id.
  • packets c <id>: short form for packets client <id>.
  • packets <text>: text-search packet rows without truncating body output.
  • filter <...>: alias for packets <...>.

Packet rows include client ids/labels so all-client views remain

distinguishable.

Validated packet injection uses the same builder and relay path as the

Injection plugin:

  • inject server <packet>: send a client-to-server Shockwave packet.
  • inject client <packet>: deliver a synthetic server-to-client Shockwave

packet to the selected client runtime.

  • sendpacket ... and rawpacket ...: aliases for inject.
  • Prefix the command with @<client-id> or @all to select its target

sessions. The packet expression is preserved in full, including whitespace,

byte escapes, and line breaks.

Examples:


inject server {h:94}
@2 inject client {h:48}{s:"example"}
@all sendpacket server @^

Injection is validated before relay delivery. Unknown numeric headers remain

usable, while malformed packets and sensitive authentication/key headers are

refused.

Room And Runtime Commands

Renderer/runtime-backed commands:

  • room: print selected room facts from runtime and packet state.
  • user: print current user/session facts.
  • rooms <query>: search room/navigation data where available.
  • hotelView or showHotelView: leave the current room and show hotel view.
  • navigator [view], nav [view], or openNavigator [view]: open the

Navigator. The default view is nav_pr.

  • public <name|node|unit|port>: enter a public room from loaded Navigator

data. Aliases are enterPublic, enterPublicRoom, and publicRoom.

  • inventory or hand: open/request the hand inventory.
  • hideBulletin or hideBulletinBoard: close the current bulletin/window

prompt when the source UI exposes a close control.

  • windowClick <window-id> <element-id>: click a known source window element

through the runtime helper. Aliases are clickWindow and

clickWindowElement.

  • zoom 1|2, stageZoom 1|2, or roomZoom 1|2: set the room-stage render

scale to 100% or 200%. The bottom toolbar is not scaled by this command.

  • lookup <name>: show local runtime rows, decoded packet rows, social rows,

private-message context, and Origins public API data.

  • showNames true|false: enable or disable engine-rendered username labels

above room avatars. This updates the same persistent app preference used by

Settings. Height and label colors are configured in Settings.

  • hideFurni true|false: hide/show room furniture in the selected visible

runtime. showFurni is an alias for hideFurni false.

  • hideUsers true|false: hide/show room avatars in the selected visible

runtime. showUsers is an alias for hideUsers false.

  • hideUi true|false: hide/show source UI windows in the selected visible

runtime. showUi is an alias for hideUi false.

  • fx <preset> or sceneFilter <preset>: apply a Pixi scene effect to the

selected visible runtime. Use fx list to print available presets and

fx none to clear the effect. Current presets are greyscale,

blackwhite, sepia, negative, technicolor, polaroid,

kodachrome, browni, nightvision, vintage, predator, lsd,

matrix, noise, scanlines, and crt. Aliases include grayscale,

gray, grey, bw, and scanline. fx matrix applies the dedicated

Razer-green Matrix grade with the animated CRT-style scanline overlay.

  • walk <x> <y> [furni-id]: send source-mapped ORIGINS_MOVE [1269]

through the targeted client's relay using the live VL64 integer triple.

  • say <message> or chat <message>: send room chat for the target session

where the target has a running hidden runtime; visible fallback uses the

renderer path.

  • input [client-id] <message>: chat alias for headless/hidden clients.
  • wave: send the v3-equivalent WAVE [94] packet for the target session.
  • dance [1-4]: send the v3-equivalent DANCE [93] packet.
  • stopdance: stop dancing through DANCE [93] value 0.
  • hcdance [number]: send the HC dance variant through the same v3-equivalent

dance packet path.

  • carrydrink or carry: send the v3-equivalent CARRYDRINK [80] packet.
  • fps [limit]: show or update frame-rate limit where supported.
  • perf: print performance/runtime stats.
  • gpu: show GPU/runtime capability status. Hidden/headless targets report

WebGL availability plus renderer/vendor facts through the main-process

command bus; the selected visible client uses the renderer console fallback.

Hardware acceleration is enabled by default when Electron starts. Dev Tools

can disable it for the next app restart if the user needs a fallback.

Social Commands

Implemented with scoped v3-equivalent Social relay packets when an account id

or parsed row is available:

  • message <user|account-id> <message>: send a private messenger line.
  • adduser <name>: send a friend request.
  • requests: refresh/display friend requests.
  • accept <request-name|account-id>: accept a friend request.
  • decline <request-name|account-id>: decline a friend request.
  • follow <friend-name|account-id>: follow a friend.
  • removefriend <friend-name|account-id>: remove a friend.

These commands can use target prefixes, for example:


@2 message dek "sorry this is just a test message"
@3 adduser dek
@all requests

Utility Commands

Implemented:

  • clear: clear console output.
  • wait <ms> or sleep <ms>: pause command-script execution, clamped to

120000 ms.

  • history [count]: show persisted redacted command history. Direct

login <email:password> entries are stored as login [credentials] ....

  • alias: list aliases.
  • alias <name> <expansion>: persist a command alias. Aliases expand before

normal command parsing, so target prefixes and quoted args still work.

  • unalias <name>: remove an alias.
  • bind <key> <command>: persist an app-scoped key binding, for example

bind F1 "mimic status" or bind Ctrl+F1 "select 1".

  • bindings: list key bindings.
  • unbind <key>: remove a key binding.
  • exec <script-file>: read a local UTF-8 script file and execute each

non-empty, non-comment line through the same command bus.

  • exec <script-file> --dry-run: parse the script, simulate aliases inside

the script, validate targets, and print the redacted command plan without

executing commands or mutating stored aliases/bindings/history.

Binding rules:

  • Bindings do not fire while focus is inside text inputs, selects, textareas,

editable content, the console input, or the game webview.

  • Backquote is reserved for toggling the console.
  • close all / stop all cannot be bound unless the bound command includes

--force.

  • Script execution is capped at 200 executable lines per file.
  • Dry-run mode does not persist alias/binding changes from inside the script.

Remaining Workflows

Not complete yet:

  • True protocol-only headless clients: current headless clients use hidden

Shockless runtime windows so Director/Pixi/game state still runs correctly.

Hidden runtime windows are now non-focusable offscreen windows to avoid

Electron show:false timer throttling. Protocol-only clients remain the

required scalable path for high-count AFK sessions.

  • Native room invite/accept packet choreography is still a research item. The

implemented summon route uses friend-follow and direct private-room entry.