Announcement

Collapse
No announcement yet.

[Solved] Troubles migrating blueprints that contain ustrucs/uenums derived from C++.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [Solved] Troubles migrating blueprints that contain ustrucs/uenums derived from C++.

    Edit:

    I was able to get the results I was looking for by using this single redirect:

    +PackageRedirects=(OldName="/Script/OldModuleName",NewName="/Script/NewModuleName",MatchSubstring=true

    where OldModuleName and NewModuleName are the module name differences between my 2 projects. I had tried this earlier but due to the nature of my actual module names (Going from TheCardGame to TheCardGameServer) it seemed to cause an infinite loop due to the substring "theCardGame" being contained within the new string "theCardGameServer" so it was never able to not find the substring and know when to stop.







    Hey everyone,
    I have 2 projects that share several structs and uenums that derive from a set of cpp files. Both projects share the exact same cpp files through a symlink.
    Any blueprints that contain any of these uenums or ustructs will fail to retain these properties when migrated between the two projects. On migration the uenums are reverted to bytes and the ustructs are removed altogether. I haven't tested but I assume this would be similar for UObjects derived from cpp and any other CPP derived class/functions/variables.

    I tried using the re targeting syntax in the engine.ini to handle project name alterations between the 2 projects but that seems to have no affect on the issue. I assume this is a limitation to the migration system rather than a bug. Perhaps related to some sort of unique identifier mismatch for the data types between the 2 projects.

    However I was wondering if anyone knew of any workarounds that may be available. In my situation I will always be migrating from one specific project to another specific project. With knowing the target and and source information would it perhaps be possible to modify the uassets manually to survive the migration? I will try to dig into this myself, but wanted to see if anyone else has tackled this before so i'm not re-inventing the wheel.

    I know the simple solution is just to recreate the BPs in cpp; However, for academic purposes I'm testing client-server traffic using BPs between asymmetrical projects so it is imperative to have the BPs derive these structs and enums from the shared cpp. The current alternative is the timely process of manually adjusting the BPs on each migration, fixing all the enums that got turned into bytes and re-adding all the struct variables and related nodes.

    I thank you for your time and any assistance you may be able to provide.
    Last edited by treemakesagame; 06-27-2018, 07:08 PM.
Working...
X