Devblog October 2025

General

The Devblogs of August, September, October, and November, were all done at the same time.
This is because I was very focused on the update v0.4.6 released the 27 September 2025.
Then I immediately fall back in work on the patches v0.4.6.1 and v0.4.6.2. released 15 and 23 November 2025.

Mod with Cesium Worlds

In October during a weekend I tried the Cesium for Unreal plugin, used to import real world data in Unreal Engine like Google Earth photogrammetry data.
I had to make several changes in the plugin source code but in the end I can load the full world and plays MMVS in it.

The collisions are not perfect and the game code consider only what you see but it’s a good start. Also it works well in VR.
For the multiplayer that doesn’t work at all but I fixed that later, I will speak about that in the devblog of November.

What nice I can play with the shaders so I can change the appearance and offset the visual geometry like here.

So I can easily create deep footprints with destruction effects where Talas walk.
I also wanted to test the AI with extreme scales and it works like a charm.
Here in the engine unit Talas have a scale of 1000 and the player a scale of 0.01, so Talas height is about 180km. Perfect if you like mega Macros stuff.

Scale Based Interactions

When I did the test with the extreme scales I noticed some new bugs with the character scale and how the game handle it. You have to know in the game code the character script class is split in two, one for micro character and one for macro character.

They both have their own code for macro or micro interactions, and the other scripts will detect the character class to know how to work. This is since v0.3 but now that the game is very modular I try to make the scripts check the character scale and not only the type.

Example: the teleporter was made for micro characters, but now if I scale the teleporter to Talas size, Talas will be able to use it. The teleporter script now only checks if the scale fits and not the character type.

Same for the rug script, before it checked if the character was a macro type,
now it just checks the scale and updates the collisions per character.

Using scale rather than character type makes the game and interactions much more consistent with multi scales.

Step Surface Capture

About the rug it uses another script used to capture the character steps and contacts with a surface,
perfect to make the surface deformation and footprints.

With the Cesium I reused that script and I totally reviewed the way it captures contacts.
Now the texture used to render it is way smaller and the render more optimized.

With Cesium world it is used for make the footprints and destruction with the macro steps.
And about the Cesium mod I did many cleanups, removed all testing assets to focus on a few clean levels that will be available in the mod.
Also I made it able to work in multiplayer, that’s far from perfect but it works.

New AI Personality Presets

In the devblog of August I spoke about the AI kink filters that got removed in favor of AI decisions system.
This makes the AI code less restrictive and complex but far more flexible.

In October I added the AI Personality Presets letting the user choose predefined AI personalities, it’s what replaces the kink filters. If a user wants Talas to avoid vore actions they can choose the “No Vore” preset.

As Game Master the AI Personality Editor replace the old AI Decision Table.
You can edit in details the decision weights for each action like before, but now you can also set presets and blend or override the data with sub decisions presets.

The idea is to let the most of control and flexibility to the user.
For example the user can set an “Aggressive” AI personality with the “Disable Vore” subdecision preset blended at 80%.
So Talas will be aggressive with micros but he will focus on stomping.

Another example is use the default AI personality but set with the “Hangry Vore” sub decision preset at 100%. If Talas see you he will just try to eat you without playing other vore actions.

Of course all that fully replicated in multiplayer letting clients set Talas AI Personality.

I also added an option to set the AI personality preset from the game start settings.
Now when you start a new game you will have a new option “AI Starting Preset” It’s the same presets you will found as game master in the new AI Personality Editor.

Scaled damage options

I added an option to scale the macro damage with the scaled mass difference. Not just the scale but the real mass.
If Talas steps on you with you at scale 1 and Talas at scale 20, you will get 30 damage like before.
But if Talas scales up to 40, you will get 240 damage.

For the moment, I will activate this options only on the desert map. In the cozy house, you will continue to get 60 damage at any scale. In future I will let this option configurable by the game master.

