-- [ 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: > 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 > >
-- -omega -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
