It's bug related to playing delayed events on the client. Running a delayed event will delay ALL events that are called after the delay event until delayed is actually played. I came across this bug a while ago. To fix it I created my own queue for the events I needed to delay, which fixes the problem. You're not imagining it.
Ikkyo ----- Original Message ----- From: "Alfred Reynolds" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 07, 2003 12:42 PM Subject: RE: [hlcoders] weapon prediction bug > per entity per frame, i.e per unique player entity per rendered screen. So > if in a single frame 2 events were sent to the client then only one of them > (the last I believe) would get through. > > zmeko wrote: > > What do you mean by entity frame? > > Alfred Reynolds wrote: > > > >> The deep recesses of my memory seem to think that you can only have > >> 1 event per entity per frame. Perhaps the reload event is stomping > >> over the top of another event? > >> > >> - Alfred > >> > >> Tony "omega" Sergi wrote: > >> > >> > >>> I don't even use those cl_lw checks at all, so its always just on. > >>> > >>> But, after all kinds of massive debugging I've determined now that > >>> its actually the events not firing on the client; that is, any event > >>> that's not reliable (all weapon fire; since I don't want them to go > >>> when out of pvs..) will randomly stop firing LOCALLY. I'm still > >>> messing with it to see if I can find a solution, like perhaps to > >>> force reliable on local calls, but not remote :/ > >>> > >>> Further with that; my reload event which I set to reliable the other > >>> day; when my fire events stop triggering on the client, the reload > >>> still does. I haven't confirmed whether reliable actually has > >>> anything to do with it yet, since its hard for me to duplicate this > >>> bug when tis well, random. > >>> > >>> > >>> -omega > >>> Blackened Interactive - http://www.blackened-interactive.com > >>> Omega Wing - http://owing.blackened-interactive.com > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On Behalf Of Pat > >>> Magnan Sent: August 7, 2003 11:21 AM To: > >>> [EMAIL PROTECTED] > >>> > >>> Hmm, ok guess that shouldn't be too random then :). > >>> > >>> I did find it strange that changing this code: > >>> if ( cl_lw && cl_lw->value ) > >>> { > >>> HUD_WeaponsPostThink( from, to, cmd, time, random_seed ); } > >>> > >>> so there's no check for cl_lw (i.e. the conditional was changed to > >>> if ( 1 )), seemed to have no effect - that is, HUD_WeaponsPostThink > >>> was never called if someone types cl_lw 0, since I draw something > >>> on the screen from that function continuously -- well based on a > >>> value only ever set there, and it stops working as soon as someone > >>> types cl_lw 0 in the console I can see that it was not being called. > >>> > >>> I guess that means the only way to disable a client's ability to > >>> turn prediction off is to set it to 1 right before the check? > >>> > >>> I guess I'd have to say other than this cl_lw stuff, I have no > >>> issues with the prediction not working or HUD_WeaponsPostThink not > >>> being called because we draw based on that value and I've never > >>> heard of it randomly not working... > >>> > >>> Oh for your problem omega, setting cl_lw to zero guarantees that > >>> HUD_WeaponsPostThink is NOT ever called... so it shouldn't fix it > >>> not being called.. at least that's what that code above says to me > >>> :p, maybe some other check for it, the only 'default' other check is > >>> this, and one in the gauss code I think...: > >>> > >>> int CHud::MsgFunc_SetFOV(const char *pszName, int iSize, void > >>> *pbuf) { .. snip ... if ( cl_lw && cl_lw->value ) > >>> return 1; > >>> > >>> So, if you rely on FOV at all, then you'd need a zero in cl_lw for > >>> your weapons to work correctly perhaps? Comment that check out, and > >>> see if the predicted weapons work correctly now?. No idea on the > >>> randomness of it.. > >>> > >>> At 10:40 AM 8/6/2003 -0700, you wrote: > >>> > >>> > >>>> <snip> > >>>> > >>>> > >>>>> You seem to have the opposite problem where the prediction is > >>>>> mucked. I noticed also that checking cl_lw, the value seems to > >>>>> intermittently change (tried to print to console based on it's > >>>>> value, and it seems to decide to reset itself at random). > >>>>> > >>>>> > >>>>> > >>>> There is only one place in the engine where cl_lw is reset > >>>> > >>>> > >>> to 0, here is > >>> the > >>> > >>> > >>>> code for it: > >>>> > >>>> if (cl_funcs.pPostRunCmd ) > >>>> { > >>>> cl_funcs.pPostRunCmd( from, to, cmd, runfuncs, > >>>> time, random_seed ); } else > >>>> { > >>>> extern cvar_t cl_lw; > >>>> if ( cl_lw.value != 0 ) > >>>> { > >>>> Cvar_SetValue( "cl_lw", 0.0 ); } } > >>>> > >>>> obviously this should never be called as long as your client > >>>> > >>>> > >>> dll exports > >>> the > >>> > >>> > >>>> HUD_PostRunCmd function. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> It seems like somewhere this value is getting munged, as well > >>>>> checks for it don't work correctly at all. I lean to the idea > >>>>> there is a bug in the engine and the value is getting stomped. > >>>>> > >>>>> Hmm, wait, HUD_WeaponsPostThink is called when cl_lw is true is > >>>>> that not correct? > >>>>> > >>>>> At 11:15 AM 8/6/2003 -0400, you wrote: > >>>>> > >>>>> > >>>>>> This is something that has been going on for a long time, and I > >>>>>> had thought I'd fixed it, but now it seems like its really an > >>>>>> engine bug. Here's the lowdown: > >>>>>> > >>>>>> For a long time, people have been complaining about "weapon > >>>>>> jamming" (as they call it) long before I started working on FLF; > >>>>>> So I began re-writing the weapon code completely. Locally it > >>>>>> seems to work perfectly now, but over the internet it randomly > >>>>>> stops predicting. And that's the keyword, I can't re-produce it, > >>>>>> it just at random times "jams" (or more specifically, > >>>>>> HUD_WeaponsPostThink is not called at ALL anymore.) cl_lw 0 > >>>>>> seems to fix it, which if my understanding is correct, tells the > >>>>>> engine to not call HUD_WeaponsPostThink and then the server will > >>>>>> not skip the event playback from FEV_NOTHOST. Correct? > >>>>>> > >>>>>> The problem is; now all weapon prediction features are lost, just > >>>>>> to make the weapons not "jam". This is a pain in the ass, and the > >>>>>> fact that I can't reproduce it to even debug and see if it is > >>>>>> something messed up in the weapons code, or if it's in the engine > >>>>>> for sure it leaves me in a pickle jar with no fork to pull > >>>>>> myself out. > >>>>>> > >>>>>> I was wondering mostly if anyone else has experienced this, and > >>>>>> if they can confirm or deny if it really is an engine problem, or > >>>>>> something that can be fixed in weapons code :/ > >>>>>> > >>>>>> I'm getting ready to rip my hair out again (and to think. It just > >>>>>> grew back from last time I was fixing weapons!) > >>>>>> > >>>>>> -omega > >>>>>> Blackened Interactive - http://www.blackened-interactive.com > >>>>>> Omega Wing - http://owing.blackened-interactive.com > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > _______________________________________________ > 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
