Reach skip option

[Axionize]

Add a config option to skip reach checks for non-player targets. Useful for performance and if you don't care about KA or reach on mob grinders and mobs.

[ManInMyVan]

I think there should be a warning to not enable this because of falses without reporting it

[Axionize]

What are you talking about? I don't quite understand what you're trying to say. This does not cause falses (if anything it would hide falses assuming they exist, which for reach is just not true). This just skips reach check if the target is not a player.

[ManInMyVan]

What are you talking about? I don't quite understand what you're trying to say. This does not cause falses (if anything it would hide falses assuming they exist, which for reach is just not true). This just skips reach check if the target is not a player.

reach falses on non-player entity -> this gets enabled -> false never gets reported -> false never gets fixed

[ItsClairton]

What are you talking about? I don't quite understand what you're trying to say. This does not cause falses (if anything it would hide falses assuming they exist, which for reach is just not true). This just skips reach check if the target is not a player.

reach falses on non-player entity -> this gets enabled -> false never gets reported -> false never gets fixed

There are already false positives involving Reach with entities that are not Players. In version 1.8, at least, I was able to reproduce false positives involving Horse, Elder Guardian, and Skeleton.

[Axionize]

@ItsClairton
Do you have a clip of this? If so it would be big news. As far as we're away Reach (not hitbox but reach distance) is perfect and unfalsable.

[ItsClairton]

@ItsClairton Do you have a clip of this? If so it would be big news. As far as we're away Reach (not hitbox but reach distance) is perfect and unfalsable.

All the issues I've encountered so far are related to incorrect hitboxes. I'll send some examples:

Horse: https://streamable.com/ogyfnb
Elder Guardian: https://streamable.com/75ej5c

[SamB440]

The horse thing is caused by the mounting process and switching between flying and vehicle packets, I seem to remember fixing that in pharus

[ItsClairton]

The horse thing is caused by the mounting process and switching between flying and vehicle packets, I seem to remember fixing that in pharus

Is this also related to falses with simulation when mounting/dismounting too? AimModulo360 sometimes falses too

[Axionize]

@ItsClairton I've been unable to replicate the Elder Guardian false. Did you flag reach before while cheating before you sent me this clip?

I was only able to replicate after cheating for a bit and then attacking the Elder Guardian legit, in which case this is intended behavior since flagging Reach the first time makes us use a more aggressive check next time that can false (but can also cancel hits and not just flag).

[Axionize]

@SamB440 could you PR the fix from Pharus into Grim, I'd very much like Reach to remain unfalsable

[ItsClairton]

@ItsClairton I've been unable to replicate the Elder Guardian false. Did you flag reach before while cheating before you sent me this clip?

I was only able to replicate after cheating for a bit and then attacking the Elder Guardian legit, in which case this is intended behavior since flagging Reach the first time makes us use a more aggressive check next time that can false (but can also cancel hits and not just flag).

No, I was using the vanilla client + Optifine, did you test it on 1.8?
Spawned entity with: /summon Guardian ~ ~ ~ {Elder:1}

[Axionize]

@ItsClairton I've been unable to replicate the Elder Guardian false. Did you flag reach before while cheating before you sent me this clip?
I was only able to replicate after cheating for a bit and then attacking the Elder Guardian legit, in which case this is intended behavior since flagging Reach the first time makes us use a more aggressive check next time that can false (but can also cancel hits and not just flag).

No, I was using the vanilla client + Optifine, did you test it on 1.8? Spawned entity with: /summon Guardian ~ ~ ~ {Elder:1}

Yes I tested it on Vanilla 1.8 server + client and on a 1.21.1 server + client. I was unable to reproduce in both cases without cheating first.

If you were using Optifine, please make sure fast math is off.

[ItsClairton]

@ItsClairton I've been unable to replicate the Elder Guardian false. Did you flag reach before while cheating before you sent me this clip?
I was only able to replicate after cheating for a bit and then attacking the Elder Guardian legit, in which case this is intended behavior since flagging Reach the first time makes us use a more aggressive check next time that can false (but can also cancel hits and not just flag).

No, I was using the vanilla client + Optifine, did you test it on 1.8? Spawned entity with: /summon Guardian ~ ~ ~ {Elder:1}

Yes I tested it on Vanilla 1.8 server + client and on a 1.21.1 server + client. I was unable to reproduce in both cases without cheating first.

If you were using Optifine, please make sure fast math is off.

I just tested it using Vanilla 1.8.9, and the problem still occurs. This issue only happens with the Elder, not with the regular Guardian. I think the Elder is being treated as a regular Guardian when it shouldn't be, because it is larger and therefore has a bigger hitbox.

[ItsClairton]

Grim/src/main/java/ac/grim/grimac/utils/nmsutil/BoundingBoxSize.java

Lines 61 to 62 in 5fbbaba

	} else if (EntityTypes.ELDER_GUARDIAN.equals(type)) { // TODO: 2.35 * guardian?
	return 1.9975f;

This condition will never happen on a 1.8 server because the Elder Guardian is a variant of the Guardian, and in legacy versions, both have the same ID, so PacketEvents identifies them both as "Guardian".

Then both will fall into this condition:

Grim/src/main/java/ac/grim/grimac/utils/nmsutil/BoundingBoxSize.java

Lines 73 to 74 in 5fbbaba

	} else if (EntityTypes.GUARDIAN.equals(type)) {
	return 0.85f;

[Axionize]

@ItsClairton I cannot reproduce on the latest build of LightningGrim and using a debugger shows that Elder Guardians reach the correct Code path on 1.8.

This is almost certainly an issue on your end. Did you build Grim yourself, potentially with outdated PE? Please try the latest build of https://modrinth.com/plugin/lightning-grim-anticheat and tell me if this issue still exists.

[ItsClairton]

@ItsClairton I cannot reproduce on the latest build of LightningGrim and using a debugger shows that Elder Guardians reach the correct Code path on 1.8.

This is almost certainly an issue on your end. Did you build Grim yourself, potentially with outdated PE? Please try the latest build of https://modrinth.com/plugin/lightning-grim-anticheat and tell me if this issue still exists.

2.3.69-b47?

[ItsClairton]

Tested with 2.3.69-b47

[ItsClairton]

Exactly the steps I did:

https://streamable.com/r3qly1

[Axionize]

@ItsClairton I've fixed this in B48 please tell me if any related issues to this remain.

https://modrinth.com/plugin/lightning-grim-anticheat

[ItsClairton]

@ItsClairton I've fixed this in B48 please tell me if any related issues to this remain.

https://modrinth.com/plugin/lightning-grim-anticheat

@Axionize Reach fixed, Thanks