🎮 HLStatsX.NET

Welcome to HLStatsX.NET

A modern rewrite of HLstatsX Community Edition for Half-Life engine games, built to preserve what made the original useful while replacing the parts that made it increasingly hard to maintain, extend, and deploy.

Research-driven overview Legacy Perl + PHP to .NET 10 Web, daemon, and scheduled workers

HLstatsX has always been more than a scoreboard. It is a real-time stats and ranking system built around the culture of community servers: kills, sessions, awards, ranks, chat, clans, map performance, and the long tail of game-specific events that keep old multiplayer communities alive. The original Community Edition earned its place because it solved a real problem well - parse the stream of server logs, put the data somewhere durable, and turn it into a site people actually want to check.[1]

HLStatsX.NET starts from that same respect for the original design. The point is not to reinterpret the product into something unrecognizable. The point is to keep the feature set, the data model, and the spirit of HLstatsX intact while giving it a platform that matches modern software expectations. In the current codebase, that shows up as a deliberate split into a web app, a real-time daemon, an awards worker, a core domain layer, and an infrastructure layer, all targeting .NET 10.[2]

What this project actually is

The simplest description is still the best one: HLstatsX Community Edition is a real-time statistics and ranking system for Source engine based games. Its historical architecture is equally direct: a Perl daemon parses streamed game logs, MySQL stores the resulting data, and a PHP site renders the public and admin interfaces.[1]

HLStatsX.NET keeps that model, but updates the way it is expressed in code. The current repository already reflects a cleaner, service-based structure: HLStatsX.NET.Web for the site, HLStatsX.NET.Daemon for live log ingestion, HLStatsX.NET.Awards for batch maintenance tasks, HLStatsX.NET.Core for interfaces and shared models, and HLStatsX.NET.Infrastructure for EF Core and MySQL access.[2]

That is an important distinction. This is not a marketing rewrite that only covers the public pages. It is an attempt to replace the entire operational shape of HLstatsX: the web UI, the daemon, and the maintenance jobs that make the statistics credible over time.

Why a rewrite was needed

Reason 1

One product was spread across multiple aging runtimes

The original system works by combining Perl, PHP, MySQL, and a large amount of game-specific logic. That split made sense in its time, but it means maintainers have to keep several mental models and deployment assumptions alive at once. Every operational improvement becomes a cross-stack exercise.

Reason 2

Maintenance had drifted into compatibility work

The archived Community Edition README points users to newer forks for updated PHP compatibility, and even highlights GeoIP2 work driven by changing external requirements.[1] That is a strong sign that keeping the old stack alive was consuming effort that could otherwise go into actual features and long-term cleanup.

Reason 3

Legacy code can preserve behavior while still blocking progress

HLstatsX is full of details that matter: ranking rules, event handlers, map and weapon breakdowns, awards, admin tools, live stats, and game-specific special cases. The legacy PHP pages and Perl handlers remain an excellent behavioral specification, but they are not an ideal foundation for the next decade of development.[2]

Reason 4

Modern users expect stronger deployment and security defaults

Community software now lives in containers, cloud VMs, reverse-proxied Linux hosts, and automated CI pipelines. It also needs safer defaults around authentication, cross-site scripting, and CSRF. Rewriting on a modern framework is not just a style preference; it is an operational upgrade.[3][6]

The old HLstatsX stack proved the product idea. The rewrite exists because the maintenance model no longer fits how people build, host, secure, and contribute to software today. That is a preservation argument as much as a modernization argument.

Why .NET is a sound choice

Platform fit

One ecosystem for web and background services

Microsoft positions ASP.NET Core as cross-platform, open source, fast, secure, and suitable for apps and services that run on Windows, Linux, and macOS.[3] The same .NET platform also supports long-running worker services with built-in hosting, configuration, DI, and logging.[4]

Architecture fit

It maps naturally onto HLStatsX's real shape

HLstatsX is not just a website. It needs a web UI, a log-processing daemon, and scheduled maintenance jobs. .NET handles all three with a consistent hosting model. That makes it a better fit than forcing the project to remain split between unrelated stacks.

Support fit

.NET 10 gives the rewrite a stable runway

The current repository targets .NET 10, and Microsoft's support policy lists .NET 10 as an LTS release with support through November 14, 2028.[2][5] For a long-lived community project, predictable servicing matters.

Operations fit

Modern deployment stops being a side quest

Worker services are explicitly documented for long-running background processing and containerized deployment.[4] The HLStatsX.NET project guide already points toward Docker and reverse-proxy hosting, which is exactly the sort of hosting model a modern game-community project should be ready for.[2]

Security fit

Safer framework defaults are part of the payoff

ASP.NET Core documents built-in protections and guidance for issues such as XSS and CSRF, along with standard authentication support.[3][6] A rewrite cannot fix every design choice automatically, but it does move the project onto a platform with first-class security primitives.

Developer fit

Clarity beats nostalgia

A strongly typed, testable C# codebase with explicit layers is simply easier to reason about than a hybrid of procedural PHP pages and Perl event handlers when you want new contributors, safer refactors, and fewer accidental regressions.

Why this rewrite already feels real

Projects
5

Web, daemon, awards, core, and infrastructure projects are already separated in the current solution.

Target framework
net10.0

Every main project and the test project currently target .NET 10.

Database access
MySQL + EF Core

The rewrite keeps compatibility with the established HLstatsX data world while using modern data access and DI patterns.

Parity strategy
Spec first

The PHP implementation remains the authoritative reference, which helps the rewrite preserve behavior instead of losing it.

Just as importantly, the rewrite is not starting from zero. The project guide shows broad feature coverage already in place across player rankings, profiles, clans, weapons, maps, servers, awards, search, and major parts of the admin and daemon story, with the remaining gaps narrowed to specific pages and deferred subsystems rather than missing foundations.[2]

That matters because a serious rewrite needs more than good intentions. It needs proof that the replacement can actually absorb the weirdness of the original system. HLStatsX.NET already looks like a codebase that understands that responsibility.

The important thing to understand: this rewrite is not rejecting HLstatsX's history. It is taking the old behavior seriously enough to preserve it, while moving the implementation onto a stack that is easier to host, easier to extend, easier to test, and more realistic to maintain.

Welcome, then, to the next version of a very old idea

The best community software usually survives because somebody decides it is still worth caring for after the original environment has moved on. That is what HLStatsX.NET feels like: not a flashy replacement for its own sake, but a careful argument that classic game communities deserve software built for the present, not frozen in the assumptions of the past.

If the legacy Perl and PHP code proved that HLstatsX could become part of server culture, this rewrite argues that it can still matter in a modern stack. And .NET is a sound choice precisely because it lets the project treat web delivery, long-running background work, deployment, security, and maintainability as parts of the same system instead of separate battles.

Sources and research notes

  1. Archived HLstatsX Community Edition README describing the original architecture and current archived status: https://raw.githubusercontent.com/NomisCZ/hlstatsx-community-edition/master/README.md
  2. Current HLStatsX.NET local repository review, including project structure, feature map, .NET 10 targets, and deployment notes from CLAUDE.md, project files, and program startup code.
  3. Official Microsoft ASP.NET Core overview: https://dotnet.microsoft.com/en-us/apps/aspnet
  4. Microsoft Learn documentation for .NET worker services: https://learn.microsoft.com/en-us/dotnet/core/extensions/workers
  5. Official .NET support policy, including .NET 10 LTS lifecycle: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
  6. Microsoft Learn guidance on CSRF protection in ASP.NET Core: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery