MHServerEmu Progress Report: October 2025

Time for the spookiest MHServerEmu Progress Report of the year. Again.

Minor Improvements

The work on 0.8.0 is going full steam ahead. This is our final major stable release in the 0.x series, and a lot of work that remains comes from the laundry list of “do it sometime later”. Well, “later” is now, and these things need to be taken care of.

In October I have spent some time to cross out a number of minor things from this list. Here are some of them:

• Implemented the floor selection dialog when interacting with the elevator in Avengers Tower in Chapter 10.

• Implemented orb effect reduction based on shrinkage progress when it is picked up.

• Implemented credit drops when hitting Doop for a high enough percentage of his health in a single hit.

• Implemented the CombatActive flag, which prevents players from getting loot in some cases if their heroes are not engaged in combat.

• Players now get some mission loot drops even if they are not near the loot source entity, as long they have contributed to the mission.

• Ported the improved RepVar system implementation from MHServerEmu2013, resulting in some validation issues related to the Party system being resolved.

• Fixed a number of issues with item-based procs not being unassigned when they should.

This is just the beginning of the polishing stage. More minor improvements and fixes like this will be coming over the course of 0.8’s development.

Web API Overhaul

Most of my October development efforts went into overhauling our server’s web API implementation. Before I go into what exactly I have been doing, I would like to provide some context.

There are two ways for MHServerEmu to communicate with the outside world. The primary way is via stateful connections based on TCP sockets: this is how the vast majority of client-server communication happens. The other way is by using stateless HTTP connections: the game originally used them for the initial authentication step in the login process, as well as to access the Billing service when purchasing G bundles via the in-game web browser.

Previously, we had a very rudimentary HTTP server implementation that we used from the very early days of MHServerEmu for authentication. Over time I also bolted on some additional functionality to use the same “AuthServer” as a web API for simple features, like creating accounts and retrieving performance metrics. However, this original implementation was done in quick way just to get things going, and it needed major changes to keep up with the increasing functionality and performance requirements.

Here are some of the problems the old implementation had:

• Adding new endpoints and changing the output of existing ones required modifying existing code in multiple places, which was unintuitive and bug-prone.

• We were doing essentially server-side HTML rendering, which involved some wheel reinventing and could potentially cause performance issues that would affect the rest of the server.

• There were very few security measures, which made it a prime attack vector for potential attacks on the server.

I knew this would require a major rewrite for a long time, so I avoided implementing features that rely heavily on HTTP requests, such as making use of the in-game “Add G” panel. Now that the game is in an almost feature-complete state, I have the time to take care of this properly.

Here is what I did to address the issues:

• Endpoints are now represented by classes that implement methods corresponding to standard HTTP request methods (e.g. GET requests are handled by an implementation of the Get() method). Instances of these classes are created and registered using dependency injection. This encapsulates individual endpoints into separate classes / files and allows us to add and modify them without changing the lower level code. (This section reads somewhat like an OOP textbook, but I believe going with the popular approach was the appropriate solution in this particular case.)

• Endpoints now use JSON as the default serialization format for both input and output. All HTML rendering functionality has been moved into a JavaScript-based “dashboard” application that runs in the user’s browser. This approach allows the server to avoid doing unnecessary work and enables more in-depth frontend customization without modifying the backend code.

• Additional security measures have been implemented, including more robust exception handling and rate limiting. There is more than can be done on this front, and I will continue working it all the way to 1.0 and beyond.

At the time of writing this, I have finished porting all of our existing web API functionality to the new JS-based dashboard. Here is an example of what the new graphical representation of the /RegionReport endpoint looks like:

This JS dashboard is intended to be more of a reference implementation: users are free to customize the representation of data provided by the server’s web API however they like.

This is only scratching the surface of what is now possible. The next item on the list is restoring the in-game “Add G” panel, which we are going to use to convert Eternity Splinters to Gs without relying on chat commands. In the long term, we now have a much more user-friendly way of interacting with the server, which we will most likely use to make certain server management functionality more accessible, such as granting accounts special priviliges. However, exposing features like this to the web API inherently includes potential security risks, so we need to be careful when implementing them.

PvP

AlexBond is back again to talk about his work restoring the last remaining game activity - PvP.

---

Hey to all PvP enjoyers, AlexBond here. The time has come to bring back the game mode nobody cares about. I am talking about Fire & Ice PvP, which remained stuck in the beta stage.

Not many people know this, but there were actually two other PvP modes in development. The plan was to release them by the Holidays 2013, but the Holidays never came…

We have two other PVP modes planned, including a large “strategic” PVP map that involves killing a bunch of mini-bosses, capturing nodes, cutting off supply lines and ultimately destroying the enemy headquarters. This should be done by the Holidays.

Unfortunately, version 1.52 contains assets only for a single PvP mode, referred to internally as DefenderPvP. However, there are prototypes for unreleased PvP regions. Here is what they were going to look like:

NexusPvP (Nexus War)

SvartalfheimPvP

FactionPvP (this mode was available in older versions of the game)

DangerRoomPvP

DefenderPvP (Fire & Ice PvP, this is the mode available in 1.52)

This mode is controlled by a class called PvPDefenderGameMode with its data defined in PvPDefenderGameModePrototype:

The primary functionality of this mode is managing three types of mobs:

• Attackers: packs of ranged and melee mobs that spawn every 35 seconds at your team’s base and move towards the enemy team’s base.

• Turrets: immobile ranged mobs that defend the way to your team’s base.

• Defenders: ranged mobs that stand in team bases. Defeating the opposite team’s Defender is the victory condition.

Every kill in this mode is reported by a banner (a text message in the middle of the screen). Occasionally kills also trigger voice lines based on what is defined in the main prototype.

There is also a number of score statistics defined in the PvPScoreEventHandlerPrototype that need to be tracked to be displayed in a scoreboard. This prototype specifies column indices for a ScoreTableSchema:

Data for most columns is tracked via EntityDead and AdjustHealth game events. The exception for this is Runestones, which is tracked through the OnPropertyChange() callback for the RunestonesAmount property.

I was confused when I was working on implementing event handling for this because inside ScoreTableSchemaPrototype there is also a field called Event that is always set to Invalid…

At first, I mistakenly assumed that this is where tracking events are defined, but it turned out PvP events are actually defined through EventHandler. While looking into this, I also discovered Gazillion’s plan for creating similar scoreboards for X-Defense and Holo-Sim, but it appears they decided not to do it.

The scoreboard UI that displays tracked data has issues: columns names are offset by one. Unfortunately, this cannot be fixed server-side…

There are also hidden mechanisms for boosting new players in PvP modes. These boosts increase outcoming and reduce incoming damage. Here is an example of a curve for such boost:

Each consecutive match reduces this boost. In fact, there are many other boosts like this that were planned:

Many of these curves are dummies with placeholder values, but some of them have meaningful multipliers. For example, DamageBoostForWinPct uses the PvPRecentWinLossRatio property that is calculated based on recent PvP performance. I will leave implementing these boosts to Crypto, because powers are his field of work.

As you can see from reading this report, the developers had many plans for expanding PvP, but most of these plans were abandoned, and the only remaining mode, Fire & Ice PvP, remained in beta. You will be able to check this mode out (and never play it again) when matchmaking is implemented. This is all I have to share about this.

This is my final large scale contribution to the emulator, and until 1.0 is out I will be working only on bug fixes and optimization. I am glad that I have been able to contribute to this project, and seeing it thrive is very important for me. I will also continue working on MHUpkManager: perhaps in the future it will enable us to restore other PvP modes.

---

Back to the grind. See you all again in November!