No net_fakelag is fine. This is because the weapons are not being predicted. Ill try and find the fix for you.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo 'r2d2rigo' Diaz Sent: Sunday, February 03, 2008 8:37 PM To: [email protected] Subject: Re: [hlcoders] Weapon Prediction Problems? -- [ Picked text/plain from multipart/alternative ] Wasn't the net_fakelag command broken? I think I read that a long time ago here in the list. 2008/2/3, Cale Dunlap <[EMAIL PROTECTED]>: > > This is a multipart message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > Alright, I'm stumped. I can't tell if this is a prediction problem, or of > something else is going on. > > > > I've written about 35 or so new weapons and they ALL experience animation > and effect glitches in a laggy environment (net_fakelag 100 is how I've > been > testing this). > > > > If I have a semi-auto weapon such as a pistol which is only allowed to > fire > every 0.2 seconds it can fire every single frame when there is any sort of > lag introduced to the game. Obviously when I say "fire" I mean just play > the > effects, it doesn't actually fire on the server-side. This happens on full > auto as well, but isn't so obvious to the player because it is masked by > the > real rate of fire. > > > > When I run the debugger, I discovered that the server and client time get > out of sync, causing the m_flNextPrimaryAttack variable to become > instantly > stale on the client side. Here is the rundown of what is going on: > > > > 1. Client sends fire command, plays the effects > > 2. Client updates m_flNextPrimaryAttack to gpGlobals->curtime + x.xx > > 3. Server acknowledges, fires the weapon > > 4. Server updates m_flNextPrimaryAttack to gpGlobals->curtime + x.xx > > 5. Server sends client updated m_flNextPrimaryAttack time > > 6. Client corrects m_flNextPrimaryAttack which ends up BEHIND > gpGlobals->curtime > > 7. Client sends fire command, plays effects > > 8. Client updates m_flNextPrimaryAttack to gpGlobals->curtime + x.xx > > 9. Server denies command because it isn't allowed to shoot on the > server yet > > 10. Server sends client updated m_flNextPrimaryAttack time > > 11. Client corrects m_flNextPrimaryAttack again, ending up BEHIND > gpGlobals->curtime again allowing it to shoot again > > > > Basically the server is sending the client an old m_flNextPrimaryAttack > time > near continuously. This would normally be OK, but the gpGlobals->curtime > variables become out of sync. The server thinks it is 1263.6800 when the > client has 1263.7500. This only happens when there is lag. > > > > To test to make sure it wasn't my mod, I ran a vanilla setup of the > scratch > SDK and discovered that the weapons built into that SDK experience the > same > symptoms. I'm not sure if it is for the same reasons or not though, I > didn't > run it through the debugger. > > > > I sure hope there is some easy way to fix this. Perhaps it is just a > symptom > of using fake lag? Maybe I should just set up a server in the same room, > then shake the Ethernet cable violently until bits fall out of the cable, > creating lag? (joke) > > > > Thanks in advance. > > > > Cale > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 > 1:50 PM > > > -- > > > _______________________________________________ > 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
