search

Facepunch / garrysmod-issues

Garry's Mod issue tracker
141 stars 56 forks source link

Erroenous trace behavior #4142

Open Stooberton opened 4 years ago

Stooberton commented 4 years ago

Details

Whenever an entity is moving towards a traces origin with the end position at or near the target entities position (or perhaps on the same plane), trace behavior is erroneous. Happens on ver 2019.12.18 and has happened for as long as I can remember on any host OS, and doesnt appear to behave any differently whether hosted dedicated, p2p, or single.

XQOCbt3T4e

Steps to reproduce

Move an entity towards a trace's origin with the target position being at or around the ent's position (Preferably repeatedly, appears to "miss" at random). Example code: Example.txt

This can additionally be reproduced with anything that uses traces, such as within Wiremod/E2 and has crippled addons such as ACF.

thegrb93 commented 4 years ago

Maybe related https://github.com/Facepunch/garrysmod-issues/issues/2413

willox commented 4 years ago

The traces here are not hitting because the bone cache is outdated. It's tricky to solve without every addon that does something like this refreshing the bone cache (bad) or SetPos automatically refreshing the bone cache (bad.)

But... before any trace is performed against the bones, the model is already traced against with an up-to-date position. I think it'd be safe to optimize out the entire trace against the bones for instances where models have only one bone (and then assume we hit it.)

I think that's what I'll do, but I want to think about it a bit. There's no binding for refreshing the bone cache but you can try this hack to confirm it 'fixes' the issue:

ent:SetPos(ent:GetPos()+ent.vel*FrameTime())
ent:FrameAdvance(5) -- don't actually do this i'm just showing you that it is the bones
thegrb93 commented 4 years ago

Ye that's almost how it was fixed in wire https://github.com/wiremod/wire/blob/master/lua/entities/gmod_wire_turret.lua#L42 glad to see there's a solution.

willox commented 4 years ago

The better solution is probably to just let GMod traces opt-out of testing against hitboxes.

Stooberton commented 4 years ago

Forgot to mention in the original post, but this bug also applies to parented entities. Even a solution that applies specifically to parented entities would be beneficial.

TwistedTail commented 4 years ago

About parented entities specifically, traces seem to ignore them entirely in most cases.

These issues in general have caused a lot of problems on an addon we're currently working on, which is highly dependent on the interaction between traces and entities. I'm pretty sure other addons would have similar problems than us on the same matter.

thegrb93 commented 4 years ago

^ I think that's another issue unrelated to this one.

TwistedTail commented 3 years ago

Seems like both issues, the original one and the one I mentioned, are only related to tracelines instead of all traces in general.

Using a slightly modified version of @Stooberton's example code, we can see that tracelines have trouble hitting a prop moving towards it, while a tracehull with [0, 0, 0] size seems to be able to hit it just fine.

Traceline missed 230 times.
Tracehull missed 0 times.

The issue I mentioned, although it's not the same as the original one, also seems to be especific for tracelines. In the following picture, the prop on the right is directly parented to the prop on the left. Tracelines can't hit it, tracehulls can ([0, 0, 0] size aswell).

Hull entity Entity [147][prop_physics]
Line entity Entity [0][worldspawn]

parent test