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=6121132&posted=1#post > 6121132 > > > > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
