Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

I tracked down the source of my issue.  Someone once posted a bug fix
for jittery AI animations by changing

C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
{
...
if ( !IsSelfAnimating() )
{
m_flAnimTime = engine-GetLastTimeStamp();
}
}

to

if ( IsSelfAnimating() )


Meanwhile, another fix courtesy of the official Wiki says to remove this
whole block of code (
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Animations_are_jittery
).  Both of these fixes are wrong!  m_flAnimTime needs to be set for the
weapons otherwise they'll act jittery when a new sequence is sent from
the server.  The correct fix is as follows:

C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
{
...
if ( !IsSelfAnimating()  !IsNPC() )
{
m_flAnimTime = engine-GetLastTimeStamp();
}
}

Check and see if you've wrongly implemented one of the other incorrect
fixes like I had.

Yahn Bernier wrote:

Well, I'm 100% sure we don't have this bug in our current codebase.  So
probably when the SDK gets imaged from it the bug will be fixed for all.

Yahn

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick
Sent: Tuesday, September 25, 2007 7:13 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

These bugs scare me, if neither Valve nor the more experienced coders
can fix them. What hope is there for the rest of us less experienced
coders?

On 9/25/07, Justin Krenz [EMAIL PROTECTED] wrote:

It seems that fix only comes into play when getting an attachment from



the local weapon.  My problem is elsewhere as it happens during all
animations.  Is anyone else experiencing my problem?  I suppose I
should create a new base sdk mod and see if it happens there too to
make sure it's not something I've broken, but I know it's not
occurring in the HL2DM sdk.

Yahn Bernier wrote:

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ] There is another
bug fix which will go into the Orange Box version of the SDK related



to the view models replaying part of their previous animation.
(And there are a few other fixes which explain why cl_showerror is
overly spammy on m_nTickBase/m_vecOrigin errors for the local
player).

It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the
following change (new code in red) in c_baseanimating.cpp:

//--

---
// Purpose: if the active sequence changes, keep track of the
previous ones and decay them based on their decay rate
//--

