Bit of an old thread, but unfortunately I'm going to have to come back
to it: I'm afraid I was mistaken too. IsFirstTimePredicted did fix some
issues graphically, but some things are still seerriously fubar on our
linux (dedicated server) build related to how client-side prediction
behaves. I'm out of ideas here, and we planned to go public this friday.
I'm guessing there's no direct contact person at valve for issues like this?
On 25/01/2011 1:56, Andrew Ritchie wrote:
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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
