CFrictionModifier triggers broken in multiplayer

[L453rh4wk]

Playing Opposing Force and Half-life DM, I've found a very annoying problem in some maps like (op4ctf_hairball and op4ctf_wonderland). The problem consists in after a player leaves an oily / icy surface (CFrictionModifier triggers) his friction never resets to default and needs to die and respawn to avoid start bouncing arround madly.

Coding my mod, i've solved it by editing pm_shared.c at line 3332

// In single player, reset friction after each movement to FrictionModifier Triggers work still.
if ( !pmove->multiplayer && ( pmove->movetype == MOVETYPE_WALK ) )
{
pmove->friction = 1.0f;
}

replacing this code block by:

if (pmove->movetype == MOVETYPE_WALK )
{
pmove->friction = 1.0f;
}

I'm using the latest beta version on windows 7 Exe version 1.1.2.2/Stdio (valve) Exe build: 13:14:12 Aug 29 2013 (6153)

[tschumann]

Hm, I remember this used to work in Opposing Force on Steam ages ago but not in the Half-Life mod code (incidentally, thanks for posting a fix - I wanted to solve this in a mod but couldn't work out where the problem was).

[tschumann]

@L453rh4wk why don't you create a pull request?

[Lifeisstrange74]

@mikela-valve will you consider fixing this in a future update?

[SamVanheer]

See #2542 for why this fix won't work properly.

That issue is also a duplicate of this one.

[kisak-valve]

[GoldSrc] func_friction broken in Multiplayer

Issue transferred from https://github.com/ValveSoftware/halflife/issues/2542. @BlackShadow posted on 2019-06-21T13:11:42:

For some reason when player touches func_friction entity it creates slippy walking effect. This issue occurs only in Multiplayer games. This issue happens in every Multiplayer Goldsrc game so far.

Video about the bug: https://streamable.com/qn4ep

---

@Sockman1 commented on 2019-06-21T13:39:30:

I think I found the cause in the PM_MOVE function in pm_shared.c:

// In single player, reset friction after each movement to FrictionModifier Triggers work still.
\tif ( !pmove->multiplayer && ( pmove->movetype == MOVETYPE_WALK  ) )
\t{
\t\tpmove->friction = 1.0f;
\t}

Basically it's only resetting friction every frame in singleplayer. I don't know why it isn't used for mutiplayer.

---

@BlackShadow commented on 2019-06-21T13:48:47:

@Sockman1 Thanks for pointing this out. This issue can be easily fixed by adding "else" check.

\t// In single player, reset friction after each movement to FrictionModifier Triggers work still.
\tif (!pmove->multiplayer && (pmove->movetype == MOVETYPE_WALK))
\t{
\t\tpmove->friction = 1.0f;
\t}
\telse 
\t{
\t\tpmove->friction = 1.0f;
\t}

---

@SamVanheer commented on 2019-06-21T14:09:38:

If i had to guess this is because it won't predict movement correctly when you have a lot of lag. The predicted movement will not account for friction for some frames, but when you get resynced with the server it'll snap you back.

[JulianHeuser]

@BlackShadow An else check wouldn't work, it would reset friction for objects that aren't the player.

The easiest way to fix this is to just remove the check for multiplayer from the if statement. A more complex but possibly better way is to reset the player's friction as soon as they leave a func_friction trigger.

[BlackShadow]

The fix i've posted is working actually. I've tested it. It's more like a hack than a fix. But it works.

[Zhukow]

yes, this problem has been present for a long time in the multiplayer game since it was updated in 2013, look how great everything was in the old build of 2009, before the update there the sliding worked as it should without problems!

[Zhukow]

In general: this problem (slide bug) can be solved, but only on your server, if you replace new steam files on old files in the folder cl_dlls, client.dll and in the folder dlls, opfor.dll