RotationPlace false positive

[wallhacks0]

Describe the false positive and how to replicate it

happens on older versions only i think, on line 102 a comment falsely assumes that the latest rotation is always up to data when placing. However this is not true at all. Since on 1.8.9 the placing of blocks gets handled before sending the player position packet. So if the yaw or pitch changed on the tick that you place a block grim will flag you.
I suggest somehow waiting with verifying the rotation until the PlayerPositionPacket is send so that you can use the latest rotation and properly check the placement.

to test this just boot up 1.8.9 and start placing blocks while moving your mouse quickly

Grim version

2.3.69 was testing on loyisa

Server version

idk some 1.8.9 server

Client version

1.8.9

Plugins

idk

[ManInMyVan]

we do wait for the position packet

[ManInMyVan]

line 102 is 1.7 players...

[SamB440]

This happens on all versions. Target block can be updated on render instead of tick, it can probably false even post flying

[wallhacks0]

Sorry I didn't read source correctly, it seems to be fine. Which is weird because im still abled to flag on vanilla. Maybe it has to do with this?

List<Vector3f> possibleLookDirs = new ArrayList<>(Arrays.asList( new Vector3f(player.xRot, player.yRot, 0), new Vector3f(player.lastXRot, player.yRot, 0) ));

its not using player.lastYRot for the second one maybe it should?

[Axionize]

This happens on all versions. Target block can be updated on render instead of tick, it can probably false even post flying

Are you telling me I'm wasting my time slowly making LineOfSightPlace perfect? How tf does it false even post fly?