> > When the player creates AttackAction, it fills in details about the player's > input state, things like how long he's been holding the attack button, when > he's released the attack button, etc. The AttackAction is created using the > CreatePredictedEntityByName method. Only the client deals with button presses. Are you hooking into the right code on the server?
Over and above that, are you sure you /want/ to predict this? Prediction can be passed off on hitscan weapons but its paradoxes are far more apparent with projectiles (and to some extent with melee). Players expect to be able to see them incoming, but if a lagged player fires a predicted rocket it may very well spawn on the server a few inches from the target's face. Not a fair fight! On 14/02/2010 5:22, Michael Chang wrote: > Hopefully this message gets to Yahn but if anyone else knows anything please > help as well. > > I'm referring specifically to this issue, in this very post circa 2004 > > http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg09429.html > > Here's an excerpt > > > Predicting entity creation is something we use for TF2, > > but the HL2/HL2DM/CS:S code doesn't use it yet. Since that specific > > functionality is unshipped, you may run into some issues. You'll want > > to look at predictable_entity.h and predictableid as well. > > ... > > There isn't a good example in the current SDK for this. :( > > > >> The usage pattern would be to create the prediction of a rocket or >> > grenade (so that if you are lagged it doesn't just pop into existence at > > some later time like you are probably used to) and predict its > > simulation forward while waiting for the server to ack the true object. > > The real tricky part is that the predicted entity must be locked to the > > creating player's clock for simulation (see AddToPlayerSimulationList() > > in c_baseplayer.cpp.h). > > > >> If anyone starts to go down this road and runs into snags, feel free to >> > post questions and I'll try to respond. At some point I'd like to ship > > out a proper example which will make all of this stuff clear, or at > > least write up a document. > > > > We've run into this very snag, as well as lacking documentation or examples > to learn from. Can we please get an example? > > > *Here's the situation:* > > We have a system where when the player attacks, the player creates a > predicted entity. This entity drives the player's animation and the attack's > logic. Let's call this entity AttackAction. > > When the player creates AttackAction, it fills in details about the player's > input state, things like how long he's been holding the attack button, when > he's released the attack button, etc. The AttackAction is created using the > CreatePredictedEntityByName method. > > > *Here's the problem:* > > When the server gives back the "real" entity and replaces the predicted > entity, the client's copy of the entity has default values (same values as > if it's just been initialized). The shared code that ran on the server seems > not to reflect the changes the client had made. In fact, our network vars > are reset, no state information is retained (or so it appears), and using > IsFirstTimePredicted() to prevent doubling up of animations do not work. > > > *The result:* > > The AttackAction seems to think it's restarted itself upon reception of the > server's version. It restarts our player animation, causing it to repeat > itself. The animation subsequently look like it doubles on itself. > > What's the correct way of predicting entity creation? Can we get some sort > of documentation if any is available, or examples that we can follow to see > it working? > > > Thanks > > ~M > _______________________________________________ > 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
