Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] No it doesn't. It only fixes when you are standing on a moving entity, like an elevator. About the jittery when walking over tables: is your CMoveHelperClient::ProcessImpacts empty? In that case, fill it with the code of CMoveHelperServer::ProcessImpacts (except the PhysicsTouchTriggers-call) and try it again. On 7/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > You think this patch fixes the horrible jitters bug when walking over > tables etc? Cool I haven't tried that one yet - will do. > > > http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Jerky_Movement_when_player_is_on_moving_lift.2Felevator > > > At 2006/07/23 06:13 AM, Robbie Groenewoudt wrote: > >-- > >[ Picked text/plain from multipart/alternative ] > >@bloodykenny: Elevators now work good, with the patch at the VDC. > >Client should have the same physics code as the server... > > > >On 7/23/06, Aaron Schiff <[EMAIL PROTECTED]> wrote: > >> > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> The major reason for the jitters is that the client knows that an > object > >> is > >> solid, but it doesn't have it added to the clientside physenv (which > would > >> simulate it). Since the client doesn't know simulation, player movement > is > >> predicted based on what it assumes are static objects. The server > predicts > >> differently of course because of physics simulation. This change is > then > >> sent to the client which makes the jitteriness appear. > >> > >> -- > >> ts2do > >> -- > >> > >> ___ > >> 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 > > ___ > 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
Re: [hlcoders] Client-side touch prediction
You think this patch fixes the horrible jitters bug when walking over tables etc? Cool I haven't tried that one yet - will do. http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Jerky_Movement_when_player_is_on_moving_lift.2Felevator At 2006/07/23 06:13 AM, Robbie Groenewoudt wrote: >-- >[ Picked text/plain from multipart/alternative ] >@bloodykenny: Elevators now work good, with the patch at the VDC. >Client should have the same physics code as the server... > >On 7/23/06, Aaron Schiff <[EMAIL PROTECTED]> wrote: >> >> -- >> [ Picked text/plain from multipart/alternative ] >> The major reason for the jitters is that the client knows that an object >> is >> solid, but it doesn't have it added to the clientside physenv (which would >> simulate it). Since the client doesn't know simulation, player movement is >> predicted based on what it assumes are static objects. The server predicts >> differently of course because of physics simulation. This change is then >> sent to the client which makes the jitteriness appear. >> >> -- >> ts2do >> -- >> >> ___ >> 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] @bloodykenny: Elevators now work good, with the patch at the VDC. Client should have the same physics code as the server... On 7/23/06, Aaron Schiff <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > The major reason for the jitters is that the client knows that an object > is > solid, but it doesn't have it added to the clientside physenv (which would > simulate it). Since the client doesn't know simulation, player movement is > predicted based on what it assumes are static objects. The server predicts > differently of course because of physics simulation. This change is then > sent to the client which makes the jitteriness appear. > > -- > ts2do > -- > > ___ > 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
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] The major reason for the jitters is that the client knows that an object is solid, but it doesn't have it added to the clientside physenv (which would simulate it). Since the client doesn't know simulation, player movement is predicted based on what it assumes are static objects. The server predicts differently of course because of physics simulation. This change is then sent to the client which makes the jitteriness appear. -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Ah ok... that Touch()... I'd say the jitteriness when walking over objects is currently one of top 3 most glaring bugs in the HL2 engine. It's probably related to all those posts recently about trying to get elevators to not be choppy. I've never played a map with an elevator in it though. At 2006/07/18 09:32 AM, Jorge Rodriguez wrote: >[EMAIL PROTECTED] wrote: >>What problem does this solve exactly? I tried it, and the client is still >>jittery when walking on tables or into boxes. > >Racking my memory to remember a five month old patch, if I remember >correctly, this patch simply allows client-side touch triggers to occur. >I'm not sure it actually affects movement in any way. It might improve >it somewhat, or be one piece in a larger puzzle that improves it. All >this bit does right here though is just allow for Touch() and whatever >to be called, so that you can tell from the client if the player has >touched an object. > >-- >Jorge "Vino" Rodriguez > > >___ >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
Re: [hlcoders] Client-side touch prediction
[EMAIL PROTECTED] wrote: What problem does this solve exactly? I tried it, and the client is still jittery when walking on tables or into boxes. Racking my memory to remember a five month old patch, if I remember correctly, this patch simply allows client-side touch triggers to occur. I'm not sure it actually affects movement in any way. It might improve it somewhat, or be one piece in a larger puzzle that improves it. All this bit does right here though is just allow for Touch() and whatever to be called, so that you can tell from the client if the player has touched an object. -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] Well...I only heard this once...but it may be possible that the player movement is processed before physics simulation and that causes the player to be moved out of the way -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
What problem does this solve exactly? I tried it, and the client is still
jittery when walking on tables or into boxes.
At 2006/03/23 12:14 PM, Jorge Rodriguez wrote:
>Client-side touch prediction is disabled in the standard SDK. I had some
>need for it, so I stuck it in. Since it's non-trivial, and something
>that shouldn't have to be written twice, I'm posting it here for
>opinions and corrections. It's mostly just copied from the equivalent
>server code. This patch is from my version control system, so it might
>not fit so cleanly into the patch utility. And those line numbers might
>not be totally accurate, if I've edited those files before.
>
>cl_dll/movehelper_client.cpp
>===
>--- cl_dll/movehelper_client.cpp
>+++ cl_dll/movehelper_client.cpp
>@@ -128,6 +128,38 @@
>
>void CMoveHelperClient::ProcessImpacts( void )
>{
>+// Don't bother if the player ain't solid
>+if ( g_pLocalPlayer->IsSolidFlagSet( FSOLID_NOT_SOLID ) )
>+return;
>+
>+// Save off the velocity, cause we need to temporarily reset it
>+Vector vel = g_pLocalPlayer->GetAbsVelocity();
>+
>+// Touch other objects that were intersected during the movement.
>+for (int i = 0 ; i < m_TouchList.Size(); i++)
>+{
>+C_BaseEntity *pEnt = ClientEntityList().GetEnt(
>m_TouchList[i].trace.m_pEnt->entindex() );
>+if (!pEnt)
>+continue;
>+
>+// Don't ever collide with self
>+if ( pEnt == g_pLocalPlayer )
>+continue;
>+
>+// Reconstruct trace results.
>+m_TouchList[i].trace.m_pEnt = pEnt;
>+
>+// Use the velocity we had when we collided, so boxes will
>move, etc.
>+g_pLocalPlayer->SetAbsVelocity( m_TouchList[i].deltavelocity );
>+
>+pEnt->PhysicsImpact( g_pLocalPlayer, m_TouchList[i].trace );
>+}
>+
>+// Restore the velocity
>+g_pLocalPlayer->SetAbsVelocity( vel );
>+
>+// So no stuff is ever left over, sigh...
>+ResetTouchList();
>}
>
>void CMoveHelperClient::StartSound( const Vector& origin, const char
>*soundname )
>
>cl_dll/prediction.cpp
>===
>--- cl_dll/prediction.cpp
>+++ cl_dll/prediction.cpp
>@@ -837,9 +837,7 @@
>
>RunPostThink( player );
>
>-// TODO: Predict impacts?
>-//// Let server invoke any needed impact functions
>-//moveHelper->ProcessImpacts();
>+moveHelper->ProcessImpacts();
>
>FinishCommand( player );
>
>So far this code works for my purposes. Has anybody else done this, or
>want to try this and provide some input? Maybe Valve has some pointers,
>or a reason why they didn't do it in the first place?
>
>Thanks.
>
>--
>Jorge "Vino" Rodriguez
>
>
>___
>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
Re: [hlcoders] Client-side touch prediction
So - the boxes fall on you at night? I bet it's hard to see them. Have you thought about lighting up the boxes so players can see them, or is the darkness actually part of the gameplay? :^) Quoting Jorge Rodriguez <[EMAIL PROTECTED]>: > Aaron Schiff wrote: > > >-- > >[ Picked text/plain from multipart/alternative ] > >nightfall is a mod that Amckern is working on > >physics boxes are func_physbox entities > >physics death is when they crush you > > > > > ... and this code will stop the player dying from those boxes? That > doesn't make any sense to me, this code is client side so it shouldn't > affect that at all. > > -- > Jorge "Vino" Rodriguez > > > ___ > 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
Re: [hlcoders] Client-side touch prediction
Lets forget it :) My Website http://www.ammahls.com Lead Programer NightFall http://www.nightfallmod.net Developer of CST and ZHLT 3.0 http://www.zhlt.info Team Lead - Prime - http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] No...he's not saying that at all. On 3/29/06, Jorge Rodriguez <[EMAIL PROTECTED]> wrote: > > Aaron Schiff wrote: > > >-- > >[ Picked text/plain from multipart/alternative ] > >nightfall is a mod that Amckern is working on > >physics boxes are func_physbox entities > >physics death is when they crush you > > > > > ... and this code will stop the player dying from those boxes? That > doesn't make any sense to me, this code is client side so it shouldn't > affect that at all. > > -- > Jorge "Vino" Rodriguez > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] nightfall is a mod that Amckern is working on physics boxes are func_physbox entities physics death is when they crush you ... and this code will stop the player dying from those boxes? That doesn't make any sense to me, this code is client side so it shouldn't affect that at all. -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] nightfall is a mod that Amckern is working on physics boxes are func_physbox entities physics death is when they crush you On 3/29/06, Jorge Rodriguez <[EMAIL PROTECTED]> wrote: > > Adam "amckern" Mckern wrote: > > >Yeah sorry - thats one word i cant even try and spell > >physics > > > > > OK so phis means physics, but I still don't know what physics boxes or > physics deaths are. Come to think of it, I don't know what nightfall is > either, is it a map? > > I'm not trying to insult your intelligence -- I really don't know what > they are. I'd like to know exactly what effect the code has had on your > game so I can see it for myself and understand it better. > > -- > Jorge "Vino" Rodriguez > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Adam "amckern" Mckern wrote: Yeah sorry - thats one word i cant even try and spell physics OK so phis means physics, but I still don't know what physics boxes or physics deaths are. Come to think of it, I don't know what nightfall is either, is it a map? I'm not trying to insult your intelligence -- I really don't know what they are. I'd like to know exactly what effect the code has had on your game so I can see it for myself and understand it better. -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Yeah sorry - thats one word i cant even try and spell physics --- Jorge Rodriguez <[EMAIL PROTECTED]> wrote: > Adam "amckern" Mckern wrote: > > >Runs clean with nightfall, and seems to stop in my > >testing the phis death that is cased by the > suspended > >phis boxes! > > > >Well done > > > > > Sorry, but I don't know what phis death and > suspended phis boxes are. I > don't even know what 'phis' means. Can you regress > please? > > -- > Jorge "Vino" Rodriguez > > > ___ > To unsubscribe, edit your list preferences, or view > the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > My Website http://www.ammahls.com Lead Programer NightFall http://www.nightfallmod.net Developer of CST and ZHLT 3.0 http://www.zhlt.info Team Lead - Prime - http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Adam "amckern" Mckern wrote: Runs clean with nightfall, and seems to stop in my testing the phis death that is cased by the suspended phis boxes! Well done Sorry, but I don't know what phis death and suspended phis boxes are. I don't even know what 'phis' means. Can you regress please? -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Runs clean with nightfall, and seems to stop in my
testing the phis death that is cased by the suspended
phis boxes!
Well done
--- Tim Lippert <[EMAIL PROTECTED]> wrote:
> Does this help with getting rid of the "client stuck
> on object xxx" wall bug my players are screaming
> about in Kreedz Climbing??
>
> Or is it something very different and only
> pertaining to physics models?
>
>
>
> Client-side touch prediction is disabled in the
> standard SDK. I had some
> need for it, so I stuck it in. Since it's
> non-trivial, and something
> that shouldn't have to be written twice, I'm posting
> it here for
> opinions and corrections. It's mostly just copied
> from the equivalent
> server code. This patch is from my version control
> system, so it might
> not fit so cleanly into the patch utility. And those
> line numbers might
> not be totally accurate, if I've edited those files
> before.
>
> cl_dll/movehelper_client.cpp
>
===
> --- cl_dll/movehelper_client.cpp
> +++ cl_dll/movehelper_client.cpp
> @@ -128,6 +128,38 @@
>
> void CMoveHelperClient::ProcessImpacts( void )
> {
> +// Don't bother if the player ain't solid
> +if ( g_pLocalPlayer->IsSolidFlagSet(
> FSOLID_NOT_SOLID ) )
> +return;
> +
> +// Save off the velocity, cause we need to
> temporarily reset it
> +Vector vel = g_pLocalPlayer->GetAbsVelocity();
> +
> +// Touch other objects that were intersected
> during the movement.
> +for (int i = 0 ; i < m_TouchList.Size(); i++)
> +{
> +C_BaseEntity *pEnt =
> ClientEntityList().GetEnt(
> m_TouchList[i].trace.m_pEnt->entindex() );
> +if (!pEnt)
> +continue;
> +
> +// Don't ever collide with self
> +if ( pEnt == g_pLocalPlayer )
> +continue;
> +
> +// Reconstruct trace results.
> +m_TouchList[i].trace.m_pEnt = pEnt;
> +
> +// Use the velocity we had when we
> collided, so boxes will
> move, etc.
> +g_pLocalPlayer->SetAbsVelocity(
> m_TouchList[i].deltavelocity );
> +
> +pEnt->PhysicsImpact( g_pLocalPlayer,
> m_TouchList[i].trace );
> +}
> +
> +// Restore the velocity
> +g_pLocalPlayer->SetAbsVelocity( vel );
> +
> +// So no stuff is ever left over, sigh...
> +ResetTouchList();
> }
>
> void CMoveHelperClient::StartSound( const Vector&
> origin, const char
> *soundname )
>
> cl_dll/prediction.cpp
>
===
> --- cl_dll/prediction.cpp
> +++ cl_dll/prediction.cpp
> @@ -837,9 +837,7 @@
>
> RunPostThink( player );
>
> -// TODO: Predict impacts?
> -//// Let server invoke any needed impact
> functions
> -//moveHelper->ProcessImpacts();
> +moveHelper->ProcessImpacts();
>
> FinishCommand( player );
>
> So far this code works for my purposes. Has anybody
> else done this, or
> want to try this and provide some input? Maybe Valve
> has some pointers,
> or a reason why they didn't do it in the first
> place?
>
> Thanks.
>
> --
> Jorge "Vino" Rodriguez
>
>
>
__
> Verschicken Sie romantische, coole und witzige
> Bilder per SMS!
> Jetzt bei WEB.DE FreeMail:
> http://f.web.de/?mc=021193
>
>
> ___
> To unsubscribe, edit your list preferences, or view
> the list archives, please visit:
>
http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
My Website http://www.ammahls.com
Lead Programer NightFall http://www.nightfallmod.net
Developer of CST and ZHLT 3.0 http://www.zhlt.info
Team Lead - Prime - http://www.nigredostudios.com
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Client-side touch prediction
Does this help with getting rid of the "client stuck on object xxx" wall bug my
players are screaming about in Kreedz Climbing??
Or is it something very different and only pertaining to physics models?
Client-side touch prediction is disabled in the standard SDK. I had some
need for it, so I stuck it in. Since it's non-trivial, and something
that shouldn't have to be written twice, I'm posting it here for
opinions and corrections. It's mostly just copied from the equivalent
server code. This patch is from my version control system, so it might
not fit so cleanly into the patch utility. And those line numbers might
not be totally accurate, if I've edited those files before.
cl_dll/movehelper_client.cpp
===
--- cl_dll/movehelper_client.cpp
+++ cl_dll/movehelper_client.cpp
@@ -128,6 +128,38 @@
void CMoveHelperClient::ProcessImpacts( void )
{
+// Don't bother if the player ain't solid
+if ( g_pLocalPlayer->IsSolidFlagSet( FSOLID_NOT_SOLID ) )
+return;
+
+// Save off the velocity, cause we need to temporarily reset it
+Vector vel = g_pLocalPlayer->GetAbsVelocity();
+
+// Touch other objects that were intersected during the movement.
+for (int i = 0 ; i < m_TouchList.Size(); i++)
+{
+C_BaseEntity *pEnt = ClientEntityList().GetEnt(
m_TouchList[i].trace.m_pEnt->entindex() );
+if (!pEnt)
+continue;
+
+// Don't ever collide with self
+if ( pEnt == g_pLocalPlayer )
+continue;
+
+// Reconstruct trace results.
+m_TouchList[i].trace.m_pEnt = pEnt;
+
+// Use the velocity we had when we collided, so boxes will
move, etc.
+g_pLocalPlayer->SetAbsVelocity( m_TouchList[i].deltavelocity );
+
+pEnt->PhysicsImpact( g_pLocalPlayer, m_TouchList[i].trace );
+}
+
+// Restore the velocity
+g_pLocalPlayer->SetAbsVelocity( vel );
+
+// So no stuff is ever left over, sigh...
+ResetTouchList();
}
void CMoveHelperClient::StartSound( const Vector& origin, const char
*soundname )
cl_dll/prediction.cpp
===
--- cl_dll/prediction.cpp
+++ cl_dll/prediction.cpp
@@ -837,9 +837,7 @@
RunPostThink( player );
-// TODO: Predict impacts?
-//// Let server invoke any needed impact functions
-//moveHelper->ProcessImpacts();
+moveHelper->ProcessImpacts();
FinishCommand( player );
So far this code works for my purposes. Has anybody else done this, or
want to try this and provide some input? Maybe Valve has some pointers,
or a reason why they didn't do it in the first place?
Thanks.
--
Jorge "Vino" Rodriguez
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] IMO The only solution for bad physics interactions is to install a clientside physics simulation for serverside objects...this would require the player to know about all constraints to be able to simulate the physics objects predicted to be touched On 3/26/06, Jorge Rodriguez <[EMAIL PROTECTED]> wrote: > > Physical Mayhem Bug wrote: > > >Does this help with the awful jerky lag that happens when you walk into > or onto a table? > > > > > I haven't tried it against any dynamic objects, only static ones. I > think it's worth a try though, if you're up to it. > > -- > Jorge "Vino" Rodriguez > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Physical Mayhem Bug wrote: Does this help with the awful jerky lag that happens when you walk into or onto a table? I haven't tried it against any dynamic objects, only static ones. I think it's worth a try though, if you're up to it. -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Does this help with the awful jerky lag that happens when you walk into or onto
a table?
At 2006/03/23 11:14 AM, Jorge Rodriguez wrote:
>Client-side touch prediction is disabled in the standard SDK. I had some
>need for it, so I stuck it in. Since it's non-trivial, and something
>that shouldn't have to be written twice, I'm posting it here for
>opinions and corrections. It's mostly just copied from the equivalent
>server code. This patch is from my version control system, so it might
>not fit so cleanly into the patch utility. And those line numbers might
>not be totally accurate, if I've edited those files before.
>
>cl_dll/movehelper_client.cpp
>===
>--- cl_dll/movehelper_client.cpp
>+++ cl_dll/movehelper_client.cpp
>@@ -128,6 +128,38 @@
>
>void CMoveHelperClient::ProcessImpacts( void )
>{
>+// Don't bother if the player ain't solid
>+if ( g_pLocalPlayer->IsSolidFlagSet( FSOLID_NOT_SOLID ) )
>+return;
>+
>+// Save off the velocity, cause we need to temporarily reset it
>+Vector vel = g_pLocalPlayer->GetAbsVelocity();
>+
>+// Touch other objects that were intersected during the movement.
>+for (int i = 0 ; i < m_TouchList.Size(); i++)
>+{
>+C_BaseEntity *pEnt = ClientEntityList().GetEnt(
>m_TouchList[i].trace.m_pEnt->entindex() );
>+if (!pEnt)
>+continue;
>+
>+// Don't ever collide with self
>+if ( pEnt == g_pLocalPlayer )
>+continue;
>+
>+// Reconstruct trace results.
>+m_TouchList[i].trace.m_pEnt = pEnt;
>+
>+// Use the velocity we had when we collided, so boxes will
>move, etc.
>+g_pLocalPlayer->SetAbsVelocity( m_TouchList[i].deltavelocity );
>+
>+pEnt->PhysicsImpact( g_pLocalPlayer, m_TouchList[i].trace );
>+}
>+
>+// Restore the velocity
>+g_pLocalPlayer->SetAbsVelocity( vel );
>+
>+// So no stuff is ever left over, sigh...
>+ResetTouchList();
>}
>
>void CMoveHelperClient::StartSound( const Vector& origin, const char
>*soundname )
>
>cl_dll/prediction.cpp
>===
>--- cl_dll/prediction.cpp
>+++ cl_dll/prediction.cpp
>@@ -837,9 +837,7 @@
>
>RunPostThink( player );
>
>-// TODO: Predict impacts?
>-//// Let server invoke any needed impact functions
>-//moveHelper->ProcessImpacts();
>+moveHelper->ProcessImpacts();
>
>FinishCommand( player );
>
>So far this code works for my purposes. Has anybody else done this, or
>want to try this and provide some input? Maybe Valve has some pointers,
>or a reason why they didn't do it in the first place?
>
>Thanks.
>
>--
>Jorge "Vino" Rodriguez
>
>
>___
>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
Re: [hlcoders] Client-side touch prediction
-- [ Picked text/plain from multipart/alternative ] Allrighty. Thanks for this :D On 3/23/06, Jorge Rodriguez <[EMAIL PROTECTED]> wrote: > > Benjamin Davison wrote: > > >-- > >[ Picked text/plain from multipart/alternative ] > >Can I ask what benefits this would serve? > > > > > In my case, I'm doing some exotic movement code and I needed to predict > when the player touches something. I'm sure there's lots of other > applications that I can't think about right now. > > -- > Jorge "Vino" Rodriguez > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Can I ask what benefits this would serve? In my case, I'm doing some exotic movement code and I needed to predict when the player touches something. I'm sure there's lots of other applications that I can't think about right now. -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side touch prediction
--
[ Picked text/plain from multipart/alternative ]
Can I ask what benefits this would serve?
On 3/23/06, Jorge Rodriguez <[EMAIL PROTECTED]> wrote:
>
> Client-side touch prediction is disabled in the standard SDK. I had some
> need for it, so I stuck it in. Since it's non-trivial, and something
> that shouldn't have to be written twice, I'm posting it here for
> opinions and corrections. It's mostly just copied from the equivalent
> server code. This patch is from my version control system, so it might
> not fit so cleanly into the patch utility. And those line numbers might
> not be totally accurate, if I've edited those files before.
>
> cl_dll/movehelper_client.cpp
> ===
> --- cl_dll/movehelper_client.cpp
> +++ cl_dll/movehelper_client.cpp
> @@ -128,6 +128,38 @@
>
> void CMoveHelperClient::ProcessImpacts( void )
> {
> +// Don't bother if the player ain't solid
> +if ( g_pLocalPlayer->IsSolidFlagSet( FSOLID_NOT_SOLID ) )
> +return;
> +
> +// Save off the velocity, cause we need to temporarily reset it
> +Vector vel = g_pLocalPlayer->GetAbsVelocity();
> +
> +// Touch other objects that were intersected during the movement.
> +for (int i = 0 ; i < m_TouchList.Size(); i++)
> +{
> +C_BaseEntity *pEnt = ClientEntityList().GetEnt(
> m_TouchList[i].trace.m_pEnt->entindex() );
> +if (!pEnt)
> +continue;
> +
> +// Don't ever collide with self
> +if ( pEnt == g_pLocalPlayer )
> +continue;
> +
> +// Reconstruct trace results.
> +m_TouchList[i].trace.m_pEnt = pEnt;
> +
> +// Use the velocity we had when we collided, so boxes will
> move, etc.
> +g_pLocalPlayer->SetAbsVelocity( m_TouchList[i].deltavelocity );
> +
> +pEnt->PhysicsImpact( g_pLocalPlayer, m_TouchList[i].trace );
> +}
> +
> +// Restore the velocity
> +g_pLocalPlayer->SetAbsVelocity( vel );
> +
> +// So no stuff is ever left over, sigh...
> +ResetTouchList();
> }
>
> void CMoveHelperClient::StartSound( const Vector& origin, const char
> *soundname )
>
> cl_dll/prediction.cpp
> ===
> --- cl_dll/prediction.cpp
> +++ cl_dll/prediction.cpp
> @@ -837,9 +837,7 @@
>
> RunPostThink( player );
>
> -// TODO: Predict impacts?
> -//// Let server invoke any needed impact functions
> -//moveHelper->ProcessImpacts();
> +moveHelper->ProcessImpacts();
>
> FinishCommand( player );
>
> So far this code works for my purposes. Has anybody else done this, or
> want to try this and provide some input? Maybe Valve has some pointers,
> or a reason why they didn't do it in the first place?
>
> Thanks.
>
> --
> Jorge "Vino" Rodriguez
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Client-side touch prediction
Client-side touch prediction is disabled in the standard SDK. I had some
need for it, so I stuck it in. Since it's non-trivial, and something
that shouldn't have to be written twice, I'm posting it here for
opinions and corrections. It's mostly just copied from the equivalent
server code. This patch is from my version control system, so it might
not fit so cleanly into the patch utility. And those line numbers might
not be totally accurate, if I've edited those files before.
cl_dll/movehelper_client.cpp
===
--- cl_dll/movehelper_client.cpp
+++ cl_dll/movehelper_client.cpp
@@ -128,6 +128,38 @@
void CMoveHelperClient::ProcessImpacts( void )
{
+// Don't bother if the player ain't solid
+if ( g_pLocalPlayer->IsSolidFlagSet( FSOLID_NOT_SOLID ) )
+return;
+
+// Save off the velocity, cause we need to temporarily reset it
+Vector vel = g_pLocalPlayer->GetAbsVelocity();
+
+// Touch other objects that were intersected during the movement.
+for (int i = 0 ; i < m_TouchList.Size(); i++)
+{
+C_BaseEntity *pEnt = ClientEntityList().GetEnt(
m_TouchList[i].trace.m_pEnt->entindex() );
+if (!pEnt)
+continue;
+
+// Don't ever collide with self
+if ( pEnt == g_pLocalPlayer )
+continue;
+
+// Reconstruct trace results.
+m_TouchList[i].trace.m_pEnt = pEnt;
+
+// Use the velocity we had when we collided, so boxes will
move, etc.
+g_pLocalPlayer->SetAbsVelocity( m_TouchList[i].deltavelocity );
+
+pEnt->PhysicsImpact( g_pLocalPlayer, m_TouchList[i].trace );
+}
+
+// Restore the velocity
+g_pLocalPlayer->SetAbsVelocity( vel );
+
+// So no stuff is ever left over, sigh...
+ResetTouchList();
}
void CMoveHelperClient::StartSound( const Vector& origin, const char
*soundname )
cl_dll/prediction.cpp
===
--- cl_dll/prediction.cpp
+++ cl_dll/prediction.cpp
@@ -837,9 +837,7 @@
RunPostThink( player );
-// TODO: Predict impacts?
-//// Let server invoke any needed impact functions
-//moveHelper->ProcessImpacts();
+moveHelper->ProcessImpacts();
FinishCommand( player );
So far this code works for my purposes. Has anybody else done this, or
want to try this and provide some input? Maybe Valve has some pointers,
or a reason why they didn't do it in the first place?
Thanks.
--
Jorge "Vino" Rodriguez
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
