Child Blueprint Fails to Reparent to parent class

[Rosium]

I wanted to export an enemy blueprint to another project, but all references break and a pop up appears stating that the parent class is invalid. no matter how many times the broken nodes were fixed, once you close and reopen the project everything is undone.

The parent class can not be found in the dropdown list within any of the child classes.

There was an issue with duplicated GUIDs, i tried the following:
-removing saved, intermediate, and cache
-added the CoreRedirects to the DefaultEngine.ini
-rebuilt binaries
-duplicating the base class and deleting the old, however, the redirectors for the old enemy base class can not be removed, until the saved, intermediate, and cache folders were deleted.

The files can not be migrated to another project.
All files referencing the enemy class breaks.

When the files were created from scratch, they were still broken and all references to the main player blueprint was lost.

My goal is to fix the enemy blueprints so that is can be safely exported to another project and to reparent to child blueprints.

Here are all of the pop-ups I received during this dilemma.

[93cbbb041d664728acde881e234fed25 (Kiray)]

My workflow of making a blueprint class migration as safe as possible.

Before migration, reparent the blueprint to a base class from the engine. In your case, reparent your enemy parent class to a pawn or a character.

Functions/variables/parameters… that are hard referencing a class that’s not in the engine, also change them into base engine classes.

Example: Change enemy function “ChasePlayer(PlayerBP* player)” to “ChasePlayer(Character* player).” Change the function pin type to Pawn in blueprint.

Fix up all the errors and nodes from the reparenting, leaving as much original logic as possible. The base classes are place holders.

Right click on BP and open reference viewer, the less references the safer. All the references are going to migrate with the child class.

THEN you can migrate the child class. Do the fixing before migration, not after.

After migration, reparent/reimplement/repair the changes to the new ones.