Complete user manual

Installation, first launch and updates#

Choose the correct package#

The download center contains three ZIP packages with distinct roles.

Viewers open a room's viewer link in a browser. They do not install the server executable. Client account authentication and radar room administration use separate credentials: the account password is not a radar admin token, and a radar publish token is not a client license key.

Extract and start the client#

1. Download the client ZIP and extract the complete archive into a directory.
2. Open the extracted client folder. Keep PlutoMissed.exe, its DLLs, fonts and resource directories together.
3. Double-click 启动软件.cmd, or launch PlutoMissed.exe directly. Both start the same client.
4. Use a writable directory. The client stores configuration in its Config subdirectory and writes update files beside the executable.
5. Point shortcuts to the extracted executable. Move the complete client directory rather than moving the EXE alone.

Run from the extracted directory, outside the archive preview. Avoid overwriting the current package with unrelated DLLs from an older installation. A missing DLL, font or image requires restoring the complete current package; changing feature parameters does not restore a missing dependency.

Read the startup status bar#

The login window's bottom bar shows startup progress. Account action buttons remain disabled until initialization finishes.

A correct account password and a working acquisition device are separate requirements. A disabled action button while initialization is incomplete is not repaired by changing passwords. The controller's movement output and the DMA / keyboard initialization required by login also have separate checks; a connected controller does not replace DMA initialization.

Understand the update boundary#

The executable checks the stable or beta channel built into that executable. These channels update separately. The account's Missed / Full license edition comes from a successful cloud login and is a different selection.

A newer version is downloaded with progress shown in the bottom bar, then the current EXE is replaced and restarted. The same version is not repeatedly installed, and a newer local version is not deliberately downgraded. The client EXE update does not replace the complete package's configuration, fonts, images and companion DLLs. DMA companion libraries have a separate refresh step based on cloud configuration. Download the complete package when a release adds supporting resources.

After a successful replacement, PlutoMissed.exe.previous may remain beside the executable. It is the previous EXE, not a second complete installation. A failed replacement may produce PlutoMissed.exe.update-status.txt; the next startup reports that the previous replacement failed. Address file locks or directory permissions, then retry. For a version rollback, stop the client and preserve the complete current directory before the maintainer checks the older executable's channel and supporting resources. A restarted client still checks current cloud releases.

Installation and startup troubleshooting#

Cloud accounts, license keys and login#

Pages and input rules#

The login window has seven tabs: Login, Register, Trial, Recharge, Change password, Unbind and Convert. Each tab performs one account action. Fill the fields belonging to that action, and wait for the result while the bottom bar says the request is being submitted.

Sign in with an existing account#

1. Wait for the bottom bar to report that software, DMA and hotkeys are ready.
2. Select Login and enter the registered username and password.
3. Click the login action and wait for completion.
4. Read the welcome message and expiry time. The main menu title shows the release channel, client version and actual license edition.
5. The main menu appears after successful login. Hide the settings window with its menu hotkey when required; hiding it is different from exiting the client.

A new client configuration saves the successful login's username and password for filling the next startup's input fields. Existing configurations retain their previous save preference. The current login surface has no separate “Remember password” toggle. Filled fields still require a fresh cloud login; they do not provide offline authorization. The saved data resides in the Windows-protected configuration bundle described in the configuration chapter.

Register a paid account#

1. Open Register.
2. Enter a new username, password and a valid unused license key.
3. Submit registration.
4. After the result confirms that the key was activated, return to Login and sign in with the new account.

Registration creates an account; login creates the client session. Successful registration does not skip login and enter the feature menu. A key already bound to another account is not an unused registration key.

Register without a key and use a trial#

1. Open Register and enter a username and password, leaving the license-key field empty.
2. Submit registration and read the result.
3. A result granting N trial minutes means the same account is ready for the Trial or Login tab.
4. A result granting no duration requires recharge before login.

Keyless registration records eligibility by machine. A machine that has already claimed the trial does not receive another claim merely by changing the username. The interface's fixed text says “2 hours,” and the backend default is 120 minutes, but the current server setting determines the actual grant, including a possible grant of zero. Use the registration result and final expiry time. Trial login uses the same account authentication and does not grant a second duration.

Recharge an account#

1. Open Recharge.
2. Enter the target account's username, its password and an unused license key.
3. Submit the recharge action.
4. Check the expiry time in the success response, then sign in to inspect the actual authorization.

The account edition and recharge-key edition must match. An edition-mismatch result refers to Missed / Full, not to the stable / beta client channel. Switching the release channel does not change the key's edition. Submitting a recharge request is not proof that it succeeded; use the returned result.

Convert Full to Missed#

1. Open Convert and read the displayed Full → Missed direction and 20% remaining-time deduction.
2. Enter the current Full account's username and password.
3. Submit the conversion action.
4. After success, sign in again and check the edition and expiry in the main menu.

The operation changes cloud authorization and deducts 20% of the remaining duration at that moment, rather than 20% of the original purchase. Ten remaining hours become approximately eight. The entry does not convert Missed to Full and is not a stable / beta channel switch.

Current limitations of password and unbind pages#

Change password asks for a username, super password and new password. Unbind asks for a username and password. In this client, these two pages still contact the legacy account service, whereas login, registration, recharge and conversion contact the new account service. A visible tab does not prove that a new cloud account has matching self-service support.

For a new cloud account's device mismatch or password change, ask the account maintainer to handle that account in the matching service. A legacy success response is not proof that the new cloud binding or password changed. Verify the result with a normal cloud login after it is handled. Restoring local defaults is also distinct from account unbinding and does not remove the cloud device binding.

Common account messages#

After login, authorization heartbeats continue. Expiry, bans, revoked sessions, administrator removal and invalid machine bindings end authorization and trigger a message and client exit. A transient network error does not grant permanent authorization; the application also stops when its existing cloud lease expires.

Main menu, language and display settings#

Locate normal controls#

The left sidebar holds global settings. The right area contains four feature tabs.

The initial menu occupies approximately 75% of the current work area's width and height and is centered. Drag its top title strip to move it, or the window edges to resize it. Columns rearrange when space becomes limited. The sidebar has its own scrollbar; scroll it to reach configuration buttons near its end. Current configuration persistence does not store the compact menu's position and size; a restart starts with the initial layout.

Hide the menu or exit#

Saved bindings override defaults. Read the key shown by the control. Remote hotkeys rely on the initialized host keyboard sampler; local keyboard and mouse input edit the menu. For an unresponsive hotkey, leave text editing or binding capture, then verify its displayed binding and host keyboard initialization. A menu tooltip does not replace a device test.

To change a main-menu binding, click the binding control, release the mouse button used to activate it, then press the desired key. For a chord, hold the modifier and press its main key. Check the new displayed name and save Configuration. In the main menu, Esc cancels capture, and approximately ten seconds without input ends capture. The login window's binding widget instead clears a binding on Esc; restore a usable menu binding before hiding the window after clearing it.

Select Chinese or English#

Open Language / Menu → Display language and select Simplified Chinese or English. Main-menu controls use the selected language, and changing it saves configuration automatically. Some dynamic messages and login-window text remain Chinese. Language selection does not change the account edition, update channel or server address.

Change accent colors#

Accent color affects title strips, selected controls and buttons. Hover color affects their hover state. Adjust the color control, inspect the live menu and save Configuration. The normal compact menu's white surface remains fixed; its normal controls do not recolor the complete surface.

These colors are separate from skeleton, name, item and visible / blocked drawing colors on the feature pages. Changing the menu accent does not replace those drawing settings.

Select the output display and overlay#

Choose the display under Screen / Window → Output display. The shown dimensions describe the current output. Reopen the menu after connecting or removing a monitor to refresh the display catalog. A saved display that is absent falls back to an available primary display.

Enable overlay controls the desktop drawing surface. Turning it off may hide player drawing and other overlay output; it does not prove that acquisition stopped or cloud login failed. For missing drawing, check this switch, the output display and the relevant feature page.

Use the black background mask#

Draw background mask is enabled in a new configuration. It makes the drawing background black, with player drawing and other enabled outputs drawn above it. This is a presentation setting, separate from player visibility calculation, radar publishing and aim activation.

Turning it off removes the opaque black background. With the settings menu hidden, the window returns to desktop transparency and click-through. Settings, modal messages and an interactive player list retain their own interaction areas. To reach an application underneath, hide the settings menu and dismiss active interactive dialogs.

The client's desktop mask and the radar viewer's black drawing canvas are separate settings. This desktop switch does not change the web theme, web borders or browser fullscreen state. The radar chapter covers the browser's skeleton fullscreen mode.

Frame rate, vertical sync and optimization entries#

Increasing the render cap does not simultaneously raise valid DMA sampling, radar publish frequency and monitor refresh rate. Start with a stable cap, inspect actual output and resource usage, then change the value. The setting is a limit; achieved FPS still depends on processing time and vertical sync.

Save, load and restore configuration#

Understand the three buttons#

The Configuration area's Chinese name mentions sharing / moving. Its buttons operate on a fixed local file; they do not open a file chooser and do not provide normal-user cross-computer export / import.

A useful check is: change one value → inspect the result → Save → change it again → Load → confirm that the saved value returns. Load overwrites the corresponding unsaved edits, so save edits that must survive. Exiting is not the current normal settings' automatic-save entry.

Some controls save automatically, including language, output display, logging, completed render-cap editing and the radar's dedicated save button. Each configuration save writes the full supported current settings, so also save deliberately after editing other features.

File location and protection#

The primary file is client directory\Config\冥王星配置.dat. It is not an editable JSON or INI. Windows DPAPI protects it under the current user context. Copying it to another Windows user or computer is not a general configuration export.

A backup of the bundle includes remembered credentials and the radar publish token. Share the needed parameter values instead of treating the entire bundle as a public example. Current-user protection encrypts the local file; it is not an account license, a cross-computer compatibility guarantee or a sharing tool.

Migrate an older installation#

With no readable new bundle, the client attempts to migrate existing files from its directory and create a new protected bundle. Existing Config\kakaConfig.bak, login INIs, lists and some resource settings are copied into their corresponding sections. Migration does not automatically remove the original files. Once the new bundle is readable, it is the primary configuration; old plaintext files are not the normal daily editing path.

Keep a copy of the older complete directory before migrating under the same Windows user. Inspect important switches, bindings, output display, controller settings and radar credentials afterward. Across users, computers or a Windows reinstall, re-enter necessary settings and sign in in the new environment; direct recovery of the old encrypted file is not guaranteed.

Back up and restore your configuration#

1. Save settings in the current client, then exit it.
2. Copy Config\冥王星配置.dat to a private backup directory and record the client version and save date.
3. To restore in the same Windows user and original environment, keep the client stopped and put your backup at that path.
4. Start the client and inspect each page. The account still requires cloud login.