Like the mass, the damage is exponential, so be careful with it. Just for fun in the Cesium mod, with mega macro Talas the scale difference with Talas is 100 000, here the damage table.

Corvidius Mod

Welcome to Corvidius!
That is not officially in game, like for Vik and Vuin characters it’s for test mods.

Like the other one I continue to focus on cosmetic mods for now.
That mean the mod will only change the visual and can be loaded locally without impacting the gameplay or multiplayer.

This is also why the stuck to sole position don’t fit with Corvidius paw.

Thank Corvidius for let me use his model: Corvidius
Model Maker: Darkwargreymon

Teleport check and transition state

When a player is teleported in a world partition level the game need to check and load the teleport destination area during the teleport to avoid falling through the world.

In v0.4.6 I did a code that can check that and keep the player behind a loading screen until the area is loaded but the player character still falls through the world. That’s an issue I fixed in October.

Now, when a player is teleported, they will get a specific state: no collision, no gravity, and no movement until the area is fully loaded. (It’s better to wait for the floor to exist before trying to land on it.)

To make this I totally reviewed the simulated data (FX, sound, UI, delays), I separated the teleport module from the UI module used to fade in and out the loading screen. And I created a new transition character state. (The one used to disable collision, gravity and movement.)
I also moved the simulated data outside the code in config files to be able to change them without changing the code.

About the FX it works like before but now I have a config file for every teleport type. - Teleport in the level - VR teleport - VR turn teleport - Vore transition enter / exit

I made an override system that works a bit like the cameras. The player will have his own config, and the teleport enter, exit or external context can override specific settings.

In the video to test I used a debug fade but in game that will be a black screen with the loading text when the teleport take too much time.

New teleport FX

Following the change in the teleport system I updated the teleport FX to keep it more consistent with the character scale and state.

Memory leak fixes

Using the Unreal Insights tool I was able to track and fix several memory leaks issues in the code.
Up is before, Down is after.

I was not used to use Unreal Insights for memory leak so I learned a bit and it was very useful.

Digestive System optimizations

I think I’ve built one of the most complex and optimized systems to simulate a digestive system in a Vore game, haha.

For v0.4.6.1 I really wanted to optimize the Digestive System environment for VR performance.
For more than a week I’ve been stuck on optimizing the digestive system update code to reduce CPU usage.

By default the digestive system is cut in several parts, each part is cut in several sections and depending on what you’re looking at, the player position and other player positions it will only update the necessary render geometry and collision geometry to save CPU and GPU resources.

It’s more complex than that but in general:

It updates every frame the part where the player is located (Render and Collision)
Updates every 0.5 seconds the parts that contain other players (Collision)
Updates every 1.0 seconds the render of the parts you see but where the player is not located.
Skips updating the render of parts that are not visible.

To stress test my system I disable the view and positions optimizations. And this forces the system to update all the digestive system parts at every frame for render and collision. I do this on a AMD Ryzen 9 7950X 16-Core Processor.

in v0.4.6 the calculation takes around 120ms per frames.
in v0.4.6.1 the calculation takes around 22ms per frames.

Here what you see is the full digestive system calculation in one frame with the stress test enabled:

In game in the digestive system, without stress test, it’s down to 2ms per frame for the full digestive system update.

I also learned many things about optimization with C++ during this big optimization pass. ChatGPT helped me a lot. So that’s not an issue anymore for VR usage.

The code now prepares the modifiers and caches the data. It prepares all geometry in a tick manager and cuts the tasks in parts to run them in parallel to use all CPU cores at the same time. During the parallel execution, it avoids any variable copies. And at the end it applies the final geometry data in textures to send it to the GPU vertex shader.

I can optimize more, in the picture you can see two red lines.

“Filter” is the process to choose what modifiers will be used to apply the geometry.
“Hooks” is used to move objects with the digestive system movements, like the lights or physical objects.

Those two big blocks take in total 1ms in game, but for now that’s not necessary, maybe I will redo a pass for a next update.

120ms to 22ms,
+81.7% performance. Flex