Alfred Reynolds took care of the prediction if I recall correctly. - ScarT
On 21 March 2011 23:25, Maarten De Meyer <maar...@off-limits.be> wrote: > 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> 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> >> 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 >> >> > > _______________________________________________ > 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
