mob grinders = massive false positives

[PhanaticD]

currently using build 955 but has happened since I first updated to 1.9

mob grinders where mobs are all compacted into a small space trigger this

https://gyazo.com/32d2fb35ba029b60f80123e9131f004a https://gyazo.com/0a67c46dda28643924f2e6bb8951ae85

[asofold]

Good point, this is something we need to tackle soon.

Not sure myself what we'll do, possible approaches are:

1. Track entity positions similar to player positions (at least lazily on hitting). Might then run the loop checks like with players. Possibly silently cancel the first hit on an untracked entity (no vl adding).
2. Detect mobs crammed into a narrow place and add some kind of extra leniency, e.g.:
   • Just increase the allowed hitting margin for the direction and reach checks.
   • Keep track of some kind of moving-region, expanding lazily on hits + expire (half a location trace). Effectively allow hitting 'somewhere where the mob has been'.
   • Just keep track of a 'crammed with mob place' and allow hitting there with much more leniency (data stored per player, more runtime efficiency).
   • Possibly one of the above does with just increasing the y-margin, for very crammed places, needs to be tested+logged.

Hard to tell which one will do it or which one is actually easier to implement. The first one has all the infrastructure there already, except for adding the entity-tracking map with a periodic expiration check. However it's not sure that the lazy checking is enough, one might need to update the entity positions... for hot spots like grinders. So the second one with a 'crammed region' detection and being more lenient for hits within that region, should be one of the fastest ways to actually fix such issues.

[Kakifrucht]

+1, annoying one, thanks for your effort

[RoboMWM]

If this helps: https://gist.github.com/RoboMWM/3a99f096a5b886bf83f47fce88c0687c

[asofold]

@RoboMWM Thank you for the quick reply! Is the improbable violation level only from that testing run resulting in the debug log, or has the level been similarly high before starting to test? (I.e. did you ensure to reset it by 'ncp reload' or 'ncp remove TobsterDolphin' or check with 'ncp info TobsterDolphin' before recording?)

The level-sum shown by 'ncp info' clearly is somewhat extreme - but it would be interesting to know, if ...

• It has been accumulated during the server uptime of idk-14 days, or...
• just happened then during recording after server restart
• (something else)

[RoboMWM]

Is the improbable violation level only from that testing run resulting in the debug log, or has the level been similarly high before starting to test?

The picture was an example of what happens, taken after the debug log and /ncp reload of the situation that causes it.

Since they were doing this stuff beforehand, it's very likely that level has accumulated.

The level-sum shown by 'ncp info' clearly is somewhat extreme

They were doing quite a bit of this at several minutes, if not an hour before I joined. Server also had been up for probably several days as well.

[asofold]

I was misinterpreting the image - it's been the actual violation level at that point of time, not the all-time vl-added sum. So that's clearly an extreme violation level even for false positives.

Fight.speed is near impossible to trigger without hitting multiple entities within short time on MC 1.9.x, so the speed violation likely is from the crammed mobs there.