I'm glad you brought this topic back up, and I've found the definite
fix. The original problem was that weapons would shoot too fast, but
I've been encountering a problem where weapon animations are just plain
glitchy when not at a sub 50 ping. Both of these problems are only
evident in the base SDK and not the HL2 DM SDK. Your moving the
m_flNextPrimaryAttack variable into the player is an interesting hint at
the real source of the problem, but the problem is not due to anything
about how networked data is updated or received. The problem is that no
weapons are being predicted!
If you put "cl_predictionlist" in the console, it will print a list of
all entities in the world that are being predicted. If you run in HL2
DM, the list is something along the lines of player, view model, and
player weapons. However, if you look at the list in a base SDK mod,
only the player and view model are listed. That's because your weapons
aren't being predicted. The reason they're not predicted is because
CWeaponSDKBase does not override C_BaseEntity's ShouldPredict() function
to tell the game to predict the weapons. In the HL2 DM sdk, the weapons
are derived from CWeaponHL2MPBase which overrides ShouldPredict() and
returning true if the local player is the one holding the weapon.
How to fix this bug:
In weapon_sdkbase.h, add:
#ifdef CLIENT_DLL
virtual bool ShouldPredict();
#endif
In weapon_sdkbase.cpp, add:
#ifdef CLIENT_DLL
bool CWeaponSDKBase::ShouldPredict()
{
if ( GetOwner() && GetOwner() == C_BasePlayer::GetLocalPlayer())
return true;
return BaseClass::ShouldPredict();
}
#endif
Tony "omega" Sergi wrote:
--
[ Picked text/plain from multipart/alternative ]
I was thinking about it and talking in irc briefly with Joel about it, and I
think it may simply have to do with the order of networking, and the way the
prediction works.
Whereas, (Someone at valve, correct me if i'm wrong, but it appears this is
what's happening)
Player networking is processed, player is simulated on the client for
prediction, which calls into the weapons; m_flNextPrimaryFire is still in
the past for every single one of these prediction calls, so the weapon keeps
firing.
weapon entities now update and receive networked data, and have the correct
time. oops, too late, player handles the firing!
so effectively, putting it in the player, allows the weapon code which is
totally HANDLED by the player, to predict properly, since the physical
weapon entity is nothing more than a seperate data container with custom
functions. that the player manipulates every bit of. -- effectively an
extension.
So thus, the solution appears to be store anything that you need to be
accurate, on the player and NOT the weapon, even if only one particular
weapon needs it. (Hell, abuse the send proxy abilities and add seperate
tables that get sent through the player when and only when the player has
that particular weapon)
-Tony
On 9/17/07, Jonathan Murphy <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Interesting omega, might need to try it in RnL as I think we have this
problem on occasion too.
On 9/18/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Bringing back an old topic, because I am having this issue too.
However, I seem to have solved it, I don't know WHY this solves it
(unless
it has to do with the prediction after all!)
I moved all my weapon timers (m_flNextPrimaryAttack / secondary) into
the
PLAYER.
so in CSDKPlayer / C_SDKPlayer i have m_flNextPrimaryFire and
m_flNextSecondaryFire, it's networked exactly the same as the
basecombatweapon one, with the same DEFINE_PRED_FIELD_TOL values on the
client.
i put it in public so i can just do pPlayer->m_flNextPrimaryFire etc.
did
a
find in replace for all my weapons, tested with fakelag, bug gone.
My guess is because of the way the prediction works, it's predicting the
player fine, but not other entities attached to the player.
*shrug*
at least this works without any 'hacks'.
oh and i send it as localplayer exlusive.
On 4/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote:
I'll take a closer look at this since it's in the vanilla SDK.
Yahn
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garry
Newman
Sent: Thursday, April 19, 2007 7:49 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
I think I might have seen this in GMod. Does it happen more when
you're
jumping?
On 4/19/07, Mark Chandler <[EMAIL PROTECTED]> wrote:
Here is some videos that I took over the last couple of days to show
you the bug.
Hidden:
http://lodle.net/mf/ hidden.avi
Golden Eye Dev:
http://lodle.net/mf/ges.avi
NimMod:
http://lodle.net/mf/NimMod.avi
Plan Of Attack:
http://lodle.net/mf/planofattack.avi
Empires:
http://lodle.net/mf/empires.avi
Codec is 3ivx.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, April 19, 2007 10:10 AM
To: hlcoders@list.valvesoftware.com; hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
Why do most mods never see this issue?
At 2007/04/12 08:43 PM, Justin Krenz wrote:
Prediction->IsFirstTimePredicted() did not fix the problem as the
problem is not with simulating a command multiple times. The
problem
is with the m_flNextPrimaryAttack variable. Take a look at this:
CMD# m_flNextPrimaryAttack gpGlobals->curtime
CLIENT:
8255 125.99979 126.22500
8258 126.26978 126.27000
8261 126.26978 126.31499
8264 126.35978 126.36000
SERVER:
8255 126.26978 126.31499
8258 126.35978 126.36000
CLIENT:
8268 126.26978 126.42000
8270 126.44978 126.45000
8275 126.44978 126.52499
8276 126.53977 126.54000
SERVER:
8270 126.44978 126.45000
8276 126.53977 126.54000
This is information taken from just before PrimaryAttack() is
called.
As you can see, the extra weapon firings are from commands that are
not being predicted multiple times. They're from commands that
only
see the weapon as firing on the client. What is not included here
is
information from just after PrimaryAttack() is called. If I
included
that information, you would see that m_flNextPrimaryAttack is being
updated to a time in the future as it should be during
PrimaryAttack() and then has been reverted to an earlier time
sometime inbetween the calls to PrimaryAttack. That's the source
of
the problem and causes the client to fire the weapon multiple
times.
Yahn Bernier wrote:
This might not be the best fix. Because of the way prediction
works, it's expected that variables from the server are set back
and
re-simulated multiple times if there's latency in the connection.
You have to make sure that you only create effects, etc., the
first
time you predict a weapon firing on the client. You can determine
whether this is the "first time predicted" by asking
prediction->IsFirstTimePredicted().
The discrepency with ammo sounds like a bug in the mod where the
server and the client are not simulating the exact same # of
bullets
to deduct from the clip. There are shared random # generators and
other means to make sure that the same CUserCmd which causes
firing
should deduct the same # of bullets on both client and server
(SharedRandomInt, etc.)
Yahn
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Chandler
Sent: Thursday, April 12, 2007 4:22 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] FW: SDK Needs to be fixed
Not sure but only half of this worked for ge:S source. But its
given
me idea how to fix the rest so ill post up when im done.
Mark [aka Lodle]
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Krenz
Sent: Friday, April 13, 2007 4:31 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
I was contacted personally by the Goldeneye Source team about this
bug, and I had fixed this already in Empires. I assume since this
is a bug inherent in the HL2DM sdk that everyone will want to fix
this bug in their code. This is the e-mail including the fix I
sent
to the GE team:
The bug is caused by the networked variable m_flNextPrimaryAttack
being reset after the client has simulated firing, but the server
has not fired the weapon yet. The client will fire their weapon
and
increase m_flNextPrimaryAttack to a time in the future. When the
client receives the next server update, this variable is reset to
the server's value of m_flNextPrimaryAttack which has not recorded
that a shot has been fired yet. With the value now being less
than
curtime, it's ok to fire the weapon again which is much sooner
than
it should be.
This bug was also related to another bug we had where our ammo
counter would count down with each shot and then jump back up
because the client was firing shots and the server was correcting
the client on how many bullets had actually been fired. This was
also causing the client to begin reloading their weapon when it
did
not need reloading.
How to fix the first bug:
In basecombatweapon_shared.h, add the following (create a variable
to store the last time the client fired):
#ifdef CLIENT_DLL
float m_flPrevPrimaryAttack;
#endif
In basecombatweapon_shared.cpp,
CBaseCombatWeapon::CBaseCombatWeapon(),
add the following (start the new variable off as 0):
#ifdef CLIENT_DLL
m_flPrevPrimaryAttack = 0;
#endif
In basecombatweapon_shared.cpp, CBaseCombatWeapon::ItemPostFrame(
void ), find the lines that read:
if ( ( pOwner->m_afButtonPressed & IN_ATTACK ) || (
pOwner->m_afButtonReleased & IN_ATTACK2 ) )
{
m_flNextPrimaryAttack = gpGlobals->curtime; } PrimaryAttack();
Change the "PrimaryAttack();" line to the following:
#ifdef CLIENT_DLL
if (m_flPrevPrimaryAttack <= gpGlobals->curtime) { #endif
PrimaryAttack();
#ifdef CLIENT_DLL
m_flPrevPrimaryAttack = m_flNextPrimaryAttack; } #endif
This stores the client's m_flNextPrimaryAttack variable in a
separate, non-networked variable that won't get "stomped" with
each
network update. We then check the m_flNextPrimaryAttack variable
against the client's m_flPrevPrimaryAttack to see if we should
really be simulating
PrimaryAttack() on the client again. If your weapons have
secondary
attacks that are susceptible to the same bug, you'll have to add
another variable for the secondary attack time and check against
that.
For the second bug, check your weapons' PrimaryAttack() functions
and make sure any lines that alter the weapon's m_iClip1 or
m_iClip2
variable are only occurring on the server. By default, there
should
be a line that reads:
if ( iBulletsToFire > m_iClip1 )
iBulletsToFire = m_iClip1;
m_iClip1 -= iBulletsToFire;
Surround the line that decrements m_iClip1 with #ifdef/#endif
GAME_DLL:
#ifdef GAME_DLL
m_iClip1 -= iBulletsToFire;
#endif
Otherwise, the client will reach m_iClip1 == 0 sooner than the
server and begin reloading while there may be one bullet left in
the
gun according to the server. You also might see that the ammo
counter is jumping around as the client decrements bullets, and
then
the server says that there are more bullets in the gun causing the
counter to flash to a higher number.
Mark Chandler wrote:
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
SDK Needs to be fixed
_____
Hi,
My name is mark and im one of the main programmers for a source
mod
called Golden Eye source (http://goldeneyesource.com). Now we
have
had
a major
bug
that has been plaguing the mod for about 8 months to a year now.
The
problem
is that when firing a bullet in game some times it multi fires
causing
two bullet decals to appear (or worse up to 50). This problem is
hardly noticeable for pings from around 0-100 but gets worse
after
that.
The mod team and i have have spent countless of hours on this
problem rewriting code and searching to what is causing this but
with no luck.
To prove that it is not the fault of golden eye modified source
code i
started a new mod based on the advanced sdk. And guess what? Same
results.
http://lodle.net/multifire2.avi
Lag was introduced using net_fakelag (200 and 500) and from the
video you can see the shoot gun going mad and the mp5 producing
multi fire.
I would post this on verc but hardly any valve employees go there
any
more.
So im posting it here in the attempt to get a solution to this
problem.
Mark [aka lodle].
http://forums.steampowered.com/forums/showthread.php?p=6121132&poste
d=1#
post
6121132
--
_______________________________________________
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
--
-omega
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
Programmer for Resistance and Liberation
www.resistanceandliberation.com
Junior Programmer for Red Tribe
www.redtribe.com
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
-omega
--
_______________________________________________
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