Preserving the complete client directory for an upgrade makes recovery of resources easier than preserving its EXE alone. Restore the file while the client is stopped, so a live save does not overwrite the restored copy.

What Restore defaults preserves#

Click Restore defaults, then Confirm restore or Cancel. Confirmation rebuilds normal defaults and saves them. The current output display, dimensions and window handle, current menu visibility, controller type, COM, IP, port, UUID and connection state are retained, preventing this operation from immediately dismantling an active device connection.

Other settings, including aim, recoil, drawing, common bindings, language and colors, return to defaults. Radar settings reset too; enter its address and room credentials again before publishing. The operation leaves the bundle's separate saved-login section intact. It does not unbind the cloud account, change cloud expiry or delete rooms from the radar server.

“Defaults restored” means the defaults were applied and saved. “Defaults applied; save failed” means this session uses defaults but disk persistence failed; the next launch may load the older saved values. Address directory permissions or file locks and save again.

Configuration troubleshooting#

Menu, configuration, and key binding basics#

This chapter covers menu operation, aim assistance, recoil compensation, the automatic trigger, and mouse/keyboard output devices in the normal client interface. Default values refer to a fresh configuration. An installation that has loaded an older configuration, saved custom settings, or upgraded from an earlier version retains its existing settings. Grayed controls are subject to the current account's verified permissions; the product name does not replace the actual permission state.

Separate menu input from game output#

The client computer runs the software and displays its menu and drawings. The source computer runs the game and supplies the state read by the client. A mouse/keyboard output device sends client output to the source computer; the menu's “Primary/secondary computer operation” section controls the software's own menu. These functions are independent: a remote mouse operating the menu does not prove that the aiming output device is connected, and a successful output-device connection does not prove that remote desktop cursor coordinates are available.

The default F2 binding overlaps. F2 selects Configuration 1 and toggles the aim master switch; one press triggers both actions. To switch configuration while keeping the aim switch unchanged, assign different keys to “Aim switch hotkey” and “Configuration 1 switch key,” then save. Assigning the same key to other actions creates similar conflicts.

Change a key binding#

1. Open the relevant key control and click the area displaying the current key name.
2. Release the left mouse button used to activate that control.
3. Press the new key. To bind a modifier itself, such as Shift, Ctrl, or Alt, press and then release that modifier.
4. After the displayed key name changes and the “Key updated” notification appears, test the actual binding.
5. Click “Configuration sharing/moving → Save” in the sidebar.

Press Esc while waiting to cancel binding. Waiting ends after approximately 10 seconds without a captured key. Keyboard keys, left/right/middle mouse buttons, and side buttons are recognized inputs. A modifier plus a mouse button supports a combined binding, such as Ctrl plus a mouse side button. This does not imply support for arbitrary combinations of several keyboard keys. Remote menu input has its own sample-validity requirements; an unfinished capture ends when its input becomes unavailable or its page disappears.

Connect the mouse/keyboard output device and confirm output#

Start with a COM-type device#

The normal interface offers COM-type device and IP-type device under “Connection type.” COM mode automatically probes serial devices; its current automatic identification uses a MAKCU version response. Seeing a COM port in Windows does not establish compatibility with every serial output device. Check the firmware protocol, driver, USB cable, and port against the actual hardware.

Operation order:

1. Connect a supported serial device to the client computer and confirm that its serial device appears in Windows.
2. Open “Mouse/keyboard device settings” in the sidebar and choose “COM-type device.” The interface displays “Automatically detect serial device.”
3. Keep “Auto-connect” enabled and observe the connection state. After a failed initial probe, resolve the device issue and click “Connect device” to retry.
4. Once “Connected” appears, move the game to a small test setting where movement is easy to observe. Disable aim assistance, recoil compensation, and the automatic trigger first.
5. Click “Test movement” and observe whether the source computer's physical cursor or view moves within a small area. This button sends real movement for approximately 1 second along a small-radius rotation and does not send clicks.
6. After output behaves correctly, enable the required functions one at a time and save the configuration.

The connection-type selector is locked during connection, movement testing, and an established connection. IP, Port, and UUID being locked after a serial connection is normal; those fields are not required for a serial connection. Disconnect before changing type. A manual disconnect disables auto-connect; check that option again when automatic connection is wanted.

Use an IP-type device#

1. Check IP, Port, and UUID against the device's own configuration. The initial IP shown is 192.168.2.188, while Port and UUID start empty; displayed factory values do not establish the correct values for your device.
2. Ensure that the client computer reaches that device address. Check the appropriate network adapter, subnet, and device power.
3. Select “IP-type device” under “Connection type” and enter the three device parameters.
4. Click “Connect device” and wait for “Connected.” The current IP-type path uses a KMNET network connection.
5. Disable automatic output in the order described above, then run “Test movement” to confirm the physical output path.
6. To attempt connection automatically on startup, enable “Auto-connect” and save.

Auto-connect initiates a connection attempt; it is not a guarantee of endless retries. After a failure, correct the settings, inspect the hardware, and connect manually. Use the port and UUID provided by the device. Keep the radar service port, device input-return port, and device control port distinct.

Read the connection state#

“Connected” checks the software's connection procedure, while “Test movement” checks the actual output path. Neither establishes that every aiming, release, or automatic-key behavior has been verified in the game. Mouse DPI, game sensitivity, scoped sensitivity, screen resolution, and firmware affect the physical response. This guide does not provide a single recoil-control success rate or aim-speed value that covers all hardware.

Aim/recoil settings: understand the current parameter groups first#

One shared configuration, grouped by the current firing mode#

The current page uses globally shared settings. Automatic, single/burst, bolt-action, shotgun, and throwable groups have their own speed, distance, or dedicated controls; the page does not expose a fully independent speed and FOV configuration for every gun.

Switching the same rifle between automatic and single fire uses the shared keys and parameters for the corresponding mode. The software needs valid, sufficiently fresh firing-mode data. Repeatedly increasing speed does not repair incorrect weapon or firing-mode identification.

“Configuration 1 / Configuration 2” retain the current preset and compatibility key fields. Global speed, distance, FOV, recoil strength, and shared firing-mode keys do not become a second independent set when another preset is selected. Compatibility keys for bolt-action rifles and shotguns, plus preset fields such as downed-target and tire keys, are read from the selected preset. Start tuning with one fixed preset; examine the second preset after the first has been confirmed.

Aim switches and target conditions#

Targets also require a valid game scene, local player and weapon, distance, FOV, and bone positions. Whitelists and target filters affect selection. Checking “Enable aim” does not establish output when the controller is disconnected, target positions are invalid, or reloading is active.

For downed targets, inspect “Skip downed targets,” the dedicated key, and the selected preset first. The current Full-license path does not accept dedicated downed-key activation. After a license or version change, use the functionality actually available and avoid treating a normal aim key as a downed-target key.

Primary keys, backup keys, and secondary body parts#

The primary-key body-selection policy starts with the chest, then other valid body parts, and uses the head as a later fallback. Enabling “Default head preference” moves the head ahead of that order. The Missed-license path requires holding the primary key with the secondary key; the Full-license path permits independent secondary-key activation. Assigning the same key to primary and secondary removes their distinct meaning, so use different keys.

“Show prediction point” also has an ADS reference-point display path. With that display enabled, holding the secondary key alone while already aiming down sights enters reference-point display and pauses the current crosshair movement. This condition also affects the Full-license path's independent secondary key. To aim at the secondary head in that situation, hold the primary and secondary keys together, or disable “Show prediction point” before testing independent secondary-key activation. Default head preference, secondary keys, and visibility interact; the final body part follows valid positions and visibility rather than guaranteeing the same bone every time.

Test keys in order: disable all hip-fire switches; equip an ordinary weapon in a valid game scene; hold the primary key and observe locking; release it and confirm stopping; add the secondary key; finally test the secondary ADS requirement. This separates an unread binding from an unmet body-part condition.

Hip-fire#

Automatic, single/burst, bolt-action, and shotgun groups each have an independent “Hip-fire aim” switch; all start disabled. Enabling a group adds activation while not aiming down sights and while in aim stance or firing. Normal scoped aiming still follows the primary and secondary keys. A hip-fire switch does not mean the client takes over the mouse at every moment.

Before regular use, run a brief test without ADS, then aim down sights to check key gating, and finally check release after stopping firing or aim stance. For unintended hip-fire activation, disable the relevant group's hip-fire switch first, then inspect whether the primary key or right mouse button is still being reported as held.

FOV range#

For a 1920×1080 drawing region, the shorter side is 1080 and the 25% base radius is 1080÷2×25%=135 pixels. Dynamic mode adjusts this for the current view and remains subject to the maximum multiplier. The percentage is not the game's viewing angle. Changing output resolution, display, or dynamic FOV changes the circle's pixel size.

When a target is not acquired, enable “Show aim FOV,” check that its selected body part is inside the circle, and verify the distance limit. A larger range admits more targets that were not intended for selection. Start with a smaller range and adjust to the actual target distribution. After changing FOV, leave speed unchanged for one observation before deciding to alter it.

Aim distance#

Distance is a selection ceiling. It does not guarantee valid samples for every target inside that ceiling and does not state the weapon's effective range in the game. Longer distances depend more on target motion, valid reads, trajectory state, and display stability. Reducing the ceiling avoids unintended distant locks; it does not repair an invalid local weapon or a disconnected output device.

Aim speed and acceleration#

The five “Aim speed” groups use the same base percentage for horizontal and vertical movement, with an interface range of 0–300%. At 0%, that group's base aim speed is zero. At 100%, the internal base computation uses its full proportion; it does not mean a 100% hit rate.

Keep the weapon, magnification, game sensitivity, DPI, display, distance, and stance fixed, and change one field in a repeatable small scene. Record its previous value and observe overshoot, lag, or oscillation; save after confirming improvement. When close targets are too fast but distant targets are normal, inspect enemy-distance acceleration first. When the edge of the circle is too fast but its center is normal, inspect screen-distance acceleration. For high-magnification anomalies, inspect magnification adaptation. Continuously increasing speed does not correct jittering bones, expired reads, or discontinuous device output.

Aim drawings#

Optional reference points and circles have valid-state requirements. Before treating an absent point as an ineffective drawing switch, inspect the current weapon, ADS/key state, and target samples. Low color opacity also makes drawings difficult to see.

Tire settings#

The current tire controls are “Tire key,” “Tire-lock FOV,” and “Tire smoothing.” The initial tire key is Caps Lock; tire-lock FOV starts at 60 and has an interface range of 1–360. Tire targeting is enabled in the normal runtime, with the dedicated key entering tire selection. Its FOV also changes with the current camera view.

These controls edit the rifle tire configuration in the current preset; the compatibility tire fields for other weapons are not guaranteed to synchronize. Start with a rifle and the current preset on a valid nearby vehicle tire before checking other weapons. “Tire smoothing” displays a range of 0.1–100 and an initial value of 5, but the current active production output does not consume it as an independent speed control. Adjusting it is not a verified tire-response optimization. Tire locking is not automatic firing; firing still comes from the user's action or an independent automatic trigger that meets its conditions.

Smoothing and random effects under “Detection prevention settings”#

The public controls under this title change aiming paths, transitions, and random offsets. The title does not establish an anti-cheat bypass result or guarantee safety or account-ban outcomes; this chapter describes observable adjustments. Grayed controls indicate unavailable license permission.

When default head preference or the secondary head key is used for player aim, this entire effect group is bypassed, including ADS smoothing, post-shot slowdown, curves, and randomness. Confirm the actual aiming part and default-head setting before testing the group so that behavior from different parts is not mixed together.

Zero random amplitude leaves that item with no amplitude. The head and limbs use a smaller scale, while the chest, abdomen, and pelvis use a larger scale. Centimeters are not fixed screen pixels; distance and magnification change the visible offset.

Test in order: disable the curve and each random amplitude and confirm stable base speed; enable the ADS transition; enable post-shot slowdown; finally increase the desired random amplitudes one by one. Record the prior value each time and retain the same body part, weapon, and magnification. Random settings deliberately reduce precision. For excessive offsets or distant instability, return the corresponding amplitude or spread to 0 and inspect base aiming before making large simultaneous speed increases.

Algorithmic recoil compensation#

Enable it in order#

1. Connect the output device and complete “Test movement.”
2. Open “Aim/recoil settings → Algorithmic recoil compensation V1.0” and check “Enable recoil compensation.” The master switch starts disabled.
3. Retain the initial strength values. Start with a recognized ordinary firearm and briefly fire manually from a stable state.
4. Inspect the weapon, attachments, firing input, and recoil state under “Current loadout.”
5. Confirm ordinary automatic recoil strength first, test strength while aim is locked second, and test the single-fire group last.
6. Release the physical fire key and confirm output stops; then save.

Recoil strength is grouped by weapon family, unlike aim keys grouped by current firing mode. For example, a rifle switched to single fire remains in the rifle recoil category while its ordinary aim keys use the single/burst mode group. Strength above 102% increases horizontal compensation; vertical compensation remains capped at 102%. A 110% setting does not mean a linear 10% increase on both axes. At 0%, that group's compensation strength is disabled.

The feature computes mouse compensation from current muzzle movement and recoil magnitude, requiring a valid local player, weapon, firing input, and output device. It uses fresh physical firing input; automatic key events do not replace valid physical firing samples. When aim owns the mouse axes, the independent recoil path pauses to avoid stacking two movements. Game cursor/menu state, device disconnection, invalid reads, and reloading also affect the conditions.

Read “Current loadout”#

The loadout panel includes the weapon, recognized attachments, sample state, recoil reason, firing input, recoil reading, controller, and output-attempt count. A valid weapon identification shows the weapon name; unrecognized attachments show their current state or reason. stale_sample means the data has expired rather than remaining valid indefinitely. An increasing output-attempt count means the software attempted dispatch; it does not replace a hardware acknowledgment or observation of physical mouse movement.

Tune residual recoil movement#

For residual upward movement, confirm valid recoil readings, continuous output, and the applicable strength group first. For excessive downward movement, reduce that strength. For horizontal drift, separate game recoil, horizontal strength, manual input, and the aim path, especially because values above 102% primarily increase horizontal strength. When enabling aim changes recoil behavior, test manual recoil compensation and aim lock separately; axis ownership and the automatic-while-aiming strength alter the result.

Keep the same gun, attachments, stance, magnification, game sensitivity, mouse DPI, and firing duration during comparisons, observing short segments. Recheck after changing those conditions; values for one gun do not promise results for every gun. A 120% setting does not supply missing conditions for bolt-action rifles/crossbows, unrecognized weapons, or unavailable fresh physical firing samples.

Raycast automatic trigger#

Understand its independent control#

The automatic trigger requests an automatic button action when crosshair/visible-bone overlap, valid sight path, weapon readiness, and output ownership conditions are satisfied. It starts disabled and has its own master switch, hotkey, and per-weapon always-on policies. Disabling ordinary aim does not imply that the automatic trigger is disabled, and the trigger does not automatically activate ordinary aim.

The normal page exposes the following controls. Gray controls indicate unavailable account permission; internal parameters absent from the interface are not adjustable items in this chapter.

With no toggle key assigned, enabling the master switch accepts the remaining conditions directly. With a hotkey assigned, a new activation cycle starts permitted and its first valid key press pauses it. Do not assume the first press always turns it on. After changing or reopening the master switch, perform a short test against the actual state.

“Always on” does not remove obstruction, ammunition, or weapon-readiness checks. To disable the trigger completely, turn off the master switch and clear all four always-on policies: automatic, semi-automatic/handgun, bolt-action, and shotgun. Leaving any always-on policy enabled permits automatic button requests for a matching weapon even with the master switch off.

Enable it for the first time#

1. Connect the output device, test movement, and confirm that the current license enables the trigger controls.
2. Leave every always-on policy disabled. Verify ordinary aim separately to avoid investigating two problems at once.
3. Enable the trigger and assign a toggle key that does not conflict with other actions.
4. Run a short test on a stationary, visible, unobstructed target and observe release after moving the crosshair off its body.
5. Check stopping and priority separately when the crosshair moves away, an obstacle appears, reloading starts, ammunition is empty, the weapon changes, and manual firing is used.
6. After stable basic tests, enable individual weapon always-on policies and adjust overlap or the bolt-action history window one item at a time.
7. End the test by completely disabling the master switch and always-on policies, and confirm that automatic button actions stop. Restore the recorded settings and save when regular use is required.

Manual firing retains priority, and automatic input has separate release handling. Output integration varies with the device protocol; a working movement test does not establish support for independent automatic-button ownership. Lowering overlap thresholds does not repair unknown visibility, an unverified path, an unready weapon, empty ammunition, or a missing output path.

When the trigger produces no action, troubleshoot in this order: account permission → master switch and always-on policies → whether the toggle key has paused activation → device connection and output support → valid scene and weapon → crosshair/bone overlap → distance/hip-fire settings → valid visibility and path → ammunition/cooldown/reload. For bolt-action rifles, also inspect the history window and threshold; for shotguns, inspect valid bones and the related prediction conditions. Confirm repeatable behavior on an ordinary target before adding complex movement and obstruction.

Operate the menu from the source computer#

Memory-based mouse menu input#

Entry point: “Advanced function settings → Primary/secondary computer operation.” “Memory mouse menu operation” starts enabled. “Mouse coordinate scale” starts at 1.00, with a range of 0.25–4.00. With the mouse connected directly to the source computer, valid remote keyboard/mouse samples operate the software's settings menu through an independent cursor, alongside the client computer's local cursor.

Operation steps:

1. Open the menu with its bound Home key through a verified input source and confirm that it displays correctly. Do not assume a global local-keyboard toggle without testing it.
2. Open “Primary/secondary computer operation” and inspect remote keyboard state and the input source.
3. Enable “Memory mouse menu operation” and move the source computer's mouse.
4. Confirm the independent cursor position and click response. Start with a page tab, then drag a numeric control.
5. When the computers have different resolutions and the position is clearly offset, make small changes to “Mouse coordinate scale.” It adjusts menu-coordinate mapping rather than game mouse sensitivity or aim speed.
6. When keyboard/mouse state is invalid, click “Retry remote keyboard” and wait for reinitialization.

The client computer's local keyboard/mouse has priority. Recent local activity temporarily prevents remote takeover; briefly stop using the local mouse before testing remote input. A sample timeout, invalid source, or hidden menu releases retained remote pressed states, preventing continued dragging or held buttons after disconnection. “Local keyboard/mouse has priority; remote takeover paused” is not a remote-hardware failure. “Waiting for source-computer keyboard/mouse samples” indicates insufficient valid remote samples.

KMNET physical keyboard/mouse return#

“Device return port” starts at 27392, with an interface range of 1024–65535. “Returned mouse sensitivity” starts at 1.00, with a range of 0.1–3.0. Returned input uses the physical device mouse's relative motion, while memory mouse input uses remote desktop coordinates; the two sensitivity fields serve different purposes.

1. Connect KMNET through the IP-type procedure first.
2. Inspect return-input state. After connecting, the software attempts to start return input by default; when it has not started, click “Enable device keyboard/mouse operation.”
3. Connect the actual keyboard/mouse through the physical input path supported by the device and move the mouse or press a key.
4. After “KMNET listener bound, waiting for physical keyboard/mouse” becomes “KMNET relative input received,” check the menu cursor and buttons.
5. When the cursor is lost, click “Center returned cursor,” then adjust returned mouse sensitivity.
6. Click “Disable device keyboard/mouse operation” when it is not needed; this also disables automatic return startup for the current session. Disconnecting the device also releases and stops returned input.

The port field is locked while return input is enabled; disable return input before changing it. This is the local listening port for physical input reports, separate from the device control port and web radar port. For startup failures, check the firewall, port ownership, IP connectivity, and whether the connected device is still KMNET. This entry point does not integrate return input from other device types.

Common problems with remote menu operation#

A repeatable tuning and troubleshooting process#

Start from normal default settings#

1. Save the current usable configuration and record connection parameters and keys that need to be retained. Use the interface's restore confirmation when restarting from defaults.
2. Fix one output display and check the current dimensions against the game picture.
3. Connect the device and complete the small-area movement test.
4. Select one preset and assign nonconflicting keys for preset selection and the aim master switch.
5. Keep the automatic trigger and recoil compensation disabled. Enable ordinary aim first, show FOV, and verify primary key → lock → release after letting go.
6. Keep the weapon, magnification, DPI, and game sensitivity fixed. Tune base tracking speed, then adjust acceleration one item at a time as needed.
7. Check head/chest selection, secondary keys, and visibility conditions before enabling required hip-fire groups.
8. Release aim keys and verify recoil compensation separately, tuning ordinary automatic strength, strength while locked, and the single-fire group.
9. Test the automatic trigger after basic input is stable, initially without always-on policies.
10. Save and reload at each stage to confirm persistent values. After restarting, recheck the device and important switches.

Identify which part is failing#

When reporting a problem to support, state the client version, connection type, related menu values, reproduction steps, and exact status text. Distinguish successful connection, a software output request, physical mouse movement, and the in-game result. A repeatable observation from the same scene and settings is more useful for diagnosis than an unverified fixed hit-rate claim.

Player ESP: switches, information, and distance#

This chapter covers Player ESP and the normal display controls in Advanced. Defaults in the tables describe a new configuration in the current version. Saved configurations override these defaults. An existing configuration retained across an update may have different switches, colors, hotkeys, and distances.

Build a readable display from scratch#

1. Open Player ESP and enable the player ESP master switch and player skeletons.
2. Set ESP distance to the required player drawing range. Set information distance to the range where names, team numbers, and other text are useful. Start with 300 meters for information and adjust for screen density.
3. Enable names, team markers, and distance in Player Information. For weapon information, enable held weapons, then check weapon text and ammo under Independent Display and Size → Display Item → Weapon.
4. Increase Skeleton Thickness when lines are too thin. Reduce Information Size or information distance when text becomes crowded. Change one field, observe the result, then change another.
5. Enable Player Box for bounding boxes. Box line width and skeleton thickness are independent settings.
6. Click Save when finished. The saved values are used after the next launch. Load replaces unsaved changes with the saved configuration.

World player, item, vehicle, and throwable drawing requires an active match and valid camera data. Missing player drawing in the lobby is normal. After joining another match or during a camera sampling interruption, check the scene, PID, and actual sampling state first. Increasing range does not create missing game data.

Base ESP controls#

The player ESP master switch is not a master switch for the whole application. Items, map markers, or timers remaining visible after turning it off are controlled by their own modules. To disable all world drawing, check player, item, vehicle, airdrop, death box, and throwable modules.

Range, thickness, and text size#

Independent Display and Size provides another set of shortcuts to the same fields, not a second display profile:

The two entries use different slider ranges while sharing the value. Setting ESP distance to 1200 meters in the shortcut also changes the main field; it does not create a second 1200-meter display. When one control changes another, check whether they are two entries for the same field.

Weapon Distance is not an absolute independent cutoff. The current drawing logic retains weapon-information eligibility for players already inside the information range, and the current target may receive expanded information. Weapon text beyond the configured weapon distance therefore calls for checking Information Distance and current-target state. Coordinate player, information, and weapon ranges when simplifying the display.

Player information switches#

Weapon text and icons are adjustable separately. For text without icons, disable Show Weapon while retaining Show Weapon Text. For icons and ammo, enable Show Weapon and Show Ammo. Ammo rendering depends on an available weapon icon; missing icon assets can also remove the ammo label.

Ordinary firearms show valid ammo counts or Reloading. A throwable being cooked shows Pin Pulled. Throwables and certain special weapons do not show ordinary ammo numbers. Blank ammo does not mean zero rounds; the weapon may not use this display, or a valid value may be unavailable.

Read visibility colors as evidence-based display#

Visible and occluded colors are display results. Missing scene models, regions still mounting, incomplete path coverage, or missing new observations result in unknown evidence. The current display policy treats unknown evidence as visible by default. Green therefore does not prove that the path has no obstacle. The web radar preserves the publisher's visibility result and known/unknown state instead of recomputing occlusion from a viewer's new camera.

One player can have different colors on different body parts because arm, head, and torso observations are independent. A player classified as visible as a whole does not make every bone visible. Missing or overly old bones are not completed with fabricated poses.

New configurations use green for ordinary visible skeletons and red for ordinary occluded skeletons. Both ordinary information colors are white. Separate colors exist for AI, downed players, blacklist, whitelist, partner markers, targeted rays, and locked targets.

Colors overlap; read their priority together:

1. The resolved personal/cloud list relationship selects blacklist or whitelist colors.
2. Other players receive base colors according to downed state, partner marker, AI classification, and visibility.
3. Historical-stat danger highlighting changes information text, not the whole skeleton.
4. Current official markers may apply a dynamic information color.
5. Local bone visibility and lock coloring determine the final individual segment colors.

For readability, choose strongly contrasting visible and occluded skeleton colors. Set text colors for the background where they will appear. Alpha in the color editor also affects visibility. Use text size to make text smaller and alpha to make color fainter; these are different adjustments.

Skeleton style and detail#

Open Advanced → Player Skeleton Style.

Bone Model is a display style built from acquired bones. It is not a complete player skin, clothing model, or game mesh. Selecting it does not require player-model files on the web viewer. Distant bone models scale according to projected height to prevent far players from becoming oversized blobs.

For constrained devices or crowded scenes, try Basic 10 before reducing player and shared sampling ranges. Use Full 19 for more pose detail. Allow new samples to arrive after switching detail, then inspect actual publication rates and the display; a selected setting does not prove an accepted sample count.

Historical-stat source and danger information color#

Player Stats Source determines the statistics used for text and danger thresholds. The choices are:

• Highest Ranked.
• Ranked Solo, Duo, or Squad TPP.
• Ranked Solo, Duo, or Squad FPP.
• Normal Solo, Duo, or Squad TPP.
• Normal Solo, Duo, or Squad FPP.

The existing Chinese label “最高竞技段位” means Highest Ranked in the UI, but the current selection compares available API KD/KDA values between ranked modes and chooses the highest value. It does not select by highest rank points. When ranked KD is unavailable, the selection tries the highest available normal-mode KD. An explicitly selected ranked team size and perspective falls back to the corresponding normal team size and perspective when KD is missing; it does not silently change Solo to Squad.

Previous Season Fallback is on by default. Available current-season data is retained; previous-season data is a backup for missing current data. The display does not mix current-season rank, previous-season KD, and another mode's average damage into one summary.

KD/KDA and average-damage checks are alternatives: either reaching its threshold is sufficient. Both do not have to pass. Missing data is neither zero KD nor a dangerous-player signal. KD [--] indicates no usable value. KD* marks a value derived from kills and lost rounds when the API does not provide actual death counts. KDA marks an API-provided KDA value.

The player's current-match cumulative damage, historical average damage, and floating cumulative-delta estimates are three distinct data types. Changing one display switch does not rewrite the other data.

Information and display hotkeys#

Both Show Teammates and Item Visibility use F1 in a new configuration. When multiple actions share a key, the current hotkey handler executes all registered actions. One F1 press can therefore change teammate filtering and item visibility together. Assign different keys and save instead of treating this as random switch failure. Refer to the hotkey chapter for chord and binding operations.

Item ESP and inventory filtering#

Open Item ESP. The normal workflow is to enable the master switch, select individual items, set the display distance, and then choose icons and filtering.

Main controls and defaults#

Player ESP → Independent Display and Size → Items also provides Show Item Distance and Icons Plus Text. Distance is on by default; icons plus text is also on. With Show Icons disabled, the renderer uses text. To show icons and labels, enable both switches. For compact icon mode, disable Icons Plus Text.

Seventeen categories of individual selections#

The catalog is split into Assault Rifles, DMRs, Sniper Rifles, Shotguns, SMGs, LMGs, Handguns, Medical Items, Equipment, Muzzles, Grips, Magazines, Stocks, Scopes, Ammunition, Throwables, and Other. Click the square beside a specific item. A filled square includes it; an empty square excludes it.

The current version uses one include/exclude list. Old groups are normalized into selected items rather than being switched through A/B/C/D hotkeys. A new configuration preselects certain common weapons, attachments, equipment, throwables, and keys; it does not select every item. When an item is absent, find its category and verify its individual selection.

The catalog defines filtering; it is not a live list of ground items. A selected item still requires acquired game data, the master switch, a distance within range, no quantity/attachment exclusion, and a display state where battle mode or locked-target policy is not temporarily hiding it.

Quantity limits#

Quantity sliders in the main Item ESP panel range from 1 to 8. Advanced → Smart Item Configuration edits the same values with plus/minus buttons over 0–999. Values at both entries remain shared. The unit is item count, not meters, percentage, or backpack capacity.

For example, a first aid threshold of 4 hides matching ground items when the read inventory record reaches 4. This reduces additional collection prompts. It does not discard existing kits or automatically collect the first four.

Zero is not unlimited. Once that type has a read inventory record, its count meets a threshold of zero. To keep seeing that supply, disable quantity filtering or raise its threshold in Advanced.

Item data updates periodically. Picking up, dropping, or switching a weapon does not guarantee that every filter updates in the same render frame. When an item remains hidden after a filter change, turn the item master switch off and on to rebuild the cache, then recheck selection, range, and battle mode. Restore the complete Assets folder for missing icons; increasing font size does not repair missing image files.

Practical item combinations#

• Nearby resupply: retain medical items and currently needed attachments, use a short range, and enable distance labels and quantity filtering.
• Initial landing: check needed weapon, ammo, and basic-equipment categories. Temporarily disable quantity filtering so retained thresholds do not hide supplies.
• Dense loot: enable Item Combination. If the display remains crowded, reduce range and deselect unnecessary items.
• Fully attached weapon: keep Accessory Filtering; matching installed attachments enter the hidden list. After switching weapons, allow the new weapon data to refresh.
• Looting death boxes: enable the box's contents and select the desired individual items on the Item ESP page. Box contents do not bypass the selection catalog.

Vehicles, airdrops, and death boxes#

These three modules have separate switches, hotkeys, distances, and text sizes. They are not controlled by the player ESP master switch. Battle mode, cursor operation, and an active target lock can temporarily hide world items, vehicles, and packages according to display policy.

Vehicles#

Open Player ESP → Vehicle ESP.

The shortcut label Vehicle Durability shares the Vehicle Fuel field. It is not separate tire durability, part durability, or armor durability. Invalid health/fuel data is not represented by invented full bars. World vehicle drawing and main/mini-map vehicle markers have separate switches; enable both for both views.

Airdrops#

Open Player ESP → Airdrop ESP.

A title without content rows calls for checking Show Airdrop Items, individual item selections, and whether package contents have refreshed. A title does not prove all contents have been acquired. Airdrop icons belong to client world/map drawing and do not require switching to the web radar.

Death boxes#

Open Player ESP → Death Box ESP. The existing display wording may also appear as “骨灰盒” or Ash Box.

For crowded boxes, reduce range before reducing font size or disabling content rows. Retain titles for positioning. Contents usually use a font one pixel smaller than the title. Extremely small values such as 1 px make information unreadable and are not a useful crowding fix.

Main map and mini map#

These marker groups overlay the game's own main and mini maps. Positioning follows acquired map visibility, placement, zoom, and world-origin transformation. They are separate display locations from the independent 3D web radar.

Controls in each map group#

Enable the required marker type, open the game's main map or observe the mini map, then adjust icon size for density. Use the shortcut entry for death boxes and special rooms. Main-map markers do not float on the screen independently when the game map is closed.

When the game main map is open, map drawing takes the place of projected world players. Closing it restores player projection. Mini-map objects are clipped according to the acquired mini-map range; increasing player ESP distance does not force out-of-range objects onto the mini map.

