m_flTimeAttackQueued is hack to get reload unaffected m_flNextAttack
there are probably false periods before m_flNextSecondaryAttack for Get_Target_Time which isn't critical (with Target_On_Simulation 0) but should be solved eventually
intentionally was kept until "something" along with watermark inside of datamap lol
jitters in certain scenarios due to interpolation history not being filled which doesn't bothers anyone (probably) so i've removed "fading"
i've got problem with imagination regarding reliable method of relative correction on networking errors so old approach is preferable for moment
currently focusing on gmod-x64 fork of segregation so probably won't update l4d2 for period of time
[^\S\r\n]+(?=\r?$)
also explicitly specifying value type seems to be good practice to prevent unintended fraction down-rounding (just what've happened in paint.hpp with color 128 -> 127)
also remove scope check i've competely forgot about in draw_crosshair.hpp
i'll get rid of server's timer eventually
also there's bug (i'll take look on later) of "correction accumulation" on tickbase when server is paused which causes memory corruption
my plan to use constant buffering to instantize actions (as healing, reviving) turned out ill-fated:
- many things are using server relative timing: rock stuns, lagcompensation and many of interactables (they're all getting delayed by 150*(1/30) seconds)
- there's always undefined behaviour no matter whether i'm constantly buffering or periodically
- implementing logic that prevents buffering on when you're about to get hit by rock or to use something would adjust weapon timings (they're all getting delayed by 150*(1/30) seconds)
thus i've removed some of things i've worked on (as exploits, viewmodel timing correction)
mostly same thing about extra commands up to 21 while exploiting (my old trick doesn't works anymore): it's either undefined behaviour or feature cuttage
but on good note:
- prediction got hardened against timing fluctations
- prediction now respects network timing updates
- speedhacking issued undefined behaviour is significantly mitigated (not completely but i'd prefer to not bloat my code over such rare cases)
i'll be working on features from now, here's potential list (anything that involves guessing is very low priority):
rock prediction (involves guessing, it's not lagcompensated)
tongue cutter (involves guessing)
tongue aimbot/triggerbot (i've actually forgot to adjust lagcompensation for it but i'm not playing versus anyway)
animation cycles prediction (involves guessing, u-rates are synced already so it's just about latency adjustments now)
minigun aimbot (i'd like to work on it but just one thing that it's angle is limited thus impossibility to compensate spread accurately ruins it for me)
visual improvements (such as visually removing m_duckUntilOnGround)
