How to update references after renaming BP in engine?


#1

So I made a spinning cube (Basic Tutorial 1: Create a cube Blueprint and rotate it using Skookum) which worked great, but then I tried renaming the blueprint which made it stop spinning. If I click the Sk button I get taken to a new class which isn’t really what I want. (just wanted to rename the BP)

What’s the best way to update the references so the original script works on the renamed BP? I saw that in the Script area of the SkookumScriptClassData component there’s a field where you can specify a class, but even if you write the name of the original class, if you then click the Sk button to open the class in the IDE you will open the class for the empty new (renamed) class which seems confusing to me.

Is this something you can fix in the IDE/UE4 itself or do you need to change the actual names of the files?


#2

All of the :sk: stuff is stored in a pretty sensible folder hierarchy. So if you had an actor blueprint named BP_Cube, you’d find:

Scripts\Project\Object\Entity\Actor\BP_Cube

So if you renamed your blueprint to BP_AwesomeCube then you could just rename the BP_Cube folder to BP_AwesomeCube and you’d be good.


#3

I see, thanks. What’s the difference between the Project and Project-Generated-BP folders?

It seems like when things get stuck in the Project folder things stop working. For example I create a BP_Cube which spins, put it in the level. When creating the classes in the IDE things are created in the Project folder (in the log: Copying from template) I rename it to Renamed_Cube. When I play the level the cube isn’t spinning. In the Project folder I have a BP_Cube and in the Project-Generated-BP folder I’ve got an Actor.Renamed_Cube. If I copy the files from the Project BP_Cube folder to the Project-Generated-BP Actor.Rename_Cube folder and compile again the cube starts spinning again, and it works even after I rename it from there.

Is something not working right or am I just doing something wrong?


#4

Hmm something may have gotten a little out of sync. The Project-Generated-BP folder is auto-generated. So if you create a new blueprint and compile, it will show up there. One issue with renaming in UE4 is that often things aren’t truly renamed, instead UE4 uses redirectors, so it may be that your visible name is one thing and the underlying name is another until you issue the fix-up redirectors right-click command.

Because of the redirectors fiasco, we generally tend to not rename any assets once they’re in, especially once checked into perforce (this is without :sk: in the picture). This is just a guess, but perhaps this is happening in this instance.


#5

It seems like when you add some code and compile things are actually put in the Scripts\Project folder. From there if you rename the BP in engine the filename stays the same in the Scripts\Project folder but the filename in the Project-Generated-BP folder changes. This seems like a bug to me. Because why would the auto generated empty (after adding code and compiling) folder change when the folder in Scripts\Project with the real script object doesn’t?

I don’t see how redirectors have anything to do with it because if SkookumScript managed to rename the auto generated folder it might as well have renamed the Scripts\Project folder at the same time. Not being able to rename any assets sounds a bit limiting, especially since I often rename BPs and they don’t stop working. I’ve learned how you can fix it by renaming the folder and reloading the project in the IDE but shouldn’t it just work automatically?


#6

Could be a bug. What are the exact steps to reproduce this?

Is it:

  1. Create a BP
  2. Add custom script to BP
  3. Change name of BP

??


#7

Basically yes.

  1. Create a BP (in my case right clicking a mesh and doing create blueprint from this)
  2. Add a SkookumScriptClassData component
  3. Compile
  4. Show in IDE
  5. Add some code (in my case spinning cube example) and compile
  6. Rename the BP and put it in the world, doesn’t spin
  7. Rename the BP back to its original name, spins again

#8

This is a tricky one. The original idea was that, since the Project-Generated-BP overlay is 100% managed by the plugin, it is in charge of renaming classes in there whenever the associated Blueprint is renamed. However, the user is in charge of the Project overlay. So the question is if

  1. the plugin should be allowed to tinker with user code such as classes in the Project overlay, or
  2. this should be user’s responsibility to handle

Maybe a dialog box asking for permission would be the solution. What do you guys think?


#9

For me if the plugin doesn’t change folder names in the Project overlay it feels like there’s a disconnect between UE4 and SkookumScript. Right now if you rename a blueprint with SkookumScript components you’ll have to fix that outside of both UE4 and SkookumScript by renaming folders. Or by being careful not to rename anything at all which seems like a bad workaround.

I’m new to SkookumScript but for me it would make sense if the Show in IDE button always took me to the code I wrote (in my example doing the spinning cube tutorial, renaming the BP and clicking the Show in IDE button takes me somewhere else). Making this the default would make things more predictable in my opinion because if you renamed your BP you would probably want to rename your scripts to that name at the same time. Otherwise you’ve got a renamed BP with scripts that are not renamed which makes things pretty confusing for me at least.

If that’s not how everyone works with SkookumScript I would love for any way of making this possible, dialog box, project setting or anything else. :slight_smile:


#10

I have mixed feelings about auto-renaming the Project overlay. Would there be a way to do it that wouldn’t destroy the entire perforce history of the code assets?


#11

We could look into using P4 move/rename to do the job. How does UE4 handle renaming an asset? From peeking at their source control code it seems like moving/renaming is not supported.


#12

It looks like they do an integrate and then a resolve in this case. Those redirectors cause a lot of pain.


#13

Hmm it seems then we should do the same with :sk: files/folders. That is a bit involved actually. Will add to dolist.