HKMP 3.0 Bug Fixing

The last month and a half or so I have spent doing a much needed round of bug fixing for HKMP 3.0. The issues that were fixed were mostly reported by you guys playing the development build, so thanks a lot for that! In this post I'll walk you all through a few interesting and/or quirky bugs that have been reported and fixed.

Immediately when releasing the latest development version on the Patreon, we ran into some unforseen issues. As is the case with a lot of the development lately, implementing new features or improving certain synchronisation aspects requires interacting with a lot of the systems of the codebase. Now I would be lying if I said that the codebase is pristine, well-kept, and comprehensible. Mostly due to the introduction of the "entity system", the codebase has become a lot messier than I would want it to be. As I've discussed before, Hollow Knight is not a game that particularly lends itself well to being made multiplayer. And in a lot of instances this means that the generalized system I want to make out of it has to be adapted for specifics. In other words, if a certain enemy does not work in the system, it gets additional code to make its behaviour still work.

One of the later features I implemented was related to synchronising boss music and ambience sounds that play during boss fights and enemy arenas (the ones you get locked into). Believe it or not, but the synchronisation of music was the root cause for why players were not able to enter certain houses (Sly's hut, Salubra's charm store) and why some bosses simply did not spawn any geo. The reason for this was that music in Hollow Knight is initiated also through FSMs (Finite State Machines). Almost every enemy in the game has an FSM that controls its behaviour and in the case of the bosses also the music that plays. In order to synchronise music, there needs to be one player in charge of when music plays and when it should stop (at the end of the fight for example). Naturally, in the entity system this is the so-called "scene host", or the first player that enters the room. To this extent, because the scene host should control music, we do not want the game of other players to start playing music. But instead, only when the server tells players that music should be started, should it be allowed to play. However, playing music is part of these FSMs and directly stopping the method call that starts music will inadvertedly make it so that the FSM does not progress anymore. In the case of bosses this meant that the boss would not spawn geo at the end of the fight. And weirdly enough, for doors this would mean that players could not enter anymore. Apparently doors also make use of FSMs that stop playing music because the player is entering a transition. Intercepting the method calls for stopping music also prevents the method calls for the player entering the transition.

Another rather obscure bug presented itself with the Mantis Lords boss fight. Some players reported that the projectiles in the Mantis Lords fight did not spawn for any player other than the scene host. Having tested this boss fight numerous times in the past when adding it to the system, this must mean that the issue had manifested due to something that was implemented later. The cause for this was actually a fix for another bug that I thought would add some redundancy to the system. Namely, some entities in the game would not properly initialize themselves early enough for the entity system to create all the necessary hooks and functions. This was a bug that occurred in some basic enemies and the fix that was deployed at the time seemed fairly foolproof: delay the creation of hooks until the enemy is done initializing. This delay was solely based on the specifics of the enemy and couldn't possibly mess with anything else or so I thought. A single if-statement in the check for when the enemy was initialized messed something up. Hollow Knight breaks some scenes up in two parts: the base scene (for example "Fungus2_15") and either a boss scene (for example "Fungus2_15_boss") or the defeated boss scene (for example "Fungus2_15_boss_defeated"). The check responsible for testing whether the enemy was initialized also checks for the scene that the enemy was in. If this enemy's scene corresponds to the current scene of the game, all is good. However, if there is a mismatch between the enemy's scene and our current scene, we might be dealing with an enemy from a previous scene, and we simply cancel the hooks. This works perfectly fine when dealing with basic enemies, but presents an issue with boss enemies. The Mantis Lords for example reside in such a boss scene and while this scene is loaded on top of the base scene, the game reports that we are in the base scene. Therefore, the check will fail, the hooks never register, and subsequently the Mantis Lords do not network any projectiles.

These last two example encapsulate the complexities of the entity system and why it is so difficult to implement. On the one hand, I want to try and solve problems as generically as possible to try and address most enemies at once. On the other hand, in a lot of cases this means that the changes I make affect a lot of different systems and while improving certain aspects, the changes could negatively impact something else. Of course these bugs would have been caught earlier if I would have tested the version beforehand, but keep in mind that the bugs manifested themselves in completely different areas than the one the feature/fix targeted. And carefully playing through the entire game each time I implement something is not feasible.

Apart from the issues discussed in this post, I have fixed a bunch of lower impact bugs as well. And I should note that there are still some issues standing that are not fixed yet. Specifically, some people reported that sometimes entering a room would render other players and all enemies completely invisible. I cannot seem to reproduce this issue myself, so if you come across it, please let me know in the Discord and share your ModLog file. It would be hugely appreciated!

I'll leave you all with a new development release, feel free to check it out and let me know what you think. Slowly we are getting closer to a proper release, perhaps even before Silksong releases ;)