A modern reimagined player account manager for Freelancer Server, redesigned for large-scale game builds, Unicode support, asynchronous processing, and extensible architecture.

DCAM (Dvurechensky Account Manager / DS Account Manager Rework) is a redesigned tool for analyzing, visualizing, and managing player account data on a Freelancer server.

Legacy account managers were originally created in an era with very different constraints:

• smaller game builds
• simpler data structures
• limited encoding requirements
• minimal architectural expectations

Over time, it became clear that the old approach:

• does not scale well
• breaks on large modifications
• fails with non-Latin encodings (e.g., Cyrillic)
• is difficult to extend
• and does not fit modern infrastructure needs

As a result, the project was rebuilt from scratch with a focus on:

• clean and maintainable architecture
• support for large-scale game data
• modern .NET practices
• proper Unicode handling
• asynchronous processing
• extensibility for future services

I, Dvurechensky, decided to rebuild this tool almost from scratch, because the original approach no longer matched the real-world requirements of my project.

Historically, the tool was known as:

• DCAM
• DC Account Manager
• DS Account Manager

However, it was designed for significantly smaller datasets and simpler game environments than those I work with today.

My game — and even the base Freelancer project — could take 10+ minutes to process.

This is unacceptable for modern workflows, especially when the tool is used regularly as part of a larger pipeline.

The original tool was designed for an English-only environment and lacked proper localization support.

I needed a tool that works naturally in a multilingual environment, including Russian.

When processing game data containing Cyrillic text, the old tool produced:

• ????????????
• corrupted symbols
• broken text formatting

This made parts of the data unreadable or unusable.

The original tool relied heavily on XSD-based structures.

This approach:

• is outdated
• difficult to maintain
• does not scale well
• and does not align with modern .NET development practices

The old project suffered from a classic issue:

• business logic
• data handling
• UI logic
• event handling

were often all placed in a single file.

For example, MainWindow.cs could easily exceed 2000+ lines of mixed responsibilities.

This made:

• maintenance
• testing
• refactoring
• feature development

significantly harder.

Most logic was executed synchronously and sequentially.

This resulted in:

• blocked UI
• poor performance on large datasets
• lack of scalability
• painful future development

The original tool was too isolated and difficult to integrate into a larger system.

I needed integration with:

• custom anti-cheat services
• internal tools
• synchronization with the Lizerium portal
• and a broader engineering ecosystem

This is not a minor refactor — the project was fundamentally redesigned.

The project was migrated from a synchronous execution model to an asynchronous architecture.

This enables:

• non-blocking UI
• faster processing
• better scalability
• readiness for heavy workloads

The old stack:

• DataSet
• DataTable
• XSD designers

was completely removed.

Reason:

XSD designers are not supported in modern .NET versions (.NET Core / 5 / 6 / 7 / 8)

The project now uses:

• List<T>
• POCO classes
• DTO models

This provides:

• clearer data structures
• better serialization/deserialization
• improved testability
• easier refactoring
• modern engineering practices

The project now follows:

• MVP pattern
• service layer separation
• clear responsibility boundaries
• extensible architecture

Principles applied:

• SOLID
• UI / logic separation
• testability
• component reuse

Responsible for:

• workflows
• user actions
• service coordination
• data transformation

It must remain independent from specific UI implementations.

Responsible for:

• rendering
• UI events
• forwarding user actions

No business logic should live here.

This allows:

• testability
• reusability
• UI framework independence

The project is evolving beyond a simple account manager into a solid engineering foundation.

• faster account processing
• full Unicode support
• deeper game entity analysis
• integration with internal services
• anti-cheat integration
• synchronization with Lizerium infrastructure
• modular rework of legacy components

Based on the legacy tool:

Previously developed and maintained by:

• cannon
• josh
• ktstgt

This project aims not to replace its legacy, but to preserve its core ideas and evolve them into a modern system.

This means:

• some features may be missing
• some functionality may still be in migration
• internal components may be under redesign

If you want to contribute, you are welcome to:

• explore the architecture
• suggest improvements
• help restore missing features

Likely based on:

• flhash.exe
• author: [email protected]
• date: 2003-06-11

Likely based on:

• flfachash.exe
• author: Haenlomal
• date: October 2006

See: CHANGELOG.md

See: LICENSE

This is not just a rewritten legacy tool.

It is an attempt to:

• preserve valuable engineering ideas
• eliminate technical debt
• modernize architecture
• and prepare the tool for real-world usage in large-scale game ecosystems

What used to be a simple utility is now evolving into a fully-fledged, extensible, and engineering-grade application.