Ok, well I seem to have completely horked my weapons now, but the rapid fire thing is fixed (using Justin's fix).
I added the ShouldPredict to the SDK base weapon class and they all show up in the prediction list, however a few more problems have manifested themselves. Now I have two of everything (bullet holes, muzzle flashes, shell ejections, recoil, animations, etc.) I used Justin's method of storing the old NextPrimaryAttack variables off on the client and checking them, that seemed to fix the rapid fire semi-auto (because the ShouldPredict() fix didn't seem to fix it). Perhaps I just need to start at square one with my weapons again. My basecode is so incredibly convoluted now I can't really make sense of it anymore. Cale -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Chandler Sent: Sunday, February 03, 2008 8:21 AM To: [email protected] Subject: RE: [hlcoders] Weapon Prediction Problems? http://list.valvesoftware.com/mailman/private/hlcoders/2007-September/022161 .html Quote I'm glad you brought this topic back up, and I've found the definite fix. The original problem was that weapons would shoot too fast, but I've been encountering a problem where weapon animations are just plain glitchy when not at a sub 50 ping. Both of these problems are only evident in the base SDK and not the HL2 DM SDK. Your moving the m_flNextPrimaryAttack variable into the player is an interesting hint at the real source of the problem, but the problem is not due to anything about how networked data is updated or received. The problem is that no weapons are being predicted! If you put "cl_predictionlist" in the console, it will print a list of all entities in the world that are being predicted. If you run in HL2 DM, the list is something along the lines of player, view model, and player weapons. However, if you look at the list in a base SDK mod, only the player and view model are listed. That's because your weapons aren't being predicted. The reason they're not predicted is because CWeaponSDKBase does not override C_BaseEntity's ShouldPredict() function to tell the game to predict the weapons. In the HL2 DM sdk, the weapons are derived from CWeaponHL2MPBase which overrides ShouldPredict() and returning true if the local player is the one holding the weapon. How to fix this bug: In weapon_sdkbase.h, add: #ifdef CLIENT_DLL virtual bool ShouldPredict(); #endif In weapon_sdkbase.cpp, add: #ifdef CLIENT_DLL bool CWeaponSDKBase::ShouldPredict() { if ( GetOwner() && GetOwner() == C_BasePlayer::GetLocalPlayer()) return true; return BaseClass::ShouldPredict(); } #endif Credit Goes to Justin Krenz -----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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 1:50 PM 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
