Bukkit

@HubToo

I also found the sentence with "generic" now - not entirely sure what i was pointing at back then, i could imagine it to be a left-over entry hinting at the actions parts and active flags which almost all checks have in them, which have been inserted into the checks page.

The consistencychecks are automatic anyway, there is some checking of internal data, to track effects by NPCs or bugs in either the server or NCP (e.g. certain events missing). I believe you set logging.debug to true, which should be the reason for the messages to appear at all.

210 blocks is a lot :) - i'd like to detect "most things" automatically, e.g. by comparing known blocks to new ones, currently we need to fill in some extra information, because the server does not always tell us correctly. Using blockbreak.debug, you can see what flags are set for typical vanilla blocks, so it should be possible to copy those for blocks that are shaped same way as vanilla blocks. Unfortunately some blocks have specific (yet hard-coded) workarounds, we will try to work around those at some point, possibly with more flags, until we run out of flags (, which will mean recoding to something more flexible).

Note that you can't change block break timings other than adding the blocks to the allowinstabreak list right now, which probably is slightly annoying (break whatever block instantly with hands).

Edit: If you succeed, we could make a wiki page for the mod, containing the necessary change (provided you want to share them).

@ggtank

Right now i would make it build 793. We will make a release somewhat soon (weekend ~ really). Until then we will go through a list of fixes and a few checks to alter/add. The latter are more prone to introduce problems, but they will be new checks (packet level, maybe one in the fight section, the fight.speed check will likely be removed for 1.8).

@HubToo

Cauldron + xyz mod ... we can't support all mods out of the box, maybe we can help with configuration, but we can't guarantee that all checks are usable with all mods.

Some of the checks naming may be misleading.

• The "creativefly" check monitors flying players, which is not restricted to creative mode. Flying speed in survival mode can matter, but even in creative mode cheaters could create a huge server load if not crash it. That's why we provide limits there. So if you want to fly faste (which game mode?), you can set the speed modifiers higher in the configuration.
• The survivalfly check monitors normal moving in terms of "no flying". If your mod reports different block shapes or if there are unknown blocks, there might be problems with walking on those. In fact the mod might change all moving, or just miss out firing events that are to be in Bukkit servers. Our checks are optimized for the vanilla server and its capabilities.

The block flags part is part-explainen here:
https://github.com/asofold/NCPDocs/blob/master/wiki/configuration/compatibility/..%2F..%2Fdevelopment%2Fdev-pinboard.creole#overrideflags

How many blocks is it about ?

What do you mean with the "generic checks section" ? We are currently reworking the wiki in the background to bring it up to date, but what else do you need to adjust?

@chrishillz

We don't recommend banning automatically in general, thus we could only assist with questions about individual checks, probably IRC (spigot) is a better place to exchange experience with such, it's also somewhat crowded.

Concerning kicking, IRC might also be better, because checks have different kinds of false positives. It's thinkable that we provide a strict config with kicking some day, but currently too many things change, so it'll not happen soon.

@edcsg

You can send a PM with BukkitDev? The "ncp version" command would print output to where you run it from (e.g. console, best to copy test) - if you run the NCP development build 787, the version information will also be printed in the nocheatplus.log.

@edcsg

That's because the swimmingspeed modifier is meant to modify the horizontal speed of swimming :p, not the vertical speed for jumping out of the water.

I assume there is no jump-potion effect involved, but that with Cauldron maybe the water block shape can't be interpreted by NCP.

