Don't use Q_rint in MSG_WriteAngles...

[mh]

...or other +/- 0.5f tricks.

There is a bug with some maps (outlined here: ) where entities do have angles set, but the standard precision loss in stock ID code doesn't cause them to have any effect. Switching to Q_rint-like behaviour causes things to go mildly berserk.

This also affects any protocol change where angles have more precision that 1 byte.

Fully reproducable in hrim_sp1: the part where you push a button and a platform rises out of lava.

[goldenboy]

[mh]

[Spike]

how does that fix anything?
if the server is generating the wrong bbox then its collisions will be broken anyway.
if the model really is rotated with an origin, its clientside representation will differ from the server's 1-rotated bbox whether its sent as 0 or 1.0/255.

[mh]

It's not bbox-related.

OK, specific case where this occurs. hrim_sp1 has a brush model that has angles of (0, -1, 0).

Protocol 15's default handling of angles (((int)f*256/360) & 255) makes this send to the client as (0, 0, 0).

Using Q_rint makes it send to the client as (0, ~(-1), 0).

In the former case the bmodel is drawn in the correct location.

In the latter case it's not. It's not just out of position by a small amount, it's wildly out of position.

Compare:



The bbox on the server stays correct, the bmodel is drawn in the incorrect position on the client, you jump on the platform but only a small part of it will actually catch you - the rest of the time you're going into lava.

So what the hacky/quick-n-dirty thing does is kinda reproduce the behaviour of standard protocol 15 for really small angles by forcing anything in the range -1..1 to 0. Standard protocol 15 already does this anyway so it's nothing new.

[mh]

[r00k]

Shouldn't there be corresponding READ functions?

[mh]

No need because once an angle is encoded into a byte, that byte is only ever going to give the same result back when decoded. It's the byte that it gets encoded into that matters.

[r00k]

_small tangent_

I noticed ProQuake (for lack of another comparison) uses shorts for angles (client --> server) BUT doesnt send PRECISEangles to the client from the server in SV_WriteEntitiesToClient.

So im a bit confused, (easily done), the client moves the mouse, aims at angle 34.54 (truncate/rounds/sends) to the server 34degrees the server runs through its frame sends back to ALL client's 34*(360/256) = 47.8125 ???

[Tomaz]

[r00k]

[mh]

All clients sent angles to the server as part of their input.

But.

Yes, the send back from the server does overwrite, but the client does nothing with this data. At least for the local client; it does use the data for other clients to orient their player.mdl correctly; for the local client it does absolutely nothing. The angles go into the entity_t struct for the local client for sure, but the view position on the local client is actually controlled by cl.viewent which is updated separately in your view.c

Then the next frame the local client just sends it's angles again, which are accumulated from input into a usercmd_t; doesn't even go near an entity_t (at least for this part of it; r_refdef.viewangles also comes in but let's not complicate things; Quake has too many variables scattered around the place all containing the same data and it makes my head hurt sometimes).

So really you've got two entity_t structs on each client representing the local client; cl_entities[cl.viewentity] is one of the regular entity_t structs that get overwritten by the server, and all other clients live there too, cl.viewent is a separate "special" entity_t that manages the state of you as the local client.

Clear as mud?

[r00k]

Ok that's why sometimes players look like they are aiming at one point but the rockets comes out from the corner of their "bounding box"...

as long as my POV isnt getting reAdjusted. That would make for jittery aim.

[mh]

...or it might be just MDL animations being crap...