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
