Inconsistent code order of MoveInstancesForMovedComponent and RerunConstructionScripts on Actor Move

Hi there,

We ran into a little bit of trouble recently with a code inconsistency in the Actor class. We have been doing some work to get a blueprint actor and foliage working together for our purposes and I noticed that there is a major difference between AActor::PostEditChangeProperty and AActor::PostEditMove when it comes to handling the updating of the foliage location via MoveInstancesForMovedComponent on the AInstancedFoliageActor.

In PostEditChangeProperty the loop of the components to do MoveInstancesForMovedComponent is done first, before RerunConstructionScripts is called.

In PostEditMove, RerunConstructionScripts is called first and then the loop of the components to do MoveInstancesForMovedComponent is called.

I was wondering if there was a specific reason for this inconsistency or if it just happened to land that way as it had no real consequence since blueprints and foliage aren’t supported together as yet.

The reason this became an issue for us is that we needed to relink the foliage to the newly created primitive components which happen in RerunConstructionScripts. We move all the foliage from the old component which is being destroyed, to the new one via MoveInstancesToNewComponent on the AInstancedFoliageActor. This code calls UpdateLocationFromActor on all the FFoliageMeshInfo which reset the root location to the components location.

What this means is in the PostEditMove case, is that when the MoveInstancesForMovedComponent is called after the reconstruction, the component is the same as the cached location so the foliage does not move. As noted this is only an issue because of code we added and we have worked around the issue,

I just wanted to bring it up in case this inconsistency has other issues or will affect the future work to get foliage and blueprints working together in your road map. If there is not a technical reason behind the difference it would be great to have it consistent if possible.

Thanks for any information you have on this.

Hi ,

Thank you for bringing this to our attention. This involves some code that has been in place for quite some time. When I mentioned your concern about this bit of code yesterday, it sparked a small discussion among a few developers. I do not know yet what the final result will be, but it does look like we will most likely adjust the code in one of those locations to match the other location.