-- [ Picked text/plain from multipart/alternative ] Bringing back an old topic, because I am having this issue too. However, I seem to have solved it, I don't know WHY this solves it (unless it has to do with the prediction after all!) I moved all my weapon timers (m_flNextPrimaryAttack / secondary) into the PLAYER.
so in CSDKPlayer / C_SDKPlayer i have m_flNextPrimaryFire and m_flNextSecondaryFire, it's networked exactly the same as the basecombatweapon one, with the same DEFINE_PRED_FIELD_TOL values on the client. i put it in public so i can just do pPlayer->m_flNextPrimaryFire etc. did a find in replace for all my weapons, tested with fakelag, bug gone. My guess is because of the way the prediction works, it's predicting the player fine, but not other entities attached to the player. *shrug* at least this works without any 'hacks'. oh and i send it as localplayer exlusive. On 4/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > 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: hlcoders@list.valvesoftware.com > 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: 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&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 > > -- -omega -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
