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