AI marks identified bots; ordinary player markers usually show team numbers and facing. The renderer retains T/S friend/shared-position markers with expiry, map matching, and deduplication. In the currently matched source, the legacy cloud position submission has field-type incompatibilities with the server, so these markers do not establish working friend-position sharing. Use the independent 3D web sharing radar for current sharing; treat the two paths separately.

For missing icons, restore complete client image resources. For a global marker offset, check game map/resolution state and valid sampling, then close/reopen the map. Icon size is not a coordinate-calibration tool.

Throwable display and timers#

Open Advanced → Raycast Throwable Trajectory. This section covers drawing; target selection, trajectory solving, and release operations belong to the throwable-operation chapter.

Future trajectories are controlled by Enable Automatic Trajectory in the general/collision throwable group. Historical paths are controlled by Grenade Trail here. Enable both to see both. Disabling one does not automatically disable the other.

Local cooking timers require a held throwable with a valid elapsed cooking value. Text and dashboard timers have separate switches; disabling both produces no cooking-timer drawing even when the master is on. Grenade time uses the current configured fuse duration; flashbang timing uses its corresponding branch. The displayed number is calculated from acquired data and does not replace the game's operation state.

Historical trails connect observed points. Disappearance, leaving valid display, disabling the throwable display, or changing match ends that trail segment. A reappearing projectile does not bridge an unobserved gap. A trail stopping is not proof of an observed explosion; it may have left the range or lost sampling.

Thrown-grenade reference circles currently use approximately 3.8 meters in radius and C4 approximately 16 meters. They are visual references, not equal-damage guarantees for everyone inside. High-throw circles near players are distance-band guidance and must be distinguished from collision-solved future trajectories and automatic-release conditions.

Floating damage feedback#

Open Advanced → Floating Damage Configuration. The current version estimates attribution from increases in local cumulative damage. A leading tilde, “~”, explicitly marks that estimate.

For example, ~23 means an observed cumulative increase of about 23 was attributed to one recent candidate. It does not confirm that one particular bullet dealt exactly 23 damage. Target health-bar drops are not used to infer this feedback.

Settings#

Maximum font must be at least minimum font; the current UI normalizes the relationship. Raising minimum font above the previous maximum also raises the maximum. Font size is not a one-to-one damage number; a delta around 100 approaches the maximum size.

Conditions for feedback#

1. Local cumulative damage produces a valid positive increase.
2. A current/recent candidate from roughly the last 500 ms permits unique attribution. Missing candidates are not replaced by guessed victims.
3. A grenade-release context from roughly the last 6 seconds provides at most one candidate. Multiple potential victims in the candidate region, or conflicting aim/grenade candidates, cause attribution to be skipped. Grenade increases are not automatically assigned to whoever is currently under the crosshair.
4. The target remains in acquired player data, projects onto the screen, and the delta reaches the threshold.

No floating number does not prove no damage. Ambiguous attribution, a high threshold, a target leaving the screen, or delayed data can skip a display. Reducing the threshold to zero admits smaller valid increases; it does not create missing targets or exact per-shot events.

Changing match or returning to the lobby clears the animations and attribution baseline. Cumulative damage resetting to zero is not treated as negative damage or a new hit.

Normal Advanced controls, performance figures, and model use#

DMA Optimization controls available to normal users#

Metadata/Weapon Target defaults to 30 Hz and ranges from 5 to 120 Hz. It controls the requested refresh rate for player text metadata, weapons, and related information. It is not the render FPS or web radar send frequency.

1. Open Advanced → DMA Optimization.
2. Read the metadata target and adjacent Published figure.
3. Increase gradually when names/weapons refresh too slowly and the device has capacity. Reduce it under device pressure to leave time for body position and bone batches.
4. Observe actual Published rates instead of assuming they must equal the target.
5. The acquisition value is saved after editing ends. Restore Acquisition Defaults restores and saves default acquisition settings.

The player Acquisition Target control is fixed/disabled for normal users. Its value is a target rate, not proof of an achieved physical DMA success rate. It is not a normal-user slider for choosing an arbitrary Hz value.

DMA Executions counts cumulative execution calls. Requested KB and Completed KB measure player verification-batch bytes, while the execution count also includes standard scatter reads. Dividing those byte figures by all execution calls does not establish a uniform packet size or universal read success.

Render FPS, actual player publication Hz, metadata publication Hz, and radar sending Hz are four different numbers. A display at 144 FPS does not establish 144 player samples per second. Radar at 30 Hz does not establish 30 new bone samples from the publisher. Identify which rate is limiting the result before adjusting its corresponding controls.

Status information#

Status Information toggles overlay status text. Footer Rotation Marker toggles the small rotating mark in the menu footer. Both are on by default. Hint Color selects the status-information color.

Hint Font ranges from 10 to 32 px and shares the player Information Size field. It is not a fully independent status-text size. Some current status text has fixed layout sizes; do not expect this slider to enlarge the footer, every status message, and every menu label together.

The footer displays the map, player, PID, scene, sampled player count, model-loading state, and cloud-model mirror, with host load at the right. Names, maps, or figures showing waiting/-- before a valid match are normal. “Account cumulative reports: --” is currently placeholder text and is not an acquired total report count.

Using normal scene-model consumers#

Scene models remain on the computer running the client. The service mounts relevant regions according to the current map, location, and configured source for supported scene occlusion checks. Keep the delivered directory/resources intact and maintain connectivity to the model service.

1. Keep the complete client directory. Do not move the executable away from its resources.
2. After joining a valid match, inspect the footer's map/model state and allow time for the current region to load.
3. With a license supporting visibility, enable the player visibility settings and choose contrasting visible/occluded colors.
4. Uncovered geometry remains unknown evidence and follows the default visible display policy. Green does not prove complete scene coverage.
5. Web sharing uses bones and positions; the web-server package does not require the client's map meshes, player meshes, or real-time model directory.

Bone Model is a player bone drawing style. Scene Models provide local occlusion evidence. The first draws without a complete player-skin model download; missing scene geometry is not recalculated by the web viewer's new camera. Image assets, acquired bone data, and scene geometry are separate dependencies. Restoring an icon does not restore missing scene geometry.

Displayed or reserved items in the current interface#

The following normal-user interface entries do not have a separate effective runtime control or completed implementation in the current version. They are documented to explain the interface, not promised as completed functionality.

Display combinations and troubleshooting#

Three useful display profiles#

Observe changes in the same position and scene first. Changing maps, stream state, scopes, and multiple settings at once makes causes harder to distinguish. A saved control and valid game observations are separate facts; saving does not create game data.

Checks in order#

Player List: open, move, and read the roster#

The Player List brings currently displayable players, selected statistics, current-match performance, and cloud relationships into one table. It is an independent window from the main settings menu; an enabled list remains visible after the main menu is hidden.

Open and close the list#

1. Open Player ESP → Information and Hotkeys.
2. Enable the player roster control, named “查当局户口” in Chinese, to show the roster window. Disable it to close the window.
3. Use Player List Key to toggle the list. A new configuration defaults to U; existing configurations follow the binding displayed in that control.
4. Move the pointer to the roster title, “户口本 · 拖动此处移动” (Roster · Drag here to move), and drag it with the left mouse button.
5. Scroll vertically inside the table to see more rows. The header row stays at the top of the table. Drag the title area to move the whole window.
6. After changing the list key, statistics source, or thresholds, click Save in the sidebar.

Hiding the main menu does not close the roster. The roster and its details popup remain interactive while the pointer is over them; leaving these windows restores the applicable overlay click-through behavior. Title dragging, table scrolling, clicking a name, and clicking relationship buttons are separate actions.

Row order, count, and filters#

The current window uses a fixed order: the local squad comes first, the local player comes first within that squad, and remaining rows follow team number and name. Its headers do not provide click-to-sort controls for KD, damage, or latency.

Players identified as dead, entries without valid names, and animal entries are filtered out. Player Count in the footer is the number of rows displayed after filtering. It is not the starting roster size, the number of players seen during the entire match, or the game's official alive counter. A player can disappear after death, closing a details popup that was open for that player.

The displayed list depends on the available reading range, match state, and valid samples. An empty table does not prove there are no other players in the match. Check the active match, map and PID in the footer, and whether other current player information has appeared.

All fourteen columns#

Ordinary names for the local player and squad use teal. List relationships, danger information, and available partner/official-level markers also affect colors or badges. A colored name reflects the level marker read by the software; it does not establish a person's real identity or official job.

Roster Statistics: modes, seasons, and value sources#

Select the mode that matches your purpose#

Statistics Source under Player ESP → Information and Hotkeys controls the table summary. A new configuration defaults to Highest Ranked Tier, with Previous Season Backup enabled.

Select Ranked Squad FPP to examine first-person squad ranked performance. Highest Ranked Tier can select different modes for different players, so it is not a comparison under one shared mode. KD and KDA supplied by a source have different meanings; the highest-value selection preserves their labels rather than converting KDA into KD.

Current season, normal fallback, and previous season#

1. The software starts with the selected mode in the current season.
2. A ranked mode without valid KD can fall back to the normal mode with matching team size and perspective. Ranked Squad FPP maps to Normal Squad FPP, rather than third-person solo.
3. Highest Ranked Tier without valid ranked KD tries the highest valid displayed KD/KDA among six normal modes.
4. When the current selection and its supported normal fallback have no usable statistics, Previous Season Backup allows available previous-season data.
5. A valid current-season selection stays in use. The software does not choose previous-season statistics merely to obtain a higher number.

KD/KDA, rounds, and average damage come from one selected statistics record; they are not assembled from different modes. An available ranked tier retains ranked meaning. When normal fallback statistics appear beside an available ranked tier, inspect the KD tooltip or details to confirm the source instead of calling normal average damage ranked average damage.

Changing Previous Season Backup first changes the selection rule; missing records are then requested in the background. Network errors, pending service responses, or modes without records leave fields as --, Unranked, or another unavailable state. Toggling the control does not guarantee an immediately complete row.

Distinguish KD, KDA, and the asterisk#

Keep the KDA or * marker when reading table values. Details also show KD, KDA, or KD* as appropriate. Confirm mode, season, and denominator before comparing these ratios.

Loading behavior and practical checks#

Statistics are fetched in the background during a match, and the table uses retrieved cached records. Temporary transport failures are retried. Closing and reopening the window is not a force-refresh action. The normal interface has no Refresh All Statistics Now button.

