I have a shoot mechanic that launches a physics ball that can bounce on the level collision (it is basically the FPS template ball). In relation to this I want to create a preview of the bounce trajectory. The idea is to use the trace to let the player know what direction the ball will bounce, before he actually launches it.
Later I will switch out the trace with a mesh (my “preview line”) and transform it using the values currently passed to the trace’s end-input. Until then I have used the trace to get the basics right.
Obviously there will be an error margin as the trace/line will not care about the physics (velocity and shape). I’m planning to accomodate for the velocity by using the charge values as criterias for the trace length etc. I will add the trace/preview to a tick event once I see that it is acceptable.
I’m using 4.6.1.
actually the problem is when the line trace hits a normal in 1,0,0 direction ( it not about the world)
But I’ve made a reflection by normal that is working for me (it was a hell to do this since I’m not a programmer)
I think is a bug because I saw other users reporting the same problem.
below the code:
I know you’re in 4.6.1 now, but did you upgrade your project from an older version of the editor? The reason I ask is on further testing, my original setup works correctly in a new 4.6.1 project but I noticed that I get the same results as you in a older 4.5.1 project I have.
Okay, here are a couple possible solutions. Both fixed the issue for me in 4.6 but not 4.5.
Add the Normal and Impact Normal of the previous line trace and use that info to set the Start of the next line trace.
Or make an Array out of the Hit Actor and have the next line trace ignore that actor.
Let me know how they go.
I’ll try again when I got home. I’m thinking… maybe it stopped working because I put the results of the line trace to a variable and traced the next line with the variable.
I really have the impression that when I first tested the tjballard solution it have worked
The JIRA report came back as not being a bug. The developers said that the correct way to handle this setup is to use the first fix I posted above. You shouldn’t directly line trace off a a surface normal, you need to add that small offset to keep errors from happening.
However, there still seems to be issues with older converted projects. I believe recreating them in 4.6 will fix the issue and upgrading from there works correctly (tested with our latest internal build).