General
July 2026 focuses on new features in the digestive system, with big audio improvements making the exterior sounds hearable from inside, new physics interactions, and a better gameplay experience.
I also talk about the SVN corruption I ran into and how I lost 2 weeks trying to recover it.
And I finish with an explanation about modular systems and the use of the Player Start Spawns.
Audio Listener System
TL;DR: You can now hear what happens around Talas while being inside his digestive system, with occlusion and reverb using the new audio listener system.
I started working on audio listeners with Wwise to make it possible to hear the world from inside Talas’ digestive system. To recap, Wwise is the new audio engine for the next version of MMVS (v0.4.7).
For the first test in the video, I was able to create a second listener on the distant camera. The listener detects the two sphere sound sources and sends the raw sound to the player.
(Activate the sound on the video below)
This works for a static listener, but it required more research and development to support movement.
Wwise is powerful, but the integration with Unreal Engine is a bit messy and closed.
Once you go beyond common use cases, you run into closed functions with no possible override. Here, for example, Wwise supports several listeners, but in the integration plugin, the code forces all listeners to use the Unreal player camera location.
This is hardcoded in a function that cannot be overridden.
(In the previous video I used another method.)
So I had to reverse-engineer where this was done, edit the plugin code to add workaround functions or options, and then use them in MMVS C++ code. By the way, that’s not the first time I’ve done that with Wwise. I have my own repository with all the Wwise modifications I made for MMVS.
- Now the camera listener supports movement. Before that, it was static.
- Supports any audio source without having to set them up one by one. Before, I needed to manually set up each audio source that should be heard by the camera listener.
- Supports stereo and camera rotation.
- Supports ray-traced occlusion as shown in the video, reverb, etc.
In fact, it’s a true listener, as if it were the main player listener.
(Activate the sound on the video below)
The next step was to separate the player listener from the distant camera listener to add specific audio management.
In the next video, both listeners use the same bus structure. They separate audio sources (diegetic, subdiegetic, non-diegetic, etc.) but keep their own settings and variations.
So I can add effects on a specific listener:
(Activate the sound on the video below)
I wanted to add more functionality and transfer the audio directly into the game world, to apply environmental effects, etc., as if the sound were really coming out of the in-game monitor (not just an on/off zone like here).
For that, I need to extract the audio from a specific muted bus and reinject it into the game world, but after many tests I didn’t find any way to do that correctly.
But it’s not an issue for the digestive system, so I will retry when needed in the “Camera & Monitor” update.
For now, this works perfectly with the digestive system. You can hear Talas walk and interact with objects from inside his digestive system.
(Activate the sound on the video below)
Here I show more details of the audio listener debug system and how the sound logic is duplicated for each listener.
(Activate the sound on the video below)
Surface Contextual & Pelvis Offset
TL;DR: Better in-game digestive system camera stability with the new Surface Contextual Scripts to inject configuration overrides for foot interactions and animations.
In detail, I created a new contextual setup to configure foot interactions and animations depending on scripts attached to surfaces.
- Before, the animation and foot interaction were just getting the surface type and context to choose the config to use.
- Now it will also check if the surface contains specific scripts to inject configuration overrides.
Example: Cobble’s steps detect that the surface underneath is a “flesh surface”, so the code sets the flesh config with sounds, decal textures, etc., and it also detects an optional script that disables footprint spawning.
So in-game I hear the flesh sound, but no footprint decal is spawned.
This avoids creating many sub-surface types for each use case.
Two identical surface types can have different results depending on the attached script.
Here in the video, the same applies to player animations. Cobble dynamically adjusts the pelvis offset depending on the leg position, but now inside the digestive system, using attached scripts, I disable the pelvis offset to keep the camera stable and avoid nausea for the players.
Digestive System: More Physics and Talas’ Movement
TL;DR: Added more physics surfaces in the digestive system that move with Talas’ movements.
I added more physics surfaces in the digestive system.
It is similar to the Flesh Wall Interactions with a physical object that moves the surface around it, but here you can’t directly interact with it and this time it impacts the collisions.
Then with Talas’ steps and his global movement in the world, it produces physical impulses in the digestive system. Combined with the sound, this gives a nice sense of organic movement.
(Activate the sound on the video below)
Corrupted SVN Server
TL;DR: How I detected corruption in my SVN server, rebuilt it, and secured it.
During this month I hit a new blocking issue: my SVN server became corrupted. I lost around two weeks trying to fix the corrupted files without success, and finally rebuilt a new SVN server. But no worries: the game’s working copy is stable, I didn’t lose any work, and I immediately created several backups to reduce risk.
This issue cost a lot of time, but it resulted in much more secure data management with daily backups and checks.
────────────
As a reminder, for MMVS I use an SVN repo.
SVN is a version control system (VCS) that allows me to keep track of all the changes I make to the project.
When I take a step in the development of the project, I commit the changes to the SVN server that stores it as a revision in the repository.
This way I can roll back to a previous version if I need to or if I want to check the history of the project.
During this month, after a power outage, I noticed that revision 7417 was corrupted, so I was no longer able to commit to the SVN repo. Looking deeper into the details in the SVN repo, I noticed that it was not the first corruption…
After many searches and tests in the backups, I was able to extract all stable revisions, but I was not able to recover or repair all the corrupted revisions.
I was able to save revisions 0000 (31 August 2019) to 6705 (27 December 2025)
I have 3 corrupted revisions.
- The revision 6706 (29 December 2025) is corrupted, and it was already corrupted in the older backup that contains it: 01_2026-01-06_0300. So I can’t recover a clean version from before the corruption, and I couldn’t repair it.
- The revision 7177 (17 April 2026).
- And the revision 7417 (20 May 2026).
Revision 7417 was the blocking one that prevented me from committing new changes to the SVN repo. That’s the one that made me notice that the SVN repo was corrupted.
Before that, the server was able to run and produce more revisions without issue, so I never noticed this before 7417.
If I try to access some revisions after 6706, many of them fail because they depend on a previous corrupted revision, even when the revision itself is not corrupted. That’s the issue with a delta chain. If one link in the chain is broken, every dependent revision becomes inaccessible.
So from 6706 (29 December 2025) to 7767 (07 July 2026) the revisions are unstable: only 3 revisions are corrupted, but any revision in this range may fail if it depends on one of them.
I can still use the repo to access the history on the revisions that don’t depend on the corrupted revisions, but I will of course not continue to work with this repo.
Following this issue, I created a new SVN repo and set it up for MMVS use.
The last revision, 7767, still works, but 7768 was never committed because the repository was too unstable to continue using. I still had its raw data in backup folders outside of SVN.
So I added the data of revision 7767 in the new repo, then committed 7768 as a new revision.
That’s now my main repo for MMVS.
By the way, Epic Games released a new VCS called Lore. I plan to switch to it in the future, but it is not yet ready for production, so I will continue with SVN.
I also increased security and checks: - I set up automatic backups every day instead of every week, and I will keep the backups much longer than before. - My NAS has a UPS, but the NAS was not automatically shutting down when the UPS detected a power outage. That is now fixed. - And I will set up an automatic SVN verify to check every day if all revisions are valid. If a revision is corrupted, it will send an email.
I also changed the way I manage the SVN server. - Before, I was using an Entware package with opkg directly installed on the NAS. But that was complicated to manage with updates, autorun scripts, and access control through SSH commands, etc. - Now I use an SVN server running in a Docker container.
A Docker container is an isolated environment that runs on the NAS, and it is isolated from the NAS system.
So if something goes wrong, it will not affect the NAS system, and it is not dependent on NAS system libraries.
I just set up Docker to use the garethflowers/svn-server image, and it was done.
Player Start and Spawn Points
TL;DR: Explained how I improved the player start and spawn point logic to make the player lie down on the bed when the game starts.
While fixing bugs, I redid the script logic to make the player lie down on the bed when the game starts.
It is only a technical detail, but I think it is a good example of the programming approach I use throughout MMVS.
────────────
In 0.4, I added a simple script in the cozy house to teleport and lay the host player on the bed in the cardboard box after one second when the level is loaded. But it worked only with the game host and acted as an override that did not follow the engine player start logic.
So I fully redid it properly. Unreal Engine natively detects the player start points in the level, checks unoccupied ones using collision checks, then it spawns the player on a random unoccupied player start point. Thanks to object-oriented programming and Unreal Engine’s architecture, I can override the class responsible for choosing player start points and implement my own spawning logic while keeping the engine’s default spawning system intact.
I already did some modifications before to separate the macro and micro player start points. - When a player spawns as micro, it will spawn on the micro player start points with a specific tag name inside the cardboard box. - When an AI spawns as macro (Talas), it will spawn on the macro player start point in the Kitchen, also using the tag name.
And here I added a new priority system, changed how occupied player starts are detected, and added spawn notifications.
To do that, I also overrode the player start point class to add properties to manage priorities and a control target.
Then I created a new control class. If a Player Start Actor references it, the control class receives spawn notifications and can decide whether the player start is occupied. That control (an Actor Component) is designed to be inherited from and attached to any object (Actor) in the level.
And here is where modularity becomes useful: I can create a child control class, add code to lay the player on the cardboard-box bed, add that new class on the bed, and add a player start point that will use the bed as control.
- When the game code spawns a new player, it checks all player start points to know which ones are available and not occupied.
- The player start point looks for the Control component on its target and delegates the occupancy checks to it.
- Then, with the priority system, the game code chooses the best one, spawns the player at the chosen player start point, and notifies it.
- The player start point gets the notification and passes it to the control component.
- The control on the bed detects the notification and instantly lays the player on the bed.
The player start system is written in C++, while the gameplay logic is implemented in Blueprint.
And the logic that lays the player on the bed and checks whether the bed is occupied is implemented without modifying the core system.
The core system is not aware of the bed or any of its dependencies.
GameMode (Manages the player spawn)
↓
Player Start
↓
Player Start Control
↓
Bed ActorThanks to modularity, I can very easily adapt that for any use.
If I want to start a cinematic or apply gameplay events specific to a player start point, I can simply create a new control class, add the logic, and set the control target.
I build reusable LEGO bricks, then assemble them into whatever I need.
This has been my standard approach for designing gameplay systems for several years now.
I’ve already talked about this modular approach in previous devblogs when presenting my Interaction System, AI, the Situation Animation System, and other gameplay systems.