ShotDebugReport.hpp File Reference

Wire-format types for the PR-20 lag-comp shot debug visualizer. More...

#include "ecs/components/Hitbox.hpp"
#include <cstdint>
#include <glm/vec3.hpp>
#include <vector>

Include dependency graph for ShotDebugReport.hpp:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
struct	net::shotdebug::WireCapsule
	One capsule on the wire. More...
struct	net::shotdebug::ReportHeader
	Header that precedes the variable-length per-target body of the SHOT_DEBUG_REPORT packet. More...
struct	net::shotdebug::TargetHeader
	Per-target sub-header preceding the variable-length capsule list. More...
struct	net::shotdebug::ShotDebugCapture
	Server-side runtime capture of one shot's debug data, produced by WeaponSystem::handleFire and consumed by ServerGame (which serialises into the wire form above and sends to the shooter via Server::enqueueTo). More...
struct	net::shotdebug::ShotDebugCapture::Target
	Per in-range target's REWOUND capsule list at fire-time. More...

Namespaces
namespace	net
namespace	net::shotdebug

Variables
constexpr std::uint16_t	net::shotdebug::k_missClientId = 0xFFFFu
	Sentinel hitTargetClientId meaning "shot missed all targets".

Detailed Description

Wire-format types for the PR-20 lag-comp shot debug visualizer.

Carries everything a single hitscan shot resolved on the server needs to be drawn on the shooter's screen alongside the client's own snapshot of the same moment:

• shooter origin + direction + range (server's view)
• hit target (or sentinel for miss) + hit point + body region
• per in-range target's REWOUND capsule list (the historical sample the server actually raycast against)

Combined with the client's own captured "where I aimed" + "what I saw the targets looking like at fire-time", the debug UI renders blue (client) vs red (server) capsules and rays, so the player can SEE lag-comp alignment errors directly.

Sent ONLY to the shooting client. Not broadcast — every other client has zero use for this data and the bandwidth would scale quadratically with player count.

Wire layout (POD, little-endian — all hosts in this project are LE x86 / arm64; this isn't a portable wire spec):

struct ShotDebugReport { uint32_t shotInputTick; // matches client's clientPredictTick at fire uint16_t hitTargetClientId; // 0xFFFF = miss uint8_t hitRegion; // BodyRegion enum value, 0 on miss uint8_t numTargets; // count of TargetSnapshot blocks following float originX, originY, originZ; // server's eye position at fire float dirX, dirY, dirZ; // server's shot direction (unit) float range; // hitscan range float hitX, hitY, hitZ; // server's resolved hit point // numTargets × { // uint16_t targetClientId; // uint8_t numCapsules; // ~12 typical // uint8_t _pad; // numCapsules × WireCapsule // } }

One report at N=12 capsules × 1 target = 16-byte header + per-target header (4 B) + capsule (32 B × 12 = 384 B) ≈ 410 bytes / shot. At 10 shots/sec from one player = 4 KB/s on the shooter's downlink. Negligible.