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: [email protected] 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: [email protected]; [email protected] > 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: [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 > >> > >>>a major > >>bug > >>>that has been plaguing the mod for about 8 months to a year now. > >>>The > >>problem > >>>is that when firing a bullet in game some times it multi fires > >>>causing > >> > >>>two bullet decals to appear (or worse up to 50). This problem is > >>>hardly noticeable for pings from around 0-100 but gets worse after > >>that. > >>>The mod team and i have have spent countless of hours on this > >>>problem rewriting code and searching to what is causing this but with no luck. > >>> > >>>To prove that it is not the fault of golden eye modified source > >>>code i > >> > >>>started a new mod based on the advanced sdk. And guess what? Same > >>results. > >>>http://lodle.net/multifire2.avi > >>> > >>>Lag was introduced using net_fakelag (200 and 500) and from the > >>>video you can see the shoot gun going mad and the mp5 producing multi fire. > >>> > >>>I would post this on verc but hardly any valve employees go there > >>>any > >>more. > >>>So im posting it here in the attempt to get a solution to this > >>problem. > >>>Mark [aka lodle]. > >>> > >>> > >>> > >>http://forums.steampowered.com/forums/showthread.php?p=6121132&poste > >>d=1# > >>post > >>>6121132 > >>> > >>> > >>> > >>>-- > >>> > >>>_______________________________________________ > >>>To unsubscribe, edit your list preferences, or view the list > >>>archives, > >>please visit: > >>>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > >> > >>_______________________________________________ > >>To unsubscribe, edit your list preferences, or view the list > >>archives, please visit: > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >>_______________________________________________ > >>To unsubscribe, edit your list preferences, or view the list > >>archives, please visit: > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >>_______________________________________________ > >>To unsubscribe, edit your list preferences, or view the list > >>archives, > please visit: > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > > >_______________________________________________ > >To unsubscribe, edit your list preferences, or view the list > >archives, > please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
