-- [ 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: >>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
