MultiSphereTraceByChannel Issue in UnrealEngine 4.26.0 (Preview2)

Question

I am currently learning the UnrealEngine and made huge steps in less time. I worked with version 4.25.1 for a while now and created a projekt in there without having any problems so far. Yesterday I switched from version 4.25.1 to 4.26.0 (Prev2) and observed a strange behaviour.

In the older version I used "MultiSphereTraceByChannel" in one of my Actor-BluePrints and everything worked fine. Looping through the HitArrayResult gave me all hits of the tracer with specific objects.

Now in 4.26.0 it seems that it does not work properly anymore like before. Every hit returns an ImpactPoint of [0,0,0].

Here is a shortened example of my BluePrint:

So First I trace every hit with MultiSphereTraceByChannel with specific objects and then I try to render a sphere at each ImpactPoint of all found hits. This worked in the older Version but does not now...

Does anyone have any Ideas/Suggestions/Questions?

To me it seems that something changed in the newer version which affects the MultiSphereTracer to work like it did before.

Sincerly OlsonLong

Edit:

This problem also happens with regular SphereTraceByChannel-Function!

Answer 1

After some investigations i found the problem/solution to this and it still bothers me that this happens in 4.26... The problems are the Start- and End-Vectors of the SphereTracer (doesn't matter which tracer).

In my example i use ActorLocation as Start- and(!) End-Vector which leads to this struggle. Now if i shift the vector like 1 unit on Z, everything workes fine again.

This is the correct way of the example above:

Works with both MultiSphere- and SphereTraceByChannel. But it still bothers me why this happenes because now i have to change ALL SphereTracer and shift them by only 1 unit.

Answer 2

Thank you. This was also my issue. Unreal 5.1.1 I was getting all sorts of weird numbers. Huge normals. Y and Z flipped impact points. #DEN numbers in c++.

I can also understand that such a trace would like a direction (which for this case seems to default to (1,0,0) in c++ TSceneCastCommonImp ), but just failing randomly is to me a bug. Better fail consistently then. Guess I have to write a bug to Epic now..