PunchAngle not being properly predicted/networked

[Kefta]

Tested on a dedicated server. Notice that command 726401 predicts again AFTER 726402 starts, and the punch value changes between these cases. Also, the values never match with the server even though both were set to the same initial punch value.

CODE

hook.Add( "Move", "PunchTest", function( pPlayer )
    if ( DOPRINT and not pPlayer:IsBot() ) then
        print( pPlayer:GetCurrentCommand():CommandNumber()
            .. "\nIsFirstTimePredicted: " .. tostring(IsFirstTimePredicted())
            .. "\nPunch: " .. tostring(pPlayer:GetViewPunchAngles()) .. "\n" )
    end
end )

CLIENT

726400
IsFirstTimePredicted: true
Punch: 0.458 0.132 0.000

726400
IsFirstTimePredicted: false
Punch: 0.458 0.132 0.000

726401
IsFirstTimePredicted: true
Punch: 0.553 0.162 0.000

726401
IsFirstTimePredicted: false
Punch: 0.553 0.162 0.000

726402
IsFirstTimePredicted: true
Punch: 0.627 0.185 0.000

726401
IsFirstTimePredicted: false
Punch: 0.563 0.156 0.000

726402
IsFirstTimePredicted: false
Punch: 0.636 0.179 0.000

726402
IsFirstTimePredicted: false
Punch: 0.636 0.179 0.000

SERVER

726400
IsFirstTimePredicted: true
Punch: 0.475 0.138 0.000

726401
IsFirstTimePredicted: true
Punch: 0.569 0.168 0.000

726402
IsFirstTimePredicted: true
Punch: 0.643 0.191 0.000

[Faerachnidendro]

Well I'll be damned... that explains the jitter on weapon recoil a bit more, for some weapon bases. Good spotting.

[Jvs34]

No, the jitter on weapon recoil of the weapon bases you try is because those weapons don't predict properly.

The prediction of the punch angle has a margin of error that it accepts so it will never jitter unless the values are much bigger than the margin of error and it will restore back to the value of the server.

[Faerachnidendro]

Good to know! Mine in particular are running far smoother anyway, thanks to util.SharedRandom.

Still a bit screwy towards the end of a magazine though, I probably have the prediction off a bit myself after some recent changes.

Edit: nvm, I've randomed elsewhere down the line.

[Kefta]

I believe the inaccuracies come from the tolerance mixed with network float inaccuracies, which essentially lead to it becoming worse between realms. See here:

Although both start out the same, they quickly become out of sync with the DTVar in the Move hook storing the angle becomes further away between realms.

[Faerachnidendro]

@Kefta was this using util.SharedRandom? would be interesting to see a comparison - might do it later myself.

[Kefta]

No, I use my own shared minstd_rand library, but it played no part in this demonstration. An initial shared value for the punch was set and it slowly became more out of sync. I'll post my decay code later today

[Faerachnidendro]

o_o Now I'm curious about your library! 😝 If you don't mind, I'll end up using your decay code on my end, to see if there's any difference with the variation between different machines(thinking that perhaps hardware(including network) capabilities might have an affect on the outcome).

[willox]

I'm struggling to make a weapon that can reproduce this

[Kefta]

Default decay

Test code: http://pastebin.com/wAAFiyrV Default SMG (out of sync by 18572): http://pastebin.com/WBipWTQm weapon_base inherent (http://pastebin.com/xUcYGaHt): http://pastebin.com/RApxKDRq

Custom decay

Decay code: http://pastebin.com/HcBm5MFR weapon_base inherent: http://pastebin.com/taDpzUSf

These are obviously very small differences that don't matter too much alone, but spread algorithms that place a higher priority on punch angles and firing before a viewpunch angle fully decays creates even larger inaccuracies.

This is the output with prediction errors and impacts enabled of my weapon base with the custom decaying enabled (https://github.com/Kefta/GSWeapons/blob/master/gsweapons_css/lua/weapons/weapon_csbase_rifle.lua#L120-L169) which sets the viewpunch to the same initial value: http://pastebin.com/4KDcVH29

Blue = server impacts, Red = client impacts

[Kefta]

Probably unrelated, but I've noticed that the punch angle caused by fall damage will desync on the pitch, but the roll is within acceptable error range.

002 CPlayerLocalData::m_vecPunchAngleVel - vec[] differs (1st diff) (net 4.812500 0.000000 -16.687500 - pred 0.000000 0.000000 -16.706417) delta(-4.812500 0.000000 -0.018917) 001 CPlayerLocalData::m_vecPunchAngle - vec[] differs (1st diff) (net -2.000000 0.000000 8.687500 - pred 0.000000 0.000000 8.716500) delta(2.000000 0.000000 0.029000)