Tripmine beam bug

[ghost]

Greetings!

I discovered this bug while developing my own mod, but the root cause is in Half-Life's implementation of tripmines.

Basically, a tripmine beam will have its start point moved to an incorrect place if the client has not seen the mine yet (e.g. if the mine has not been in the client's PVS).

The interesting part is: the start point gets set to the last place a CGrenade exploded (this includes derived classes like hand grenades, satchels, other tripmines...).

Once the client walks closer to the tripmine (so that it enters PVS) the beam is corrected. It keeps the same endpoint (which was always correct), but changes its start point to be the tripmine location.

Here are 2 examples of it in action:
snipped

Has anyone looked at this before? Any ideas about how to fix it?

Normally I would look at things like whether events are sent (un)reliably, when messages are sent to clients and so on. The problem is that I can't see where this is done for temporary entities like beams and tripmines. Any ideas/brainstorming would be appreciated!

[ghost]

I realize it's a bit weird to reply so soon with the fix, but I actually looked at this months ago and only came back to it today. Coming at it with a fresh perspective made it much easier to solve.

It turns out you can set your CTripmineGrenade::MakeBeam up like this:

    Vector vecStart = pev->origin;
    m_pBeam = CBeam::BeamCreate( g_pModelNameLaser, 10 );
    /* Remove this line: m_pBeam->PointEntInit( vecTmpEnd, entindex() ); */
    m_pBeam->PointsInit( vecStart, vecTmpEnd );

Since the entity might not be transmitted yet (outside pvs), entindex() won't work correctly. You should use the mine's origin as the start vector instead. This way, clients get sent a beam between 2 points in space that are correct.

I'm too lazy to test it in the half-life code and make a pull request, but maybe somebody else can? It worked in my mod anyway, so I'm good to go!

[tschumann]

Sorry I didn't try it - I have seen this in Gunman Chronicles though and wondered what was the cause. Nice work finding a likely fix.

[JoelTroch]

Didn't knew of that bug's existence, I'll try the fix on a clean SDK as soon as I can and I'll report if it's good for a PR.

UPDATE: I confirm that the fix is fully working and a PR can be created. For the record, here's the code:

m_pBeam = CBeam::BeamCreate( g_pModelNameLaser, 10 );
//m_pBeam->PointEntInit( vecTmpEnd, entindex() ); // The line of code to remove
m_pBeam->PointsInit( pev->origin, vecTmpEnd );

[SamVanheer]

A possible alternative for this issue would be to always transmit the tripmine in AddToFullPack. Ignoring ENGINE_CHECK_VISIBILITY for the first frame of the tripmine's life should do the trick here.

[RauliTop]

@kisak-valve fix proposed label?