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!