Again it
Atm most coders uses too many methods for it
For Example:
1) getting server time and calculating fps via it
Code:
//Credits to Coderiz aka Skyjur
#include <amxmodx>
#include <amxmisc>
#include <fakemeta>
/*.....*/
new Float:f1
new Float:plr_fps_cof[33]
new Float:plr_frame_time[33]
public plugin_init()
{
/*.....*/
register_forward(FM_PlayerPreThink, "preThink")
}
public preThink(id)
{
f1 = get_gametime()
plr_fps_cof[id] = (10 * plr_fps_cof[id] + 100.0 * (f1 - plr_frame_time[id])) / 11
plr_frame_time[id] = f1
}
this one with filter, also it could be without it...
2) best code but still with server time constituent
Code:
static Float:fFrameTime
global_get(glb_frametime, fFrameTime)
3) the best way to avoid server time constituent:
in hlsdk (pm_shared.c PM_PlayerMove) we can find such code for getting player fps for performing movement
Code:
// # of msec to apply movement
pmove->frametime = pmove->cmd.msec * 0.001;
We can use same method. Unfortunaly cmd.msec transimitted in 1 byte. How to write time in 1 byte? It`s easy
For example client have 91 fps (1/91)=0,010989 seconds, then this value multiply by 1000 (10,989), cut off (10) and then transmitted to server.
Minimal client fps via fps_max = 20, so maximal value in cmd.msec = 50 ((1/20)*1000 = 50)
And minimal cmd.msec value could be find with 1000 fps. When player is dead and there is no alive movement for him, client sends to server cmd.msec = 0 (+1 way to isPlayerAlive )
Let`s perform reverse conversion: frametime=10*0,001=0,01 => 100 fps. So real fps for movement could be much different from client (in current example 9%)
Code to retrieve cmd.msec:
Code:
#include <amxmodx>
#include <fakemeta>
public plugin_init()
{
/*.....*/
register_forward(FM_CmdStart, "cmdStart");
}
new gFrameTime[33][2]
new Float:gFrameTimeInMsec[33]
public cmdStart(id, uc_handle, seed)
{
gFrameTime[id][1] = gFrameTime[id][0]; //maybe u dont need it
gFrameTime[id][0] = get_uc(uc_handle, UC_Msec); // Our cmd.msec
gFrameTimeInMsec[id] = gFrameTime[id][0] * 0.001;
}
Also cmd.msec uses in calculation of
Code:
pmove->waterjumptime -= pmove->cmd.msec; //CD_WaterJumpTime
pmove->flTimeStepSound -= pmove->cmd.msec; //pev_flTimeStepSound
pmove->flDuckTime -= pmove->cmd.msec; //pev_flDuckTime
pmove->flSwimTime -= pmove->cmd.msec; //pev_flSwimTime
and others (pev_fuser2 etc)
NOTE: If u set fps_max 101, and developer 1, your client will send to server UC_Msec = 9, that means for prediction code 111,+ fps. So really by setting fps_max 101 its real 101 fps, and better to force fps to value = 100 and not 101 in that case in many other protection plugins.
Also u can use it to predict or prove some movement values, for example:
Log of vertical movement after jump
Code:
Frame1: origin[2]=-155,968750 ; velocity[2]=000,000000 ; UC_Msec=16
Frame2: origin[2]=-151,777893 ; velocity[2]=255,528167 ; UC_Msec=19
Frame3: origin[2]=-147,067260 ; velocity[2]=240,328155 ; UC_Msec=20
We want to know velocity[2] at jump off:
F1.velocity[2] = F2.velocity[2] + F1.pev_gravity*F1.sv_gravity*F1.UC_Msec*0,001 = 255,528167+1,0*800,0*16*0,001 = 268,328167;
For example knowing of real velocity[2] at jump off we could calculate height=velocity[2]*velocity[2]/(800*2)
Also we can find next velocity[2]:F3.velocity[2] = F2.velocity[2] - F2.pev_gravity*F2.sv_gravity*F2.UC_Msec*0,001 = 255,528167-1,0*800,0*19*0,001 = 240,328167; (as you see difference 0,000012 unit)
With such knowledge we can detect slide surfaces (if they changes our velocity[2]), edge bugs, wall bugs, we can write universal protection for longjump stats (and drop all hooks of +hook, slap commands etc), real emulation of movement for custom entity (in some rare cases) and many other things.
Add: if you want to find F3.origin[2] from F2 you can use: F3.origin[2] = F2.origin[2] + F2.UC_Msec*0,001*(F2.velocity[2] - F2.pev_gravity*F2.sv_gravity*F2.UC_Msec*0,001/2) = -151,777893 + 19*0,001*(255,528167 - 1,0*800,0*19*0,001/2) = -147,067258 (0,000002 from original) Isn`t easy
Linear Mode
