March 2024

General

…

Reference Cycle Crash

I occasionally have Engine crashes due to infinite cycles in loading references.

I don't know exactly what's causing this, but it's a recurring problem that's become more prevalent lately as I have more and more modular assets that reference each other.

One small asset can depend on many other assets to function, which in turn can depend on other assets, creating loops that in some cases, I believe, cause the engine to crash.

When this happens, I have to delete an asset to break the loop, then put it back in when the engine is loaded.

This month, in order to keep references and dependencies to a minimum, I did a major overhaul of most of the game's assets.

If you're familiar with Unreal Engine

I've partitioned my function libraries so that each library imports only the references it depends on, by theme.
I use interfaces much more for communication between blueprints. This allows you to send and receive information via standardized functions, thus reducing the number of references.
In some cases, I use the Gameplay Ability System to retrieve character data without having to import the character and all its dependencies
I've also done a lot of small fixes and cleanups to remove unnecessary references.

Gameplay Ability System

A few months ago I told you about Unreal Engine's Gameplay Ability System (GAS). I had started to integrate it and had done a few tests.

This month, inspired by the Lyra sample from Epic Game and following some tutorials, I've completely rewritten the integration.

Using the gameplay ability system allows me to create more modular, "plug & play" parts of the code, just like in an RPG.

For example, if my character falls into a liquid, I can add a "wet" effect with automatic removal after a delay. I can also specify that this effect has to decrease the maximum speed of my character.
I can then add another "on fire" effect that automatically removes the "wet" effect and this time damages the player every specified amount of seconds seconds by a specified amount of damage.

The integration has taken a long time to complete because it's quite complicated.

Health

As part of the integration, I completely rewrote the health management code, this time with the help of the game's ability system and with inspiration from the Lyra sample.

I created several attributes for the management of current health, maximum health, regeneration rate, and so on.

Damage and health regeneration are now managed by gameplay effects.

For example, in the case of Vore, if Cobble falls into Talas' stomach fluid, he will take a small amount of damage every second due to the acidity.

I've also created an Abilify for Cobble that sets his maximum health to 200 at the start of the game.

Automatic health regeneration is controlled by an ability. Below a certain threshold, and if the player doesn't take damage for a certain amount of time,

the ability adds a gameplay effect that gradually replenishes the player's health, taking care not to exceed the threshold.

If the player takes damage in the meantime, the regeneration will stop.

The attribute change will also take into account certain character-related data.

Damage Immunity, to make the character impossible to damage, which I use for Talas and Game Master.
Permanent Vitality to restore the minimum health to 10.

It's a little cumbersome to set up, but it opens a lot of doors.

I had to update all the dependencies and the different players that should be able to damage the player after I updated the health management.

I also took the opportunity to rework the fall damage, which used to be based on height.

Now it will be based on impact speed and strength.

This also means that you can take damage when Talas throws you against the wall.

Grab System

In order to continue fixing animation-related bugs and clean up some of the code, I had to work on a new grab system.

I needed to update the way I transfer animation data from the character to the animation script, and the way I handle overrides associated with a grab.

It should be noted that I had created 2 independent grab systems.

One that I created specifically for VR.
And one just for Talas when he is grabbing and holding a micro.

The two systems work fine, but they're not compatible with each other, and they're not general enough for my use.

I'm stuck if I want to upgrade them easily.

In the future, it will be possible for Talas and Cobble to catch more things, like a cup, food, the remote-controlled car, micro of course, and so on.

So I started with a very general system that allows a character to have multiple types of grabs.

The advantage of this is that a grab is not defined by a point of attachment, but by a way of holding (handle).

In this example, it is possible for Cobble to catch in 3 different ways thanks to the three handles.

with his left hand
with the right hand
or with both hands at the same time.

Another script will then define the permissions to prevent Cobble from grabbing an object with his right hand if he's already holding another object with his 2 hands.

The whole thing is modular, which means I can easily extend it and add as many handles as I want.

For example, I can have Cobble hold things with his jaw. Or make Talas catch micro with his claws.

If I create a new macro character with four arms, I can have him grab four micro, or maybe two large objects with his two arms on either side, or one larger object with four arms.

Multiplayer test.

I then updated the animation scripts and added several basic animations to show how an object is caught.

From there, it's easy to define contextual animations according to the actor and the object being held.

Characters Files and Blender Assets.

I keep running into little problems with the character management system.

This time I noticed a bug where some animations were not exported correctly. It was related to a bug in Blender that caused conflicts with object names.

I have a folder for each character with several work files for sculpting, retopology, textures, animations and especially the rig.

When I want to start working on a new animation, I link and import the character's rig. This way, every time I open the animation file, I can re-import the character and keep the rig up to date.

I use my MMVS plugin to manage characters per animation file and my batch exporter to export all animations to Unreal without opening each file.

The problem is that I used the same name for different types of data in my rig file. The armature, the actor that contains the armature and the collection that is linked to the armature all have the same name.

This shouldn't be a problem, but a bug can cause the link to fail and when I reopen the animation file. It displays a corruption error and loses the link to my animation data...

I’ve updated all my characters to have different datatypes and names in the rig file.
To check the files and avoid possible errors, I updated my MMVS plugin.
I've added an option to update the animation files with a new link.

When Blender detects an error, it has a rather annoying way of fixing it, by deleting everything associated with the error, including the frame and animation data. So the animation (NLA) is deleted.

To correct this, I'm forced to move the rig so that the animation file doesn't recognize it, and when it opens. Instead of deleting everything, pissing on the floor and setting it on fire, I get a simple error message saying that the source of the link cannot be found.
From there, I can access the animation data to extract it from a cache.
I update the link to the new rig location and reload the character.
Finally, I re-import the animation data into the new rig.

This is very tedious, so of course I use my MMVS script to automate all the steps.

With the modifications linked to my plugin, I took the opportunity to make the characters natively usable with blender's asset library.

Snuggle with FBX Import Issue

See that little red offset caused by inaccuracy in the float values?

This breaks the process of importing animations into Unreal Engine and causes my animations to explode. I was stuck on this for 3 full days.

First I deleted parts of my rig step by step to find out which part was causing the problem.
Now I have one version that works and another that doesn't.
I compare in Blender and the only change is a constraint on one bone to copy another bone.
I create a script to compare the fbx data and find a small offset in the animation scale data of several bones.

This small offset is the cause of the problem in Unreal, although I don't understand why.

I look in my rig blender for what could be causing this small offset, but the offset is not caused by anything other than the floating values, which are not absolute.

The only option is to force the scaling with a constraint or reduce the risk of increasing the floating inaccuracy by using smaller bone sets in the skeleton hierarchy.

What I then import works as before.

Finding and understanding why was very tedious.

Debug And UI

I've made several modifications to my debug menus to standardize them so that I can create and modify them more easily.

This saves time, and in the event of a problem I can find the source much more easily by checking the data.

To test each game feature I tend to create a menu linked to that feature and a map to test interactions.

UI

I've made a UI pass to fix a lot of little problems.

First, I updated the color wheel widget to use my new property system.

I've updated the user interface inspector, which is now more modular and not specific to character customization as before.

It is now possible in the code to preview several characters or other objects.

For the moment, this doesn't change anything for the user, but in the future I'll be able to use the inspector to view other elements.

I also did a quick pass over the customization menu.

I've put back the button for loading random preconfigurations in the customization menu.

Video

It's something that's been suggested to me several times, so I've finally added support for vertical synchronization and HDR displays.

In fact, if you take a screenshot using the in-game option, the image will be HDR exr.