Shockless Documentation

Multi-Client Sessions

Index

Multi-Client Sessions

Shockless can keep more than one client session open at the same time. Use this

for switching between visible clients, running hidden/headless sessions, testing

plugins against more than one account, and sending console commands to one

client or a group of clients.

Session Types

  • Visible sessions render in the GameHost. They can be selected from the

numbered session strip and show that client's own game view.

  • Headless sessions run without a visible GameHost surface. They still log in,

parse packets, keep room/session state, write packet rows, and accept routed

console commands.

  • Client 1 is the primary embedded client created by the normal Start flow.

Extra clients are assigned client ids such as client2, client3, and client4.

Only the selected visible client is interactive. Hidden and inactive visible

clients stay connected, but they do not take over the stage.

Account Text File

The load command can read a local text file that you create yourself. The file

is not bundled with Shockless and should not be committed to source control.

Use this repeating two-line format:


Habbo name
email@example.com:password
Second Habbo name
second@example.com:password

Rules:

  • The first line is the display label or Habbo name.
  • The next line is the login email and password separated by the first colon.
  • Repeat the two-line pair for each account.
  • Blank lines are ignored.
  • Use quotes around paths that contain spaces.
  • Treat the file like a password file. Store it locally and do not share it.

Example paths:


load "C:\Shockless\accounts.txt" 2 --headless
load "D:\Games\Shockless\accounts.txt" 3 --concurrency 2

The app keeps credentials in memory only for the login flow. Console echo and

session output show labels and status, not full credentials.

Loading Sessions

Start visible clients from a text file:


load "C:\Shockless\accounts.txt" 2 --concurrency 2

Start headless clients from a text file:


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

Start one client directly from a credential pair:


login email@example.com:password --label "Alt One"
login email@example.com:password --headless --label "Alt One"

Create a blank visible client for manual login:


newclient --label "Manual Login"

Do not include an account in the load file if that same account is already

logged in as a visible session. Shockless tries to skip active visible usernames,

but the clean workflow is to keep your already-logged-in main account out of

the file you are loading.

Encrypted Account Store

For repeated use, import the same two-line file into the encrypted app-data

account store. The key is read from an environment variable so it is not typed

into the console.

Set the 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

Short form:


load-store 2 --headless --key-env HABBPY_V4_ACCOUNT_STORE_KEY

Remove the encrypted local store:


accounts clear

Selecting And Closing Clients

List running clients:


list

Select a client:


select 2
select "Alt One"

Rename a client label:


rename 2 "Storage Alt"

Close one client:


close 2

Close all extra clients while keeping the main client:


close all --keep-main

The Multi Account panel exposes the same actions through the GUI: load visible,

load headless, load from store, select sessions, set mimic options, summon

targets, and close individual extra sessions.

Targeting Commands

Prefix a command to choose where it runs:

  • @2: one client id.
  • @main: the configured main/summoner client.
  • @all: every running client.
  • @visible: visible clients.
  • @headless: headless clients.
  • @Label: a client label.

Examples:


@2 say hello from client two
@all wave
@headless fps
@main room

Without a target prefix, commands use the selected client where the command

supports per-client routing.

Packet Log Filters

Packet rows include the client id and label so packets from multiple sessions

can be distinguished.


packets all
packets selected
packets client 2
packets client 3

The Packet Log panel has matching filters for all clients, the selected client,

or a specific client id.

Summon

Summon moves other clients toward the configured main client when enough room

context is available.

Set the main client:


main 1

Summon one client:


summon 2

Summon all extra clients:


summon all

Summon only headless clients:


summon headless

Force private-room entry when the main private room id is known:


summon all --room
summon 2 --main-room-id 224520 --main-room-name "Codex Test LAB"

If the visible main client is already inside a private room, the renderer adds

the main username and room id to summon commands automatically. Visible target

clients use a renderer handoff so their own mounted runtime enters the room.

Headless clients use the hidden runtime and packet-backed room entry routes.

Summon depends on live server state, friendship, room availability, and whether

the target client has finished logging in. Use list after summon to confirm

room state per client.

Mimic

Mimic forwards selected outgoing actions from one source client to the other

clients through whitelisted packet routes.


mimic status
mimic on --source 1
mimic source 2
mimic set movement on
mimic set speech off
mimic set actions on
mimic set rooms off
mimic off

Categories:

  • movement: walking and room movement packets.
  • speech: chat, shout, whisper, and typing routes.
  • actions: wave, dance, carry, sign, and look actions.
  • rooms: private-room join forwarding.

Mimic never forwards login, encryption, ticket, machine id, or identity packets.

Common Workflows

Use two headless alts with a visible main:


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

Use two visible alts that you can switch between:


load "C:\Shockless\accounts.txt" 2 --concurrency 2
wait 8000
select 2
select 3
select 1

Send one command to everyone:


@all say hello
@all wave

Inspect one client's packets and parsed panel state:


select 2
packets selected

Notes And Limits

  • Headless sessions are designed for lower rendering overhead, but they still

run enough runtime state to parse packets and execute mapped actions.

  • Very high account counts need the command-line/protocol headless work to keep

machine load low. Hidden runtime clients are heavier than a protocol-only

connection.

  • Visible view switching should not log a client out. It hides inactive visible

stage surfaces instead of unmounting their runtime.

  • Commands that need direct stage UI access require a visible selected client.

Relay-backed commands can target visible or headless clients.