Bukkit

NoCheat 2.20a has a bug in it that will prevent people from using the chat if you use plugins like xAuth and their "freeze" feature(s).

Use NoCheat 2.20b instead (just uploaded it, should be available very soon).

@asofold

I think I have to give some background info for this. Fall damage in Minecraft works as follows:

The player sends with every movement an "onground" value, telling the server if the player is in the air or touching ground. "nofall" hacks cheat here and send with every movement the player makes "onground=true".

The server measures fall damage by adding the height difference of all moves of a downward moving player, as long as it keeps sending "onground=false", and deals the collected height as fall damage when "onground=true" is sent by the player.

NoCheat does measure the fall distance of a player independent of the "onground" value (because that value can't be trusted) and when it believes that the fall distance measured by the Minecraft server is too low, it will adjust the fall distance to the value it measured itself. NoCheat itself will however never deal any damage to players.

What you most likely see happen is the following:

1. Player uses "nofall" hack setting "onground=true" all the time, jumps off cliff.
2. While falling, the server will not count any fallheight, so server_fallheight stays 0. NoCheat however will count fallheigh and end up with e.g. nocheat_fallheight = 8.
3. Player reaches the water surface. Now NoCheat compares its value with Minecrafts, and spots a significant difference. It will set server_fallheight = 8 because of that and give you a warning message.
4. The player still sends with every move he makes "onground=true", therefore instructing the server to deal him fall damage according to his fallheight
5. Depending on if the player touches the water already at that point or not, the server will say "he is in water, so I won't really deal him any damage" or "he is not in water and sent onground=true, so he must be on land and therefore I deal him damage".

Players dying when landing in deep water is a dead giveaway for players that use a "nofall" hack. Because of how NoCheat and Minecraft work, even if NoCheat makes a mistake when calculating the fallheight and sets it too high, it couldn't damage a player that lands in deep water, as the client will only send "onground=true" when the player already is in the water, and therefore the server will always cancel fall damage.

PS: At least that's the idea. If you think this can't be the reason, can you send me a screenshot of the location where you tried to do that and one of the messages you've got from NoCheat (with the exact values it complained about, you can replace names with placeholders if you want).

NoCheat 2.20a:

• made info of "/nocheat playerinfo" and corresponding API call more verbose (differentiate between flying, running, sneaking, swimming)
• new bugfix "inventory.closebeforeteleports" (default true) which will cleanly close all inventory screens of players when they get teleported, preventing smuggling of items between worlds past plugins and potential duplication in many cases.
• projectiles should no longer be handled by the "fight" checks, even if they are used by players to attack other players

@jamqdlaty

I can't prevent that.

The only reliable way to prevent people from accessing chests is to limit who can open the chest, e.g. with a plugin like "lockette". Relying on walls etc. to prevent people from clicking the chest can never be fully reliable. E.g. people could in your case just use a "freecam" mod to look through the wall and access the chest that way, or just let the wall disappear clientside to only see the chest.

@Zidkon

I already limit blockplacing in two ways in the newer NoCheat versions ("blockplace.direction" check):

1. They must be looking at the block that they build against. E.g. you want to place a block on top of another one, you'll have to look at the lower block to do that.

2. The player has to stand on the correct side of the block. E.g. to build a block ontop of another block, you have to stand a little bit above it to be able to see its top surface. Same goes for all other directions (east, west, north, south, below). You can't stand north of a block and place another block against the south side of it, or be below a block and place another block ontop of it.

At least that's how it should work now.

About the placing of x blocks per second. I believe that's a futile attempt to stop such autobuilding. Either it gets too strict such that normal players get annoyed if because of lag etc. their blocks keep disappearing, or it's too loose and mod writers will just add tiny delays in their blockplacing to avoid detection anyway.

@Baummann1703

Why don't you revoke their VIP status if they are doing that? Making nofly regions is more difficult than it sounds and I have currently no time plan on when I'll add that.

@PhantomFysics

I could probably do that, but the effect of that would end whenever the player leaves the server and then comes back, because NoCheat doesn't persist any per player data.

NoCheat 2.20:

• make NoCheat detect the newer MC 1.0.1 versions (no warning about "unknown" bukkit version on startup)
• new command "/nocheat playerinfo playername [filter]" allows you to see what data NoCheat collected about a player.
• NoCheat API:
• "cc.co.evenprime.bukkit.nocheat.NoCheat: public Map<String, Object> getPlayerData(String playerName);"
• to collect that data about from a different plugin. Data values collected are all String, Integer or Long (whatever makes sense respectively). Data for a player is available for about 1 minute after he left the server, then gets discarded.

The new command "/nocheat playerinfo playername [filter]" allows you to look a bit under the hood of NoCheat. It will display data collected by NoCheat for a specific player, namely when the collecting started (usually when the player logged in or NoCheat got loaded), how often a specific check was failed and how much "violation level" (vl) the player collected in total for failing that check. The data will be available up to 1 minute after the player left the server, then it gets discarded.

I now also provide a somewhat official API method to collect that data. All you need is get a reference to the "NoCheat" plugin (Just like most people already do for the "Permissions" plugin(s)) and then call the method "getPlayerData(String playerName);". It will return a Map of strings and values with the same data that the "playerinfo" command provides.

@naragov

Maybe another plugin blocks flying too. E.g. "towny" can do that to some extent. If you give people the * node, they probably got a permission of that other plugin that allows them to fly.

You can check if NoCheat is blocking the flying of a player by using the command "nocheat permlist playername". It will show what permission nodes NoCheat sees and uses. If those say e.g. "nocheat.checks.moving.flying: true", then that means that the player really has that permission and nocheat will definitely not stop him from flying.

@Zidkon

Bukkit has a builtin /version command. Simply type "/version NoCheat" and you get all the info you'll ever need about it. :)

Yes, I probably could add such a check that counts placed blocks, but I don't know when I'll have time for that.

NoCheat 2.19:

A temporary fix for that ( now ) widespread hack that gives players invulnerability after death and still allows them to attack, break blocks etc. Also, walking on lily pads shouldn't be a problem anymore with NoCheat.

@don4of4

"most" is an understatement. The only thing left active in that config is the chat checks, and those do nothing at all as long as nobody sends a message (and even then, it shouldn't cause any lag)

Do you get any error messages on your console? Usually if people have lag it's the result of something breaking and printing hundreds of lines onto the console.

@w000rm

Added that. New check is "chat.empty" and will kick players by default for sending an empty chat message (as usual, you can change that).

NoCheat 2.18

I removed "godmode" check for now. It is in it's current state just fubar in MC 1.0.0 and I can't find an easy way to fix that. So I'll probably have to rewrite it from scratch in the near future.

Also, another bunch of changes to config file reading and writing, fixing a nullpointer exception and giving additional error messages.