Hi all This has been brought up before and I don't think the details of "fixing it" has ever been fully disclosed. I think I'm running exactly into this problem as described by Tony Sergi from 2007
http://www.opensubscriber.com/message/hlcoders@list.valvesoftware.com/6392737.html > Hey guys, I'm having a bit of a prediction issue with weapon code. > > Basically what's happening is, when you're lagged out (real, or > net_fakelag) > the client seems to be calling ItemPostFrame multiple times a frame, > instead > of just once. > This is causing my weapons to fire a random amount of times more, on the > client, than they should. > > Has anyone else encountered this? gpGlobals->curtime as per usual is being > tested, and when I DevMsg the fire sequence, the multiple fire times are > indeed using the exact same time. > > I would like to fix this, as quickly as possible without a gross hack. > > Thanks > > -- > -omega > -- . Yahn's answer was a big clue, to test if it's the first time you're predicting this thing on client, and if so.. do whatever you're supposed to do.. otherwise ignore the method. This is the way prediction works, the client "resimulates" all of the > CUserCmds since the last ack'd one. For debugging this stuff, it's best > to turn cl_pred_optimize to 0 and you'll always do the full reprediction > every frame. > > When you trigger client side only effects in weapons, you should only do > them the first time a CUserCmd is predicted. You should use something > like this: > > #if defined( CLIENT_DLL ) > // during prediction play footstep sounds only once > if ( prediction->InPrediction() && > !prediction->IsFirstTimePredicted() ) > return; > #endif > > To deal with such cases. > > Yahn > Ofcourse this applies to client-side-only stuff that should play once, like client-side-only animation. This applies to us because we've decided to make all player-animations client-side-only for local players. Without further-ado, here's my problem, demonstrated in video-form. http://www.ghost-hack.com/berimbau/prediction_problem.avi In the video, the first two times I swing I had 0 lag (listen server). Next third and fourth time I swing, I turned on net_fakelag 300. You see the problem.... We have a weapon controlling the player animation. The weapon fires 3 times, resets itself (wait time), and then fires 3 times again, etc while holding IN_ATTACK. The following print-out reveals the bizarre problem. (Swingcount controls the player animation as well as the m_flNextPrimaryAttack.) Client predicts the attack message: client is attacking at 99.284996 client has enough stamina true with swingcount: 0 client incrementing swingcount to... 1 client stance: 0, direction: 0, swingcount: 1 client time: 99.284996, firerate: 0.300000 Server gets it, and things are good server is attacking at 99.284996 server has enough stamina true with swingcount: 0 server incrementing swingcount to... 1 server stance: 0, direction: 0, swingcount: 1 server time: 99.284996, firerate: 0.300000 client is attacking at 99.584999 Did client get the message yet? Swingcount is still 1! client has enough stamina true with swingcount: 0 client incrementing swingcount to... 1 client stance: 0, direction: 0, swingcount: 1 client time: 99.584999, firerate: 0.300000 Already something here goes terribly wrong. Even though swingcount updates (networked) with the msg "client incrementing swingcount to ...", the client weapon re-simulates itself using ItemPostFrame 0.3 seconds later. server is attacking at 99.584999 server has enough stamina true with swingcount: 1 server incrementing swingcount to... 2 server stance: 0, direction: 0, swingcount: 2 server time: 99.584999, firerate: 0.300000 We get a notification here from the server. So far the client is one swing count behind, which gets corrected in the following: client is attacking at 99.584999 client has enough stamina true with swingcount: 1 client incrementing swingcount to... 2 client stance: 0, direction: 0, swingcount: 2 client time: 99.584999, firerate: 0.300000 Client goes on to predict the next attack 0.3 seconds later client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 Okay WTF!!!! Client GOES BACK IN TIME HERE ---- and resimulates at swingcount 1. And for the next few steps, it immediately increments swingcount multiple times. client is attacking at 99.584999 client has enough stamina true with swingcount: 1 client incrementing swingcount to... 2 client stance: 0, direction: 0, swingcount: 2 client time: 99.584999, firerate: 0.300000 client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 client is attacking at 99.974998 client has enough stamina true with swingcount: 0 client incrementing swingcount to... 1 client stance: 0, direction: 0, swingcount: 1 client time: 99.974998, firerate: 0.300000 client is attacking at 99.584999 client has enough stamina true with swingcount: 1 client incrementing swingcount to... 2 client stance: 0, direction: 0, swingcount: 2 client time: 99.584999, firerate: 0.300000 client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 client is attacking at 99.584999 client has enough stamina true with swingcount: 1 client incrementing swingcount to... 2 client stance: 0, direction: 0, swingcount: 2 client time: 99.584999, firerate: 0.300000 client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 client is attacking at 100.095001 client has enough stamina true with swingcount: 0 client incrementing swingcount to... 1 client stance: 0, direction: 0, swingcount: 1 client time: 100.095001, firerate: 0.300000 client is attacking at 100.154999 client has enough stamina true with swingcount: 1 client incrementing swingcount to... 2 client stance: 0, direction: 0, swingcount: 2 client time: 100.154999, firerate: 0.300000 Finally 300ms later the server puts a stop to this madness, but meanwhile the clientside animation is already totally fucked; excuse my french. server is attacking at 99.900002 server has enough stamina true with swingcount: 2 server incrementing swingcount to... 3 server stance: 0, direction: 0, swingcount: 3 server time: 99.900002, firerate: 0.800000 client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 client is attacking at 100.259995 client has enough stamina true with swingcount: 0 client incrementing swingcount to... 1 client stance: 0, direction: 0, swingcount: 1 client time: 100.259995, firerate: 0.300000 client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 client is attacking at 99.900002 client has enough stamina true with swingcount: 2 client incrementing swingcount to... 3 client stance: 0, direction: 0, swingcount: 3 client time: 99.900002, firerate: 0.800000 client is attacking at 100.379997 client has enough stamina true with swingcount: 0 client incrementing swingcount to... 1 client stance: 0, direction: 0, swingcount: 1 client time: 100.379997, firerate: 0.300000 client is attacking at 100.424995 client has enough stamina true with swingcount: 1 client incrementing swingcount to... 2 client stance: 0, direction: 0, swingcount: 2 client time: 100.424995, firerate: 0.300000 Etc. Please help. What do I do here? It seems like swingcount is falling out of prediction for no good reason, even though client and server are running the exact same code. The weapon IS predicted via ShouldPredict/IsPredicted. I've done this to test, but it doesn't fix anything: Immediately in ItemPostFrame() #ifdef CLIENT_DLL if( prediction->InPrediction() && !prediction->IsFirstTimePredicted() ){ return; } #endif In theory it should only run stuff in ItemPostFrame the first time. Instead, it's running it multipe times, completely destroying player-animation. I've also done the above checks around CheckButton() and SetAnimation for player, etc. Nothing seems to work. ~M _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