1. Check whether the player's Kills and Damage show current-match information, separating a historical-data issue from an entirely empty row.
2. Hover over KD/KDA to inspect source, season, and normal-fallback markers.
3. Click the name to confirm the mode and season in details.
4. Examine an explicit mode before comparing Highest Ranked Tier, distinguishing missing data from a different selection result.
5. Enable previous-season backup when the selected current-season mode has no record, then allow background retrieval to complete.
6. Persistent historical-data gaps across many players call for checking the software computer's network and statistics service. Increasing ESP distance does not retrieve missing service records.

Player Details: inspect one player's records#

Open, change, and close details#

1. Find the target in the roster and click the name area.
2. The Player Details popup shows clan/name, team, level, reputation, state, candidate latency, and current-match kills and accumulated damage.
3. Open Statistics Data and select the required mode.
4. Inspect the Ranked and Normal tabs. Ranked corresponds to ranked data and Normal to normal-mode data; selecting a different source adjusts the active tab according to its mode type.
5. Read the mode, tier, KD/KDA, rounds, average damage, data source, and season identifier.
6. Press Esc to close details. Details close when that player disappears from the current list. Click another player's name to examine that player.

The details selection is for the current inspection. Opening a new player starts from the main Statistics Source setting; it does not replace saving that main setting. When Ranked says no current ranked statistics are available and suggests Normal, open the Normal tab instead of describing normal fallback as ranked statistics.

State and missing fields#

The latency question mark is a data-quality indicator. Describing 46 ms? as that player's confirmed official latency of 46 milliseconds exceeds the evidence currently available. Preserve its candidate meaning.

Blacklist and Whitelist: relationships and synchronization#

The three actions#

Relationships use the fixed game-player identity rather than the current display name. Each software account keeps its own relationships, while public blacklist count is a separate aggregate. A different software account does not inherit the previous account's list state as its own.

The Black button does not submit a report to the game, ban a target, or replace the game's block feature. Whitelist is target-selection protection inside this software. Other player identities, vehicle targets, and manual actions follow their respective rules.

Set, remove, and confirm a relationship#

1. Confirm the client is logged in normally and the roster has valid player rows.
2. Verify the name and team number. Open details first when names are similar.
3. Click Black or White on the target row. The current choice is highlighted and underlined.
4. Watch the list footer for synchronization in progress.
5. Wait for synchronization to finish, then check the row's relationship again.
6. Click None to remove a relationship and wait for cloud synchronization again.
7. Relationships are stored through the cloud account. Sidebar Save Configuration is not the relationship submission button. For a check after restarting, use the same software account and wait for its data to load.

An immediate color change means the action entered the local pending queue; it is not confirmation that the server saved it. Pending actions are retried after connection failure. Repeatedly switching Black, White, and None does not speed up synchronization; the latest selection becomes the pending choice for that player.

Interpret synchronization messages#

Before relationships are available, none of None, Black, or White may appear selected on a row. Wait for initialization; unknown and ordinary None are different states. Sidebar Restore Defaults does not bulk-delete the cloud account's relationships.

Danger Information: thresholds, colors, and priority#

Location and initial values#

These controls are under Player ESP → Information and Hotkeys. Danger conditions affect player-information display; they are not automatic ban or report decisions.

Any matching KD/KDA, average-damage, or public-blacklist condition is sufficient. Setting one threshold to zero disables that condition, leaving the other two active. Missing statistics are not treated as zero and do not trigger danger by their absence.

Adjust the controls in order#

1. Select Statistics Source first to establish which mode the thresholds evaluate.
2. Set Danger KDA and Danger Average Damage, then inspect players with known statistics.
3. Set Danger Blacklist Count above zero to use public blacklist count. A threshold of 10 matches 11, not 10.
4. Choose a readable Danger Information Color.
5. Check whether the target is already in your blacklist or whitelist, separating relationship colors from danger colors.
6. Click Save in the sidebar.

Your whitelist takes priority and suppresses danger classification. Your blacklist/whitelist colors take priority over ordinary danger information colors; partner/official markers also have their own display priorities. The roster highlights dangerous rows in red, while world-player information uses the applicable configured color. Danger information does not change skeleton colors or line width; read skeletons through ESP colors and visibility rules.

Same-Match Software Markers and Report Estimates#

Read the same-match count#

The roster footer's same-match Pluto user count is the number identified by the cloud; unavailable data shows Unknown. A fixed game-player identity identified by the cloud receives a same-match software prefix before its name.

This count differs from Player Count: the former comes from cloud software-user discovery and the latter from the table's filtered rows. It is also distinct from squad size, web-radar viewers, and room connections. Ordinary users read same-match status through the name prefix and count.

The normal social actions are blacklist/whitelist relationships. There are no Add Friend, Friend Chat, or Invite Friend to Web Room buttons. Share a web-radar room through its own viewing link, as described in the standalone radar chapter.

Report labels refer to cloud estimates#

The software creates observations from available match events such as spectator changes and kills. The cloud applies estimation rules and aggregates them under the interface's existing report labels. These values are not official game report records, confirmed reports received by the game, or ban results. They do not prove that a particular player submitted a report.

Values depend on available events, continuous sampling, cloud processing, and software account state. Entering a match, interrupted sampling, unavailable cloud data, or a finished match can result in Unknown. Do not replace Unknown with zero; a known zero also does not mean nobody has ever reported the player.

Four time ranges and display locations#

After death and entering spectator mode, the bottom estimates follow the currently valid viewed identity. Read your original identity separately from the player being watched. On a fresh spectator switch or unconfirmed identity, check names and Unknown states instead of attributing a prior target's numbers to yourself.

Handle changing numbers#

1. Identify the display: main-menu placeholder, overlay bottom, roster column, or details.
2. Confirm the local/viewed identity and selected player.
3. Distinguish current match, today, seven days, and total rather than substituting one range for another.
4. For Unknown, check match and network state and wait for recovery. Editing local settings does not create cloud records.
5. For a maintainer review, provide the exact display location, player name, range, client version, and message text. Describe the number as an estimate, not official report evidence.

Cloud Map Dots versus Standalone 3D Web Radar#

Different display destinations#

Current cloud map-dot compatibility limitation#

This version retains cloud same-match position sending and map-consumer code, with a field-format compatibility problem between the current client and that API. This manual therefore does not present cloud map dots as a usable sharing procedure for this version. Coordinate Sharing Settings on the normal settings page has no editable room, key, or friend fields.

Use the standalone 3D web radar chapter's service packages, publishing settings, and viewing links to deploy the shared skeleton webpage supplied here. It runs separately from the older cloud map-dot path; the login backend is not the standalone radar service deployment.

Recognize the existing map-consumer markers#

The map consumer filters received positions by match, map, world context, valid coordinates, and freshness. It removes stale positions and skips the local player and players already drawn locally. Its existing symbols are a cyan T for a source marked as teammate by the sender and an orange S for other shared sources. These are not web-skeleton colors or friendship buttons.

The main map and minimap each require their corresponding visible map and Show Players control; the minimap also applies a distance limit. Turning on these map controls does not resolve the current cloud position API compatibility issue. They continue to control the client's local map display.

Notices and Reminders: display and dismissal#

Permanent notices#

Permanent notices delivered by the cloud appear in the available area of the main-menu title bar. Hover over clipped notice text to read it in full. No notice text appears when title space is insufficient or no notice is supplied. A separate notice settings page is not required.

Temporary notices and reminders#

Temporary notices and reminders appear in an Information popup. Long content wraps and can scroll in the message area. Read it, then click Confirm at the lower right or × at the upper right. Current social feedback remains visible for about eight seconds before automatic dismissal; network and other operation messages can use different durations.

The popup has focus and blocks background interaction, preventing menu clicks while reading. Pending messages are processed in order, and a new revision of the same notice can be shown again. The normal client receives service notices and reminders; it has no controls to create notices, configure friend reminders, or edit service notices.

Troubleshooting the Roster and Cloud Information#

Separate four kinds of data#

One working category does not prove the other three are working. Current-match damage updating while KD remains -- calls for checking historical statistics. An open radar webpage with Unknown cloud fields calls for checking client social data.

Symptoms and specific actions#

Troubleshoot one category at a time and record exact fields and messages. Reconnecting hardware, selecting a historical mode, waiting for cloud synchronization, and restarting the standalone radar service solve different problems and do not replace one another.

Using throwable aim and future trajectories#

This chapter covers pre-throw preview, target selection, trajectory prediction, and automatic release. Observed trails after a throw, explosion-reference circles, and the central cooking timer are described under Throwable Display and Timing. These groups control different behavior; they are not multiple names for one switch.

A new configuration enables Enable Throwable Aim, Automatic Release by Flight Time, and Take Over Physical Left Button During Automatic Release. For the first familiarization run, turn Automatic Release by Flight Time off, observe a manual release, and enable automatic release separately afterward. When an existing profile is loaded, use the actual displayed state.

Automatic release does not require an enemy lock: a free preview along the current camera direction also enters release evaluation when its landing point, flight time, current grenade cooking state, and scene collision are valid. The direct stop switch is Automatic Release by Flight Time. The general aim master switch, whether a preview line is visible, and whether an enemy circle exists do not replace checking this switch.

Locations and the three operating states#

The current Missed license opens throwable features. An unauthorized or Full license does not acquire these permissions from its name. For disabled controls, check the active login license instead of changing the download channel or profile file.

First use: observe before enabling output#

1. Enter an active match. Confirm valid camera and local-player state, and connect the controller using the device chapter.
2. Open Aim Settings → Throwable Aim Configuration and turn Automatic Release by Flight Time off. To observe without software camera adjustment, also turn Enable Throwable Aim off.
3. Open Advanced Settings → General Grenade and Collision. Enable Automatic Trajectory and Show Predicted Landing Point. Keep text at 18 px and use clearly visible line and text colors.
4. Equip a throwable and enter normal throw preparation in the game. Start cooking using the game's controls; the software does not replace these game actions.
5. Change the camera direction slowly and observe the path and High Throw/Low Throw text. After switching throw mode in the game, wait for the text to update. Stop relying on the previous path while the mode is stale.
6. A normal preview shows a path, distance, and mode. A valid future landing point shows a yellow landing circle. --m, Mode Unknown, or Waiting for High/Low Throw Pose means that part of the input is incomplete.
7. Complete a manual throw and compare the path direction with the actual launch. The reference path is an estimate; a visible curve does not verify all terrain or every weapon.
8. For target aim, enable Enable Throwable Aim afterward. Begin observation with the new-profile defaults of 100 m distance, 180 px FOV, and 20% speed. A target still needs a valid selection window and fresh position samples.
9. For automatic release, use a supported controller from the table below, check the switches, preparation state, and cooking time, then enable Automatic Release by Flight Time separately.

Verify four results separately: the preview refreshes, mode text matches the game, the camera adjusts with a valid target path, and the game actually completes the throw. A line does not prove camera movement, and a controller command does not prove a game throw.

