Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tau Cannon/Gauss Gun beam colour is broken in steam release #2865

Open
Skinkroot opened this issue Feb 20, 2020 · 4 comments
Open

Tau Cannon/Gauss Gun beam colour is broken in steam release #2865

Skinkroot opened this issue Feb 20, 2020 · 4 comments

Comments

@Skinkroot
Copy link

Retail Half-Life release includes a feature where the more the Tau Cannon is charged the more white the beam will get. This feature is broken in steam and instead the beam is always bright white when using secondary fire

@Koterminus
Copy link

It looks like this also happens in the current Steam versions of Blue Shift and Opposing Force. The version of the Tau Cannon that appears in Opposing Force's multiplayer mode also has the same bug.

@kisak-valve
Copy link
Member

Gauss Gun beam effect is incorectly reading colors and brightness values

Issue transferred from #2933.
@vasiavasiavasia95 posted on 2020-07-28T14:29:01:

After client prediction was introduced, gauss effect handling was moved to the client resulting in gauss's beam effect being broken.
Primary attack beam's color became yellow instead of orange and secondary attack beam is always shown at full brightness instead of relying on the charge time.
I did some research and found out this happens becasue beam effect requires it's color and brightness values divided by 255. This requriement was overlooked resulting in the broken behavior we got.

To fix this, this function:

halflife/cl_dll/ev_hldm.cpp

Lines 922 to 963 in c7240b9

if (fFirstBeam)
{
if ( EV_IsLocal( idx ) )
{
// Add muzzle flash to current weapon model
EV_MuzzleFlash();
}
fFirstBeam = 0;
gEngfuncs.pEfxAPI->R_BeamEntPoint(
idx | 0x1000,
tr.endpos,
m_iBeam,
0.1,
m_fPrimaryFire ? 1.0 : 2.5,
0.0,
m_fPrimaryFire ? 128.0 : flDamage,
0,
0,
0,
m_fPrimaryFire ? 255 : 255,
m_fPrimaryFire ? 128 : 255,
m_fPrimaryFire ? 0 : 255
);
}
else
{
gEngfuncs.pEfxAPI->R_BeamPoints( vecSrc,
tr.endpos,
m_iBeam,
0.1,
m_fPrimaryFire ? 1.0 : 2.5,
0.0,
m_fPrimaryFire ? 128.0 : flDamage,
0,
0,
0,
m_fPrimaryFire ? 255 : 255,
m_fPrimaryFire ? 128 : 255,
m_fPrimaryFire ? 0 : 255
);
}

Should be modifed to look like this:


if (fFirstBeam)
		{
			if ( EV_IsLocal( idx ) )
			{
				// Add muzzle flash to current weapon model
				EV_MuzzleFlash();
			}
			fFirstBeam = 0;

			gEngfuncs.pEfxAPI->R_BeamEntPoint( 
				idx | 0x1000,
				tr.endpos,
				m_iBeam,
				0.1,
				m_fPrimaryFire ? 1.0 : 2.5,
				0.0,
				(m_fPrimaryFire ? 128.0 : flDamage) / 255.0,
				0,
				0,
				0,
				(m_fPrimaryFire ? 255 : 255) / 255.0,
				(m_fPrimaryFire ? 128 : 255) / 255.0,
				(m_fPrimaryFire ? 0 : 255) / 255.0
			);
		}
		else
		{
			gEngfuncs.pEfxAPI->R_BeamPoints( vecSrc,
				tr.endpos,
				m_iBeam,
				0.1,
				m_fPrimaryFire ? 1.0 : 2.5,
				0.0,
				(m_fPrimaryFire ? 128.0 : flDamage) / 255.0,
				0,
				0,
				0,
				(m_fPrimaryFire ? 255 : 255) / 255.0,
				(m_fPrimaryFire ? 128 : 255) / 255.0,
				(m_fPrimaryFire ? 0 : 255) / 255.0
			);
		}

@BlackShadow
Copy link

BlackShadow commented Aug 3, 2020

Ah, i didn't realize they moved this to client prediction code.

@vasiavasiavasia95
Copy link

@mikela-valve This issue can be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants