Creating a makeshift "close-enough"-factor on "GetEyeTrace"-tracer

[Mailer]

The initial thread title may sound a bit too strange to use as a starting point for the problem I am having so I'll just start off by clarifying a bit more here, as thoroughly and briefly as I can:

I am currently working on a fairly basic "charging"-swep that let's you gain momentum towards an entity within your sight, hence why I am using...
local tr = self.Owner:GetEyeTrace()
...as the main decider for whether or not the weapon should dash you forward, because I only want the owner to gain velocity forward (which implies that some status buffs are being applied to the owner) if they are actively looking at a target to eventually dash into.
The problem is that using GetEyeTrace() alone is very hit-and-miss, because the contours of having a moving entity, primarily a second player, within your eye-tracing are very slim so the user may sometimes fail the targeting by just a few pixels, which causes the SWEP to do nothing and enter a small penalty-cooldown I have intentionally added. This is where the problem comes in:

I am trying to find a decent solution to giving the user's eyetracing a bit more "leeway", which means activating the SWEP even when the eyetracer doesn't precisely hit an entity to charge to, but merely misses by a semi-slim margin.

My initial idea for a solution to this would be to use even more tracers that run parallel to the initial GetEyeTrace-tracer, which would then also detect the SWEP even if the user is aiming slightly off. With the use of util.TraceLine:

https://files.facepunch.com/forum/upload/321820/5aabaf14-ecb1-45f4-9d45-bc0f000ef15e/image.png

local tr_high = util.TraceLine( { start = (self.Owner:EyePos() + Vector(0, 0, 5)), endpos = (tr.HitPos + Vector(0, 0, 5)) } )

where the Vector(0, 0, 5) would be an offset from the initial tracer; And these "offset parallel"-tracers, of which there would be high, low, left and right, would also trigger the weapon to activate, thus giving me the "leeway" I want. However upon trying this solution, I found that I didn't get the results I expected; Although I were able to aim below the entity and still have the weapon fire off with some offset in mind, the problem instead became that I suddenly had "islands of aim" where it would also fire off, even though the player weren't even looking at the entity anymore.
I imagine it's just me being incompetent in understanding how tracers work, specifically the util.TraceLine aspect.

If anyone has a better suggestion, or could point me in a good direction, I would really appreciate it.

[Socram]

I think it might be useful to flip the solution around. Rather than doing multiple spaced out traces against a skinny, silhouette of an enemy, do a single trace against a more forgiving area around the enemy, like a box.

util.IntersectRayWithOBB should do the job nicely, let me know if you have any questions.

[The_HAVOK]

You could try using ents.FindInCone( )

[Mailer]

I've tried both solutions but I think I prefer ents.FindInCone because of how I've also dealt with tables of entities in the past, thus becoming a bit more like coding on familiar grounds; Returning a location, and then using that to find the target, would be one step too many for my taste, although I am absolutely not doubting that util.IntersectRayWithOBB would be perfectly viable solution as well. Honestly, I may have just forgotten that ents.FindInCone existed in the first place. It also eliminates the need to define a maximum range which is nice, thanks to the range-parameter included.
Still, I appreciate both solutions very very much; I ended up cooking up something like this:

local targetlist = ents.FindInCone( self.Owner:EyePos(), self.Owner:GetForward(), 700, 0.99 )
-- 700 = range; 0.99 for a very slim cone, thus a fine tolerance of aiming error

...where I would then later pick the optimal target out of this table of candidates.