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
