The bug never happened to me, because I noticed the broken function call that was introduced in an earlier video. And even in this video Ben doesnt notice that the parameter DoNotTrace is not the default value, which is TraceFullPath. I guess this means, that it will look for obstacles in the whole trajectory or not.
As in the bug ticket mentioned the problem is a float rounding error, which can’t be fixed in the engine, this just happens. Its up to us to make sure the HitLocation can’t be under the ground (in which no solution can be found) and elevate the HitLocation so that it safely cant happen.
I don’t think there will ever be a bug fix for this, since its our fault to rely on too tiny float values. Computer floats are never 100% exact, since real world float values can contain an infinite amount of data (1/3 for example), but a computer float is limited.
Please don’t report this bug, which isnt one anymore.