Re: [hlcoders] Interpolation of projectiles
I preferred to make the weapon the owner of the rocket, then call GetOwnerEntity()-GetOwnerEntity() when I wanted the player. ;-) A bool is a nice, broad solution though. Christopher Harris wrote: Also if the player is the owner to the rocket then it should never trace from any rocket traces against the owner. To get the owned entity to trace against its owner in our mod for some owned objects that we wanted to have the player trace against we had to add a baseentity bool that we checked when doing the trace logic that prevents this to ignore this check. Chris -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom Edwards Sent: Thursday, September 03, 2009 8:12 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Interpolation of projectiles AddSolidFlags( FSOLID_TRIGGER | FSOLID_NOT_SOLID ); Then perform whatever tests you want in Touch(). I have a short grace period after the rocket fires within which it doesn't explode on the player who fired it. Adam amckern McKern wrote: I got a rocket launcher based on the RPG class, if you spawn the rocket model within the p model it will explode in the p model - the best way to get around it is to mask the effect with a sprite, or something like spawing it behind the player - i found NO way to get a model based projectile to work any other way. Adam Owner Nigredo Studios http://www.nigredostudios.com --- On Wed, 2/9/09, Tom Edwards t_edwa...@btinternet.com wrote: From: Tom Edwards t_edwa...@btinternet.com Subject: Re: [hlcoders] Interpolation of projectiles To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Wednesday, 2 September, 2009, 9:42 PM It can't be exploited, it's just a rendering artefact on the client. I've been poking TF2 a little more and have spotted some oddities: * Rockets don't get a model, on the client, until a set period of time has passed. Before this only the glow effect is visible. I think the idea is to mask the spawn pause as the rocket flaring in the launcher before it starts forward. * Grenades and Huntsman arrows aren't interpolated. Instead they spawn behind the player at a distance determined by interp time with collisions disabled, so that they pass through the barrel at the correct moment. This avoids the spawn pause but looks bizarre with high lerp. That Valve could only hack around the problem doesn't fill me with confidence that there's a good solution to it. Nick wrote: 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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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 ___ To unsubscribe, edit your list
Re: [hlcoders] Interpolation of projectiles
AddSolidFlags( FSOLID_TRIGGER | FSOLID_NOT_SOLID ); Then perform whatever tests you want in Touch(). I have a short grace period after the rocket fires within which it doesn't explode on the player who fired it. Adam amckern McKern wrote: I got a rocket launcher based on the RPG class, if you spawn the rocket model within the p model it will explode in the p model - the best way to get around it is to mask the effect with a sprite, or something like spawing it behind the player - i found NO way to get a model based projectile to work any other way. Adam Owner Nigredo Studios http://www.nigredostudios.com --- On Wed, 2/9/09, Tom Edwards t_edwa...@btinternet.com wrote: From: Tom Edwards t_edwa...@btinternet.com Subject: Re: [hlcoders] Interpolation of projectiles To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Wednesday, 2 September, 2009, 9:42 PM It can't be exploited, it's just a rendering artefact on the client. I've been poking TF2 a little more and have spotted some oddities: * Rockets don't get a model, on the client, until a set period of time has passed. Before this only the glow effect is visible. I think the idea is to mask the spawn pause as the rocket flaring in the launcher before it starts forward. * Grenades and Huntsman arrows aren't interpolated. Instead they spawn behind the player at a distance determined by interp time with collisions disabled, so that they pass through the barrel at the correct moment. This avoids the spawn pause but looks bizarre with high lerp. That Valve could only hack around the problem doesn't fill me with confidence that there's a good solution to it. Nick wrote: 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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders __ Get more done like never before with Yahoo!7 Mail. Learn more: http://au.overview.mail.yahoo.com/ ___ 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] Interpolation of projectiles
Also if the player is the owner to the rocket then it should never trace from any rocket traces against the owner. To get the owned entity to trace against its owner in our mod for some owned objects that we wanted to have the player trace against we had to add a baseentity bool that we checked when doing the trace logic that prevents this to ignore this check. Chris -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom Edwards Sent: Thursday, September 03, 2009 8:12 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Interpolation of projectiles AddSolidFlags( FSOLID_TRIGGER | FSOLID_NOT_SOLID ); Then perform whatever tests you want in Touch(). I have a short grace period after the rocket fires within which it doesn't explode on the player who fired it. Adam amckern McKern wrote: I got a rocket launcher based on the RPG class, if you spawn the rocket model within the p model it will explode in the p model - the best way to get around it is to mask the effect with a sprite, or something like spawing it behind the player - i found NO way to get a model based projectile to work any other way. Adam Owner Nigredo Studios http://www.nigredostudios.com --- On Wed, 2/9/09, Tom Edwards t_edwa...@btinternet.com wrote: From: Tom Edwards t_edwa...@btinternet.com Subject: Re: [hlcoders] Interpolation of projectiles To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Wednesday, 2 September, 2009, 9:42 PM It can't be exploited, it's just a rendering artefact on the client. I've been poking TF2 a little more and have spotted some oddities: * Rockets don't get a model, on the client, until a set period of time has passed. Before this only the glow effect is visible. I think the idea is to mask the spawn pause as the rocket flaring in the launcher before it starts forward. * Grenades and Huntsman arrows aren't interpolated. Instead they spawn behind the player at a distance determined by interp time with collisions disabled, so that they pass through the barrel at the correct moment. This avoids the spawn pause but looks bizarre with high lerp. That Valve could only hack around the problem doesn't fill me with confidence that there's a good solution to it. Nick wrote: 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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders __ Get more done like never before with Yahoo!7 Mail. Learn more: http://au.overview.mail.yahoo.com
Re: [hlcoders] Interpolation of projectiles
It can't be exploited, it's just a rendering artefact on the client. I've been poking TF2 a little more and have spotted some oddities: * Rockets don't get a model, on the client, until a set period of time has passed. Before this only the glow effect is visible. I think the idea is to mask the spawn pause as the rocket flaring in the launcher before it starts forward. * Grenades and Huntsman arrows aren't interpolated. Instead they spawn behind the player at a distance determined by interp time with collisions disabled, so that they pass through the barrel at the correct moment. This avoids the spawn pause but looks bizarre with high lerp. That Valve could only hack around the problem doesn't fill me with confidence that there's a good solution to it. Nick wrote: 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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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 ___ 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
I got a rocket launcher based on the RPG class, if you spawn the rocket model within the p model it will explode in the p model - the best way to get around it is to mask the effect with a sprite, or something like spawing it behind the player - i found NO way to get a model based projectile to work any other way. Adam Owner Nigredo Studios http://www.nigredostudios.com --- On Wed, 2/9/09, Tom Edwards t_edwa...@btinternet.com wrote: From: Tom Edwards t_edwa...@btinternet.com Subject: Re: [hlcoders] Interpolation of projectiles To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Wednesday, 2 September, 2009, 9:42 PM It can't be exploited, it's just a rendering artefact on the client. I've been poking TF2 a little more and have spotted some oddities: * Rockets don't get a model, on the client, until a set period of time has passed. Before this only the glow effect is visible. I think the idea is to mask the spawn pause as the rocket flaring in the launcher before it starts forward. * Grenades and Huntsman arrows aren't interpolated. Instead they spawn behind the player at a distance determined by interp time with collisions disabled, so that they pass through the barrel at the correct moment. This avoids the spawn pause but looks bizarre with high lerp. That Valve could only hack around the problem doesn't fill me with confidence that there's a good solution to it. Nick wrote: 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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders __ Get more done like never before with Yahoo!7 Mail. Learn more: http://au.overview.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] Interpolation of projectiles
One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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
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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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] Interpolation of projectiles
decreasing host_timescale makes spotting the difference easier. Thanks! 2009/9/1 Nick xnicho...@gmail.com 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 Grayja...@interwavestudios.com wrote: One possibility is to override ShouldDraw() and enforce the appropriate conditions. On Aug 30, 2009, at 9:05 AM, Tom Edwards t_edwa...@btinternet.com 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
