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
