General
During this month I continued the optimizations and refactorings with the Tracking Point System and the use cases. And I fixed a large number of bugs across the game.
I also released the new roadmap and the poll for the next update.
Btw for this devblog I started to add TL;DR (Too Long; Didn’t Read) for longer sections to give a quick summary of the content.
It’s a test for now, if you like it I can keep doing it for the next devblogs.
Tracking Point System - Configuration and Methods
TL;DR: Finished refactoring and added modular tracking methods for different AI behaviors and Game Master controls.
At the end of March 2026, I did a refactoring of the Tracking Point System.
As a reminder, it’s the system that manages the position of the stomp, grab, etc.
Then in April I finished it and added the modifiers system that can handle the tracking methods.
I also improved CPU performance across several systems with the IK and other systems related to the Tracking Point System.
The system now works a bit like the interaction system:
- I have a “Stomp Tracking Point” class that manages the base logic for the stomp.
- And inside I plug tracking methods that allow me to easily change how the tracking point is calculated and used.
And finally I was able to recreate the use cases with the stomp, grab, etc.
For that I have a new debug test level that allows me to test every scenario easily and quickly, perfect for debugging and testing specific use cases.
(Here it’s lagging because I calculate many Talas and all the debugs at the same time)
I can easily test different methods and gameplay scenarios.
For a stomp, the tracking method will not be the same when Talas AI uses it or when the Game Master uses it.
Here when Talas AI is friendly he can let you dodge.
(Look at the green box and shadow FX)
For the Game Master the code uses a simple interpolation between the current position and the target position, and I control the interpolation with a curve in the animation.
And for the AI it can choose from several tracking methods depending on the situation, the context, etc.
Tracking Point System - Game Master Issues
TL;DR: Game Master system lacks adaptability to changing contexts, and have complications in debugging and updates. Plan to redo it using AI behavior trees.
During the development I got some issues with the Game Master because I need to set the data before the use.
When the AI does an action I use a Behavior Tree to set up the action depending on the context.
During the process the context can change and the AI will adapt quickly.
- If Talas wants to stomp a micro he will first move to the micro.
- Then do the stomp. (If the context is still correct)
For the Game Master, things are more complicated.
- When the Game Master requests to do a stomp the code needs to preset the movement.
- The action to move.
- The tracking data with the target and method to use.
- And the action to do the stomp.
Then I let the Game Master system manage all this with my AI task system.
If Talas needs to open a door the task system will automatically add the additional tasks. (Go to the door, open the door, continue the path, etc)
And it will run all the tasks in order.
This works well, but it doesn’t adapt to changing contexts.
And it makes debugging and updating more difficult, like here when I did the change with new tracking methods.
In the future I will fully redo the Game Master AI request system to use the behavior tree.
Talas will get simple requests like “Do stomp here” And the behavior tree will manage all the required tasks just like Talas AI does.
Tracking Point System - Shadow FX
When Talas does a stomp or prepares to stomp I have a shadow FX on the ground to indicate where the stomp will happen.
I completely redid the FX asset, made the animation smoother and like the Game Master FX I now use a scripted module to manage the logic and the color.
For the moment the FX and scripted module are only used for the stomp, but I will reuse it for other things like the grab letting the player dodge.
AI Unstuck
TL;DR: Added new AI branch to help Talas escape when stuck in walls or furniture.
Following more game tester reports, I added a new AI branch for Talas to help when he gets stuck in walls or on furniture.
He will try several ways to get unstuck and if he can’t, he will just teleport. (Teleport recovery)
Fixing conflicts with AI systems
TL;DR: Talas can now predict player movement using velocity instead of last known position when losing line of sight.
Still related to bug fixing, did a lot of cleaning on the game systems.
It’s funny how some issues are not related to script bugs, but to the game being too “physically accurate”.
Proxy
When Macro AI loses sight of a micro, it uses a target proxy with the last known position and direction to predict where to find the micro.
I spoke about it in the devblog of July 2025 the section “New AI Proxy Perception”.
I have complex AI branches that use many data to predict player position naturally, but for small interactions like stomp or grab, the code only uses the player’s last known position. Then the last known position is used to animate the tracking point used as the stomp or grab target.
So if you hide under the carpet or behind a furniture, Talas won’t use X-ray vision to stomp you.
Sight from eyes and body visibility
Now, the physical issue is that sight really comes from the eyes, and Talas doesn’t see through his own body.
- Check the devblogs of May 2025 “Macro AI Perception”
- and November 2025 “New Two Eyes Sight Module”
So during a stomp, you can be hidden by his own paw. Talas uses your last known position as if you instantly stopped, and if you are running he stomps behind you.
This is an issue, of course.
For specific animations, I can cheat and hide some body parts for Talas AI, but for the stomps I prefer to avoid that. I prefer to let the AI control how Talas predicts the position.
────────────
So, like I did for the tracking point system, the AI target proxy now has several prediction methods.
For the moment, only two:
- Static: only uses the last known position.
- Velocity Follow: is animated by the last known velocity.
For stomp and grab, Talas uses Velocity Follow.
Here’s an example video with the fixed issue.
- The micro runs in a direction, Talas prepares a stomp and during the stomp animation he loses sight of the micro behind his own paw.
- So the AI now focuses his stomp on the proxy prediction and not on the micro.
- Because the micro is running in the same direction with the same velocity the proxy prediction perfectly follows the player.
- When the micro gets stomped Talas feels the crush and recovers sight of the micro under his paw.
That also gives some dodge potential.
You can stop and run backward during the second where Talas loses sight of you to dodge his stomp in front of you.
Here’s another example while playing.
And here are some details with the debug indication in the next image.
Prediction tracking method
TL;DR: Added new tracking methods allowing AI to predict player position before stomp.
I added new tracking methods with the Tracking Point System now that the system is fully modular with plug and play tracking methods.
For the stomp the Macro AI will be able to choose the method he wants to use.
Here he will predict your position in a second before and stomp at the perfect timing, you will have to stop or change direction.
Here’s an example during gameplay.
Good luck escaping Talas when he’s angry!
Btw now Talas can use the “Stomp Again” animation. Before that was only the game master.
In the code I also separated the tracking point movement from the preview movement.
This prevents Talas’ paw from teleporting when the code moves the tracking target on the predicted position.
So I can teleport the preview to the predicted position without issue.
Grab zone fix and modular animation preview
TL;DR: Fixed grab zone and improved modular architecture in animations for easier testing and debugging.
During tests I noticed that Talas sometimes fails his grab, it was because the predicted grab zone was a simple capsule that doesn’t really fit with the grab animation.
I replaced the capsule with a mesh that perfectly fit with the grab animations. 
About the animation preview, I’m now used to doing everything modular and this helps me too with the debug and editor preview, here I did some changes about it:
Before
If I wanted to test the grab animation I needed to spawn several Talas, add test positions and run commands to make the AIs grab the test positions.
It quickly became heavy to manage and made debugging less reliable because too many systems were involved in the tests. A bug from another module could indirectly affect the grab behavior, making it harder to isolate the real source of the issue.
I needed to spawn Talas because the grab animation script directly relied on data coming from multiple character modules on the macro character script. (The grab target from the Tracking Point System, the animations to run from the Situation System, etc.)
Now
I separated the grab animation script into two scripts: - One for the raw grab logic with the target location, speed, and settings. - One for the macro character grab logic.
Example during a grab the macro character grab logic script will get the target location from the character systems and it uses the data to control the raw grab logic script, and the raw grab logic script will manage the movement, the animation to play, etc.
That way during the debug tests I can directly emulate the raw grab logic script without needing to spawn Talas with all the modules.
Transition animations
TL;DR: Implemented smooth transitions for grab animations using the Situation System.
In the game I use many teleportation with short distances.
If Talas grabs you, your character will get attached and teleported over short distances, which is very visible.
So I started to do more smooth transition with my Situation System like here when Talas grabs you with his beak.
The attachment is instant but the position update is controlled by the Situation System state with configs.
For the moment it’s only used when Talas grabs you with his beak, but in future that will be also used for the common grab, the stuck to sole, etc.
Root Motion Issue on Network
TL;DR: Fixed animation precision loss and shaking in multiplayer due to root motion mode.
A reported bug showed that in multiplayer, on the client side some animations had high precision loss.
(This section covers the technical details.)
On the video:
- The red line is the server side
- The blue line is the client side.
Notice how the server is stable but the client is shaking.
FK Precision Loss
A similar issue happens when the animations have long FK chains:
- Bone A loses precision but it’s invisible.
- Bone B loses precision too but it’s offset with the precision loss of bone A and it becomes visible.
- Bone C loses precision too and with the previous offsets it’s really visible
- Bone D is shaking because of all the previous precision loss.
To fix that we can use an IK to force the chains to procedurally aim to the target position of bone D. It’s what was used in MMVS, but in that case that was not the issue and the fact that it happened only on client side was a clue.
Root Motion
After some investigations I found that the issue was because of the Root Motion mode.
The root motion is a method to move the character with the animation.
In general the animation is attached to the character and totally dependent on the character movement,
and with the root motion it’s possible to make the character movement dependent on the animation.
More details here: Unreal Engine Root Motion
By default the animation script applies the character movement only when it detects running the animations with root motion support.
But on my side I use modular animations with a full tree of animation layers that added or removed dynamically.
If I run an animation with Root Motion from a anim layer it’s not detected, so in the main script I extend the detection to check everything including the layers.
In solo play this works without any issue, but in multiplayer on the client side the animations lose precision and become shaky as you can see in the video above.
I think that the client was sending continuous movement inputs on several threads when that wasn’t needed, causing conflicts with the movement replicated from the server.
And because the movement was still good on client and server side I think it produced prediction issues in the animation calculation and that was the cause of the shaking.
But I’m not sure and I haven’t checked as deeply in the engine code.
Finally I reset the default root motion mode to detect only the root motion animations from the main script.
The animations with root motion are sent on the main script for the root motion detection, then shared to the animation layers so the animation is properly evaluated and displayed.
Here the result:
Now on client and server side the animations are stable without any precision loss.
Network sync animations
TL;DR: Fixed animation desyncing in multiplayer by resetting animation groups based on character actions.
While fixing bugs, we noticed that in multiplayer if the animation becomes desynchronized from the server it stays desynced, and the only way to fix it is to respawn Talas.
This is because I use animation groups to keep animations of the same type synced. For example, the run cycle of Cobble play 6 animations that need to be synced and the animation script will blend them together depending on the speed and the direction.
I spoke about it in my first devblog April 2021 “Cobble desktop animation”.
The issue is that the group sync was using the local computer time and never reset.
Now the game will reset the animation groups to keep it synced with the character actions and so keep sync between the server and the clients.
Here in the video with the run cycle, the animations are desynced at the beginning.
When I stop running, it resets, and when I run again, it restarts on both the server and client with the same timing.
- Red line show the left paw position on the server side.
- Blue line show the left paw position on the client side.
MMVS is not a E-Sport game, but in multiplayer it avoids random step hits or missed step hits when Talas walks close to the player.
Modified source plugin for Wwise
TL;DR: Created private repository for Wwise plugin modifications including CPU profiling and duplicate sound fix.
I created a private repository to store my modifications of the Wwise plugins. It is simpler than maintaining raw patches.
- I added CPU profiling stats while working on CPU optimization. (That was a git patch before)
- And now added a fix to prevent sounds from playing on the server when testing the client.
You can find details in this Issue on Wwise forum
It’s unfortunate that Wwise doesn’t provide the plugin source through a repository like Unreal Engine does. This would make maintaining forks and custom modifications much easier.
Mono Audio and sub bus volume sliders
TL;DR: Added Orbs volume slider and Mono audio option with support for sub bus volume control.
In the Audio settings I added an Orbs volume slider and an Audio Mono option.
For the orbs volume slider, I edited the code to add the possibility to control sub bus volumes.
The orbs volume slider controls an audio bus that’s a child of the Effects bus.
That means if the Effects is at 10% but the Orbs is at 100% you will hear the orbs at 10% of their volume.
About the mono audio that was a target for the accessibility,
it is simpler to control that in the game than in the OS settings.
Roadmap and docs
TL;DR: Updated roadmap and documentation using markdown files.
In April I also updated the roadmap and the wiki of several side tools used by the game.
The roadmap diagram may not look like it, but it’s actually made in a separate Unreal project. 
For the pages and text I work in Visual Studio Code with markdown files and I made scripts to generate the files to add to MMVS GitHub wiki.
You can see the current roadmap and poll link here: Roadmap on GitHub
I’m now very used to working with markdown files in VS Code. I also use Copilot to check grammar or translations. The roadmap, the devblogs, documentation of my tools like my rigger or export addon, and other wiki and posts are now all made with markdown files.
Editor Own Tools
To fix Cobble Tail position in the shoe I updated the tools to set up the procedurally modified pose.
In the video I just show how some tools are useful, here with the procedural edit pose with my Stuck Zone System.
Big Bug Fixing Pass
TL;DR: Showing the process of bug search, report, and fix with the game testers.
Now the game is I think super stable. I fixed most of the bugs. The rest is planned content for next updates or engine issues that I cannot fix with a workaround.
When I’m focused on bugs I don’t post a lot in the wip channels but I’m very active on the dev server on every report from game testers. Here in the video I just show a bit how we manage the bug search, report and fix.
We used to do one thread per bug and in the threads I will add details about how the bug was fixed so I have the details if the bug comes back.
Thanks so much to all the testers for their help. <3