July 2025

General

…

Customization Replication With Extreme Lag

Now that the customization management between the modules is more fluid, I was able to make the replication works a lot better with extreme lags.
Replication is the process of sending data from the server to the clients, so that all players see the same thing in the game.

I did more optimization in the replicated data structure and added checks to ensure that the server and client players use the same skin.
Here with a simulated ping around 700 ms.

New modular Game Master UI

I fully redid the Game Master UI to make it more modular and easier to set up. Before the categories were static and hardcoded in the UI. For example, the category “Characters” was a widget that searched the Game Master Parameters from the current selection if the selection was a character.

Now the Game Master Parameters indicate the category and visibility of the parameters. And the Game Master UI will create the category and the parameters widgets dynamically. So now I can add new categories and parameters without having to change the UI code and the code about how to find the parameters.

That gives me a lot more control for specific cases. For example, the thing that made me do this change is that I added some Game Master Parameters directly on the AI Controller Actor. When you select Talas you select the Character Actor, not the AI so the Game Master UI was not able to find the AI Controller parameters.

Now the menu and panel here are fully dynamic.

For the Game Master UI I detect all controls (Parameters, Actions, Buttons) with the player selection and environment. Then the code sends the controls to the UI panel and it creates the sections, orders all, creates category and sub categories if needed.

It’s not only the panel at the right, the camera buttons at the top and tool buttons at the left also use the same system now. I made this change modular so it can be used in other places.
I will use that panel in the host game page too.

IK manager New Modifiers Method

This month for the vore animations I totally changed my method to order the IK modification logics in my IK Manager system.

Modular Anim Layers First you have to know the game is fully modular and all content is not managed by a single script.

I have a main Animation script that is always loaded on characters and layer animation scripts that are loaded with modules. For example: When Talas uses stomp the code loads the Stomp module that contains the related layer animation scripts, some other scripts, all animation files (Assets) and configuration about how everything should work.

The Animation code will first calculate the main animation script then the layer animation scripts added by the loaded modules.

Modular IK Manager To remind you, IK (Inverse Kinematics) is a method to pose a bone chain to reach a target.
Example: For an arm I can set the desired hand position and IK will pose the arm and lower arm to reach it.

In MMVS the IK Manager manages the feet and hands position but it’s not focused only on IK, it also manages the pelvis position and head position.

Now that you know that, the IK Manager was very similar to the animations layers.
Before:

The IK manager sends default data structures per procedural points to the main animation script.
The main animation script modifies it, sets the desired feet, hands, pelvis and head positions.
Then the IK manager gets the new data structures and sends it to the first animation layer script that also modifies it.
And the code does that for all animation layer scripts.
When done it uses the data structures to calculate the IK and procedural positions on the character.

This works well for simple IK modifications but it was not flexible enough for complex IK modifications. For example, for the Talas stomp I need to offset the foot position before applying the feet on floor and pelvis up offset.
So the stomp anim layer needs to override the calculation of the feet and pelvis positions and redo all the calculations to make the stomp animation work correctly.

Now:

The IK manager prepares default data structures and a list of modifiers ordered by priority.
For each modifier it calls the modifier script that modifies the data structures.
When done it uses the data structures to calculate the IK and procedural positions on the character.

That way the main animation script and animation layer scripts can add their own modifiers to the IK manager with the desired priority when needed or remove them when no longer needed.
If a modifier’s priority is higher it will be calculated before the lower priority modifiers. The stomp module now just has to add a modifier with a higher priority than the foot over (Place the foot on the ground) and pelvis up offset (Offset vertically with the feet) modifiers.

Notice the modifiers that are set up and cleared in the debug menu.

That way I can also easily split the modification steps.
Before the foot over and pelvis up offset edits were managed in a single script, now I have a modifier for the foot over and a modifier for the pelvis up offset. And if needed I can add modifiers between them.

That’s what I do now for the Grab, and it also follows the same logic for VR body tracking with the head and hands positions.

And that way I can finally do a clean Pelvis offset when Talas is crouching to Vore the Micro.

In bonus I added the over IK Modifier support for the hands, used when Talas lands on his hands to Vore a micro on the floor.

Better Macro AI Pathfinding

This was one of the remaining blocking points about the issues and bug fixing.
The macro pathfinding is much more restrictive than micro and in many cases the macro AI was simply broken not knowing exactly how to access the micro.

Basically when this happens the AI starts again from the beginning of his AI tree and moves on to another branch, most of the time Talas will try to grab the micro if he can’t reach it because it’s too close to the wall.

Now he will continue on this branch and will try to find a better path, or project himself on the point closest to the micro.

In the next video the AI is allowed to move in the purple zone but is not allowed to move in the red zone. So when the micro enters the red zone, the AI tries to find the best location to reach the micro with a stomp and without entering it.

New AI Proxy Perception

Now the Macro AI will also use a proxy actor based on his memory to target the micro position.
When the micro is visible the proxy uses the micro position and when not visible the proxy will use the last known position.

That way the Macro AI can continue to follow a micro without stopping his movement when he is not visible during a short time.
Before, when the micro left Talas’ field of vision, Talas AI simply stopped the current action, waited, then launched a new branch to check the micro’s last known position.

Also this makes Talas much more aggressive when he wants to stomp you.

AI Decision System Refactoring

Still related to the AI, I fully refactored the AI Decision System data management.
For specific tasks the AI can take decisions and depending on his personality and relation with the target he will choose a specific action with weighted probabilities.
Weighted probabilities mean random with a bias, for example if A = 100, B = 50 and C = 10 that means A have 62,5% chance to be chosen, B 31.25% and C 6.25%.

I did not change the way the AI Decision System works, but I changed how the data is loaded and managed in the code.

Before the data was hardcoded in recursive data structures, the decision list and possible relations.
Because of that the slightest change broke everything and required reviewing many code parts.

Now everything is modular, the relations and decisions.
About the decisions, the AI will load only the branches which it can access. For example, Talas can use vore situations so the AI code will load the decisions related to the vore. If I do another macro that can’t use Talas vore situations it will not load them.
And the control panel will not be saturated with useless parameters.

About relations it’s the same, the AI will load only the relations it can use depending on his personality.
With a micro Talas can be Enemy, Angry, Neutral, Buddy, Friendly or Ignore.

Depending on the relation toward the micro the Macro AI will load a specific preset of probabilities for all decisions. Now it’s possible to have more relationship points or just one just by adding it with data assets.

I did many common structs to manage the data and a new replication struct for multiplayer use with the game master. I also reviewed and tested all AI decision branches with the new system, and I was able to add some of the new Vore branches with the new animations.

I also updated the game master UI to set the probability and preview it in the Talas Decision Table.

This UI already existed in previous versions but now it is fully dynamic and modular.
The panel that previews the weighted probabilities is new.

In the future (Not for this version) it will be possible for the user to set the relations map. And you will be able to export and import decision probabilities with JSON files.

This change was planned for the AI update, but I did it now to make the Talas AI able to use the new Vore actions.