Target window and camera speed#

Increasing FOV expands candidate selection; it does not restore missing bones, bypass distance checks, or create a solvable trajectory. Increasing aim distance does not increase launch speed. Throw modes have different paths and reachable distances, so Within 100 m is not a guarantee of a valid hit.

The throwable target point currently prefers a valid head bone, then forehead. It does not inherit arbitrary body-part selection from the firearm page. The general aim switch still affects camera-movement output; automatic release has its own feature gates. Stopped camera movement does not establish that release has stopped.

Upward camera movement is part of solving the launch direction. The software aims toward the initial-velocity direction. An unsolved path, unknown scene collision, or a significant target/camera change does not fall back to directly aiming at the enemy's body. A free preview of the current direction can remain visible while camera control waits for a valid solution.

Fast target movement changes a previously calculated path. The current throwable solver uses the acquired target point and does not guarantee full velocity lead for moving targets. Predicted Hit is not final confirmation for a continuously moving player.

Fixed lock button and throw mode#

Target locking uses the fixed left mouse button. The game must also be preparing a throw without having started the throw. Holding the button in a menu is not throwable control activation.

Switch between high and low throw with the game's own binding. The software reads the actual throw state and selects its reference model. The UI's High/Low Throw Switch Key defaults to the right mouse button and records button state; it neither rebinds the game nor replaces the actual pose with the configured value.

Toggle Key defaults to G and is currently a saved retained field, without a runtime connection to the throwable enable switch. Click Enable Throwable Aim to enable or disable aiming, and click Automatic Release by Flight Time to stop automatic release. A state that does not change after G is not evidence of a keyboard failure.

Future path and landing-point settings#

The yellow future-landing circle currently uses an approximate 3.8 m reference radius. A free preview can also show an approximately 20 cm red circle at the first collision. This is a collision marker, not another 3.8 m damage area.

Predicted Landing Color and Predicted Trajectory Color change different content. A yellow future-landing circle remaining yellow after the former is changed is current behavior; inspect the reference ranges around thrown grenades/C4 instead. Observed-trail width and color are adjusted under Raycast Throwable Trajectory, separately from the preview color and fixed width here.

Direct paths, bounces, display, and release use the current solved result. Bounce preview depends on available collision geometry. The ordinary UI currently has no independent controls for bounce count, restitution, friction, integration step, or fuse length. Legacy profile fields do not establish that these controls exist on the current page.

Reading preview text and reference marks#

Some waiting states invalidate old results, so the visible preview can temporarily disappear instead of keeping every waiting message on screen. Match/weapon changes, the game mouse menu, and death also change display and control eligibility.

Reading the additional timing line#

The additional timing line appears below preview status while the local player still holds and prepares the throwable, throwable aim is enabled, and the current frame is fresh. It differs from the central cooking gauge. The retained Countdown Master setting below does not currently control it.

A new configuration currently uses a 5-second reference fuse. This is an estimated-model configuration, not a field-verified 5-second fuse for every throwable. Timed automatic release currently targets grenades; it is not a general automatic-fuse feature for flashbangs, Molotovs, blue-zone grenades, or C4.

How release time is calculated#

Automatic release uses current cooking time and this path's flight duration. It does not mean release immediately when an enemy appears. The current timing relationship is:

Planned cooking time = Reference fuse - Predicted flight - Release safety margin
Remaining wait = Maximum(0, Planned cooking time - Current cooking time)

Example: a 5.00-second reference fuse, 2.00-second predicted flight, and 50 ms (0.05 seconds) margin produce release at 2.95 seconds cooked. At 2.40 seconds cooked, approximately 0.55 seconds remain. Reaching 2.95 seconds enters command evaluation when the other gates also pass.

Changing the margin to 150 ms moves release to 2.85 seconds with the same fuse and path, 0.10 seconds earlier. It does not increase flight speed or extend the fuse. Current calculation does not automatically add the controller benchmark result as latency compensation; the margin does not mean every controller has been precisely calibrated.

Current cooking time plus predicted flight exceeding the fuse means the estimated window is already late. The code still treats the release point as reached; further waiting does not repair the missed instant. Actual game preparation, cooking, and throwing state take precedence over display text.

Conditions that automatic release requires together#

The target/camera solution is also rechecked for age and change. Current target bones must be approximately within 200 ms and camera data within 100 ms. Significant camera movement, target displacement, or leaving the selection window requires a new solution. Increasing a menu refresh setting does not bypass these validity checks.

One release session makes at most three attempts, separated by approximately 40 ms or more. These attempts wait for observable state changes; they do not represent three confirmed game throws. A device response and the game leaving preparation/entering throwing are separate evidence.

Controllers, physical-button takeover, and recovery#

KMNET takeover begins at the calculated release instant, not throughout the cooking period. Restoration observes throwing, the end of preparation, physical button-up, weapon or match changes, and uses an approximately 300 ms takeover deadline with cleanup retries.

Turning a feature switch off stops subsequent automatic-release commands. It does not retract a sent command or a throw already started by the game. An acquired takeover continues through its independent restoration or retry handling; clearing a checkbox does not establish that the device has already recovered.

These mechanisms do not eliminate uncertainty after power loss, network interruption, or a disconnected device. For Restoring Physical Left Button or abnormal physical-button behavior: disable Automatic Release by Flight Time → stop triggering further throws → reconnect KMNET in the software → verify physical down and up both work normally → repeat a manual output check.

Do not read Command Sent, Device Reply Successful, or a disappeared curve as Game Throw Completed. Completion is assessed from the game entering throwing, leaving preparation, and the visible grenade leaving the hand.

How scene models affect prediction#

Future trajectories use a reference throw model and acquired scene geometry. Dynamic objects, terrain, and static-structure coverage affect walls, floors, and bounces. A completed model load does not establish coverage of every segment required by a throw.

The current path also estimates ground height from player feet or the root. This supports reference drawing but does not fill missing wall, floor, cliff, slope, or dynamic-object geometry. A ground-estimated path does not imply complete real terrain.

With unknown scene collision, the software may still draw part of an estimated path or an origin marker. Such a path cannot currently trigger automatic release or valid target-path camera control. Restore the current map model, wait for valid samples, and check previews near obstacles before restoring automatic output.

The reference model helps inspect the current path; it does not promise field calibration for every throwable speed, pose, terrain type, and bounce. Around slopes, multiple floors, window/door edges, and moving obstacles, verify display, control, and actual launch separately.

Visible retained settings#

These ordinary controls remain visible and saved, but current reference preview does not consume them to control the corresponding display. They are listed so visible behavior is understandable; a present control is not proof of a connected feature.

Stopping, hiding, and restoring#

Releasing the left button may immediately throw through the game's own logic. It is not a universal safe-cancel action. Hiding a software menu or disabling a display item does not establish that automatic release is off. Software stopping and game-native cancellation, stowing, or completing the throw are separate actions.

Turning Enable Automatic Trajectory or Take Over Physical Left Button off alone is not the automatic-release master switch. The former can leave a target-solver path, and the latter changes held-button output eligibility. Turning Automatic Release by Flight Time off explicitly stops subsequent release commands from this feature.

Common problems and check order#

3D shared web radar#

Roles and independent deployment#

The radar consists of the software publisher, a standalone radar service, and a browser viewer. The software sends sampled players, world positions, bones, teams, weapons, states, and its source camera. The service manages rooms and relays the latest scene. Viewers open a sharing link and select their teammate by name and squad index.

The radar service operates independently of the product account backend. Its executable embeds the room administration page and 3D viewer. Running a release requires neither Go nor Node.js nor a separate frontend process. Client sign-in still uses the product account service. The radar admin token is not a software account password, and a view token is not a publish token.

Complete sequence: start service → read admin token → create room → configure client → enable sharing → send view link → viewers select themselves. Complete a local-network setup before adding a public domain and TLS. Administration and viewer controls use Ant Design with square corners. The interface defaults to light; the rendering background always stays pure black.

Deploy on Windows#

1. Download the Windows x64 server from the download center.
2. Extract the complete package to a fixed folder such as C:\Radar. Keep radar-server.exe, radar.json, and the documentation together. Do not run from a ZIP preview.
3. Open PowerShell in that folder. The server runs in this window; closing it or pressing Ctrl+C stops the service.

Set-Location 'C:\Radar'
.\radar-server.exe --config .\radar.json

Successful startup logs contain Radar listening on http://0.0.0.0:8080 and administration: /admin. 0.0.0.0 is a listening address. Use 127.0.0.1 on the server itself and its actual IP from other computers. An address-in-use, configuration parsing, directory write, or certificate error means startup has failed; resolve that error and restart.

4. In another PowerShell window, read the admin token automatically generated at first start:

Set-Location 'C:\Radar'
Get-Content .\data\admin.token
curl.exe --fail --silent --show-error http://127.0.0.1:8080/healthz

Success returns {"status":"ok"}. Connection refusal means the process is not listening there; HTTP errors make this command fail. The health endpoint proves service responsiveness, not reception of actual sampled scenes.

5. Open http://127.0.0.1:8080/admin. Other computers use http://SERVER-IP:8080/admin. Enter the token you just read.
6. When local health succeeds but LAN access fails, check Windows Firewall, host security groups, routing, and the destination IP. To permit TCP 8080 on a Private LAN, run this in an elevated PowerShell:

New-NetFirewallRule -DisplayName 'Radar TCP 8080' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8080 -Profile Private

This example matches the Private network profile. Match the rule to the actual profile and externally used port. Public deployment commonly exposes a TLS entry point while the proxy accesses an internal 8080 listener.

Deploy on Linux#

The Linux package targets x64 / amd64, not ARM. Extract everything to a fixed folder, enter the directory containing the executable, and run:

chmod +x radar-server
./radar-server --config ./radar.json

In another terminal, read the token and check the service:

cat ./data/admin.token
curl --fail --silent --show-error http://127.0.0.1:8080/healthz

Administration is at http://SERVER-IP:8080/admin, exactly as on Windows. For Permission denied, check executable permissions and mount restrictions. For Exec format error, check CPU architecture. For an occupied port, change the listener and update the client, links, and firewall together.

For continuous operation, use the included deploy/radar.service example. Place the program and configuration in /opt/pluto-radar, create a service account and data directory, then install the unit:

sudo install -d /opt/pluto-radar
sudo useradd --system --home /var/lib/pluto-radar --shell /usr/sbin/nologin pluto-radar
sudo install -d -o pluto-radar -g pluto-radar /var/lib/pluto-radar
sudo install -m 0755 radar-server /opt/pluto-radar/radar-server
sudo install -m 0644 radar.json /opt/pluto-radar/radar.json
sudo install -m 0644 deploy/radar.service /etc/systemd/system/pluto-radar.service
sudo systemctl daemon-reload
sudo systemctl enable --now pluto-radar
sudo systemctl status pluto-radar --no-pager
sudo cat /var/lib/pluto-radar/admin.token

