How to Migrate a Custom Level BP (C++)?

Development World Creation
, , , ,
1

Hello,

I have just migrated a level to a new project. The level BP’s parent is a custom level script actor created in C++ (ALevelScriptActor). Custom functions are accessed with BP nodes.

The new code compiles, but the new level BP complains that it derives from an invalid class (None). When I try to assign a parent to this level BP the editor does not detect the C++ ALevelScriptActor.

What am I doing wrong?

How do I migrate a custom level script actor?

Thanks!

Edit: When I try to create a new C++ class from the editor, both the LevelScriptActor and the CustomLevelScriptActor are detected as possible parents.

However, when I create a new Custom_2_LevelScriptActor (derived from LevelScriptActor) in the editor, I can, and it compiles in VS. However, the Level BP still does not detect this newly created Custom_2_LevelScriptActor.

Also, now I’m having issues with compiling in the editor. It’s complaining about the .generated.h file, which is not found. Building/Rebuilding the project does not solve this.

2

This has been an issue for a while.

3

I think the problem is most likely related to module name, when you make C++ project you actually making project with C++ module, one of many already in existing in the engine. The name of modules is independent from project name, but by default created module will have the same name as newly created project. Module name is part of the path name to class in reflection system and if it’s different then it wont match with the path name in the old project in level data and class will be considered missing in new project

Try doing this:

Copy the module folder (one after “Source”) with the same name to new project, delete all code files that you don’t need (leave cs files, modulename.cpp and .h) and leave only level script class and it’s dependencies (so what you need). Now add module to uproject file by editing it in text editor, like this:

"Modules": [
	{
		"Name": "ModuleWithNewProjectName",
		"Type": "Runtime",
		"LoadingPhase": "Default",
		"AdditionalDependencies": [
			"Engine"
		]
                    
	},		
           {
		"Name": "ModuleWithOldProjectName",
		"Type": "Runtime",
		"LoadingPhase": "Default",
		"AdditionalDependencies": [
			"Engine"
		]
	}
    ]

You also need to add module in to .target.cs files in Source directory, just add another line like this in same spot on both files:

ExtraModuleNames.AddRange( new string[] { "ModuleWithOldProjectName" } );

Now regenerate VS project files (there option for that in right click of uproject file) and this way you got another module with old name, with should allow to properly migrate the asset. After that you can make same class with different name in module with new project name, properly switch it in project settings and load and save the level (make sure level definitely runs on new class), delete the old name module and it reference in uproject to fully migrate the asset.

Now here protip for future, if you got some C++ code for level blueprint and you plan to reuse it in all of your project, consider making plug in, this will save you a all that trouble as you gonna have module in plugin that have same name regardless where you using it and should work in any project.

1 Like
4

Previously I’ve just copied the project and renamed a few config lines. So the new project would have a different name, but there were files still with the original name.

Perpetuating a file named “Test_0” isn’t great. I’d like to deprecate that and give the file a better name. That’s my plan here.

I can add the second module – though that’s messy. However, I would need to change the class name, which has been problematic.

This:
Module name is part of the path name to class in reflection system and if it’s different then it wont match with the path name in the old project in level data and class will be considered missing in new project

I’m looking to access that level data. That is very insightful. Thank you.

One option I’m considering is to unparent the level BP prior to migration, recreate the custom code in the new project, then reparent the level BP.

Also your suggestion for a plugin is great. Thank you. I will consider that. However performance here is king, though I don’t think it will be overly impacted.

Really, I think I should have decoupled the custom logic from the level BP, but it seems that others are having this same issue with custom classes in general.

Thanks!