Client-side weapon prediction jumps around in time to re-predict miss-predictions when the client receives more accurate information from the server. Hence, an attack function can be called multiple times for the same attack. However, the animations and sounds still aren't played multiple times.
To achieve for this, there is a variable called g_runfuncs. g_runfuncs is only true the first time an attack is predicted. The client looks at g_runfuncs before it decides to actually play an event. If false, then no effects. The weapon data will still be updated when g_runfuncs is false, but there should be no visible effects played. HUD_TxferPredictionData is the glue that hold the data persistence together, it transfers the data from one predicted frame to the next. The engine stores multiple frame in memory just incase if figures out something is wrong and has to go back a couple frame to correct a mistake. During these corrections, g_runfuncs is set to false so weapons don't re-fire, etc. gpGlobals->time should never be used in predicted weapons. All time dependent events should be zero based decrement counters which run off the msec of the user commands. This is the most reliable method of prediction. All data that a weapon depends upon to function properly needs to be passed around properly in the netcode as well. This means proper entries in the delta.lst file and the GetWeaponData, UpdateClientData, and HUD_TxferPredictionData functions must be made. A static variable in a predicted weapon function would be a "bad thing" do to the time jumping and re-predictions. It's not perfect though. Do to the netcode truncating the time values to the nearest millisecond (delta.lst) every frame, some events will still occasionally double fire. This is because between predicted client-frames the values are transferred as full floats (HUD_TxferPredictionData) unlike the truncated data that's arriving from the server periodically. The effect of the usercmd->msec server-side will have a slightly different outcome client-side. To fix this you can to truncate your decrement counters down to the nearest millisecond whenever they are modified. This helps ensure prediction accuracy. I've tried to make sense, if something is still confusing feel free to ask more questions. Ikkyo Lead Coder of Desert Crisis (http://www.desertcrisis.com) ----- Original Message ----- From: "Rockefeller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 12, 2003 1:28 AM Subject: Re: [hlcoders] clientside weapon prediction > Cortex wrote: > > You can use a static variable in PrimaryAttack client side. Then, you return > > from the function if not enough time has elapsed since your previous shot... > The "time" parameter does not change when this is the case. > And indeed, thats my workaround for now, but thats not applicable for 3 > of my weapons, cos if i return when gpGlobals->time is the same as in > the call before, the difference between two calls is sometimes to long. > That should be fixed in the engine, mainly because the seed problem, > also in other mods. > > That leads to another possible bug: > HUD_PostRunCmd() has the parameter "time". The comment above says: "time > is the current client clock based on prediction". But that cannot be > true, because if gEngfuncs.GetClientTime() changes but this "time" > parameter is always equal in more than two subsequent calls, can "time" > be fully predicted? :) > > The next thing: If PrimaryAttack() is called several times, why the hell > aren't there more than one event fired? > I remember someone from Valve stating earlier that only one event per > frame can be fired. This should be extended to: only one event per > _predicted_ frame. IMO another bug. > > Rockefeller > > > > _______________________________________________ > 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
