You checked cl_predictionlist 1 to see that the weapon was being predicted?
The time is supposed to go back on the client. It stores all
predicted values over a period of time. When it goes back in time, it
restores the values to what they were at that time. If you have a
value that is important and needs to be restored when going back in
time, it needs to be put in the prediction table. I would check that
your variables have been put in the prediction table and setup
correctly. I can't be anymore specific because I don't understand
what you're doing in terms of animation. You need to do all
animations on the server otherwise the player hitboxes aren't going to
match up.
I also wouldn't expect fakelag of 300 to look right even when the code
is working perfectly fine. That's what a player with 600 ping plays
like.
On Tue, Dec 16, 2008 at 3:38 AM, Michael Chang flux.black...@gmail.com wrote:
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.30
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.30
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.30
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.30
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.30
