No quakeworld bunnyhoppping with DP

[Plagued Monkey Rat]

Yo has anyone tried connecting to a TF QW server with DP. It was real jerky until I set cl_movement "1" & cl_netinputpacketlosstolerance "2"

...but when it comes to bunnyhopping you don't seem to accelerate at all. Tried a whole bunch of cl_movent_ variables but nothing seems to work... ideas anyone?

[Baker]

Hmmm ... sounds like something LordHavoc would probably have to answer.

I remember playing some Quakeworld with DarkPlaces and it was really smooth but later found out it had one of the predictions turned off, heheh.

[LordHavoc]

Yo has anyone tried connecting to a TF QW server with DP. It was real jerky until I set cl_movement "1" & cl_netinputpacketlosstolerance "2"

...but when it comes to bunnyhopping you don't seem to accelerate at all. Tried a whole bunch of cl_movent_ variables but nothing seems to work... ideas anyone?

cl_netinputpacketlosstolerance has no effect on QW servers, because the protocol requires 2.

I don't know why you would fail to accelerate - do you mean the prediction is glitching, or that you really can't accelerate?

[Plagued Monkey Rat]

I'm pretty sure I'm not accelerating at all. Feels like I gain no speed, but I don't lose any either.

And without cl_movement "1" its real jerky. If you jump, its like you jump in tiny steps... shudering basically.

But I find the other players movements even with cl_movement "1" are real jerky/shudering/stepping too. Its almost as if there's no interplation between the frames on your enemies. (i'm pretty sure I never turned it off).

.... if my memory serves, Tonik had a variable in zquake cl_smoothmovement... Cl_smoothjump? but it was such a long time ago. I think it was turned on by default and then eventually removed as a client side command. But became part of zquake and was always on. so FUHquake inherited it and so EZquake inherited it. But like I said it was such a long time ago in the good old zquake -bpp 16 days

[LordHavoc]

I have no idea why it would be jerky regardless of the value of cl_movement, it's silky smooth for me in testing.

You may want to experiment with different values for cl_netinputpacketspersecond, which at high values (like 72 would match other quakeworld clients) may lessen the jerkyness, but like I said, I have no idea what's going on.

You could try moving aside your config.cfg's (in id1 and the mod you're playing) and see if it plays better online, if so I'd be interested in a copy of the offending config.cfg file.

[Plagued Monkey Rat]

yeah it was cl_netinputpacketspersecond, had it still set to 20 in my tf dir/cfg, caused the jerky enemy players and lack of accel. Played round on a empty server just then and it seemed all good.... except for 3 things.

Tried to connect to a password-ed server as a spectator, and there's no spectator "1" like in qw engines, I sure there's a command but i'm to lazy to search for it.

There's a frozen dead player ghost type thing in the middle of the map i guess, could be cord 0,0,0 nfi. But he's stuck there in the floating in middle of the map on well6 for example.

Also as a nq engine dp doesn't like some qw skins.pcx due to the size diff
ie the default player skins are 296x194
while some later player skins are 320x200, the actual skins the same size but it has extra black "borders" on the right and bottom of the texture.
this causes the texture coordinates to be wrong on dp with the extra black borders been mapped onto the player model. Dunnno what voodoo magic qw engines use to overcome this, but i just thought i'd mention it.

[LordHavoc]

yeah it was cl_netinputpacketspersecond, had it still set to 20 in my tf dir/cfg, caused the jerky enemy players and lack of accel. Played round on a empty server just then and it seemed all good.... except for 3 things.

So low input packets per second causes problems with bunny hopping? That's really interesting, I may have to add a separate cvar for qw protocol then (which would default to 72).

Tried to connect to a password-ed server as a spectator, and there's no spectator "1" like in qw engines, I sure there's a command but i'm to lazy to search for it.

Nope, not implemented yet, it's on the todo.

I *think* you can do this with setinfo spectator 1 before joining, but not sure.

There's a frozen dead player ghost type thing in the middle of the map i guess, could be cord 0,0,0 nfi. But he's stuck there in the floating in middle of the map on well6 for example.

OK, that's interesting, I'll add it to the todo.

Also as a nq engine dp doesn't like some qw skins.pcx due to the size diff
ie the default player skins are 296x194
while some later player skins are 320x200, the actual skins the same size but it has extra black "borders" on the right and bottom of the texture.
this causes the texture coordinates to be wrong on dp with the extra black borders been mapped onto the player model. Dunnno what voodoo magic qw engines use to overcome this, but i just thought i'd mention it.

Another known bug on the todo.

Full list of known issues with qw:
add .mvd demo support
add .qwd demo support
inactive player entities are showing up at 0 0 0
qw skins should only be active on progs/player.mdl
qw/skins/*.pcx need to be cropped to 296x194 and loaded as internal textures so they are split into multiple layers
restrict wateralpha and such cvars according to what is permitted in qw serverinfo?
cl_netinputpacketspersecond 20 is too low for QW physics to behave properly, add a separate cl_netinputpacketspersecond_qw cvar which defaults to 72
add spectator cvar
add spectator prediction

[Plagued Monkey Rat]

cl_netinputpacketspersecond 20, well I don't know if its too low to stop bunny hopping completely, maybe it just slows down how quickly you can accel (ie takes longer to get up speed...maybe?) Hard to tell as dp is a pretty smooth engine. But 20 is way to low for qw servers, I believe the defaults now 77 on most dm servers, dunno about tf servers. Anyway i'm happy with just adjusting cl_netinputpacketspersecond to 77 anyhow.

thanks again

[LordHavoc]

Anyway i'm happy with just adjusting cl_netinputpacketspersecond to 77 anyhow.

I'd be curious to know the exact speed used by modern qw clients, but in any case, the current beta (20070901beta1) has a separate cvar which defaults to 72.

[Plagued Monkey Rat]

Well it has become 77 (the occasional 75) pretty hard to find a server that uses 72. At least in aus anyway, pretty sure the euros servers are 77, nfi about the yanks servers.

[LordHavoc]

Well it has become 77 (the occasional 75) pretty hard to find a server that uses 72. At least in aus anyway, pretty sure the euros servers are 77, nfi about the yanks servers.

I wasn't asking about the servers, they have no inherent limit in them, they dutifully reply to each client packet if the rate limit permits it, so any claim of them having a framerate is somewhat silly (they do have sv_mintic and sv_maxtic which affect gameplay, but they do not affect player movement in any way, only projectiles and such).

I'm asking what the clients send at.

[Plagued Monkey Rat]

yeah but its the servers that limit your maxfps in quakeworld for example with "serverinfo maxfps 77"

so for ezquake
you set your rate to "x" and cl_maxfps to "77" or "0" for no independent fps
and for independent fps you set your rate "x", cl_maxfps "x" and cl_physfps "77" which is like your cl_netinputpacketspersecond "77"

You can play with a lower number cl_netinputpacketspersecond "60" or cl_physfps "60" but you wouldn't be able to jump as high, move as fast, fall as slow etc. So basically any modern quakeworld player would have it set to 77

[LordHavoc]

yeah but its the servers that limit your maxfps in quakeworld for example with "serverinfo maxfps 77"

This setting is probably just a hint to the client, not enforced in any way.

[Tonik]

>> This setting is probably just a hint to the client

Yes, it's up to the client to decide how many frames to send, but most servers will warn and then kick you if you abuse the limit.

So all modern clients look for "maxfps" in serverinfo and never send more than that (or 72 if the server doesn't say anything)