Originally I had thought it would have been fixed with the
IsFirstTimePredicted check as well, but even with that, I found
our frames were being rolled back and for whatever reason the
system wasn't marking the already predicted frames as handled, or
at least resetting it. We wrapped a test case in the base MP5
provided with the SDK and could recreate the prediction issues
consistently, so might have run that by the latest SDK and see if
it still happens.
On Mon, Jan 24, 2011 at 11:11 PM, Nick <xnicho...@gmail.com
<mailto:xnicho...@gmail.com>> wrote:
If it is a problem with the valve sdk, then don't even try to
fix it,
track the problem down, send valve a detailed report, and
hope for the
best.
On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer
<maar...@off-limits.be <mailto:maar...@off-limits.be>> wrote:
> I did some checking, and you are right. My issue is
unrelated to the linux
> build, it just didn't show on windows or listenserver cause
the connection
> was way better. It is a generic prediction issue (
net_fakelag 50 causes it
> to show up on listenserver, cl_prediction 0 and it's gone )
>
> I've also searched this list's archive, I think there is
several threads on
> similar problems already. A suggestion by Yahn a short
valve-time ago I
> think is relevant here. Basically, depending on network
conditions, it is
> normal that a frame gets predicted several times, causing
the same events to
> be re-fired clientside. If I grasped it correctly, putting
this construction
>
> #if defined( CLIENT_DLL )
> if ( prediction->InPrediction() &&
!prediction->IsFirstTimePredicted() )
> return;
> #endif
>
> before anything that shouldn't happen twice ( muzzle flashes,
> SendWeaponAnim, ... )
>
> is a way to deal with this problem: the multiple
predictions will still
> happen as should be the case, but the impact on what the
client sees is
> minimised.
>
> I guess that leaves me with the question: is this really
what I'm hitting,
> and more importantly, is the above m.o. the way to go? Do I
need to
> meticulously filter out things I want to be re-predicted
and things I don't
> everywhere and if() with the above statement? Anyone else
went through this?
> I'm no prediction expert, would like to hear from those
that are :)
>
> -- Maarten
>
>
> On 24/01/2011 1:25, Andrew Ritchie wrote:
>
> I had similar experiences with our port to orange box. I
had originally
> thought that it might be my own fault for handling a lot of
our free look
> and weapon aiming client side but we even tracked the same
issues in the
> base SDK on listen servers under fake ping. I can't say
it's identical
> since you mentioned only getting it under linux, we could
recreate it on
> listen servers as well, but the symptoms are the same. I
tracked that
> prediction was rerunning the frames without ever indicating
that it was
> actually a rerun frame, the frame counter would just drop X
into he past and
> run from there. This was the biggest give away that either
I'd botched up or
> something was a lower level had an issue that needed a fix
beyond a check to
> make sure you don't repeat beyond the first prediction
frame. I was never
> able to figure out a real solution to the issue beyond
client side absolute
> platform time checks, which didn't solve anything more than
superficially.
>
> I'd be interested in hearing if you find anything or anyone
else has this
> and found a solution, as it essentially brought everything
to a grinding
> halt over a year ago, since online play become unmanageable
for a lot of
> players.
>
> On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer
<maar...@off-limits.be <mailto:maar...@off-limits.be>>
> wrote:
>>
>> Hi list,
>>
>> I've recently built our OB mod's linux server after a
loong time working
>> windows only. I got it to compile & run fine, but there's
a serious general
>> issue with the way the game acts when playing on the linux
server. It runs
>> OK, but some things are clearly off, like sprint
behavior/animations, shoot
>> animations etc. E.g., one particular, reproducible issue
is that if you
>> click to shoot, the shot goes well, but if you hold your
mouse down for a
>> while and release it, a second shoot anim/muzzle flash
happens, ammo gets
>> decremented, but immediately after that reincremented and
that second shot
>> does not register on the server. I think that means that
client side is
>> predicting a lot more than it should. I also get some
prediction errors wtih
>> cl_showerrors 1. I don't get any of this behavior with the
same client, but
>> on the windows server [Which I find a bit odd, since
prediction is
>> client-side only, no?].
>>
>> Anyone has any clue in what direction to look or has had
similar
>> experiences?
>>
>> Thanks in advance,
>>
>> Maarten
>>
>> _______________________________________________
>> 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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