---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion
q[], int boneMask ) {
  VPROF( C_BaseAnimating::MaintainSequenceTransitions );

  if ( !hdr )
  return;

  if ( prediction-InPrediction() )
  {
  m_nPrevNewSequenceParity = m_nNewSequenceParity;
  return;
  }

Give that a try and see if it fixes your issue

(You'll need to include prediction.h in the .cpp file, too)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

Yeah, I'm ashamed for all of us that we didn't find this sooner. :P

Tell me how this fix works for you.  It fixes the issues I was
having with glitchy shoot animations and of course the shoot
animations occurring over twice as fast for rapid fire weapons.
However, I'm still getting a jittering in the animations when
deploying the weapon and with net_fakelag set to at least 100.  This



doesn't occur in the HL2DM SDK, and doing a cl_pdump of the
predicted view model and the weapon itself shows that everything is
exactly the same.  The jittering occurs right when the client
receives the new m_nSequence at the bottom of

baseviewmodel_shared.cpp via the recvproxy.

Are you experiencing this same problem?


Tony omega Sergi wrote:

--
[ Picked text/plain from multipart/alternative ] Wow, great catch

man.

I didn't even notice that!
-Tony

On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Great News if this is the case. :P



--

___
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

Re: [hlcoders] FW: SDK Needs to be fixed

[Paul Peloski]

--
[ Picked text/plain from multipart/alternative ]
I pointed this one out on hlcoders 14/8/06 and Yahn was the one who said to
remove the line entirely. The original suggested fix by me was to remove the
!

Regards,

Paul

On 9/26/07, Justin Krenz [EMAIL PROTECTED] wrote:

 I tracked down the source of my issue.  Someone once posted a bug fix
 for jittery AI animations by changing

 C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
 {
 ...
 if ( !IsSelfAnimating() )
 {
 m_flAnimTime = engine-GetLastTimeStamp();
 }
 }

 to

 if ( IsSelfAnimating() )


 Meanwhile, another fix courtesy of the official Wiki says to remove this
 whole block of code (

 http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Animations_are_jittery
 ).  Both of these fixes are wrong!  m_flAnimTime needs to be set for the
 weapons otherwise they'll act jittery when a new sequence is sent from
 the server.  The correct fix is as follows:

 C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
 {
 ...
 if ( !IsSelfAnimating()  !IsNPC() )
 {
 m_flAnimTime = engine-GetLastTimeStamp();
 }
 }

 Check and see if you've wrongly implemented one of the other incorrect
 fixes like I had.

 Yahn Bernier wrote:
  Well, I'm 100% sure we don't have this bug in our current codebase.  So
  probably when the SDK gets imaged from it the bug will be fixed for all.
 
  Yahn
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Nick
  Sent: Tuesday, September 25, 2007 7:13 PM
  To: hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] FW: SDK Needs to be fixed
 
  These bugs scare me, if neither Valve nor the more experienced coders
  can fix them. What hope is there for the rest of us less experienced
  coders?
 
  On 9/25/07, Justin Krenz [EMAIL PROTECTED] wrote:
  It seems that fix only comes into play when getting an attachment from
 
  the local weapon.  My problem is elsewhere as it happens during all
  animations.  Is anyone else experiencing my problem?  I suppose I
  should create a new base sdk mod and see if it happens there too to
  make sure it's not something I've broken, but I know it's not
  occurring in the HL2DM sdk.
 
  Yahn Bernier wrote:
  This is a multi-part message in MIME format.
  --
  [ Picked text/plain from multipart/alternative ] There is another
  bug fix which will go into the Orange Box version of the SDK related
 
  to the view models replaying part of their previous animation.
  (And there are a few other fixes which explain why cl_showerror is
  overly spammy on m_nTickBase/m_vecOrigin errors for the local
  player).
 
  It's due to the interaction of the sequence blending code with the
  networking and prediction systems. To fix, we had to make the
  following change (new code in red) in c_baseanimating.cpp:
 
  //--
  
  ---
  // Purpose: if the active sequence changes, keep track of the
  previous ones and decay them based on their decay rate
  //--
  
  ---
  void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
  float flCycle, float flPoseParameter[], Vector pos[], Quaternion
  q[], int boneMask ) {
VPROF( C_BaseAnimating::MaintainSequenceTransitions );
 
if ( !hdr )
return;
 
if ( prediction-InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}
 
  Give that a try and see if it fixes your issue
 
  (You'll need to include prediction.h in the .cpp file, too)
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Justin
  Krenz
  Sent: Tuesday, September 25, 2007 5:00 PM
  To: hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] FW: SDK Needs to be fixed
 
  Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
 
  Tell me how this fix works for you.  It fixes the issues I was
  having with glitchy shoot animations and of course the shoot
  animations occurring over twice as fast for rapid fire weapons.
  However, I'm still getting a jittering in the animations when
  deploying the weapon and with net_fakelag set to at least 100.  This
 
  doesn't occur in the HL2DM SDK, and doing a cl_pdump of the
  predicted view model and the weapon itself shows that everything is
  exactly the same.  The jittering occurs right when the client
  receives the new m_nSequence at the bottom of
  baseviewmodel_shared.cpp via the recvproxy.
  Are you experiencing this same problem?
 
 
  Tony omega Sergi wrote:
  --
  [ Picked text/plain from multipart/alternative ] Wow, great catch
  man.
  I didn't even notice that!
  -Tony
 
  On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Great News if this is the case. :P

Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

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

Re: [hlcoders] FW: SDK Needs to be fixed

[admin]

Great News if this is the case. :P

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] FW: SDK Needs to be fixed

[Tony \omega\ Sergi]

--
[ Picked text/plain from multipart/alternative ]
Wow, great catch man. I didn't even notice that!
-Tony

On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Great News if this is the case. :P


--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

Yeah, I'm ashamed for all of us that we didn't find this sooner. :P

Tell me how this fix works for you.  It fixes the issues I was having
with glitchy shoot animations and of course the shoot animations
occurring over twice as fast for rapid fire weapons.  However, I'm still
getting a jittering in the animations when deploying the weapon and with
net_fakelag set to at least 100.  This doesn't occur in the HL2DM SDK,
and doing a cl_pdump of the predicted view model and the weapon itself
shows that everything is exactly the same.  The jittering occurs right
when the client receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.

Are you experiencing this same problem?


Tony omega Sergi wrote:

--
[ Picked text/plain from multipart/alternative ]
Wow, great catch man. I didn't even notice that!
-Tony

On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Great News if this is the case. :P



--

___
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

RE: [hlcoders] FW: SDK Needs to be fixed

[Yahn Bernier]

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
There is another bug fix which will go into the Orange Box version of
the SDK related to the view models replaying part of their previous
animation.  (And there are a few other fixes which explain why
cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for the
local player).

