I know that.
This is while they ARE in pvs.
I said, the origin isn't what its SUPPOSED TO BE. Only when they
die/respawn.
Even more mystery..
When I print out in hud_addentity, I added another little bit to it..

gEngfuncs.Con_Printf("player: %i, x: %f, y: %f, z: %f\ncso: x: %f y: %f z:
%f\n", ent->index, ent->origin.x, ent->origin.y, ent->origin.z,
ent->curstate.origin.x, ent->curstate.origin.y, ent->curstate.origin.z );

guess what happens?
ent->curstate.origin is correct, all the time! But ent->origin is only
whatever it was when it last respawned or died!
I don't get it at all. Nothings being filtered on the server side, its all
correct in processplayerstate (which means its obviously already in pvs,
since its sending to the client, but in hud_addentity where it does the
magic of allowing it to render or not (from my understanding) its wrong at
this point!


omega
Blackened Interactive - http://www.blackened-interactive.com
Wavelength - http://www.thewavelength.net

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED] On Behalf Of matthew lewis
> Sent: June 15, 2003 11:41 AM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] origin problem
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Individual player origins are only sent to clients when the player is in
> the client's PVS.
> --
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>


_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Reply via email to