No, because I can sit there and unload an entire clip. It won't fire the attack event on the client AT ALL. But it is going past it with debug printing.
Then when ammo is empty, I hit reload; and reload plays fine; which is called the exact same way was weapon fire; except it has the reliable flag on it. Client side *EXECUTED* events seem to just stop functioning randomly. If they're fired from the server, they always happen. I got tired of debugging so I took a break for the day and finished sp hl. I started playing the other day and finished it today. Now I want hl2, because I forgot about all of the cool mapping things you guys did in hl, and can only imagine how much cooler they will be in hl2. heh OFFTOPIC I KNOW. :F -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 Alfred Reynolds Sent: August 7, 2003 2:25 PM To: '[EMAIL PROTECTED]' 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