Keep an existing service account instead of recreating it. Adapt unit paths and data directory before startup. Read logs with sudo journalctl -u pluto-radar -n 100 --no-pager and stop with sudo systemctl stop pluto-radar. This is a deployment example; distribution, systemd availability, and permissions must match the actual host.

Deploy with containers#

The Linux release includes deploy/Dockerfile and deploy/compose.yaml. They package its existing Linux executable and do not require the project source. After installing Docker and Compose, run from the Linux package root:

docker compose -f deploy/compose.yaml up -d --build
docker compose -f deploy/compose.yaml ps
docker compose -f deploy/compose.yaml exec radar cat /data/admin.token
docker compose -f deploy/compose.yaml logs --tail=100 radar

Success means the container remains running, health checks pass, and http://SERVER-IP:8080/healthz returns status:ok. Image pull, port conflict, amd64 mismatch, and volume permissions failures are diagnosed in the logs. A named volume preserves rooms and the admin token. After rebuilding or restarting, the software republishes the live scene.

Stop while retaining data with docker compose -f deploy/compose.yaml down. Do not treat down -v as a routine restart: it deletes the named data volume. Apply changed deployment settings with up -d --build. Set the real RADAR_PUBLIC_URL before public use. The release container does not compile frontend assets.

Create and manage rooms#

1. Open /admin, enter the admin token, and click Connect administration (接入管理). It is retained in the current browser session. Log out (退出) clears that saved session token.
2. Enter a room name, such as “Tonight's squad.” Lifetime in hours (有效时长) defaults to 24 and accepts 0.01–168. This controls room lifetime, not software license duration.
3. Click Create room (创建房间). Copy the server address, room ID, publish token, and teammate view link from Connection details (接入信息).
4. Give the publish token to the person running the software and the view link to viewers. Viewers do not require the admin token.
5. Current rooms (当前房间) shows publisher online state, viewer connection count, latest scene age, stale state, and expiry time. It refreshes every 10 seconds while visible; Refresh (刷新) updates it immediately.
6. Connect / share (接入 / 分享) reveals an existing room's details again. Each new room has its own tokens; persisted room credentials survive a server restart.
7. Revoke (撤销) requests confirmation. Confirmation immediately disconnects publisher and viewers and invalidates the old credentials and link. Expired rooms are also invalid; create another and use its new ID and credentials.

Copy buttons depend on browser clipboard permissions and secure-context support. When copying is denied, select the field text and press Ctrl+C. Copy the actual token, not the password masking symbols.

Configure sharing in the software#

Open Advanced settings → 3D shared web radar (高级功能设置 → 3D 网页共享雷达). This replaces the previous web radar entry.

Example: a LAN server at 192.168.1.50, port 8080, uses http://192.168.1.50:8080. A publisher on the server itself uses http://127.0.0.1:8080. View links need an address accessible to teammates: 127.0.0.1 on a teammate's computer refers to that teammate's own computer.

Deploy at the origin root. Do not enter /admin, a viewing link, #room=..., or embedded URL usernames/passwords. The exact publishing endpoint is /ws/publish. Bare IPv6 is normalized; an explicit IPv6 URL with a port is http://[IPv6-ADDRESS]:8080.

Save the fields and enable sharing. The interface publishes settings to the runtime; changing connection settings rebuilds the connection. Read the error text in this area instead of interpreting successful saving as successful connection.

For example, 50 KiB per frame at 20 Hz is about 1000 KiB/s of uploaded scene JSON. Ten continuously watching viewers add roughly 10000 KiB/s of scene relay output. Actual traffic changes with player/bone counts, rate, slow-viewer frame replacement, and networking.

View the page and select yourself#

1. Open the administrator's full link, including /#room=...&token=.... Opening the service root with the client button does not automatically select a room.
2. Without complete credentials, Connect shared room (连接共享房间) appears. Enter the room ID and view token, then click Connect room (连接房间). Close (关闭) dismisses the dialog; Disconnect (断开连接) stops this page's connection.
3. Once the top bar says Connected (已连接), wait for the publisher. The left teammate list shows squad index, name, alive/downed/dead state, and the sharing source marker.
4. Select your own “index · name.” The page follows a stable player ID within that match. Temporary absence preserves the selection instead of silently switching to someone else.
5. After a match change or reload, it attempts a unique name-and-squad-index match. Select manually again when that player is absent or the match is ambiguous.
6. Normal rendering shows bones, names, distance relative to the selected teammate, weapon, kills, state, and source visibility. Missing fields display unknown values; unknown kills / squad indices may be -1, not actual statistics.

The selectable list contains teammates present in the source scene. The page does not invent teammates when publisher team or body sampling is unavailable. Waiting scenes clear previous-match targets. Room authentication and having a drawable scene are separate conditions.

Actual camera, estimated camera, and orbit view#

The estimated eye uses a valid head bone first. When missing, it uses approximate body heights for standing, crouching, prone, or downed states. Missing head/stance data reduces accuracy. Distances use the selected body position; browser XYZ coordinates are displayed in metres.

Light / dark UI, hidden borders, and pure-black fullscreen#

Choose Light (浅色) or Dark (深色) in the top bar. Light is the default. The preference is stored for this browser origin and shared by administration and viewing pages. The rendering area always remains #000000, even with a light interface.

Select Hide border (隐藏边框) on the left to remove the normal view's outer frame. This does not automatically hide labels or controls. Selection, follow/orbit, estimated FOV, eye offset, grid, teammate visibility, and border settings persist in the same browser. Clearing site storage resets these preferences.

Click Fullscreen (全屏) at the upper right. Native browser fullscreen shows pure black and bones and hides names, information labels, head points, grid, crosshair, status HUD, frame border, connection messages, and controls. Press Esc to return and restore your previous preferences. Exit before changing players, editing settings, or checking errors. A fullscreen view with no valid bones is black; exit to inspect missing/stale data.

A rejected request displays Fullscreen not enabled (全屏未开启). Use a browser with native fullscreen and activate it directly with the page button. An iframe host must permit fullscreen. Mobile/tablet behavior follows the actual browser API support.

Bone colors, information, and sample age#

Colors retain the publisher's visibility judgement. Selecting another teammate changes camera and distances without recomputing that teammate's occlusion. Bone endpoints preserve their own source visibility fields. Models, meshes, and complete map geometry remain on the software computer; the viewer neither uploads them nor recomputes collisions. The reference grid is not visibility evidence.

Age adds original sample age, service relay elapsed time, and elapsed time since browser reception. The displayed “received … ms” excludes unmeasured one-way network transit before reception; it is not complete end-to-end latency.

Higher transmission Hz does not refresh old bone samples. The viewer reconnects after network interruption. Revoked rooms or invalid credentials require valid credentials again. The service supplies its latest complete scene to new viewers; after process restart the publisher must send live scenes again.

Server configuration, capacity, and precedence#

Restart after editing radar.json. Precedence is JSON file → environment variables → explicit command flags; later sources override earlier ones. --config selects the file. Relative data/certificate paths resolve from the process working directory.

String environment variables are RADAR_CONFIG, RADAR_LISTEN, RADAR_DATA_DIR, RADAR_PUBLIC_URL, RADAR_ADMIN_TOKEN, RADAR_TLS_CERT, and RADAR_TLS_KEY. RADAR_ALLOWED_ORIGINS takes comma-separated additional origins. Prefer controlled files/environment for admin credentials over plaintext command history.

Inspect the executable's complete startup flags:

.\radar-server.exe --help

Client transmission rate, sampled player/bone counts, server limits, viewer count, and outbound bandwidth jointly determine load. The distance field currently has no publishing filter consumer. Slow viewers replace old pending scenes with newer ones. The server does not accumulate unlimited history or record a full-match replay. For stutter, reduce transmission rate and verify fresh source samples and networking before increasing server resources.

Domain, HTTPS, and reverse proxy#

Prepare a domain resolving to the server and a valid TLS certificate. Deploy the whole radar at the origin root, not under a /radar/ homepage subdirectory. The static website and standalone radar can use separate domains. Downloading the website bundle itself does not run a radar service.

Native TLS example, with certificate files placed in the service folder:

.\radar-server.exe --config .\radar.json --listen 0.0.0.0:8443 --public-url https://radar.example.com:8443 --tls-cert .\cert.pem --tls-key .\key.pem

The client uses https://radar.example.com:8443 or wss://radar.example.com:8443/ws/publish. HTTPS viewer pages use WSS. The client verifies certificates through system trust; fix self-signed, expired, or hostname-mismatch errors before use.

For Nginx or another reverse proxy, listen on 127.0.0.1:8080 and set publicURL to the external https://radar.example.com. Proxy the entire origin, preserve Host, forward WebSocket Upgrade/Connection, and allow long-lived connections. Included deploy/nginx-radar.conf requires real domain and certificate paths and does not combine the radar with the account backend. Typical 404 causes are incorrect paths; 400/403 causes include Upgrade/Origin; 502 means the proxy cannot reach the radar process. Keep browser, service, and proxy aligned on the public origin.

Maintenance, backup, and upgrade#

Stop the service before copying the full dataDir, configuration, and deployment settings to protected storage, then restart. Automatically generated credentials need admin.token; room credentials are in rooms.json. An explicitly configured admin token remains in its environment/configuration and is not automatically written to a new admin.token. Keep data outside public website downloads.

Upgrade sequence: record current version/settings → stop → back up executable and dataDir → replace program/deployment files → retain data/configuration → start → check health → inspect rooms → reconnect publisher → verify viewer bones/status. On failure, stop the new process and restore the old executable, configuration, and required data backup. For a client upgrade, exit the software, retain Config under the same Windows user, and do not mix old DLLs with a new EXE.

Troubleshooting step by step#

Installation, sign-in, and main interface#

Radar connectivity and rooms#

Rendering and camera#

What to record for support#

Record client version, OS, page/control, exact actions, expected and observed results, actual account permission, and device state. For radar also record server OS/port, access method, publisher state, sent/acknowledged counts, valid player/bone counts, frame bytes, camera mode, age, and error code. Hide passwords, license keys, admin tokens, publish tokens, and full viewing links in screenshots. Change one setting per attempt and record the outcome to distinguish parameters, sampling, and networking.

Glossary and operating sequence#

Beginner sequence: extract and sign in → connect devices → confirm valid scene/drawing → resolve duplicate hotkeys → check aim/recoil per weapon → save configuration → deploy standalone radar → create room → enable sharing → viewers select themselves → tune display/fullscreen. Confirm the corresponding state before advancing to the next step.