Rare serialization issue

Development Programming & Scripting Blueprint
, , ,
1

Ok so here is the setup:
We have a main character blueprint that is based upon our own c++ character that in turn inherits from ACharacter. Very standard setup. They have a First and Third person mesh much like ShooterGame
We then have 4 child blueprints of our character blueprint, that only change a few materials and settings.

After doing something completely unrelated, two of the child blueprints seemingly loose their reference to both first and third person meshes. (They are not different from the parent blueprint).
Its possible to get it back by clicking the revert arrow and all seems fine. But at next editor launch the meshes are gone again. (It also seems like it looses transform info, so maybe it affects the entire skeletalmeshcomponent)

After fiddeling around and not being able to fix it, I decided to just make two new child blueprints to replace the broken ones. This works fine until i restart the editor. Now one of the new blueprints have broken but one of the old ones is now working again. This is when I started to suspect it must have something to do with serilization. No matter how many new child blueprints i make, two are always broken and it changes around when i make new ones. So it seems the data on the disk is fine, its something that happens when it loads the blueprint.

Going through recent changes, we tracked it down to a userwidget that was added to our hud. If we remove it from the hud all characters load fine. Put it back and restart the editor and it breaks again.

I even disconnected all the nodes in the blueprint and it didnt help, only if i deleted all of the blueprint nodes would it still work while being in the HUD. Trying some random things, there was a cast to our blueprint gamestate, i changed it to a cast to our c++ gamestate. And now it works again!

Moving on I try to figure out if there is anything in the gamestate that could cause this.

Turns out our gamestate has some variables that are arrays with references to the PlayerCharacter blueprint class. Removing these would also partially fix the problem, but only if i also remove a cast and call to our gamemode.

The gamemode also has a variable containing references to classes of our playercharacter. The gamemode also makes a call to the playerstate that also has this kind of variable.
In all cases i cant get each step to work if i remove these variables or references to other blueprints that have these variables.

This is really weird and i dont know what could be wrong other than some parts of the serializer messing up due to the planets alinging or something.

Im pretty sure this cannot be reproduced in a clean project. But maybe i can send a moderately stripped down version of ours. Its easy to reproduce the problem even with zero knowledge about the project.

Cheers
Jonas

2

HI Amimoller,

  • Were the variables involved/functions involved wrapped into a circular dependency? If so, does breaking the circular dependency cause the error to halt?
  • Are you compiling/saving before closing and re-opening the editor?
  • What specific types of connections between the HUD/Widget/Gamemode were removed to stop the error from occurring?
  • Do you have any functionality that could be forcing an update onto the mesh?
3

1: Yes The player character references the HUD and naturaly lots of stuff in the hud references the playercharacter. But it seems to only be a problem when there is a variable that is a “class type” of PlayerCharacter.

2: Yes, Otherwhise there wouldnt be any changes? :slight_smile:

3: Calls to functions / Events. I think actually just casting to the gamemode to the one containing the variables was enough.

4: We where adding a few child meshes during construction, but disabling it didnt fix it. Other than that nothing special happens.

4

Try adjusting the circular dependency to break the cycle. This may be causing the error to continue to occur. The reason I asked about saving and compiling, compiling more specifically is actually for the exact reason you listed. It’s a fairly common oversight, so we can rule out simply missing information from not saving/compiling.

Are you receiving any accessed ‘None’ errors on the cast checks that were removed? If so, try adding an IsValid check before the cast to the variable you are casting. This will check to ensure the variable is populated before the casting occurs. If it does not run from the IsValid execution pin, the error may lie in variable population.

5

Yes breaking the dependecy fixes the issue and in this case it was an easy fix, but it is still something that should normaly be working?

The error happens when the character blueprint is loaded. Not while playing, so none of the blueprint nodes are ever executed.
Besides the cast does not have to be connected to anything for the error to happen.
It is also not the cast that was failing, its the mesh component on some of the characters that would fail to load, the cast was working fine.

6

With a circular dependency the waters get a bit muddy. The editor checks for compilation through each blueprint referenced by/referencing a blueprint that is edited and/or compiled.At times it can get caught in a loop, causing blueprints that have been compiled/are clean to become dirty again or overriding data. The best way to fix this is as you have already done, break the loop. In general, it is best to avoid circular dependencies whenever possible to keep this from occurring.

While there are a number of bug reports in for circular dependent errors, this one does not appear to be in that list. If you have any specific steps I can take to reproduce this on my end, I’ll be happy to take a look and try to recreate the error, and if I can add a bug report to the system.

7

I think it will be pretty difficult to replicate in a new project. We will just go with the workaround for now.
Cheers

8

Hi Amimoller,

I will mark this as answered for tracking purposes. If you find steps I can take to reproduce it on my end, please feel free to post here and I’ll be happy to take another look.