It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the following
change (new code in red) in c_baseanimating.cpp:

//--
---
// Purpose: if the active sequence changes, keep track of the previous
ones and decay them based on their decay rate
//--
---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
int boneMask )
{
VPROF( C_BaseAnimating::MaintainSequenceTransitions );

if ( !hdr )
return;

if ( prediction-InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}

Give that a try and see if it fixes your issue

(You'll need to include prediction.h in the .cpp file, too)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

Yeah, I'm ashamed for all of us that we didn't find this sooner. :P

Tell me how this fix works for you.  It fixes the issues I was having
with glitchy shoot animations and of course the shoot animations
occurring over twice as fast for rapid fire weapons.  However, I'm still
getting a jittering in the animations when deploying the weapon and with
net_fakelag set to at least 100.  This doesn't occur in the HL2DM SDK,
and doing a cl_pdump of the predicted view model and the weapon itself
shows that everything is exactly the same.  The jittering occurs right
when the client receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.

Are you experiencing this same problem?


Tony omega Sergi wrote:
 --
 [ Picked text/plain from multipart/alternative ] Wow, great catch man.

 I didn't even notice that!
 -Tony

 On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Great News if this is the case. :P


 --

 ___
 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

Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

It seems that fix only comes into play when getting an attachment from
the local weapon.  My problem is elsewhere as it happens during all
animations.  Is anyone else experiencing my problem?  I suppose I should
create a new base sdk mod and see if it happens there too to make sure
it's not something I've broken, but I know it's not occurring in the
HL2DM sdk.

Yahn Bernier wrote:

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
There is another bug fix which will go into the Orange Box version of
the SDK related to the view models replaying part of their previous
animation.  (And there are a few other fixes which explain why
cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for the
local player).

It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the following
change (new code in red) in c_baseanimating.cpp:

//--
---
// Purpose: if the active sequence changes, keep track of the previous
ones and decay them based on their decay rate
//--
---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
int boneMask )
{
VPROF( C_BaseAnimating::MaintainSequenceTransitions );

if ( !hdr )
return;

if ( prediction-InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}

Give that a try and see if it fixes your issue

(You'll need to include prediction.h in the .cpp file, too)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

Yeah, I'm ashamed for all of us that we didn't find this sooner. :P

Tell me how this fix works for you.  It fixes the issues I was having
with glitchy shoot animations and of course the shoot animations
occurring over twice as fast for rapid fire weapons.  However, I'm still
getting a jittering in the animations when deploying the weapon and with
net_fakelag set to at least 100.  This doesn't occur in the HL2DM SDK,
and doing a cl_pdump of the predicted view model and the weapon itself
shows that everything is exactly the same.  The jittering occurs right
when the client receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.

Are you experiencing this same problem?


Tony omega Sergi wrote:

--
[ Picked text/plain from multipart/alternative ] Wow, great catch man.



I didn't even notice that!
-Tony

On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Great News if this is the case. :P



--

___
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

Re: [hlcoders] FW: SDK Needs to be fixed

[Matt Stafford]

--
[ Picked text/plain from multipart/alternative ]
Fixing the bug isn't the issue... its tracking down the exact cause.

On 9/26/07, Nick [EMAIL PROTECTED] wrote:

 These bugs scare me, if neither Valve nor the more experienced coders
 can fix them. What hope is there for the rest of us less experienced
 coders?

 On 9/25/07, Justin Krenz [EMAIL PROTECTED] wrote:
  It seems that fix only comes into play when getting an attachment from
  the local weapon.  My problem is elsewhere as it happens during all
  animations.  Is anyone else experiencing my problem?  I suppose I should
  create a new base sdk mod and see if it happens there too to make sure
  it's not something I've broken, but I know it's not occurring in the
  HL2DM sdk.
 
  Yahn Bernier wrote:
   This is a multi-part message in MIME format.
   --
   [ Picked text/plain from multipart/alternative ]
   There is another bug fix which will go into the Orange Box version of
   the SDK related to the view models replaying part of their previous
   animation.  (And there are a few other fixes which explain why
   cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for
 the
   local player).
  
   It's due to the interaction of the sequence blending code with the
   networking and prediction systems. To fix, we had to make the
 following
   change (new code in red) in c_baseanimating.cpp:
  
  
 //--
   ---
   // Purpose: if the active sequence changes, keep track of the previous
   ones and decay them based on their decay rate
  
 //--
   ---
   void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
   float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
   int boneMask )
   {
 VPROF( C_BaseAnimating::MaintainSequenceTransitions );
  
 if ( !hdr )
 return;
  
 if ( prediction-InPrediction() )
 {
 m_nPrevNewSequenceParity = m_nNewSequenceParity;
 return;
 }
  
   Give that a try and see if it fixes your issue
  
   (You'll need to include prediction.h in the .cpp file, too)
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of Justin
 Krenz
   Sent: Tuesday, September 25, 2007 5:00 PM
   To: hlcoders@list.valvesoftware.com
   Subject: Re: [hlcoders] FW: SDK Needs to be fixed
  
   Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
  
   Tell me how this fix works for you.  It fixes the issues I was having
   with glitchy shoot animations and of course the shoot animations
   occurring over twice as fast for rapid fire weapons.  However, I'm
 still
   getting a jittering in the animations when deploying the weapon and
 with
   net_fakelag set to at least 100.  This doesn't occur in the HL2DM SDK,
   and doing a cl_pdump of the predicted view model and the weapon itself
   shows that everything is exactly the same.  The jittering occurs right
   when the client receives the new m_nSequence at the bottom of
   baseviewmodel_shared.cpp via the recvproxy.
  
   Are you experiencing this same problem?
  
  
   Tony omega Sergi wrote:
   --
   [ Picked text/plain from multipart/alternative ] Wow, great catch
 man.
  
   I didn't even notice that!
   -Tony
  
   On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   Great News if this is the case. :P
  
  
   --
  
   ___
   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




--
Matt Stafford (Wraiyth)
http://www.wraiyth.com
NightFall HL2 Mod - http://www.nightfallmod.com
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] FW: SDK Needs to be fixed

[Yahn Bernier]

Well, I'm 100% sure we don't have this bug in our current codebase.  So
probably when the SDK gets imaged from it the bug will be fixed for all.

Yahn

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick
Sent: Tuesday, September 25, 2007 7:13 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

These bugs scare me, if neither Valve nor the more experienced coders
can fix them. What hope is there for the rest of us less experienced
coders?

On 9/25/07, Justin Krenz [EMAIL PROTECTED] wrote:
 It seems that fix only comes into play when getting an attachment from

 the local weapon.  My problem is elsewhere as it happens during all
 animations.  Is anyone else experiencing my problem?  I suppose I
 should create a new base sdk mod and see if it happens there too to
 make sure it's not something I've broken, but I know it's not
 occurring in the HL2DM sdk.

 Yahn Bernier wrote:
  This is a multi-part message in MIME format.
  --
  [ Picked text/plain from multipart/alternative ] There is another
  bug fix which will go into the Orange Box version of the SDK related

  to the view models replaying part of their previous animation.
  (And there are a few other fixes which explain why cl_showerror is
  overly spammy on m_nTickBase/m_vecOrigin errors for the local
  player).
 
  It's due to the interaction of the sequence blending code with the
  networking and prediction systems. To fix, we had to make the
  following change (new code in red) in c_baseanimating.cpp:
 
  //--
  
  ---
  // Purpose: if the active sequence changes, keep track of the
  previous ones and decay them based on their decay rate
  //--
  
  ---
  void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
  float flCycle, float flPoseParameter[], Vector pos[], Quaternion
  q[], int boneMask ) {
VPROF( C_BaseAnimating::MaintainSequenceTransitions );
 
if ( !hdr )
return;
 
if ( prediction-InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}
 
  Give that a try and see if it fixes your issue
 
  (You'll need to include prediction.h in the .cpp file, too)
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Justin
  Krenz
  Sent: Tuesday, September 25, 2007 5:00 PM
  To: hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] FW: SDK Needs to be fixed
 
  Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
 
  Tell me how this fix works for you.  It fixes the issues I was
  having with glitchy shoot animations and of course the shoot
  animations occurring over twice as fast for rapid fire weapons.
  However, I'm still getting a jittering in the animations when
  deploying the weapon and with net_fakelag set to at least 100.  This

  doesn't occur in the HL2DM SDK, and doing a cl_pdump of the
  predicted view model and the weapon itself shows that everything is
  exactly the same.  The jittering occurs right when the client
  receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.
 
  Are you experiencing this same problem?
 
 
  Tony omega Sergi wrote:
  --
  [ Picked text/plain from multipart/alternative ] Wow, great catch
man.
 
  I didn't even notice that!
  -Tony
 
  On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Great News if this is the case. :P
 
 
  --
 
  ___
  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

Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

Yeah, you're right.  I tried the base SDK and an old version from a year
ago, and both didn't have the problem.  I'm pretty sure I introduced the
bug when I updated to the last major sdk update.

Yahn Bernier wrote:

Well, I'm 100% sure we don't have this bug in our current codebase.  So
probably when the SDK gets imaged from it the bug will be fixed for all.

Yahn

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick
Sent: Tuesday, September 25, 2007 7:13 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

These bugs scare me, if neither Valve nor the more experienced coders
can fix them. What hope is there for the rest of us less experienced
coders?

On 9/25/07, Justin Krenz [EMAIL PROTECTED] wrote:

It seems that fix only comes into play when getting an attachment from



the local weapon.  My problem is elsewhere as it happens during all
animations.  Is anyone else experiencing my problem?  I suppose I
should create a new base sdk mod and see if it happens there too to
make sure it's not something I've broken, but I know it's not
occurring in the HL2DM sdk.

Yahn Bernier wrote:

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ] There is another
bug fix which will go into the Orange Box version of the SDK related



to the view models replaying part of their previous animation.
(And there are a few other fixes which explain why cl_showerror is
overly spammy on m_nTickBase/m_vecOrigin errors for the local
player).

It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the
following change (new code in red) in c_baseanimating.cpp:

//--

---
// Purpose: if the active sequence changes, keep track of the
previous ones and decay them based on their decay rate
//--

---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion
q[], int boneMask ) {
  VPROF( C_BaseAnimating::MaintainSequenceTransitions );

  if ( !hdr )
  return;

  if ( prediction-InPrediction() )
  {
  m_nPrevNewSequenceParity = m_nNewSequenceParity;
  return;
  }

Give that a try and see if it fixes your issue

(You'll need to include prediction.h in the .cpp file, too)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

Yeah, I'm ashamed for all of us that we didn't find this sooner. :P

Tell me how this fix works for you.  It fixes the issues I was
having with glitchy shoot animations and of course the shoot
animations occurring over twice as fast for rapid fire weapons.
However, I'm still getting a jittering in the animations when
deploying the weapon and with net_fakelag set to at least 100.  This



doesn't occur in the HL2DM SDK, and doing a cl_pdump of the
predicted view model and the weapon itself shows that everything is
exactly the same.  The jittering occurs right when the client
receives the new m_nSequence at the bottom of

baseviewmodel_shared.cpp via the recvproxy.

Are you experiencing this same problem?


Tony omega Sergi wrote:

--
[ Picked text/plain from multipart/alternative ] Wow, great catch

man.

I didn't even notice that!
-Tony

On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Great News if this is the case. :P



--

___
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

Re: [hlcoders] FW: SDK Needs to be fixed

[Tony \omega\ Sergi]

--
[ 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:
  8255125.99979   126.22500
  8258126.26978   126.27000
  8261126.26978   126.31499
  8264126.35978   126.36000
  SERVER:
  8255126.26978   126.31499
  8258126.35978   126.36000
  CLIENT:
  8268126.26978   126.42000
  8270126.44978   126.45000
  8275126.44978   126.52499
  8276126.53977   126.54000
  SERVER:
  8270126.44978   126.45000
  8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[Jonathan Murphy]

--
[ 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:
   8255125.99979   126.22500
   8258126.26978   126.27000
   8261126.26978   126.31499
   8264126.35978   126.36000
   SERVER:
   8255126.26978   126.31499
   8258126.35978   126.36000
   CLIENT:
   8268126.26978   126.42000
   8270126.44978   126.45000
   8275126.44978   126.52499
   8276126.53977   126.54000
   SERVER:
   8270126.44978   126.45000
   8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[Tony \omega\ Sergi]

--
[ 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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

RE: [hlcoders] FW: SDK Needs to be fixed

[Mark Chandler]

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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

RE: [hlcoders] FW: SDK Needs to be fixed

[Mark Chandler]

Yes. Look at bug 134 in the bug list has link to video of it in vanilla. Why
has this taken so long before its seen as a problem? I first made aware of
this issue nearly 3 months ago.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yahn Bernier
Sent: Thursday, April 19, 2007 1:28 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] FW: SDK Needs to be fixed

Does this error occur from a vanilla install of the SDK code?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Thursday, April 12, 2007 6:44 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[Garry Newman]

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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

RE: [hlcoders] FW: SDK Needs to be fixed

[Yahn Bernier]

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:
 8255125.99979   126.22500
 8258126.26978   126.27000
 8261126.26978   126.31499
 8264126.35978   126.36000
 SERVER:
 8255126.26978   126.31499
 8258126.35978   126.36000
 CLIENT:
 8268126.26978   126.42000
 8270126.44978   126.45000
 8275126.44978   126.52499
 8276126.53977   126.54000
 SERVER:
 8270126.44978   126.45000
 8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[bloodykenny]

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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[Minh]

--
[ Picked text/plain from multipart/alternative ]
I think it's because it rarely occurs if your ping is below 200.
Still, it would be nice to fix it for those HPB's..

- Original Message -
From: [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com; hlcoders@list.valvesoftware.com
Sent: Wednesday, April 18, 2007 7:10 PM
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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

RE: [hlcoders] FW: SDK Needs to be fixed

[Yahn Bernier]

Does this error occur from a vanilla install of the SDK code?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Thursday, April 12, 2007 6:44 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed

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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[Tony \omega\ Sergi]

--
[ Picked text/plain from multipart/alternative ]
Yeah, it does.

On 4/19/07, Yahn Bernier [EMAIL PROTECTED] wrote:

 Does this error occur from a vanilla install of the SDK code?

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
 Sent: Thursday, April 12, 2007 6:44 PM
 To: hlcoders@list.valvesoftware.com
 Subject: Re: [hlcoders] FW: SDK Needs to be fixed

 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:
 8255125.99979   126.22500
 8258126.26978   126.27000
 8261126.26978   126.31499
 8264126.35978   126.36000
 SERVER:
 8255126.26978   126.31499
 8258126.35978   126.36000
 CLIENT:
 8268126.26978   126.42000
 8270126.44978   126.45000
 8275126.44978   126.52499
 8276126.53977   126.54000
 SERVER:
 8270126.44978   126.45000
 8276126.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

Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

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=6121132posted=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:

RE: [hlcoders] FW: SDK Needs to be fixed

[Mike Durand]

Thanks very much, Justin. I will add this fix into the SDK codebase.

-Mike Durand
 Valve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Thursday, April 12, 2007 1:31 PM
To: [EMAIL PROTECTED]
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=6121132posted=
 1#post
 6121132

RE: [hlcoders] FW: SDK Needs to be fixed

[Mark Chandler]

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: [EMAIL PROTECTED]
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

RE: [hlcoders] FW: SDK Needs to be fixed

[Yahn Bernier]

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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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

Re: [hlcoders] FW: SDK Needs to be fixed

[Justin Krenz]

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:
8255125.99979   126.22500
8258126.26978   126.27000
8261126.26978   126.31499
8264126.35978   126.36000
SERVER:
8255126.26978   126.31499
8258126.35978   126.36000
CLIENT:
8268126.26978   126.42000
8270126.44978   126.45000
8275126.44978   126.52499
8276126.53977   126.54000
SERVER:
8270126.44978   126.45000
8276126.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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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

[hlcoders] FW: SDK Needs to be fixed

[Mark Chandler]

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=6121132posted=1#post
6121132



--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] FW: SDK Needs to be fixed

[Ondřej Hošek]

You might be looking for Valve's SDK Bugzilla. Submit it as a bug and
wait -- good luck.

http://developer.valvesoftware.com/cgi-bin/bugzilla/index.cgi

~~ Ondra

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=6121132posted=1#post
6121132





___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] FW: SDK Needs to be fixed

[Andrew (Bromfitsen)]

--
[ Picked text/plain from multipart/alternative ]
We had the same issue with our recoil, but the soloution was just to make
sure it only got predicted once which we got from other examples in the
code,

it was just

if( prediction-InPrediction()  prediction-IsFirstTimePredicted() )


I'm not sure if that will help you out much but just thought I'd throw that
out there.
--

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] FW: SDK Needs to be fixed

[Teddy]

This is a bit of a wild guess, but perhaps the problem lies within the
TE_HL2MPFireBullets() function, perhaps the UsePredictionRules() for
the CPASFilter isn't working correctly. Mabey try adding the following
to test this theory out:

filter.RemoveRecipient( UTIL_PlayerByIndex( iPlayerIndex ) );

On 3/14/07, Mark Chandler [EMAIL PROTECTED] 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=6121132posted=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