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> 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> > 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
