Object placement order affecting casting

Edit : Moved to bug reports

Description the blueprint’s tracing node seems to be affected by object placement order if used in Construction Script. This heavily affect hits result when an earlier placed object can never hit anything that is placed later. I believe this is not an intended feature or limitation. The cast will never hit anything during simulate or PIE. It is important to note that however, if the Blueprint object is moved around in Editor, the cast will successfully hit. But this ironically still does not change the object placed order because if you start the game via Simulate/PIE the hit will never happen.

Repro Steps Make a blueprint object that cast a “Single Sphere Trace by channel” on the construction script. Remember to check the debug line.Place the blueprint actor first. And then place another shape in the path of the intended cast.

Results You will notice that if this blueprint object is place first, the hit can never be successful. But do notice that when you blueprint is moved in the editor, the hit will happen, but this will not change the fact that when playing in Simulate/PIE, the hit again will fail.

Expected Object placement order should not affect the casting; as this would become unpredictable.

Here are the screenshot of both result and node setup. The macro should not matter because the casting debug line is showing correctly.

In the first screenshot, it shows the hit result is showing different result despite it being in the same location.

Here is a better diagram showing the placement order of things and the result.
The number indicate the placement order, as seen, the 3rd placed Blueprint object will produce a hit while the 1st placed object produced no hit.

Hi @,

We have managed to reproduce this bug and found a potential workaround while it is being assessed. Have you attempted to recompile the blueprint script since placing it in the level? It seems that when re-compiled it will pick up the hit trace. This is not ideal however it is a workaround while we attempt to identify the problem. Thank you and have a great day!

Sorry to ask the same question again. Did this manage to get fixed in 4.1?

Hi ,

I apologize for the late reply! We discovered that this is not actually a bug. The construction script only runs when an object is first placed or moved, and not when the game plays. As such, when you place an object in after the capsule that you are tracing with, it will not pick up the object because the constructionscript has already run. This is intended behavior. Have a great day!

Which means if I intend to create a 2 blueprint that detect each other’s collision side by side, one of it WILL ALWAYS bound to fail? because one of them have to be placed after another. Is this correct?

What method then can I reliably use to predict which will spawn first? Because it seems that even during gameplay the order of placement will cause some blueprint to not detect certain objects because they are placed later.

And on top of that, this would also mean that every time such blueprint( that detects another blueprint via collision ) is placed together, I am bound to get inconsistent view from editor vs simulate ( in-game ) ? Picture below is an example.

If this limitation is an accepted behavior, then I believe those who use construction script collision detection will be stuck with this predicament forever? In fact even the given example of Epic’s collision-based grass blueprint would also be affected if the ground is placed before the grass.

I would assume the intended behavior would be that the components(at least the root ) had to be placed first then script be run globally. Wouldn’t that made more sense?