NQ and ramp problems

[dfsp_spirit]

On my new map, you sometimes get stuck for a very short time (< 1s) when you walk across the upper end of a ramp. When you try to walk down the ramp backwards you sometimes get completely stuck. I also noticed this in some other maps. What can I do to prevent this?

(There are no clip brushes in the area ofc. If they were there, you couldn't pass at all.)

It doesn't happen when I use a Quakeworld engine it seems and you can prevent it in NQ if you jump before reaching the top edge of the ramp.

[Mindf!3ldzX]

I always new Ramp was a bunch of trouble Tisk Tisk Tal !

[metchsteekle]

you could try making the ramp less of an incline, and then there's always stairs as a fallback if nothing works out.

[Spirit]

iirc this can happen when there are two brushes involved. Make the edge with one brush and it might resolve it.

[MH]

Are you running with high cl_maxfps (or host_maxfps or whatever it's called)? If so, this may not be an NQ problem but a Quake physics problem that doesn't affect QW because you wouldn't be connected to a local server with QW.

[dfsp_spirit]

@spirit:
Thanks for the idea,I just tried it with a single brush but it didn't fix the problem.

@MH: You were right on this one. I didn't mess with frame settings but I found this in id1/mysettings.cfg which is called from autoexec.cfg:

vid_vsync 0                 // disable vsync (make sure this is set to "aplication controlled" or "forced off" in video driver
pq_drawfps 0                // enable fps counter in top-right corner of screen
pq_maxfps 200               // limit fps to 200 max

The name of the cvar suggests that only proquake cares for it though but other engines seam to use it, too. After I changed that value from 200 to 75 the issue was gone (on proquake, enginex and directq).

For some reason fitzquake085 even worked with that setting at 200, most likely it has it's own config file that defines another default value and just ignores pq_maxfps in that file.

[Baker]

72 is the Quake standard frames per second. Physics can get weirded up using a higher frames per second, unfortunately. This is because the client fps is also the server fps in single player.

Eventually I am going to try some of the frames per second and ticrate independent physics ideas out there that R00k, MH and others have discussed. Goes hand and hand with the "grenade bounce" fix, really.

[dfsp_spirit]

Ok, I'll test my stuff at 72 then from now on.

[MH]

Neato. Beer?