Mir Vengeance – Pre-Launch Lockdown Progress

Vengeance Admin

Today wasn’t flashy.
It wasn’t visual.
It wasn’t “new feature” day.

It was something far more important.

Stability. Control. Clean builds.

We’re officially in the final stretch before testing begins.

1. Client Launch Behaviour – Locked Down

One of the biggest structural rules of Mir Vengeance is simple:

Client.exe should never run on its own.

Previously, if someone launched Client.exe directly, they would see a message:

“Please launch the game via MVP.exe.”

That worked — but it wasn’t ideal.

Today’s Improvement

Now when Client.exe is run directly:

  • It checks for MVP.exe in the same folder.
  • If found → it automatically starts MVP.
  • Then exits.
  • If not found → shows the original warning message.

This creates a seamless experience.
No confusion. No broken launch flow.

The launcher is now the single gateway into the game.

2. Version Numbers – Confirmed & Standardised

We reviewed how version numbers are handled across:

  • Client
  • MirVengeancePatcher (MVP)

Both are currently using the SDK default:

1.0.0.0

The version displayed in the UI comes from:

Application.ProductVersion

No hardcoded inconsistencies.
No mismatched display logic.

Clean. Predictable. Ready for proper semantic versioning when public builds begin.

3. Build Warnings – Eliminated

This one matters more than most people realise.

Today both:

  • Client
  • MVP

Build with:

✅ 0 warnings

What was addressed:

Client:

  • Nullable annotations
  • Unused variables
  • Incorrect rethrow patterns
  • WindowsBase conflicts
  • Assembly warnings

MVP:

  • WindowsBase conflict
  • Nullable warnings in AMain.Designer.cs

Zero warnings means:

  • Cleaner future refactoring
  • Safer upgrades
  • Less hidden technical debt
  • More predictable behaviour

Pre-launch software should not be full of yellow triangles.

Now it isn’t.

4. AutoPatcherAdmin – Smarter Exclusions

The patch system now excludes unnecessary files and folders.

Added file exclusion:

launcher_credentials.dat

Added folder exclusions:

cs, de, es, fr, it, ja, ko, ol, pt-br, ru, tr, zh-Hans, zh-Hant
Resources
ClientLogs
DirectX/EBWebView

This ensures:

  • No dev junk gets pushed.
  • No language packs are accidentally included.
  • No browser runtime clutter.
  • Smaller, cleaner patch manifests.

Professional patch hygiene.

5. Client Log Output – Silenced for Production

During development, logs are helpful.

During release testing?
They become noise.

Today we disabled writing to:

  • Error.txt
  • Items.log
  • StorageTrace.log
  • ItemInfoList_Summary.log

We also removed the redundant Error.txt write inside the HttpRequestException handler and updated localization strings accordingly.

This means:

  • No random log files appearing in player folders.
  • Cleaner installs.
  • Less confusion during testing.

If logging is needed again, it will be behind controlled debug flags.

What Today Really Was

Today was not about adding content.

It was about:

  • Tightening entry points.
  • Removing legacy clutter.
  • Cleaning patch output.
  • Eliminating build noise.
  • Enforcing launcher authority.
  • Preparing for real testing.

This is what pre-launch engineering looks like.

Not glamour.
Not screenshots.
Just discipline.

Status

  • Launcher control:
  • Clean builds:
  • Patch exclusions:
  • Logging hardened:
  • Ready to begin structured testing: Yes.

We are closer than we’ve ever been.

Tomorrow we start breaking it on purpose.

Categories: