Player collision with angled walls (sticky walls) Created 3 years ago2020-05-15 08:32:14 UTC by outis

I'm guessing this is an issue with all GoldSrc games? Wherein a player can randomly clip a flat wall that doesn't follow the editor's grid. The issue tends toward greater pronunciation with a higher fps. It's one of the many reasons we stick with predominately right angles. But I'm curious if anything at all can be done to alleviate?? I'd prefer an organic fix rather than something like a thin trigger_push along the wall that pushes perpendicular to the wall. (I haven't tried doing this so it might not work but a "fix" like this is where my head is at currently) Maybe there are some compile settings that can help? Maybe certain angles are more troublesome than others?

It could be anything.
I conducted a small experiment where I placed an arch consisting of 16 sides.The map was compiled with -cliptype precise in HLCSG.
In-game, it was perfectly fine without getting stuck anywhere.

But, you mentioned not following the grid. So that probably means you got floating point coordinates in places. To get an off-grid result, I added a ramp here:However, the result was basically the same. It was smooth with no clipping into walls.
So, I tried to manipulate the arch a bit to be under a different angle:Yet the result is still the same. The resulting vertices in the BSP are basically off the grid, but the player movement code handles it just fine.
Here's a video of how it looks.

So my question is, what compilers are you using and what compile parameters are you using?

Wow, thanks for the effort. This community always surprises me with the lengths you're all willing to go to help out. I'm using VHLT with -cliptype precise in hlcsg.exe just as you've done. In TFC. With fps_max 250. That first example would have been trouble in TFC, where the players can regularly move at 400+ u/s. It's more common when wall strafing. I think this is a common problem in CS surfing also. fps_max 100 mostly, if not entirely, eliminates the issue but also affects other aspects that TFC players have grown used to (yes, a few still play!) such as high-precision bunny hopping and frictionless ramp sliding.

I'll see if I can get in on video to show. Time please!

*After testing, speed has nothing to do with it and fps_max 100 helps but doesn't fix. I'll record a video later today to show it and I'll include what keys are being pressed and what fps is being used.

It's been years since I recorded Half-Life videos. I'm using a 2012 MacBook and downloaded some stuff for these (I've been wanting to get back into video editing so this is a good excuse) and they came out really poorly and I didn't feel like fixing. But you can still tell what is going on.

https://imgur.com/a/VlCXqAI - This was recorded using 250 fps and +back/+moveright.
https://imgur.com/a/Ro2LWD7 - 100 fps and same movement. I even managed to avoid fall damage in each video!

It's hard to see a difference between the videos but higher fps does make a difference. At max_fps 30, I'm not sure I've ever got it to happen and with what I can get from max_fps 999, it's a nightmare. The map is a new, experimental thing I'm working on meant to find a balance between the limits of the GoldSrc engine and TFC gameplay in 2020. That pit I'm in has 72 faces.

I set fps_max to 999 and tried out the same map. I only got stuck at the 45° part, which is where these two brushes meet:But then I tried out a normal arch, which is not twisted or bent like the one in there.(note: everything there is on-grid)

And I'd get stuck a lot. Anywhere where two brushes met. This happens due to how GoldSrc map collision works. It has something called clipnodes, which basically define a mesh for collision, it's a bunch of planes.
These clipnodes expand on common brush edges:If they didn't expand, then the player would go into the edges, as if it were something like this:Ironically, it seems to fare better with off-grid coordinates than on-grid ones, hah!
I don't think there's a way to solve this without modifying the player movement code, though. And since you're mapping for TFC, that is not an option.

So, I guess this includes a 45 degree wall with the floor? Cause that can cause issues also. Your explanation suggests that this wouldn't happen when moving along a single, steady angle but I have had this happen before on older maps. Maybe before -cliptype precise? I'll do some more testing and report back if i find anything interesting.