AUTHOR: Mike McGoveran
DATE: 5/19/2023

The Problem
For the second time now our team has come across a really nasty bug in Unreal where a c++ class asset will become corrupted in a blueprint after an update in C++ has been pushed.  For us this bug has shown on our stats component within our player character.   Our asset s are organized where we have a BaseCharacter Class that attaches to itself a BaseStatsComponent Class.   The Player uses a Blueprint BP_Clancy that inherits from BasePlayer.cpp which inherits from BaseCharacter.cpp.  The issue shows when you Select the stats Component in BP_Clancy the details pane shows blank and the game crashes on first used reference to the stats component as a memory access violation.

The strange thing about this is that any other BP that inherits from BaseCharacter is fine and shows it's stats component details still.  This indicates the Class itself is fine and there is corruption in the Unreal Binaries which is far outside reasonable debugging for our team.

The Solution
After research largely from the following forum thread: https://forums.unrealengine.com/t/inherited-component-details-not-showing-in-blu... , it has come to our attention this has been a problem since 2015 and the solutions appear to range to three option with varying rates of success:

Option 1: Rename the component reference name:  I tried this on last night's failure however this would require the entire project to go through a manual find and replace and was not reasonable.

Option2: Change the UPROPERTIES of the component reference in the BaseCharacter.h:  Tried this a few different ways with zero success.

Option 3: Reparent BP_Clancy to a different class BaseCharacter and back again:  I tried to first do this to a different class also derived from BasePlayer so I can preserve some variable defaults that were changed to prevent loss.  This did not work for the same reason as it would preserve the corruption in the stats component.   This made me realize that I need to parent up the tree all the way back up to AActor in the Unreal Class structure and back.

While this ultimately worked, we lost every single default setting on the player and each individual component.  This resulted in multiple bugs introduced and  over 2 hours teamed up with another team member trying to recall each and every setting we have fine tuned over the last 2 months.

The Secret 4th option here is rolling back to a push before the change caused the corruption, however due to the size of the push and number of changes on the push that broke this component, the consequences could have been much further reaching and had the potential to block the whole team until that member would be available to work again.  We would normally have a separate feature branch to ease this burden however due to rules set by our producers, we are restricted to work in a single branch within our version control.  These trials further highlight the importance of proper version control flow in further projects.