Set-back handling.

[asofold]

A little detail.

A more centralized set-back handling can be of use:

• Prevent cross-check set-back bypass (as existed with passable and survivalfly checks).
• Set-back actions.
• Multiple set-backs with different timing constraints and priorities. Include the ability to override lower priority set-backs.
• Monitor set-back with teleport (after moving) and scheduled set-backs (from vehicle moving or other).
• Something else...

[MyPictures]

Yea I think having a priority for setbacks is a must have kinda, especially for check styles such as Improbable which we have in NoCheatPlus. If Improbably canceled fighting there is no need for Fight_Speed to cancel it also.

Maybe we can do something against constant setbacks (rubber banding) also here.

[asofold]

NCP already does not do other checks if one cancelled the event. Improbable is a special case because partly it is fed by violations of other checks, so this will be something we will also want to have (meta checks), but you do mention a more general point here:

• Having add-in checks means that we don't have the fat CheckListener instances anymore, thus we do need some police to not only relate to cancelled events but also to other behavior of checks that use the same data source but came earlier, like "check triggered a violation" or "check cancelled the action".

Ruberbanding results from constant violations, hard to imagine that set-back handling can do much about it, though it can be the right place to //detect// rubberbanding.

[MyPictures]

Okay. Sounds good.

[SuperSpyTX]

We should be dynamically setting setbacks based on the violation level, and also calculating the last position.

It should be extremely hard to fly when I violate the check, I shouldn't even be able to jump temporarily either.

[asofold]

The demands for the accuracy of the flight checks is another thing :9.
Digesting ...

We should also keep an eye on (or make an extra thread) for the generalized topic of cancelling events and similar. So the rough topics are:

• General cancelling of events or undoing of players actions.
• Set back within moving events.
• Set back with scheduled task (no cancel / direct teleport possible).

In particular moving set-backs pose problems because there are some topics about cross-check issues but also multiple possible purposes:

• Prevent set-backs of different checks competing against each other.
• Stored set-back in terms of the last on-ground position (often not nice to teleport back to, because it is usually on the very edge of blocks).
• The last "safe" set-back: not the very last position but one that is slightly less dangerous to tp back to (probably not possible in a way that prevents any abuse).
• Store multiple set-backs to allow medium term checking and related set-back, e.g. for average speed or for more-packets counting in client-side lag (upon violation one might roll back to a position at which one assumed to be "just some networking delay" but which turned out to seem cheating rather).
• Overriding specific set-backs (if multiple are used).
• Choice of relevant set-backs (if multiple are used), + priority handling.
• Should mention: Detecting if set-backs are used (teleports) or not.
• Problematic: Minecraft protocol does not specify where a player is moving from (neither position nor context), so players moving packets are still accepted by the server, even if the player has been teleported server side but has not yet noticed client side. Detecting such could be really fancy.

[asofold]

Note that just cancelling an event or providing a method to cancel an event in an abstracted event class is not really a job of the framework, that would be up to the specific data source etc.

The part interesting for the framework are those cancellations that are "complicated" in nature (like set-backs or any actions that take time to take effect). Those could become parts of a framework layer (probably not the most inner).