Here is some videos that I took over the last couple of days to show you the bug.
Hidden: http://lodle.net/mf/ hidden.avi Golden Eye Dev: http://lodle.net/mf/ges.avi NimMod: http://lodle.net/mf/NimMod.avi Plan Of Attack: http://lodle.net/mf/planofattack.avi Empires: http://lodle.net/mf/empires.avi Codec is 3ivx. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, April 19, 2007 10:10 AM To: hlcoders@list.valvesoftware.com; hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] FW: SDK Needs to be fixed Why do most mods never see this issue? At 2007/04/12 08:43 PM, Justin Krenz wrote: >Prediction->IsFirstTimePredicted() did not fix the problem as the >problem is not with simulating a command multiple times. The problem is >with the m_flNextPrimaryAttack variable. Take a look at this: > >CMD# m_flNextPrimaryAttack gpGlobals->curtime >CLIENT: >8255 125.99979 126.22500 >8258 126.26978 126.27000 >8261 126.26978 126.31499 >8264 126.35978 126.36000 >SERVER: >8255 126.26978 126.31499 >8258 126.35978 126.36000 >CLIENT: >8268 126.26978 126.42000 >8270 126.44978 126.45000 >8275 126.44978 126.52499 >8276 126.53977 126.54000 >SERVER: >8270 126.44978 126.45000 >8276 126.53977 126.54000 > >This is information taken from just before PrimaryAttack() is called. >As you can see, the extra weapon firings are from commands that are not >being predicted multiple times. They're from commands that only see the >weapon as firing on the client. What is not included here is >information from just after PrimaryAttack() is called. If I included >that information, you would see that m_flNextPrimaryAttack is being >updated to a time in the future as it should be during PrimaryAttack() >and then has been reverted to an earlier time sometime inbetween the >calls to PrimaryAttack. That's the source of the problem and causes the >client to fire the weapon multiple times. > > > >Yahn Bernier wrote: >>This might not be the best fix. Because of the way prediction works, >>it's expected that variables from the server are set back and >>re-simulated multiple times if there's latency in the connection. You >>have to make sure that you only create effects, etc., the first time you >>predict a weapon firing on the client. You can determine whether this >>is the "first time predicted" by asking >>prediction->IsFirstTimePredicted(). >> >>The discrepency with ammo sounds like a bug in the mod where the server >>and the client are not simulating the exact same # of bullets to deduct >>from the clip. There are shared random # generators and other means to >>make sure that the same CUserCmd which causes firing should deduct the >>same # of bullets on both client and server (SharedRandomInt, etc.) >> >>Yahn >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Mark >>Chandler >>Sent: Thursday, April 12, 2007 4:22 PM >>To: hlcoders@list.valvesoftware.com >>Subject: RE: [hlcoders] FW: SDK Needs to be fixed >> >>Not sure but only half of this worked for ge:S source. But its given me >>idea how to fix the rest so ill post up when im done. >> >>Mark [aka Lodle] >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz >>Sent: Friday, April 13, 2007 4:31 AM >>To: hlcoders@list.valvesoftware.com >>Subject: Re: [hlcoders] FW: SDK Needs to be fixed >> >>I was contacted personally by the Goldeneye Source team about this bug, >>and I had fixed this already in Empires. I assume since this is a bug >>inherent in the HL2DM sdk that everyone will want to fix this bug in >>their code. This is the e-mail including the fix I sent to the GE team: >> >> >> >>The bug is caused by the networked variable m_flNextPrimaryAttack being >>reset after the client has simulated firing, but the server has not >>fired the weapon yet. The client will fire their weapon and increase >>m_flNextPrimaryAttack to a time in the future. When the client receives >>the next server update, this variable is reset to the server's value of >>m_flNextPrimaryAttack which has not recorded that a shot has been fired >>yet. With the value now being less than curtime, it's ok to fire the >>weapon again which is much sooner than it should be. >> >>This bug was also related to another bug we had where our ammo counter >>would count down with each shot and then jump back up because the client >>was firing shots and the server was correcting the client on how many >>bullets had actually been fired. This was also causing the client to >>begin reloading their weapon when it did not need reloading. >> >>How to fix the first bug: >> >>In basecombatweapon_shared.h, add the following (create a variable to >>store the last time the client fired): >> >>#ifdef CLIENT_DLL >>float m_flPrevPrimaryAttack; >>#endif >> >>In basecombatweapon_shared.cpp, CBaseCombatWeapon::CBaseCombatWeapon(), >>add the following (start the new variable off as 0): >> >>#ifdef CLIENT_DLL >>m_flPrevPrimaryAttack = 0; >>#endif >> >> >>In basecombatweapon_shared.cpp, CBaseCombatWeapon::ItemPostFrame( void >>), find the lines that read: >> >>if ( ( pOwner->m_afButtonPressed & IN_ATTACK ) || ( >>pOwner->m_afButtonReleased & IN_ATTACK2 ) ) >>{ >> m_flNextPrimaryAttack = gpGlobals->curtime; } PrimaryAttack(); >> >> >>Change the "PrimaryAttack();" line to the following: >> >>#ifdef CLIENT_DLL >>if (m_flPrevPrimaryAttack <= gpGlobals->curtime) { #endif >> PrimaryAttack(); >>#ifdef CLIENT_DLL >> m_flPrevPrimaryAttack = m_flNextPrimaryAttack; } #endif >> >> >>This stores the client's m_flNextPrimaryAttack variable in a separate, >>non-networked variable that won't get "stomped" with each network >>update. We then check the m_flNextPrimaryAttack variable against the >>client's m_flPrevPrimaryAttack to see if we should really be simulating >>PrimaryAttack() on the client again. If your weapons have secondary >>attacks that are susceptible to the same bug, you'll have to add another >>variable for the secondary attack time and check against that. >> >>For the second bug, check your weapons' PrimaryAttack() functions and >>make sure any lines that alter the weapon's m_iClip1 or m_iClip2 >>variable are only occurring on the server. By default, there should be >>a line that reads: >> >>if ( iBulletsToFire > m_iClip1 ) >> iBulletsToFire = m_iClip1; >>m_iClip1 -= iBulletsToFire; >> >>Surround the line that decrements m_iClip1 with #ifdef/#endif GAME_DLL: >>#ifdef GAME_DLL >>m_iClip1 -= iBulletsToFire; >>#endif >> >>Otherwise, the client will reach m_iClip1 == 0 sooner than the server >>and begin reloading while there may be one bullet left in the gun >>according to the server. You also might see that the ammo counter is >>jumping around as the client decrements bullets, and then the server >>says that there are more bullets in the gun causing the counter to flash >>to a higher number. >> >> >> >>Mark Chandler wrote: >>>This is a multipart message in MIME format. >>>-- >>>[ Picked text/plain from multipart/alternative ] >>> >>> >>>SDK Needs to be fixed >>> >>> _____ >>> >>>Hi, >>> >>>My name is mark and im one of the main programmers for a source mod >>>called Golden Eye source (http://goldeneyesource.com). Now we have had >> >>>a major >>bug >>>that has been plaguing the mod for about 8 months to a year now. The >>problem >>>is that when firing a bullet in game some times it multi fires causing >> >>>two bullet decals to appear (or worse up to 50). This problem is >>>hardly noticeable for pings from around 0-100 but gets worse after >>that. >>>The mod team and i have have spent countless of hours on this problem >>>rewriting code and searching to what is causing this but with no luck. >>> >>>To prove that it is not the fault of golden eye modified source code i >> >>>started a new mod based on the advanced sdk. And guess what? Same >>results. >>>http://lodle.net/multifire2.avi >>> >>>Lag was introduced using net_fakelag (200 and 500) and from the video >>>you can see the shoot gun going mad and the mp5 producing multi fire. >>> >>>I would post this on verc but hardly any valve employees go there any >>more. >>>So im posting it here in the attempt to get a solution to this >>problem. >>>Mark [aka lodle]. >>> >>> >>> >>http://forums.steampowered.com/forums/showthread.php?p=6121132&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 >> >> >>_______________________________________________ >>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
