Copy/Paste FSM GameObject values: scene cross referencing issues

[Broken Stylus]

I had to recover variables from an ancient version of an FSM that existed in an older scene. I opened said scene in additive mode, then copied the FSM that I needed and pasted it "as values" on its newer version.
But when I'm checking the variables, although they're all there, their values are not because they look for references to the older scene.
The values in question are for Game Objects, so I get the following message in place of the proper GO:

Code: [Select]

Scene mismatch (cross scene references not supported)
If I activate variable debugging in the Variables tab, I see the GO values pointing to the GO of the additive scene (the old one).
As soon as I unload and close the older scene, the variables are empty.

Is there any way I could actually force the references to update themselves by looking for the same GOs but in the current (newer) scene? The scene's hierarchy has not changed at all.

[djaydino]

Hi.
No, as the objects in the new scene have a different guid.

What you could do is (depending on your project) :
open old and new scene, then from old scene drag/drop the object with the fsm + the gameobjects that are referenced

then discard changes on old scene if you wat to keep those.

But it will still reference those GO's not the one in your scene,
but for example if you only would do enable/disable gameobject on them, you could set the new object as a child.

[Broken Stylus]

Yes, the GUID is unfortunately different and the only way to solve this problem would be by finding the equivalent reference of a GO from one scene to another.
Starting with looking at names or hierarchy. But the name method is limited because of many GOs using the same name, and even the hierarchy solution would be hazardous although more accurate because it would use the path access to find where the GO is in the hierarchy, but then would hit a wall if it found a parent to host several children with the same name and no particular order, unless it took into consideration the GO's position in said local hierarchy, at this level. That is, having 40 "shoe" GOs under the same parent for example is not going to help unless their order is taken into account.

So basically, in this case the solution is to go through them one by one and update each reference manually.