Do you find your predection is broken when you record a local server demo? I know that one of the 'patches' on the VDC breaks the anaimtion, and predection stuff.
-------- Owner Nigredo Studios http://www.nigredostudios.com --- On Tue, 25/1/11, Andrew Ritchie <gotta...@gmail.com> wrote: From: Andrew Ritchie <gotta...@gmail.com> Subject: Re: [hlcoders] Linux build prediction? issues To: "Discussion of Half-Life Programming" <hlcoders@list.valvesoftware.com> Received: Tuesday, 25 January, 2011, 11:56 AM 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 -----Inline Attachment Follows----- _______________________________________________ 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
