Stuck on object bug

[hlstriker]

Using the freshly compiled 2013 source there is a bug in the multiplayer code (not sure about singleplayer) that causes the player to get the error "client stuck on object 0" (or any other entity index if the object isn't the world). This bug is very easily reproducible and happens all the time. The easiest way to reproduce is to jump up and down while strafing against a wall or walk across some solid models (if it doesn't happen just try another wall or model). If you have developer on you will see the "client stuck on object" message and your viewmodel will jitter.

This seems to be a client prediction bug as if you use cl_pdump 1 you will see the following variables being wrong while "stuck":
m_vecVelocity
m_vecNetworkOrigin
m_flFallVelocity (if you jump up and down)

This really needs fixed but I can't seem to find the cause. If anyone knows more about the issue please let me know.

[ItEndsWithTens]

I'm sorry to say I can't offer a fix for this, but I have a map that offers a ready made, reliable way to reproduce the problem:

http://www.mediafire.com/download/6dp22fw3a6snd4n/test_hl2dm_rampjitters_v2.zip

I built the first version of this map a couple of years ago, trying to figure out why movement up ramps in HL2:DM was perfectly smooth in one place, but jittered like crazy in another. The BSP, VMF, and what notes I've taken so far are included. To summarize the readme, there are three rooms in the map, each with a set of ramps. World geometry in the first, func_details in the second, and func_brushes in the third. Within a given room, each ramp is either consistently smooth or consistently rough, but that doesn't hold true across all rooms (the gray dev textured ramp, for example, is always smooth for me in the first room, but always rough in the other two rooms). That some of the inclines allow repeatably smooth motion gives me hope this is actually a bug that can be fixed, but I'll try not to get my hopes up.

The variables you mentioned were, indeed, blinking red when moving up the rough ramps, but stayed yellow during the smooth ones. I also found that when moving up the rough func_brush ramps the m_fFlags variable joins in the fun. I only wish I knew what significance that held.

I hope the map does somebody some good, since as much as I've learned about C++ recently, I don't know even the first principles of movement in 3D games, predicted or otherwise, so close examination of the code has thus far just left me bug eyed.

[ItEndsWithTens]

I feel like a giant doofus, but after a few months it finally occurred to me to try one of the sdk forks to see if any of them offered a solution. It turns out tonysergi@303f58d seems to do the trick, somehow. That commit from tonysergi's fork has to do with multiplayer animation, but apparently solves our "stuck on object"/jittery movement issue at the same time.

The problem is that the "Multiplayer player animations" commit involves thirty files and a couple thousand changed lines of code; on top of that, at least a few of those changes depend on the work he did in previous commits. I haven't had any luck figuring out what specific set of changes is responsible for the fix, so if anyone has any insight, please do share. I imagine if we can pare down the solution to the bare minimum we'd stand a much better chance of getting a fix into this repo.

[V952]

Take a look at PREDICTION_ERROR_CHECK_LEVEL across ssdk code. They use SPROP_COORD in m_vecOrigin SendProxy by default, which appears to be the cause of the trouble. Just replace it with SPROP_NOSCALE and you're good to go. This will, however, not help with sticky surf ramps. I have tested it on several surf maps and it seems like the issue appears only on really old pre-orangebox maps. I haven't done any research on whether it's the map by itself or the game code, but I will make sure to reply if I find a fix for this.

[TheZoc]

For anyone having issues with ramps and the "client stuck on object" messages, @V952 fix works perfectly.

If you're confused, do this:
Open baseentity.cpp, search for this:

#if PREDICTION_ERROR_CHECK_LEVEL > 1 
	SendPropVector	(SENDINFO(m_vecOrigin), -1,  SPROP_NOSCALE|SPROP_CHANGES_OFTEN, 0.0f, HIGH_DEFAULT, SendProxy_Origin ),
#else
	SendPropVector	(SENDINFO(m_vecOrigin), -1,  SPROP_COORD|SPROP_CHANGES_OFTEN, 0.0f, HIGH_DEFAULT, SendProxy_Origin ),
#endif

Change the second SendPropVector to:

	SendPropVector	(SENDINFO(m_vecOrigin), -1,  SPROP_NOSCALE|SPROP_CHANGES_OFTEN, 0.0f, HIGH_DEFAULT, SendProxy_Origin ),

(This will make it match the first one).

Please, note that this is a workaround for mods! Ideally, fixes would need to be made to the SDK code to make SPROP_COORD work accurately! :)

Happy modding!

[Kefta]

@V952 The surf ramp bug indeed happens with new maps, including in CS:GO. It's unrelated to this, however, and seems to stem from something in the movement code or traces.

[V952]

@Kefta According to this record, it's related to their trace engine implementation and cannot be fixed externally unless you modify the tickrate of the server. I have got less issues using default 0.015ms interval, however my main servers were running 0.010ms (100 tick) and it was impossible to do the first ramp jump because you were stopped every 10 HUs, which sucks, because 100-tick based servers are outperforming default ones in terms of quality of gameplay, and I would rather have no surf maps at all.

I have been modding hl2dm servers since 2009 and I have tried a lot of stuff to fix this issue. All sorts of stuff, even hooking some tracing functions and replacing them with my own ones, but I'm yet to find the solution.

You may try some workarounds, like, in hl2dm maps it highly depends on whether the ramp is above or below z 0.

I doubt you can fix this tracing issue without rewriting the trace engine, which is sad, but if I find a solution I will be sure to post it.