-- [ Picked text/plain from multipart/alternative ] Interesting omega, might need to try it in RnL as I think we have this problem on occasion too.
On 9/18/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > -- > [ 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 > > -- Programmer for Resistance and Liberation www.resistanceandliberation.com Junior Programmer for Red Tribe www.redtribe.com -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
