Try this fix from Jay.
Quote: "I'm not sure if it's the issue or not, but I remember a bug like
this in episode 1. If it's the same issue, then setting smoothstairs to
zero will fix it (but cause other problems). If that's the case then you
need to add some logic to disable stair smoothing when the player is on an
elevator.
Here's the code from ep1
baseplayer_shared.cpp:
static ConVar smoothstairs( "smoothstairs", "1", FCVAR_REPLICATED, "Smooth
player eye z coordinate when traversing stairs." );
//----------------------------------------------------------------------
-------
// Handle view smoothing when going up or down stairs
//----------------------------------------------------------------------
-------
void CBasePlayer::SmoothViewOnStairs( Vector& eyeOrigin ) {
CBaseEntity *pGroundEntity = GetGroundEntity();
float flCurrentPlayerZ = GetLocalOrigin().z;
float flCurrentPlayerViewOffsetZ = GetViewOffset().z;
// Smooth out stair step ups
// NOTE: Don't want to do this when the ground entity is moving the
player
if ( ( pGroundEntity != NULL && pGroundEntity->GetMoveType() ==
MOVETYPE_NONE ) && ( flCurrentPlayerZ != m_flOldPlayerZ ) &&
smoothstairs.GetBool() &&
m_flOldPlayerViewOffsetZ == flCurrentPlayerViewOffsetZ
)
{
int dir = ( flCurrentPlayerZ > m_flOldPlayerZ ) ? 1 :
-1;
float steptime = gpGlobals->frametime;
if (steptime < 0)
{
steptime = 0;
}
m_flOldPlayerZ += steptime * 150 * dir;
const float stepSize = 18.0f;
if ( dir > 0 )
{
if (m_flOldPlayerZ > flCurrentPlayerZ)
{
m_flOldPlayerZ = flCurrentPlayerZ;
}
if (flCurrentPlayerZ - m_flOldPlayerZ >
stepSize)
{
m_flOldPlayerZ = flCurrentPlayerZ -
stepSize;
}
}
else
{
if (m_flOldPlayerZ < flCurrentPlayerZ)
{
m_flOldPlayerZ = flCurrentPlayerZ;
}
if (flCurrentPlayerZ - m_flOldPlayerZ <
-stepSize)
{
m_flOldPlayerZ = flCurrentPlayerZ +
stepSize;
}
}
eyeOrigin[2] += m_flOldPlayerZ - flCurrentPlayerZ;
}
else
{
m_flOldPlayerZ = flCurrentPlayerZ;
m_flOldPlayerViewOffsetZ = flCurrentPlayerViewOffsetZ;
}
-----Original Message-----
From: Tony "omega" Sergi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 04, 2006 1:06 PM
To: [email protected]
Subject: RE: [hlcoders] jerky platforms
Simple.
The player is the only entity in the engine that is completely different
from any other entity.
All player movement, is done via gamemovement; and is predicted on the
client.
Even the vphysics shadow is basically just a hack, it's on the server only.
Secondly, there is a bug with this (or incomplete code rather) that's been
around since Dave 'Zoid' Kirsch wrote the shared PMOVE (or gamemovement)
system for quakeworld, where the client doesn't properly know all the
collision for the other entities, at the time that it's needed. It's
documented in the q1/q2 engine source somewhere.
Essentially, the player acts like it's own 'god'. It decides where and when
it can move, and making other entities push it around, happen AFTER it
decides if it can or not.
So when the player is on the plat, the gamemovement code already makes
gravity suck it down. So then the plat goes up, and it tries to push the
player up, well the player is applying gravity, and on the client thinks
there's nothing there (it can't see the platform completely) so it applies
gravity and pushes itself down. Now, the server is trying to tell the
player; okay there's an entity trying to move us up, so it "teleports" the
player. Now, remember, the player movement code is all teleportation, it
doesn't really have velocity in the same manner, because it doesn't move the
same way that all other entities do.
The only way to truly overcome this is to make the player move via forces
instead of shifting origin directly, so the player can be simulated at the
SAME TIME as every other entity, instead of before or after it.
It's a major flaw that this engine has inherited from an engine created 10
years ago.
The vphysics shadow doesn't really help much either, it's perfectly fine in
singleplayer where there is no client side prediction, but when you get
hl2mp with prediction on, that's why you jump around when you stand on a
box, and whatnot.
--------------
-- omega
Heroes of Excelsior
http://www.heroesofexcelsior.com
Blackened Interactive
http://www.blackened-interactive.com
> -----Original Message-----
> From: Matthew Lewis [mailto:[EMAIL PROTECTED]
> Sent: July 4, 2006 12:39 PM
> To: [email protected]
> Subject: [hlcoders] jerky platforms
>
> I have been trying to figure out why the platforms are so jerky in their
> motion. I've discovered a few of things:
>
> First, for some reason the client shows the platform as class
> "func_platrot" which is correct. But the the server lists the same
> entity as "func_plat" (the base class). I discovered this by accident by
> printing the classname of the ground entity indentified in the
> ClassifyPosition() routine. (I remade the map to force all the plats to
> func_plat and this problem went away, but the other problems remained.)
>
> Second, if you print the m_vecVelocity of the ground entity, the client
> shows the correct velocity, but the server always shows it as being 0.
> This can't be right since the plats are moving correctly. I'm not sure
> what's happening here. (????) Maybe something is resetting it to zero
> before the print statement in ClassifyPosition?
>
> Third, the jerkiness seems to be from the player being kicked up into
> the air (sorta like going up a stair step) and then falling back to the
> plat. The result is that the FL_ONGROUND flag is oscillating randomly
> (along with the ground entity switching from NULL, to the platform, and
> back to NULL) while the platform is in motion. The weird thing is that
> the code used to navigate stairs doesn't seem to be the thing that's
> doing this.
>
> Any ideas?
>
_______________________________________________
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