Can you post the full output of the "ncp version" command? There is more information contained than plugin and server versions, i am interestd in the MCAccess part right now (if you post the full output. we don't need to ask back too much).

Seems there has been a ticket for Cauldron/1.7.2 already (Ticket 791). Last time we checked the moving events of Cauldron were producing totaly different output to CraftBukkit/Spigot + vanilla clients, but for jumping out of water we might examine the MCAccess version.

@MasterMithrandir

• Xray: I do recommend Orebfuscator or anything that tracks such.
• Anti tracer: i would in general recommend too (lower the entity range settings in spigot, some hiding players approach like PlayersInCubes, some spamming fake stuff approach maybe too, ProtocolLib based also).
• Anti aura - there is multiple aspects, it depends on the chosen approach.
  • Cancelling fighting events means that either plugin might cancel the events, thus the other plugin receives different data and might be rendered inoperable, potentially concerning all checking methods (risk may or may not be low).
  • Methods to spawn fake entities (also players) have already been bypassed by at least one client, it's a matter of time until those are much useless.
  • Currently (1.7.10 + 1.8) some fight checks in NCP are rendered inoperable by â change in CraftBukkit which we overlooked (much fewer attack attempts get put through to Bukkit plugins from then on), affected are at least fight.speed and combined.improbable. We have been planning to change a lot on the fighting checks and now we have to replace even more parts. Some parts might be removed, some might get an equivalent for use with ProtocolLib, some might not be replacable, but we will add new/other checks. That being said, there is more justification for a (temporary) replacement than has been before, not sure there is actually decent replacements ready at present. Our goal is to revamp basics of fight checks until the next weekend. We will (not sure if until next weekend) implement some completely new methods, so fight checks will change around a lot within the next few weeks.

Concerning tracers, i am not sure if we want to implement something there.

• Spawning fake entities: This can be effective if those entities are far away and can't be distinguished from normal entities (occasional fake moving ?) - chances are good that cheat clients will easily detect entities that do nothing or are invisible or appear too close to the player, not moving regularly etc.). So in general i think we won't implement this, which also has the advantage that other plugin developers can excel at this and provide an easy to add thing, which also will not conflict.
• Spigot entity ranges: A good basic measure, hides players if far away. People say it doesn't hide based on vertical distance though. This means best performance in comparison to all other methods - whenever you want to have a maximum distance for seeing someone, this might be an option, at least for an additional thing.
• Using the vanish API (PlayersInCubes): Hides players if far away, also by vertical distance. Drawbacks are the players list might not work (can be fixed by packet sending), commands that rely on the who-can-see-who API, only works for players.
• Using ProtocolLib:
  • We might add a simple thing, as we have to extend much onto the packet level anyway (e.g. prevent sending certain packets to players, if too far away).
  • I could imagine experimenting with a much optimized+simplified ray-tracing approach, for who can see who, but this is a pretty complex task and wouldn't happen anytime soon (unless other developers would love to share technique+effort).

@kangarkooo

I forgot to mention that Ticket 364 is meant to be the point of reference for pistons + moving (even if slime blocks are or will be a special case with pistons).

@Bobcat00

The version detection only attempts to get a result like "1.8.1" to have a rough idea of the Minecraft version in use, hard coded examples. I probably add reflection to ask Minecraft directly, also ProtocolLib.

Some features might also depend on if it is Spigot or CraftBukkit, which then will also be checked for. I rate it more important to prevent enabling of some workarounds that provide overhead or even risk for certain server versions, if the cause for the workarounds has been fixed for that server version. Have you encountered any issues with it?

@edcsg

We tried some mod(s) a while ago and found that they let the players move totally different than CB/spigot with vanilla clients. This is a big problem because our moving checks more or less pinpoint the vanilla behavior, i cannot guarantee that we will be able to fix such within some time frame. In future we might add (potentially simplified) replacement checks for anti-flying, which might then rather check the average speed instead of the exact location-to-location coordinate changes.

That being said, we first need to find out what exactly happens.

• Please tell us the output of the "ncp version" command.
• Do players always have problems with landing in water, or is it just an occasional issue.

If you have time to do this (it can be done on a crafty live server with SSD):

• Can you run development build 786 and create a debug trace?
  • Set the log file name to "logs", then issue the "ncp reload" command.
  • Use "ncp debug playername" with the name of a player who will jump into water a couple of times, reproducing the issue a couple of times.
  • Issue "ncp reload" again to end the debug logging and to switch the log file.
  • Send us the log file (zip or paste).

A workaround for water can be to allow faster moving in water in general (allows a lot of speeding in water!): Add "swimmingspeed: 200" to the survivalfly section of the configuration to allow twice the speed in water (you later check if you lower it).

checks:
  # ....
  moving:
    # ...
    survivalfly:
      swimmingspeed: 200
    # ...

Sorry for the long text, i forgot about the translator :p.