Sponge

[DarkArc]

This is an inquery/feature request for Sponge support.

I'm curious as to plans for potential Sponge support, if any, and how others might be able to assist in adding Sponge support.

[asofold]

All in all NCP is taking much time, and it's needed for the basics of a server i could have (had), so it's hard to imagine how to do 'more' without contribution in the first place.

Now for Sponge, the short version is similar to:

• With significant contribution by several developers a lot is thinkable.
• Long term plans are to make the core of NCP rather mod-independent. Think of supporting different versions of Minecraft, custom modifications to Spigot/whichever, other core mods, other packet API(s) and so on.
• Medium term goal is to add-in flexible registries that mostly abstract away the mod, but that also allow to register data sources/check-pipelines/whatnot for mod-specific or just legacy checks. The idea is to have that abstract core providing frameworks for registration with auto-registration and auto-dependency handling (your check registers once dependencies are there, and it'll re-register or unregister automatically when things change), check types and violation levels, abstract counters with arithmetics enabling abstract meta-checks or just inputs for other things, logging and similar. This of course will be kept independent of any mods.
• The difficulty of changing to another mod probably isn't even that high, as some places already use some sort of abstractions, and using some check context/pipeline objects to provide on-demand information can still be added, it would fit into the main line concept. The big point is just that it's a lot of places that have to be changed, and one can't really start 'early'.

Thinking of contribution, there of course are other things to consider, like how to organize code / workarounds / classes of checks (deterministic envelope, pretty hard heuristics, experimental heuristics, detecting specific cheat implementations via pattern matching or machine learning ...), documentation/modeling/management etc. It's a wide area and i'd certainly be open to discussion. For me it's just important that the thing provides the mostly deterministic and at least near-decent base protection, while keeping false positives at bay - this means we're dealing with latency effects in rather deterministic ways, so what i have in mind won't be too simple, plugins focused around 'simple' approaches keep popping up anyway, virtually with every new dev trying something with anti cheating, and most don't cover enough ground and/or they drop it rather sooner than later. On the other hand the system is meant to allow replacing checks even at runtime, so there can always be 'very classic' or 'very simple' implementations for checks e.g. for starters. With more people contributing it'll also be thinkable to patch up faster, by just adding a detection for a specific implementation of a cheat/client, but that can't be the main focus, as that will just be bypassed the next day, even if it raises the ban count.

The typical plans for NCP (partly long term) are mentioned here:

• https://github.com/NoCheatPlus/Docs/blob/master/Development/Discussion/Future.md
• https://github.com/NoCheatPlus/Docs/blob/master/Development/Discussion/Design.md
• https://github.com/NoCheatPlus/Docs/blob/master/Development/Roadmap.md

Beware these are largely redundant and contain an arbitrary amount of random gibberish.

[asofold]

For the question on how to support...

the first task would be to provide a common infrastructure, so both sides profit. It's probably slightly early to just rush in, as some stuff in NCP is going to be changed to something that could later be common.

Typical common infrastructure:

• Logging (already mostly is).
• Dynamic check types.
• Generic registries.
• Generic per player data (and config) framework.
• (Data structures)

Ambitious could be to attempt to do the moving checks first:

• Block property access framework (to be non static, classes for blocks).
• A range of event listeners would need to use abstraction somehow, uncertain what's best (not make abstract, create an anti cheating DSL, make abstract with some pooled access objects and/or generics). Also goes for all use of Player.

Another approach would be to just exchange knowledge/experience, so someone else builds something for sponge, with occasional exchange.

Perhaps i'll evaluate on further abstraction on moving checks at some point, so one could try a prototype without any registries at some point, with reasonable effort. (Edit: This is also interesting for recording + testability)

[EnderStar]

what about meanwhile porting the easy things like thunder sounds, hiting yourself, and other checks that wont affect mods? thanks!

[asofold]

There needs to be some common infrastructure, so the essential check code is the same for both mods. Otherwise it'll be maintaining two much different plugins for the same thing.

The idea is to just implement new data/access poroviders for most, otherwise it's not feasible for me to do.

[Janmm14]

@EnderStar Hitting yourself is blocked by newer minecraft servers themself and sponge should add an internal check for that too if that did not happen already.

[theboomer]

Given that you have an idea on how to make crossplatform systems in order to be possibly feasible, have you been able to give any further time to investigating the approach?

Sponge is much more mature now than it was a year ago, big gaps filled in now, drawing more attention for being put to use for purposes other than pixelmon servers. And an hour looking with a client like Wurst just makes my spine melt - yes, so much of it being client-side only or nearly indistinguishable from a piece of tape on a mouse button or keyboard or a persistant responsive player, not much can be done, but so many others that scream out for a way for Sponge users to be alerted --- no tool was ever perfect, nor could be, but with clever and thoughtful feedback-based tuning, it was always reassuring that NCP and orebfuscator were going to annoy most 'hackers' enough to chase away, and those who persisted would be lighting up the mod chat and logs with a variety of different noises that drew attention quickly. While a lot of these tool hacks have very very specific vector and 12-decimal fractional parts that can't be produced in game any other way and even ONE occurance of such hit in a player move event or such, and a zero-tolerance catch can be easy to code for them, it is that statistical-like 'lets give them enough rope to hang themselves if its real' approach to allow for rare false positives to fade out that NCP brings to the table that gives the power to the admins.
My experience is that only a handful of cheats need to be caught/suspected, as folks armed with 100+ tools will seldom restrict themselves to 1 or 2 undetectable ones, and try to push their limits a bit, especially flying , waterwalking, xray, chestfinding, and various types of kill auras as a safety net on even just a non-pvp, PVE survival server. A bit of noise raised out of suspicion from ncp, and then its often easy to watch invisibly as the player performs a series of acrobatic moves that are clearly hacks but not registerable, or watch them zero in on underground spaces and planted chests uncannily, or kill a mob spawned behind their back in a split second before resuming to mine.

It would be very nice to get a fraction of that back again, on Sponge, to pick up on a fraction of it to at least draw attention to those to watch...

I hope you are going to be able to manefest your thoughts to make this a possibility eventually. Positive energy being directed your way..

[Janmm14]

With the last build of NCP being more than two months ago I assume there is not even enough time to manage ncp for craftbukkit/spigot and I guess only little internals might have changed with cross-server-support in mind, so it would still take a huge amount of work to get ncp onto sponge.

[asofold]

@Janmm14 Very likely.

On the other hand the roadmap hasn't really changed, so on the very long run it becomes more probable rather. Currently i'll also work towards making it easier to contribute towards NCP rather than implementing new complex concepts, because it's not going to help the open source variant to patch up something that's non-critical or that other plugins do, if we can make it easier to distribute extra jars with experimental checks ourselves, and get more code-wise contribution incoming. And there is some overlap with working towards support of other server mods, partly planned, partly in focus.

• More generic internal registries. (planned)
• Auto registration features. (planned)
  • Include dependency mechanisms and all sorts of triggering and activation conditions (plugins present, classes existing, data sources exisiting, ...)
• Moving data and other to non static. (planned)
  • E.g. with MC 1.13 it's not unlikely to switch towards internal block abstraction with per block model classes. Internal caches will abstract types etc. more or less fully (back to ints, which can not be referenced by config and may change each run :), for a part), so the internal caches will hold information about shape (collision related), breaking, extras for moving (bouncing, friction, ...), possible some general flags that make it superfluous to query the underlying server all the time. From there on we can have 'read blocks from a configuration file and forget what the server is telling us' with little extra cost. And with block information the moving checks are in range for cross-mod use. (planned)
• Making (some) checks possible to run offline from recorded data. (distantly planned, related)

So the primary focus is to make it easier to add/alter/exchange stuff, which is pretty much in line with working towards being independent from the underlying mod. Of course the independent core won't make the checks run on another mod, but it'll make it possible to transform the most important ones one by one, while the core is already enabling on another mod.