Did you think about recording with a digital camera of a stopwatch and your monitor? Would be much more scientific. is this with the latest unmodified valve hl2mp sdk + linux server?
shouldn't be that hard to setup,,, On Tue, Jan 25, 2011 at 5:32 AM, Adam "amckern" McKern <amck...@yahoo.com>wrote: > Why i asked is becuase this was recorded directly through camista - single > player, high end computer > > http://www.youtube.com/watch?v=Dh6Z9MqZ3JA&feature=player_profilepage > > Notice that the default shot gun is VERY lagged? > > > -------- > Owner Nigredo Studios http://www.nigredostudios.com > > --- On *Tue, 25/1/11, Jed <j...@wunderboy.org>* wrote: > > > From: Jed <j...@wunderboy.org> > > Subject: Re: [hlcoders] Linux build prediction? issues > To: "Discussion of Half-Life Programming" <hlcoders@list.valvesoftware.com > > > Received: Tuesday, 25 January, 2011, 8:06 PM > > > Hmm... > > If find your comments on the MuzzleFlash prediction interesting > because it's been something I've had issues with continually. I admit, > I'm still using the Source SDK 2006, but I've always had an issue with > muzzleflashes and case ejection events repeating (up to half a second > after the original shot) but the actual shot only coming once. > > I might have to dig deeper. > > - Jed > > On 24 January 2011 22:06, Maarten De Meyer > <maar...@off-limits.be<http://mc/compose?to=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<http://mc/compose?to=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
