unfortunately there's no reliable way due to *::Deploy not being called in certain scenarios but that should serve as good foundation for later improvement.
minor precision loss possibly due to addition being replaced with multiplication (ie. cycle + rate * interval -> ticks * rate * interval)
https://www.youtube.com/watch?v=FApMeI1KlVo
shoving is also beneficial during unholstering for ~266.667ms (depends on sequence_duration, z_gun_swing_interval)
that's amended commit (prototype -> finished)
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
for whatever reason m_flStamina inside of C_SpitAbility::UpdateAbility gets pinned at 3000.f (extreme latency concern? or just typo) which in result softlocks C_TerrorPlayer::IsImmobilized for moment ability is updated
it does seems as logic remnant before buffering of 1000.f got implemented (C_TerrorPlayer::IsImmobilized tests for >2000.f) which is needed to keep m_flStamina predicted rather than networked... applying same logic but once solves problem
hopefully i'm not breaking things by omitting m_zombieClass lol
on side note i've thought about adding infinite spit but unfortunately projectiles are using timer-based acceleration
revert: prevent buffer underrun on ack build-up (only for css)
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)
