You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the trip mine transitions to another map it recreates the beam. When you go back to the previous map it will also recreate the beam, but the original beam entity will still exist since the beam is saved and restored by default:
m_hOwner = CBaseEntity::Instance( tr.pHit ); // reset owner too
}
But is incorrect, and will cause some tripmines to explode when loading save games (e.g. on c1a3d).
This is the corrected code:
if (!m_pBeam)
{
// Use the same trace parameters as the original trace above so the right entity is hit.
TraceResult tr2;
UTIL_TraceLine(pev->origin + m_vecDir * 8, pev->origin - m_vecDir * 32, dont_ignore_monsters, ENT(pev), &tr2);
MakeBeam();
if (tr2.pHit)
{
// reset owner too
pev->owner = tr2.pHit;
m_hOwner = CBaseEntity::Instance(tr2.pHit);
}
}
Also of note: the reason why the beams seem to attach to random entities (the light and battery in the video) is because the beam uses PointEntInit, and the entity endpoint stores the index of the entity. The tripmine entity index is not consistent between the two maps, so it will attach to whichever entity is in that slot, if any. If there is no entity it will still attach to that slot, but the origin value won't be valid and will likely be 0, 0, 0, or whatever the last value was that the client received from the server for that slot.
Issue #1670 covers a bug fix that changes the beam to use PointsInit so that particular aspect of this bug won't happen. Instead the beams will overlap, creating a seemingly brighter beam.
This bug was originally found by vasiavasiavasia95.
The text was updated successfully, but these errors were encountered:
An active trip mine will duplicate its laser beam after going back and forth through level changes.
This video shows the problem:
https://www.youtube.com/watch?v=PizJX3pc0xk
This happens because effects entities like beams don't transition to other maps:
halflife/dlls/effects.h
Line 112 in c7240b9
When the trip mine transitions to another map it recreates the beam. When you go back to the previous map it will also recreate the beam, but the original beam entity will still exist since the beam is saved and restored by default:
halflife/dlls/effects.h
Lines 110 to 111 in c7240b9
Effects entities encode which entity they attach to in a way that makes transitioning them rather complicated so that's not an option.
To fix this the beam needs to be made temporary so that the trip mine code can recreate it on demand.
Change this:
halflife/dlls/tripmine.cpp
Line 86 in c7240b9
To this:
After this line:
halflife/dlls/tripmine.cpp
Line 257 in c7240b9
Add this:
//Mark as temporary so the beam will be recreated on save game load and level transitions. m_pBeam->pev->spawnflags |= SF_BEAM_TEMPORARY;
The trip mine will now recreate the beam. The logic for this already exists:
halflife/dlls/tripmine.cpp
Lines 277 to 283 in c7240b9
But is incorrect, and will cause some tripmines to explode when loading save games (e.g. on c1a3d).
This is the corrected code:
Also of note: the reason why the beams seem to attach to random entities (the light and battery in the video) is because the beam uses PointEntInit, and the entity endpoint stores the index of the entity. The tripmine entity index is not consistent between the two maps, so it will attach to whichever entity is in that slot, if any. If there is no entity it will still attach to that slot, but the origin value won't be valid and will likely be
0, 0, 0
, or whatever the last value was that the client received from the server for that slot.Issue #1670 covers a bug fix that changes the beam to use PointsInit so that particular aspect of this bug won't happen. Instead the beams will overlap, creating a seemingly brighter beam.
This bug was originally found by vasiavasiavasia95.
The text was updated successfully, but these errors were encountered: