Why is my line trace flickering? seems to be colliding or z-fighting with the mouse cursor

Interesting! I’ll have a think - haven’t seen this done. How would that work:

Like so? we can only trace inside the cone? Up/down and to the sides?


a bit of random variation to the hit point

You could try this:

But that’s probably not what you need, since this is updated every frame:

I guess you’d want to it sway a bit slower? Or only apply variations when the player shoots?


You could try experimenting with something along the lines of:

  • generate random offset, here it’s 4x per second:

  • smooth it out:

  • add the offset to Trace End:

Adjust the Min|Max Magnitude, Trace Distance and Interp Speed

1 Like

I guess the cone would ideally only limit it up and down since you still have freedom to turn around in a top down game. it’s just so you can shoot an enemy somewhere else other than the chest line, would make it more interesting I think, you’d be able to use the mouse to aim a bit up or down, but not at your feet or the sky.

as for the variation, swaying slower would be ideal, but I suppose this already works. I can use the fixed trace for aiming, and the one with variation for when the character shoots the gun. however, the sway would be fantastic for adding a laser pointer effect and a decal on the target :grinning:

oh, there it is, already swaying! awesome

1 Like

At a great personal risk of sounding cocky - I am not convinced if that’s what you really want. (do correct me if I’m wrong, though!). The idea is not to limit what the player can do but when then can do it. Since shooting is usually based one the facing direction, see if that’d work for you:

Once the character turns, they will be able to shoot in the facing direction again, ofc. If you’re making a twin-stick shooter (or mechwarrior / tank -style) type of movement and rotation, this would also work because you’d be working with the forward vector of the upper body or weapon.

We’ve yet to see how the movement is supposed to work here, so I might be waaaay off with my assumptions. But judging by the anim in the first post, you’re already rotating towards the hit rotation - so this could be fine as is.


I’ll have a think - haven’t seen this done

Somehow I imagined something more elaborate. It’s just a dot product ← cool example.

Hah fair enough. The big picture:

When the player has the mouse cursor over an actor with the tags “enemy” or “target”, they should have complete freedom to aim wherever they want in XYZ, as long as it’s over this actor. this is great for different kinds of damage depending on where you hit, great for a laser sight trail effect / pointer decal, hit decals and emitters, etc.

When the cursor is over an actor tagged “friendly”, it’ll disable the line tracing, and so aiming entirely. character will even stop the ironsight animation and keep its weapon low.

Those two are basically covered with your previous code.

Now, when the player is just walking around randomly, with the mouse cursor pointing at different parts of the scenery, I don’t want to just shoot the gun at an horizontal plane. this would keep bullet hit decals on walls in a line, even randomizing accuracy a bit. I also don’t want the player to have complete aim freedom while roaming, otherwise it would be almost always looking down to the ground.

So that’s where the cone idea comes in, in fact a cone isn’t a very good description, it would look more like a vertical wedge in a circle around the player, something like this:

This would be great in a situation where let’s say the player is far away from a wall. Within that limited angle, he can hit the entire wall without looking too much up or down. But as he gets closer and closer to it, he won’t be able to aim very low or high and risk having the aim offset too weird looking at his feet or the ceiling, which doesn’t look so great in a top down game.

My original idea was to just disable the player from aiming at actors tagged “floor”, so when the mouse cursor was over a floor object, the aim would be straight. But that would still make it shoot mostly in a horizontal line at the walls, and when cursor is actually over a wall, player would still be able to look way up or down if he was close to it.

In my mind at least this wedge thing would work great lol

Hm, what you’ve described is pretty much what my suggestion does.

49ede6f8c28d4650f1a5b24eb82673cfe0e24c29_2_475x500

  • I can hit that high from here:

  • but only that high from here:

This:

Looks familiar?

We’re only using the vertical slice of the cone because the character is rotating.


You get the data first, what you do with it is another story. Same goes for “friendly” - you do not want to stop tracing, otherwise you will not know what you’re aiming at. Keep tracing and decide how to behave depending on what the trace hits.

1 Like

When it comes to staring at the floor most of the time, yeah:

Do a regular cursor trace first, see what you hit:

  • if it’s the floor → trace on the horizontal plane only
  • if it’s a valid target / wall → cone trace
  • if it’s a friendly → holster weapon or something

With both systems hooked up:

As soon as we look at something other than rhe floor, we can do up / down cone trace. Seems like a promising direction, ehm.

fair, sounds about right. for some reason I thought the character rotation was locked. this is precisely what I was imagining.

let me ask ahead, in your case what would happen if I fired a shot when the trace is red, so when the mouse isn’t hovering the floor, but hovering something else outside the cone range?

my idea was to keep the line trace always inside the cone, so whenever hovering outside of it (let’s say below it since it’s used just for the vertical axis), as long as it’s not a floor, restrict the line trace to stay at the lowest part of the cone, but inside of it.

it could be a hard stop like, follow the mouse cursor and when it leaves the cone, just stop right there, but now I’m imagining it as if the trace hit was attached to a rubber band bound to the center of the cone projection on the wall. so as you get closer to the edge of the cone, the line trace would be getting less and less responsive to following the mouse cursor, until it completely stops at the edge of the circle projected by the cone.

if I was going to imagine a B&W map of cursor responsiveness for the line trace, it would probably be a radial gradient, where white is full responsive and black non responsive. it would be 100% white up to like 75% of the curve and then starts easing into black.

image

I know this is probably not trivial to make, and possibly overkill, but since you wanted to know what I really wanted, this would be the best case scenario for me ;p

now let me try your code and see how it goes

Cache it, store last desired trace result if it was successful. If the trace would end up outside the desired range, use the stored result instead.

Working in an actual responsiveness curve close to the edges shouldn’t be difficult. As soon as we hit the grey zone, I’d interpolate the result with the curve driving Interp speed.

You only need a float the dot product spits out.

1 Like

hmmm I’d still need to change the trace as the player rotates. would only use the cached pitch, and this has gotten beyond my knowledge. the thing with the cone is that I’m using the line trace to shoot but also project the aim dot. so the line trace has to stay inside the cone somehow.

regarding the responsiveness curve, that’s me thinking loud, but way out of my league. I wouldn’t know where to start. Not sure how to figure if the trace is inside the grey zone for starters :sweat_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.