CombatGunSSS

[2.0.6] - 2026-05-14

Fixed

🔴 GunListener.isFriendlyFire() — Scoreboard team detection using wrong scoreboard (Critical)

• Root cause: shooter.getScoreboard() and targetPlayer.getScoreboard() return each player's personal scoreboard view, which may differ between players when a scoreboard plugin assigns individual views. Team membership is defined on the main scoreboard, so using a personal scoreboard could return null even when both players are on the same team — or vice versa, allowing players to bypass friendly-fire restrictions.
• Fix: Replaced both player.getScoreboard() calls with a single Bukkit.getScoreboardManager().getMainScoreboard() lookup. Team membership is now always evaluated against the authoritative server scoreboard.

🔴 GunListener — Memory leak in recentDamage map (Critical)

• Root cause: recentDamage entries were only evicted by pruneRecentDamage(), which runs after each shot. Players who disconnected (crash, /kick, network drop) or died without triggering a subsequent shot by another player left stale DamageRecord entries in the map indefinitely, growing unbounded on long-running servers.
• Fix: Added recentDamage.remove(p.getUniqueId()) to both onQuit() and onDeath() event handlers, ensuring entries are cleaned up immediately when a player leaves or dies — in addition to the existing TTL-based pruning.

🟡 GunListener — Shared static Random causes thread contention and predictable spread (Medium)

• Root cause: private static final Random RANDOM = new Random() is shared across all usages of GunListener. Java's Random is thread-safe via internal synchronization, which causes lock contention when multiple players fire simultaneously, and its LCG algorithm produces correlated sequences when called rapidly — making bullet spread slightly predictable.
• Fix: Replaced the shared field with a private helper rng() that returns ThreadLocalRandom.current(). Each thread gets its own independent, higher-quality RNG with zero contention. All three RANDOM.nextDouble() call sites updated to rng().nextDouble().

🟡 StatsManager — Unsynchronized async DB access on shared connection (Medium)

• Root cause: flushBuffer() is synchronized on the StatsManager instance, but incrementGunKill() and getGunKills() — both called from async tasks — are not. All three methods share the same JDBC Connection. Concurrent execution of flushBuffer() and incrementGunKill() could interleave SQL transactions, causing SQLITE_BUSY errors, corrupted auto-commit state, or inconsistent read results in getGunKills().
• Fix: Marked both incrementGunKill() and getGunKills() as synchronized. All three DB-touching methods now synchronize on the same monitor (the StatsManager instance), serializing access to the shared connection without requiring a connection pool.

---