I'm not delaying any events though (I've got none that need delaying right now)
This is just regular weapons fire. It works fine for a while, and then all of a sudden the events just stop playing. I thought it was postthink not happening because of something else; but its not, its physically events created in the client dll in shared weapon code; with FEV_NOTHOST, where the server doesn't send the event to the player who fired it; because the client is supposed to execute the event itself when it runs the predicted code. That's where it randomly stops functioning. It will execute all the weapon code get right to the bottom of the fire function, but the event just wont play. -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 Jason Gripp Sent: August 7, 2003 4:10 PM To: [EMAIL PROTECTED] 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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
