Re: [hlcoders] Interpolation of projectiles
"decreasing host_timescale makes spotting the difference easier." Thanks! 2009/9/1 Nick > Can you offer video/pictures to demonstrate how this bug effects all > valve games? > > Or any way for a player to replicate or exploit it? Thus you make it > both easier and more likely valve will look into this problem and fix > it. > > On Tue, Sep 1, 2009 at 2:02 AM, James Gray > wrote: > > One possibility is to override ShouldDraw() and enforce the > > appropriate conditions. > > > > > > > > On Aug 30, 2009, at 9:05 AM, Tom Edwards > > wrote: > > > >> I want to bring up the issue of projectiles hanging in the air for a > >> moment after spawning again. The last time it was discussed the > >> solution > >> given was to predict: > >> > >> > http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg21121.html > >> > >> This is a bad idea though, because it causes the projectile to > >> materialise several feet in front of the firer on observers' computers > >> (contrary to what Tony said at the time, TF2 does NOT predict > >> rockets/grenades). > >> > >> The problem is that the projectile is spawned as soon as the client > >> receives it, irrespective of interpolation, and then (correctly) does > >> not start to move until interp catches up. You can change the length > >> of > >> the delay by increasing the interp period; decreasing host_timescale > >> makes spotting the difference easier. > >> > >> I've run tests and discovered that /all/ of Valve's games are affected > >> by this issue, including TF2. I've not compiled the SDK template game > >> but I expect it also suffers. > >> > >> The solution is clear: prevent the projectile's clientside > >> representation from spawning until the interpolated world is ready. > >> Anyone know how to do that? > >> > >> > >> ___ > >> 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 > > -- Sent from Olly's SEGA Game Gear ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Interpolation of projectiles
Can you offer video/pictures to demonstrate how this bug effects all valve games? Or any way for a player to replicate or exploit it? Thus you make it both easier and more likely valve will look into this problem and fix it. On Tue, Sep 1, 2009 at 2:02 AM, James Gray wrote: > One possibility is to override ShouldDraw() and enforce the > appropriate conditions. > > > > On Aug 30, 2009, at 9:05 AM, Tom Edwards > wrote: > >> I want to bring up the issue of projectiles hanging in the air for a >> moment after spawning again. The last time it was discussed the >> solution >> given was to predict: >> >> http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg21121.html >> >> This is a bad idea though, because it causes the projectile to >> materialise several feet in front of the firer on observers' computers >> (contrary to what Tony said at the time, TF2 does NOT predict >> rockets/grenades). >> >> The problem is that the projectile is spawned as soon as the client >> receives it, irrespective of interpolation, and then (correctly) does >> not start to move until interp catches up. You can change the length >> of >> the delay by increasing the interp period; decreasing host_timescale >> makes spotting the difference easier. >> >> I've run tests and discovered that /all/ of Valve's games are affected >> by this issue, including TF2. I've not compiled the SDK template game >> but I expect it also suffers. >> >> The solution is clear: prevent the projectile's clientside >> representation from spawning until the interpolated world is ready. >> Anyone know how to do that? >> >> >> ___ >> 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] COLLISION PROBLEM
Thanks Jay AddSolidFlags( FSOLID_NOT_SOLID | FSOLID_TRIGGER ); Dit the trick > From: j...@valvesoftware.com > To: hlcoders@list.valvesoftware.com > Date: Tue, 1 Sep 2009 10:11:54 -0700 > Subject: Re: [hlcoders] COLLISION PROBLEM > > > SetSolidFlags( FSOLID_TRIGGER ); > > Is what sets the behavior you are after (allowing entities to pass through > but still registering collisions). > > It looks like you are misunderstanding the other functions you are calling: > If you SetSolid( SOLID_NONE ); then you are saying the object has no solid > representation so nothing collides with it. > If you SetSolid( SOLID_VPHYSICS ); then you are saying the object should use > a vphysics representation for collisions (union of convex hulls), then > SetCollisionGroup( COLLISION_GROUP_PLAYER ); you are limiting what collides > with it (CGameRules::ShouldCollide determines which pairs of collision groups > collide with each other). But it is still solid to anything that collides > with it. > > Jay > > > -Original Message- > > From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders- > > boun...@list.valvesoftware.com] On Behalf Of steven belmans > > Sent: Tuesday, September 01, 2009 9:51 AM > > To: hlcoders@list.valvesoftware.com > > Subject: [hlcoders] COLLISION PROBLEM > > > > > > Hi all > > > > > > > > I got a small problem. > > > > > > > > We are building a model ent thad the player can pass thru and triggers > > a function void hallo::byby (void) > > > > > > > > If I use > > > > > > > > SetSolid( SOLID_NONE); > > > > SetCollisionGroup( COLLISION_GROUP_PLAYER ); > > > > > > > > I can pass thru the model but then my SetTouch(hallo::byby); does not > > register anything. > > > > > > > > Else if I use > > > > SetSolid( SOLID_VPHYSICS); > > > > SetCollisionGroup( COLLISION_GROUP_PLAYER ); > > > > > > > > I cant pass thru! > > > > > > > > plz help > > > > > > > > I Know you dont like it when people use Hotmail > > > > Sorry > > > > > > > > _ > > Je hele online leven op één stek met Windows Live > > http://www.microsoft.com/belux/nl/windows/windowslive/default.aspx > > ___ > > 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 > _ Hebben jij en je vrienden leuke foto's van jullie feestje? Maak een groepsalbum en geniet nog extra na. http://www.microsoft.com/belux/nl/windows/windowslive/products/photos.aspx ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] COLLISION PROBLEM
SetSolidFlags( FSOLID_TRIGGER ); Is what sets the behavior you are after (allowing entities to pass through but still registering collisions). It looks like you are misunderstanding the other functions you are calling: If you SetSolid( SOLID_NONE ); then you are saying the object has no solid representation so nothing collides with it. If you SetSolid( SOLID_VPHYSICS ); then you are saying the object should use a vphysics representation for collisions (union of convex hulls), then SetCollisionGroup( COLLISION_GROUP_PLAYER ); you are limiting what collides with it (CGameRules::ShouldCollide determines which pairs of collision groups collide with each other). But it is still solid to anything that collides with it. Jay > -Original Message- > From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders- > boun...@list.valvesoftware.com] On Behalf Of steven belmans > Sent: Tuesday, September 01, 2009 9:51 AM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] COLLISION PROBLEM > > > Hi all > > > > I got a small problem. > > > > We are building a model ent thad the player can pass thru and triggers > a function void hallo::byby (void) > > > > If I use > > > > SetSolid( SOLID_NONE); > > SetCollisionGroup( COLLISION_GROUP_PLAYER ); > > > > I can pass thru the model but then my SetTouch(hallo::byby); does not > register anything. > > > > Else if I use > > SetSolid( SOLID_VPHYSICS); > > SetCollisionGroup( COLLISION_GROUP_PLAYER ); > > > > I cant pass thru! > > > > plz help > > > > I Know you dont like it when people use Hotmail > > Sorry > > > > _ > Je hele online leven op één stek met Windows Live > http://www.microsoft.com/belux/nl/windows/windowslive/default.aspx > ___ > 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
[hlcoders] COLLISION PROBLEM
Hi all I got a small problem. We are building a model ent thad the player can pass thru and triggers a function void hallo::byby (void) If I use SetSolid( SOLID_NONE); SetCollisionGroup( COLLISION_GROUP_PLAYER ); I can pass thru the model but then my SetTouch(hallo::byby); does not register anything. Else if I use SetSolid( SOLID_VPHYSICS); SetCollisionGroup( COLLISION_GROUP_PLAYER ); I cant pass thru! plz help I Know you dont like it when people use Hotmail Sorry _ Je hele online leven op één stek met Windows Live http://www.microsoft.com/belux/nl/windows/windowslive/default.aspx ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Interpolation of projectiles
One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards wrote: > I want to bring up the issue of projectiles hanging in the air for a > moment after spawning again. The last time it was discussed the > solution > given was to predict: > > http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg21121.html > > This is a bad idea though, because it causes the projectile to > materialise several feet in front of the firer on observers' computers > (contrary to what Tony said at the time, TF2 does NOT predict > rockets/grenades). > > The problem is that the projectile is spawned as soon as the client > receives it, irrespective of interpolation, and then (correctly) does > not start to move until interp catches up. You can change the length > of > the delay by increasing the interp period; decreasing host_timescale > makes spotting the difference easier. > > I've run tests and discovered that /all/ of Valve's games are affected > by this issue, including TF2. I've not compiled the SDK template game > but I expect it also suffers. > > The solution is clear: prevent the projectile's clientside > representation from spawning until the interpolated world is ready. > Anyone know how to do that? > > > ___ > 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
