2012-02-01 00:10:14 +01:00
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
################################################################################
|
|
|
|
# #
|
2012-03-09 14:41:27 +01:00
|
|
|
# Important files, config.yml or "clean up your stuff" #
|
2012-02-18 01:16:14 +01:00
|
|
|
# #
|
|
|
|
################################################################################
|
2012-02-01 00:10:14 +01:00
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
1) The config file for NoCheat is called "config.yml" now.
|
2012-02-01 00:10:14 +01:00
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
2) You can have different config files for different worlds. To achieve this,
|
|
|
|
copy the "config.yml" and rename the copy to "worldname_config.yml". Set-
|
|
|
|
tings in that file will now only affect the world with the name "worldname".
|
|
|
|
You may also delete all settings from that world-specific file that you
|
|
|
|
won't use. They'll be implicitly taken from the master "config.yml" file.
|
2012-02-01 00:10:14 +01:00
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
3) If you have files named "config.txt", "default_actions.txt" or "actions.txt"
|
|
|
|
please delete them. They are no longer used by NoCheat and serve no purpose
|
|
|
|
anymore.
|
2012-02-01 00:10:14 +01:00
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
4) Never change the amount of white-spaces in front of options in the config
|
|
|
|
file "config.yml". It will break the configuration.
|
|
|
|
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
# #
|
|
|
|
# How "actions" work, an Overview #
|
|
|
|
# #
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
NoCheat allows to define in detail what should happen when a player fails a
|
|
|
|
check in form of "actions". There are 4 possible things that may be done.
|
|
|
|
(read on to learn in detail on how to define/modify actions):
|
|
|
|
|
|
|
|
cancel: The effects of the action "cancel" depend on the check that it is
|
|
|
|
used for. Usually it means to prevent something from happening,
|
|
|
|
e.g. stop an attack or prevent sending of a chat message.
|
|
|
|
|
|
|
|
log: Create and show/log a message. Log messages can be customized in
|
|
|
|
how often, when and where they are registered/shown.
|
|
|
|
|
|
|
|
cmd: Execute a command of Bukkit or another plugin as if it were typed
|
|
|
|
into the server console by an admin. Like logging, these can be
|
|
|
|
customized.
|
|
|
|
|
|
|
|
vl>X: Is meant to symbolize "violation level at least X". Used to define
|
|
|
|
actions that will be executed only if players reached a certain
|
|
|
|
violation level. Failing a check usually increases their "vl", not
|
|
|
|
failing checks reduces it over time. Violation levels mean different
|
|
|
|
things for different checks, e.g. they may describe moved distance
|
|
|
|
beyond the limit, number of attacks above the attack limit, sent
|
|
|
|
messages beyond the spam limit.
|
|
|
|
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
# #
|
|
|
|
# How to customize your "actions" #
|
|
|
|
# #
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
1) The "cancel" action is just the word "cancel". Read in the detailed option
|
|
|
|
description to find out what it does depending on the check that it is
|
|
|
|
assigned to.
|
|
|
|
|
|
|
|
2) The "log" action is a string of the form "log:string:delay:repeat:target".
|
|
|
|
|
|
|
|
log: is simply used to let NoCheat know it is a log action. Don't remove
|
|
|
|
it from the action, or NoCheat will not know what it is and how to
|
|
|
|
handle it.
|
|
|
|
|
|
|
|
string: is the message that will be logged. Because there is so little
|
|
|
|
space here, you only give a name here and define the actual
|
|
|
|
log message in the "strings" section of the config file.
|
|
|
|
|
|
|
|
delay: a number declaring how many times that action initially has to be
|
|
|
|
executed before it really leads to logging a message. Use this for
|
|
|
|
situations where it's common to have false positives in checks and
|
|
|
|
you only want the log message to be shown if a player fails the
|
|
|
|
check multiple times within a minute.
|
|
|
|
|
|
|
|
repeat: a number declaring how many seconds have to pass after logging the
|
|
|
|
message before it will be logged again for that player. This is
|
|
|
|
needed to prevent "log-spam". Usually a value of 5 seconds is
|
|
|
|
acceptable, for rare events you can use lower values. It is very
|
|
|
|
recommended to at least use the value 1 (one second) here.
|
|
|
|
|
|
|
|
target: where should the message be logged to? You can use three letters
|
|
|
|
here. The order that you use is not important.
|
|
|
|
"c" means logging to console
|
|
|
|
"i" means logging to ingame chat and
|
|
|
|
"f" means logging to the log file.
|
|
|
|
|
|
|
|
3) The "cmd" action is a string of the form "cmd:string:delay:repeat".
|
|
|
|
|
|
|
|
cmd: is simply used to let NoCheat know it is a command action. Don't
|
|
|
|
remove it from the action, or NoCheat will not know what it is and
|
|
|
|
how to handle it.
|
|
|
|
|
|
|
|
string: is the command that will be issued. Because there is so little space
|
|
|
|
here, you only give a name here and define the actual command in the
|
|
|
|
"strings" section of the config file.
|
|
|
|
|
|
|
|
delay: a number declaring how many times that action initially has to be
|
|
|
|
executed before it really leads to running the command in the
|
|
|
|
console. Use this to create e.g. a 3-strikes-law by setting it to 3.
|
|
|
|
Only if a player fails the check 3 times within 1 minute, the
|
|
|
|
command will be really run.
|
|
|
|
|
|
|
|
repeat: a number declaring how many seconds have to pass after running the
|
|
|
|
command before it can be run again for that player. Because many
|
|
|
|
commands are expensive (take time, resources), you may want to limit
|
|
|
|
how often they can be called.
|
|
|
|
|
|
|
|
4) The "vl>" isn't really an action. It limits all actions that are written
|
|
|
|
afterwards to be only executed if the players violation level has reached
|
|
|
|
at least the given value. This allows to define layers of actions and
|
|
|
|
handle repeated or severe failing of checks different. For example the spam
|
|
|
|
check will only kick players if they reach a certain violation level (vl).
|
|
|
|
|
|
|
|
|
2012-02-20 18:35:18 +01:00
|
|
|
################################################################################
|
|
|
|
# #
|
|
|
|
# Permissions #
|
|
|
|
# #
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
|
|
NoCheat only supports "SuperPerms", CraftBukkits official permission framework.
|
|
|
|
You'll need to use a permissions plugin that supports "SuperPerms" to use it
|
|
|
|
with NoCheat. Here are some I know of:
|
|
|
|
|
|
|
|
- bPermissions
|
|
|
|
- PermissionsEx
|
|
|
|
- Essentials GroupManager
|
|
|
|
|
|
|
|
I personally recommend bPermissions, but any of them will do just fine.
|
|
|
|
|
|
|
|
By default all these permissions are set to "op", which means players with
|
|
|
|
OP-status have all permissions, unless you change it.
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
--------------------------- Permissions for CHECKS -----------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
These permission nodes are grouped the same way as the options in the config
|
|
|
|
file, based on the event type they belong to. The logic is, that a player
|
|
|
|
having one of these nodes means he will NOT be checked. Players without the
|
|
|
|
permission node will be checked.
|
|
|
|
|
|
|
|
Example: A player has permission "nocheat.checks.moving.morepackets". That
|
|
|
|
means he is allowed to use that hack/cheat because NoCheat won't check/stop it.
|
|
|
|
|
|
|
|
|
|
|
|
------------------------ MOVING Permissions for CHECKS -------------------------
|
|
|
|
|
|
|
|
- nocheat.checks.moving.runfly
|
|
|
|
Allows the player to move freely. It also treats the player as if he has
|
|
|
|
the ".flying", ".swimming", ".sneaking" and ".nofall" permission too.
|
|
|
|
|
|
|
|
- nocheat.checks.moving.flying
|
|
|
|
Allows the player to fly, independent of if he is in "creative mode" or not.
|
|
|
|
He will be limited in speed by the config settings "flyingspeedvertical"
|
|
|
|
and "flyingspeedhorizontal". It also treats the player as if he has the
|
|
|
|
".nofall" permission too.
|
|
|
|
|
|
|
|
- nocheat.checks.moving.swimming
|
|
|
|
Allows the player to swim as fast as he is allowed to walk. Normally a
|
|
|
|
player swims slower than he walks and NoCheat prevents faster movement in
|
|
|
|
water.
|
|
|
|
|
|
|
|
- nocheat.checks.moving.sneaking
|
|
|
|
Allows the player to sneak faster than he is allowed to walk. Normally a
|
|
|
|
player sneaks a lot slower than he walks and NoCheat prevents faster
|
|
|
|
movement while sneaking.
|
|
|
|
|
|
|
|
- nocheat.checks.moving.nofall
|
|
|
|
Allows the player to avoid fall damage by using hacks. Normally NoCheat
|
|
|
|
will keep track of a players movement and try to rectify the fall-damage
|
|
|
|
calculations of Minecraft in case they seem to be wrong because of players
|
|
|
|
tricking the server.
|
|
|
|
|
|
|
|
- nocheat.checks.moving.morepackets
|
|
|
|
Allows players to make a lot more movements than normally possible. Doing
|
|
|
|
more movements will result in faster overall movement speed and causes the
|
|
|
|
server to spend a lot of additional time for processing these movements.
|
|
|
|
|
|
|
|
|
|
|
|
-------------------- BLOCKBREAK Permissions for CHECKS -------------------------
|
|
|
|
|
|
|
|
- nocheat.checks.blockbreak.reach
|
|
|
|
Allows the player to break blocks that are further away than usual.
|
|
|
|
|
|
|
|
- nocheat.checks.blockbreak.direction
|
|
|
|
Don't force players to look at the blocks that they try to destroy.
|
|
|
|
|
|
|
|
- nocheat.checks.blockbreak.noswing
|
|
|
|
Don't force players to swing their arm when breaking blocks.
|
|
|
|
|
|
|
|
|
|
|
|
-------------------- BLOCKPLACE Permissions for CHECKS -------------------------
|
|
|
|
|
|
|
|
- nocheat.checks.blockplace.reach
|
|
|
|
Allows the player to place blocks that are further away than usual.
|
|
|
|
|
|
|
|
- nocheat.checks.blockplace.direction
|
|
|
|
Don't force players to look at the blocks that they try to place.
|
|
|
|
|
|
|
|
|
|
|
|
--------------------- INVENTORY Permissions for CHECKS -------------------------
|
|
|
|
|
|
|
|
- nocheat.checks.inventory.drop
|
|
|
|
Don't limit the number of items that a player may drop within a short time
|
|
|
|
|
|
|
|
- nocheat.checks.inventory.instantbow
|
|
|
|
Don't prevent players from shooting their bows instantly without taking the
|
|
|
|
usual time to pull the string back
|
|
|
|
|
|
|
|
- nocheat.checks.inventory.instanteat
|
|
|
|
Don't prevent players from eating their food instantly without taking the
|
|
|
|
usual time to munch on it
|
|
|
|
|
|
|
|
|
|
|
|
----------------------- CHAT Permissions for CHECKS ----------------------------
|
|
|
|
|
|
|
|
- nocheat.checks.chat.spam
|
|
|
|
Don't limit the number of messages and commands that a player may send in a
|
|
|
|
short timeframe
|
|
|
|
|
|
|
|
- nocheat.checks.chat.color
|
|
|
|
Don't filter color codes from messages that get sent by players, allowing
|
|
|
|
them to use colors in their messages.
|
|
|
|
|
|
|
|
|
|
|
|
---------------------- FIGHT Permissions for CHECKS ----------------------------
|
|
|
|
|
|
|
|
- nocheat.checks.fight.direction
|
|
|
|
Don't force players to look at their targets while fighting
|
|
|
|
|
|
|
|
- nocheat.checks.fight.noswing
|
|
|
|
Don't force players to move their arms while fighting
|
|
|
|
|
|
|
|
- nocheat.checks.fight.reach
|
|
|
|
Don't limit the distance for fights
|
|
|
|
|
|
|
|
- nocheat.checks.fight.speed
|
|
|
|
Don't limit the number of attacks that the player can do per second
|
|
|
|
|
|
|
|
- nocheat.checks.fight.godmode
|
|
|
|
Don't prevent the player from keeping the temporary invulnerability that he
|
|
|
|
gets when taking damage
|
|
|
|
|
2012-03-04 17:33:50 +01:00
|
|
|
- nocheat.checks.fight.instantheal
|
|
|
|
Don't prevent the player from accellerating their health generation by
|
|
|
|
food saturation
|
|
|
|
|
2012-02-20 18:35:18 +01:00
|
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
----------------------- Permissions for ADMINISTRATION -------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
- nocheat.admin.chatlog
|
|
|
|
The player will receive log messages that are directed at the "ingame chat"
|
|
|
|
as a normal chat message ingame.
|
|
|
|
|
|
|
|
- nocheat.admin.commands
|
|
|
|
The player gets access to some of the "/nocheat" commands
|
|
|
|
|
|
|
|
- nocheat.admin.reload
|
|
|
|
In combination with "nocheat.admin.commands", the player gets access to the
|
|
|
|
"/nocheat reload" command, which will cause NoCheat to reread its config
|
|
|
|
files.
|
|
|
|
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
---------------------- Things to know about Permissions ------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
NoCheat defines "parent" nodes for all permissions already for you. That means
|
|
|
|
you can use one of the following:
|
|
|
|
|
|
|
|
- nocheat
|
|
|
|
- nocheat.admin
|
|
|
|
- nocheat.checks
|
|
|
|
- nocheat.checks.moving
|
|
|
|
- nocheat.checks.blockbreak
|
|
|
|
- nocheat.checks.blockplace
|
|
|
|
- nocheat.checks.inventory
|
|
|
|
- nocheat.checks.chat
|
|
|
|
- nocheat.checks.fight
|
|
|
|
|
|
|
|
To give a player all the permissions that start with that permission node.
|
|
|
|
|
|
|
|
Especially you don't have to and should not use ".*" anywhere when defining
|
|
|
|
NoCheat permissions.
|
2012-02-23 14:03:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
You can exclude a specific player from getting logged by appending ".silent"
|
|
|
|
to the relevant permission node of the specific check. E.g.
|
|
|
|
|
|
|
|
- nocheat.checks.moving.nofall.silent
|
|
|
|
|
|
|
|
will prevent NoCheat from recording log messages for that player for the
|
|
|
|
"nofall" check, while still executing all other actions as usual. These silent
|
|
|
|
permissions won't show up elsewhere, e.g. when using the "nocheat permlist"
|
|
|
|
command.
|
2012-02-20 18:35:18 +01:00
|
|
|
|
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
################################################################################
|
|
|
|
# #
|
|
|
|
# All available config settings #
|
|
|
|
# #
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
Here you'll find the whole list of settings that you can manipulate in the
|
|
|
|
config.yml file. It is further split into logical sections
|
|
|
|
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
-------------------------------- LOGGING Section -------------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
Everything that in general has to do with controlling NoCheats logging can be
|
|
|
|
found at this part of the config.yml
|
2012-02-01 00:10:14 +01:00
|
|
|
|
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
Should messages get logged at all. If you are not interested in messages,
|
2012-02-18 01:16:14 +01:00
|
|
|
set this to false and you'll hear and see (almost) nothing of NoCheat.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
prefix:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
Will be placed in front of many log messages. To get colors, use "&"
|
|
|
|
followed by a number (0-9) or a letter (A-F). E.g. "&7NC&f:" would produce
|
|
|
|
the letters NC in red (&7), followed by black text (&f).
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
filename:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
The name of the logfile that NoCheat will use to log its messages. The
|
|
|
|
default name is "nocheat.log", but you can use a different one if you want
|
|
|
|
to.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
file:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
Should the logfile be used at all. Set to false if you don't want to use
|
|
|
|
the logfile. By default the logfile will be used (true).
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
console:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
Should the server console be used to display messages. Set to false if you
|
|
|
|
don't want NoCheat to show messages related to checks in the console. Error
|
|
|
|
messages may still get displayed there though.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
ingamechat:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
Should NoCheat display messages in the ingame chat? Set to false if you
|
|
|
|
don't want NoCheat to show messages ingame. The messages will only be seen
|
|
|
|
by players with the permission node "nocheat.admin.chatlog" or if you don't
|
|
|
|
use a permissions plugin, by players who are OP.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
showactivechecks:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
Should NoCheat display lists of checks that are enabled for each world. Set
|
|
|
|
to true if you are unsure that your (multiworld) setup of the config files
|
|
|
|
is done correctly.
|
|
|
|
|
2012-02-03 16:49:03 +01:00
|
|
|
debugmessages:
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
Should some additional messages be displayed in the server console, e.g.
|
|
|
|
about NoCheat encountering lag. The displayed messages may change from
|
|
|
|
version to version. This is deactivated by default.
|
|
|
|
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
-------------------------------- CHECKS Section --------------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
Everything that in has to do with the various checks that NoCheat runs on the
|
|
|
|
players. Use these to specify what will be done, how it will be done and what
|
|
|
|
happens if somebody fails checks.
|
|
|
|
|
|
|
|
|
|
|
|
----------------------------- INVENTORY Subsection -----------------------------
|
|
|
|
|
|
|
|
Checks that at least technically have to do with the inventory or usage of
|
|
|
|
items can be found here.
|
|
|
|
|
|
|
|
1) DROP:
|
|
|
|
|
|
|
|
The "inventory.drop" check. It limits how many separate items a player can
|
|
|
|
drop onto the ground within a specific time. Dropping a lot of separate
|
|
|
|
items at once can cause lag on the server, therefore this check exists.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should the check be enabled. Set to false if you are not interested in
|
|
|
|
this at all
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
time:
|
2012-02-18 01:16:14 +01:00
|
|
|
Over how many seconds should dropped items be counted, before the
|
|
|
|
counter gets reset and starts at zero again.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
limit:
|
2012-02-18 01:16:14 +01:00
|
|
|
How many items may be dropped in the timeframe that is specified by
|
|
|
|
the "time" setting. Please consider that dying causes a player to drop
|
|
|
|
up to 36 separate items (stacks). Therefore this value shouldn't be
|
|
|
|
set below ~50.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen when a player goes beyond the set limit. Default
|
|
|
|
settings log a message and kick the player from the server. The VL of
|
|
|
|
the drop check symbolizes how many items a player dropped beyond the
|
|
|
|
set limit. If the limit is 100 and he tried to drop 130, he will have a
|
|
|
|
Violation Level of 130 - 100 = 30.
|
|
|
|
|
|
|
|
2) INSTANTBOW:
|
|
|
|
|
|
|
|
Players may attack extremely fast and with a fully charged bow without
|
|
|
|
waiting for it to be fully pulled back. This is a significant advantage in
|
|
|
|
PvP and PvE combat.
|
|
|
|
|
2012-02-08 22:23:13 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for this behavior. Set to false if you don't
|
|
|
|
care about players using bows faster than normally possible.
|
|
|
|
|
2012-02-08 22:23:13 +01:00
|
|
|
actions:
|
|
|
|
What should happen if the player fails this check. Default is to stop
|
2012-02-18 01:16:14 +01:00
|
|
|
the attack ("cancel" it) and log messages. The Violation Level (VL) for
|
|
|
|
this check the time difference between how long it took the player to
|
|
|
|
fire an arrow and how long NoCheat thinks he should have taken, in
|
|
|
|
1/10 seconds. Therefore a VL of 10 would mean that the player shot an
|
|
|
|
arrow 1 second faster than NoCheat expected. The VL gets increased with
|
|
|
|
every failed check and slowly decreased for every passed check.
|
|
|
|
|
|
|
|
3) INSTANTEAT:
|
|
|
|
|
|
|
|
Players may eat various kinds of food instantly instead of waiting the
|
|
|
|
usual time munching on the item.
|
|
|
|
|
2012-02-08 22:23:13 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for this behavior. Set to false if you don't
|
|
|
|
care about players eating their food faster than normally possible.
|
|
|
|
|
2012-02-08 22:23:13 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if the player fails this check. Default is to stop
|
|
|
|
the eating ("cancel" it) and log messages. The Violation Level (VL) for
|
|
|
|
this check the time difference between how long it took the player to
|
|
|
|
eat his food and how long NoCheat thinks he should have taken, in
|
|
|
|
1/10 seconds. Therefore a VL of 10 would mean that the player ate his
|
|
|
|
food 1 second faster than NoCheat expected. The VL gets increased with
|
|
|
|
every failed check and slowly decreased for every passed check.
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------ MOVING Subsection -------------------------------
|
|
|
|
|
|
|
|
Checks that at least technically have to do with the player moving around or
|
|
|
|
impacting the world with his movement can be found here.
|
|
|
|
|
|
|
|
1) RUNFLY:
|
|
|
|
|
|
|
|
Players may move in illegal ways (flying, running too fast) or try to
|
|
|
|
trick the server into thinking that they are not falling/flying by
|
|
|
|
cleverly manipulating the data that they send to the server.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players get checked for this type of movement related hacks at
|
|
|
|
all. If deactivated, player may freely move around on the server, fly
|
|
|
|
or run really fast.
|
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
walkspeed:
|
2012-02-18 01:16:14 +01:00
|
|
|
How fast should the player be allowed to walk. Default is "100",
|
|
|
|
meaning 100% of normal walking speed. You will not see this option in
|
|
|
|
your config.yml file, because normally you shouldn't have to change the
|
|
|
|
walking speed of players at all (NoCheat knows when players sprint, use
|
|
|
|
Swiftness potions etc and will already adapt the speed based on that
|
|
|
|
data).
|
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
sprintspeed:
|
2012-02-18 01:16:14 +01:00
|
|
|
How fast should the player be allowed to sprint. Default is "100",
|
|
|
|
meaning 100% of normal sprinting speed. You will not see this option in
|
|
|
|
your config.yml file, because normally you shouldn't have to change the
|
|
|
|
sprinting speed of players at all (NoCheat knows when players sprint,
|
|
|
|
use Swiftness potions etc and will already adapt the speed based on
|
|
|
|
that data).
|
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
sneakspeed:
|
2012-02-18 01:16:14 +01:00
|
|
|
How fast should the player be allowed to sneak. Default is "100",
|
|
|
|
meaning 100% of normal sneaking speed. You will not see this option in
|
|
|
|
your config.yml file, because normally you shouldn't have to change the
|
|
|
|
sneaking speed of players at all (NoCheat knows when players sprint,
|
|
|
|
use Swiftness potions etc and will already adapt the speed based on
|
|
|
|
that data).
|
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
swimspeed:
|
2012-02-18 01:16:14 +01:00
|
|
|
How fast should the player be allowed to swim. Default is "100",
|
|
|
|
meaning 100% of normal swimming speed. You will not see this option in
|
|
|
|
your config.yml file, because normally you shouldn't have to change the
|
|
|
|
swimming speed of players at all (NoCheat knows when players sprint,
|
|
|
|
use Swiftness potions etc and will already adapt the speed based on
|
|
|
|
that data).
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
allowfastsneaking:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should sneaking players be allowed to move as fast as normal players.
|
|
|
|
Set this to true, if you use plugins that enable players to do that
|
|
|
|
(e.g. the "Heroes" plugin or other RPG plugins tend to do that)
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen when a player sneaks/swims/walks/runs faster than
|
|
|
|
normally allowed or is flying. Default is to log messages (depending on
|
|
|
|
how severe the cheating is) and teleport the player to the last known
|
|
|
|
legitimate location on ground that NoCheat can remember for that player
|
|
|
|
("cancel" the movement)
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
checknofall:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for a common type of "nofall" hack, that
|
|
|
|
allows them to avoid taking damage when falling. If you don't care
|
|
|
|
about fall damage, you can deactivate this. It gets deactivated if a
|
|
|
|
player is allowed to fly (see some lines below), because it doesn't
|
|
|
|
make sense to allow flying and then hurt players when they land.
|
|
|
|
|
2012-02-05 21:39:02 +01:00
|
|
|
nofallaggressivemode:
|
2012-02-18 01:16:14 +01:00
|
|
|
Enable an improved version of nofall check, that will catch additional
|
|
|
|
types of "nofall" hacks and deal damage to players directly. This is
|
|
|
|
usually safe to activate. It will only work if the "checknofall" is
|
|
|
|
also set to "true".
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
nofallactions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if a player is considered to be using a "nofall"
|
|
|
|
hack. Default reaction is to log a message and encourage Bukkit to deal
|
|
|
|
fall damage anyway ("cancel" the hack). The Violation Level is the
|
|
|
|
fall distance in blocks that the player tried to avoid. It gets
|
|
|
|
increased every time that the player fails the check, and decreased
|
|
|
|
over time if the player doesn't fail the check.
|
|
|
|
|
|
|
|
FLYING:
|
|
|
|
This is an entire subsection dedicated to the "moving.flying" check.
|
|
|
|
It will be used instead of the "runfly" check whenever a player has
|
|
|
|
the right to fly.
|
|
|
|
|
|
|
|
allowflyingalways:
|
|
|
|
Should all players be allowed to fly always.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
allowflyingincreative:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players that are set to "creative mode" be allowed to fly. If
|
|
|
|
they are already allowed because of "allowflyingalways" to fly, this
|
|
|
|
setting gets ignored.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
flyingspeedlimithorizontal:
|
2012-02-18 01:16:14 +01:00
|
|
|
How many 1/100 blocks may a player fly horizontal within one "step".
|
|
|
|
The official "creative mode" flying reaches speeds of about 0.6
|
|
|
|
blocks which means a value of 60 here.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
flyingspeedlimitvertical:
|
2012-02-18 01:16:14 +01:00
|
|
|
How many 1/100 blocks may a player fly vertically up within one
|
|
|
|
"step". A value of 100 which means 1 block seems reasonable for most
|
|
|
|
cases.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
flyingheightlimit:
|
2012-02-18 01:16:14 +01:00
|
|
|
What is the maximum height (in blocks) that a player may reach by
|
2012-03-02 16:12:15 +01:00
|
|
|
flying, relative to the max world height he is in. Some servers
|
|
|
|
experience lag when players fly very, very high. This value is how
|
|
|
|
far above the map height a player may fly.
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
|
|
|
What should happen if a player flies faster/higher than defined here?
|
2012-02-18 01:16:14 +01:00
|
|
|
Default is to log messages and to prevent the player from moving
|
|
|
|
("cancel" his last movement). The Violation Level (VL) of this check
|
|
|
|
is the distance that the player went beyond what NoCheat allowed him.
|
|
|
|
The VL increases with every failed check and slowly decreases for
|
|
|
|
every passed check.
|
|
|
|
|
|
|
|
2) MOREPACKETS:
|
|
|
|
|
|
|
|
The morepackets check is complementary to the "runfly" check. While the
|
|
|
|
"runfly" check(s) limit the distance a player can move per step, this
|
|
|
|
"morepackets" check limits the number of "steps" a player may take per
|
|
|
|
second. A normal value is 20 steps per second.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for this kind of cheating. If you are not
|
|
|
|
interested in players that cheat that way, set this to false. It is a
|
|
|
|
good idea to have this active, because players that cheat by sending
|
|
|
|
more packets than normally allowed may lag the server (each of those
|
|
|
|
packets has to be processed, after all).
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if a player is considered to be cheating by taking
|
|
|
|
more steps per second than normal. Default is to log messages and
|
|
|
|
teleport the player back to a location where he was ~1 second before
|
|
|
|
("cancel" his movement). The Violation Level VL is the number of
|
|
|
|
packets that the player sent beyond the expected amount
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------- BLOCKBREAK Subsection -----------------------------
|
|
|
|
|
|
|
|
Checks that at least technically have to do with the player breaking blocks.
|
|
|
|
|
|
|
|
1) REACH:
|
|
|
|
|
|
|
|
Players may slightly increase the distance at which they can break
|
|
|
|
blocks. This check will try to identify that by comparing player and
|
|
|
|
block location.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for this behaviour.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if the player is considered to cheat this way. The
|
|
|
|
default is to prevent him from breaking the block ("cancel" breaking)
|
|
|
|
and on repeated offenses to log messages about it. The Violation Level
|
|
|
|
(VL) is the distance in Blocks between the reach distance that NoCheat
|
|
|
|
allowed and what the player actually tried to use. The VL increases
|
|
|
|
with every failed attempt to break a block out of reach, and decreases
|
|
|
|
with every successful attempt.
|
|
|
|
|
|
|
|
2) DIRECTION:
|
|
|
|
|
|
|
|
Players may break blocks without really looking at them. This is often
|
|
|
|
combined with breaking a lot of blocks surrounding the player at the same
|
|
|
|
time.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
|
|
|
Should players get checked for this type of hack
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
precision:
|
2012-02-18 01:16:14 +01:00
|
|
|
How strict should NoCheat be when comparing the players line of view
|
|
|
|
with the broken block location. The value represents (roughly) the
|
|
|
|
amount of 1/100 blocks that the player is allowed to look past the to
|
|
|
|
be broken block. 50 (0.5 blocks) seems a good default value.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
penaltytime:
|
2012-02-18 01:16:14 +01:00
|
|
|
If a player fails this check, how long should he be prevented from
|
|
|
|
breaking blocks afterwards, in milliseconds. This is intended to make
|
|
|
|
automated destruction of blocks harder. 0.3 seconds (value 300) is the
|
|
|
|
default. Set to 0, if you don't want to limit players at all after
|
|
|
|
failing this check.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if a player fails this check. Default is to prevent
|
|
|
|
the breaking of the block ("cancel" it) and after repeated/more severe
|
|
|
|
offenses to log a message. The Violation Level (VL) for this check is
|
|
|
|
the distance in Blocks between the line of view of the player and the
|
|
|
|
block. It increases with every failure and decreases with every
|
|
|
|
successful block break.
|
|
|
|
|
|
|
|
3) NOSWING:
|
|
|
|
|
|
|
|
Players may break blocks without moving their arm. This is confusing for
|
|
|
|
nearby players, as they won't see who broke the blocks.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
|
|
|
Should players get checked for this type of hack
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if the player didn't swing his arm first? Default is
|
|
|
|
to log a message and prevent the breaking of the block ("cancel" it).
|
|
|
|
The Violation Level (VL) is the number of block-break attempts without
|
|
|
|
first swinging the arm. It increases with every failed attempt by 1 and
|
|
|
|
decreases with every successful attempt slowly.
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------- BLOCKPLACE Subsection -----------------------------
|
|
|
|
|
|
|
|
Checks that at least technically have to do with the player placing blocks.
|
|
|
|
|
|
|
|
1) REACH:
|
|
|
|
|
|
|
|
Players may slightly increase the distance at which they can place
|
|
|
|
blocks. This check will try to identify that by comparing player and
|
|
|
|
block location.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for this behaviour.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if the player is considered to cheat this way. The
|
|
|
|
default is to prevent him from placing the block ("cancel" placing)
|
|
|
|
and on repeated offenses to log messages about it. The Violation Level
|
|
|
|
(VL) is the distance in Blocks between the reach distance that NoCheat
|
|
|
|
allowed and what the player actually tried to use. The VL increases
|
|
|
|
with every failed attempt to place a block out of reach, and decreases
|
|
|
|
with every successful attempt.
|
|
|
|
|
|
|
|
2) DIRECTION:
|
|
|
|
|
|
|
|
Players may place blocks without really looking at them. This is often
|
|
|
|
combined with placing a lot of blocks in a certain shape.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players get checked for this type of hack
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
precision:
|
2012-02-18 01:16:14 +01:00
|
|
|
How strict should NoCheat be when comparing the players line of view
|
|
|
|
with the placed block location. The value represents (roughly) the
|
|
|
|
amount of 1/100 blocks that the player is allowed to look past the to
|
|
|
|
be placed block. 75 (0.75 blocks) seems a good default value.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
penaltytime:
|
2012-02-18 01:16:14 +01:00
|
|
|
If a player fails this check, how long should he be prevented from
|
|
|
|
placing blocks afterwards, in milliseconds. This is intended to make
|
|
|
|
automated placing of blocks harder. 0.1 second (value 100) is the
|
|
|
|
default. Set to 0, if you don't want to limit players at all after
|
|
|
|
failing this check.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if a player fails this check. Default is to prevent
|
|
|
|
the placing of the block ("cancel" it) and after repeated/more severe
|
|
|
|
offenses to log a message. The Violation Level (VL) for this check is
|
|
|
|
the distance in Blocks between the line of view of the player and the
|
|
|
|
block. It increases with every failure and decreases with every
|
|
|
|
successful block placement.
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------- CHAT Subsection --------------------------------
|
|
|
|
|
|
|
|
Checks that at least technically have to do with chat or commands.
|
|
|
|
|
|
|
|
1) COLOR:
|
|
|
|
|
|
|
|
Players may use color-codes to send colored messages. This may be used
|
|
|
|
to fool other players into believing they are admins or similar.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should player messages get checked for the use of color codes.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
|
|
|
What should be done if a player sends messages with color codes.
|
|
|
|
Default is to log a message and prevent ("cancel") the use of the
|
2012-02-18 01:16:14 +01:00
|
|
|
color codes, by filtering them from the message. The message itself
|
|
|
|
will still be transmitted. The Violation Level (VL) for this check is
|
|
|
|
the number of messages that contained color codes. It increases with
|
|
|
|
each color-code message by 1 and decreases slowly with colorless
|
|
|
|
messages.
|
|
|
|
|
|
|
|
2) SPAM:
|
|
|
|
|
|
|
|
Players may send a ton of messages/commands in a short time to cause
|
|
|
|
lag or even crash a server.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should player messages get checked for sending of too many messages.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
whitelist:
|
2012-02-11 21:28:56 +01:00
|
|
|
A " " (whitespace) separated list of words. Messages that start with
|
2012-02-18 01:16:14 +01:00
|
|
|
these sequences will not be counted. This is ideal to exempt commands
|
|
|
|
from getting filtered, by e.g. adding "/help" to the list.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
timeframe:
|
2012-02-18 01:16:14 +01:00
|
|
|
For how many seconds should messages and commands be counted, before
|
|
|
|
the counters get reset and counting starts at zero again.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
messagelimit:
|
2012-02-18 01:16:14 +01:00
|
|
|
How many "normal" chat messages may be sent within the timeframe. All
|
|
|
|
messages that don't start with "/" are considered "normal".
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
commandlimit:
|
|
|
|
How many commands may be issued within the timeframe. Some mods (e.g.
|
2012-02-11 21:28:56 +01:00
|
|
|
TooManyItems) send a command on every mouse-click, which may cause
|
2012-02-18 01:16:14 +01:00
|
|
|
problems if this is set too low. So choose wisely. Every message that
|
|
|
|
starts with "/" is considered a command, even if the command doesn't
|
|
|
|
exist.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if players send more messages/commands than declared
|
|
|
|
by the above limits? Default is to prevent the message/command from
|
|
|
|
being processed ("cancel" them) and for severe cases where players send
|
|
|
|
a lot of messages/commands, kick them. The Violation Level (VL) is the
|
|
|
|
number of messages/commands that were sent beyond the specified limits.
|
|
|
|
It gets increased for every message/command by 1 and reset to zero when
|
|
|
|
the "timeframe" has passed.
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------ FIGHT Subsection --------------------------------
|
|
|
|
|
|
|
|
Checks that at least technically have to do with direct combat.
|
|
|
|
|
|
|
|
1) DIRECTION:
|
|
|
|
|
|
|
|
Players may attack other players and creatures without really looking at
|
|
|
|
them. This is often combined with automatically attacking every living
|
|
|
|
thing within reach ("kill-aura"). This check will check if the attacker
|
|
|
|
looks at his target.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players get checked for this type of hack
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
precision:
|
2012-02-18 01:16:14 +01:00
|
|
|
How strict should NoCheat be when comparing the players line of view
|
|
|
|
with the his target's location. The value represents (roughly) the
|
|
|
|
amount of 1/100 blocks that the player is allowed to look past the to
|
|
|
|
be attacked entity. 75 (0.75 blocks) seems a good default value.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
penaltytime:
|
2012-02-18 01:16:14 +01:00
|
|
|
If a player fails this check, how long should he be prevented from
|
|
|
|
attacking stuff afterwards, in milliseconds. This is intended to make
|
|
|
|
automated attacking of enemies harder. 0.5 second (value 500) is the
|
|
|
|
default. Set to 0, if you don't want to limit players at all after
|
|
|
|
failing this check.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if a player fails this check. Default is to prevent
|
|
|
|
the attack from happening ("cancel" it) and after repeated/more severe
|
|
|
|
offenses to log a message. The Violation Level (VL) for this check is
|
|
|
|
the distance in Blocks between the line of view of the player and the
|
|
|
|
target. It increases with every failure and decreases with every
|
|
|
|
successful attack.
|
|
|
|
|
|
|
|
2) NOSWING:
|
|
|
|
|
|
|
|
Players may attack entities without moving their arm. This is confusing
|
|
|
|
for nearby players, as they won't see who is attacking them or the nearby
|
|
|
|
creatures.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players get checked for this type of hack
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if the player didn't swing his arm first? Default is
|
|
|
|
to log a message and prevent the attack from happening ("cancel" it).
|
|
|
|
The Violation Level (VL) is the number of attacking attempts without
|
|
|
|
first swinging the arm. It increases with every failed attempt by 1 and
|
|
|
|
decreases with every successful attempt slowly.
|
|
|
|
|
|
|
|
3) REACH:
|
|
|
|
|
|
|
|
Players may slightly increase the distance at which they can attack enemy
|
|
|
|
creatures/players. This check will try to identify that by comparing
|
|
|
|
player and target location.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-18 01:16:14 +01:00
|
|
|
Should players be checked for this behaviour.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
distance:
|
2012-02-18 01:16:14 +01:00
|
|
|
How far can the enemy be away from the attacker, in 1/100 Blocks. The
|
|
|
|
default value of 400, which is 4.00 blocks seems to work fine most of
|
|
|
|
the time. Increase if you get to many false positives to e.g. 425 or
|
|
|
|
450.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
penaltytime:
|
2012-02-18 01:16:14 +01:00
|
|
|
If a player fails this check, how long should he be prevented from
|
|
|
|
attacking stuff afterwards, in milliseconds. This is intended to make
|
|
|
|
automated attacking of enemies harder. 0.5 second (value 500) is the
|
|
|
|
default. Set to 0, if you don't want to limit players at all after
|
|
|
|
failing this check.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
2012-02-18 01:16:14 +01:00
|
|
|
What should happen if the player is considered to cheat this way. The
|
|
|
|
default is to prevent him from attacking the target ("cancel" attack)
|
|
|
|
and on repeated offenses to log messages about it. The Violation Level
|
|
|
|
(VL) is the distance in Blocks between the reach distance that NoCheat
|
|
|
|
allowed and what the player actually tried to use. The VL increases
|
|
|
|
with every failed attempt to attack enemies out of reach, and decreases
|
|
|
|
with every successful attempt.
|
|
|
|
|
|
|
|
4) SPEED:
|
|
|
|
|
|
|
|
Players may be attacking extremely fast within a short time by using
|
|
|
|
automated clicking or hacks. This is an advantage in many situations.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
active:
|
2012-02-11 21:28:56 +01:00
|
|
|
Should players be checked for this behavior.
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
attacklimit:
|
|
|
|
How many attacks may a player start within 1 second. Consider setting
|
|
|
|
this to a value that's close to how fast you believe players can click
|
2012-02-18 01:16:14 +01:00
|
|
|
their mouse. The default is 15 per second.
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
actions:
|
|
|
|
What should happen if the player fails this check. Default is to stop
|
2012-02-18 01:16:14 +01:00
|
|
|
the attack ("cancel" it) and log messages. The Violation Level (VL) is
|
|
|
|
the number of attacks beyond the set limit. For each failed check it
|
|
|
|
is increased by 1 and it gets decreased for every successful attack.
|
|
|
|
|
|
|
|
5) GODMODE:
|
|
|
|
|
|
|
|
Players may trick Bukkit into not dealing them damage when they get
|
|
|
|
attacked. This will try to identify and correct that behavior.
|
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
active:
|
|
|
|
Should players be checked for this behavior.
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
actions:
|
|
|
|
What should happen if the player fails this check. Default is to make
|
2012-02-18 01:16:14 +01:00
|
|
|
him vulnerable to the attack ("cancel" his "godmode") and log messages.
|
|
|
|
The Violation Level (VL) for this check is the number of ticks that the
|
|
|
|
player seemingly tried to stay invulnerable. A second has 20 ticks.
|
|
|
|
Every time the player fails the check, the VL gets increased by the
|
|
|
|
amount of ticks (but at most 15 per failed check), and everytime the
|
|
|
|
player didn't avoid taking damage it gets reduced slowly.
|
|
|
|
|
2012-03-04 17:33:50 +01:00
|
|
|
6) INSTANTHEAL:
|
|
|
|
|
|
|
|
Players may trick Bukkit into regenerating their health faster when they
|
|
|
|
are satiated (full food bar) than normally possible. This will try to
|
|
|
|
identify and correct that behaviour.
|
|
|
|
|
|
|
|
active:
|
|
|
|
Should players be checked for this behavior.
|
|
|
|
|
|
|
|
actions:
|
|
|
|
What should happen if the player fails this check. Default is to not
|
|
|
|
allow the health regeneration ("cancel" the regeneration) and log a
|
|
|
|
message. The Violation LEvel (VL) for this check is the number of
|
|
|
|
seconds that the player tried to skip while regenerating health. It
|
|
|
|
gets reduced whenever the player regenerates health while obeying the
|
|
|
|
normal regeneration times.
|
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
------------------------------- STRINGS Section --------------------------------
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
This is the section that defines various strings for "log" or "cmd" actions.
|
2012-02-18 01:16:14 +01:00
|
|
|
Each has a name (the part in front of ":") and a definition (the part behind
|
|
|
|
the ":"). Whenever you use a "log" or "cmd" action in one of the "actions: "
|
|
|
|
options of this config file, the string will be taken from this section.
|
|
|
|
Arbitrary many additional strings may be defined here, or existing strings
|
|
|
|
may be changed.
|
|
|
|
|
2012-02-11 21:28:56 +01:00
|
|
|
Most messages/commands use place-holders in [ ], which will be replaced at
|
2012-02-01 00:10:14 +01:00
|
|
|
runtime with relevant information. Some of these may only be available in
|
|
|
|
certain circumstances, only "[player]" can be used everywhere, especially
|
|
|
|
in "cmd" actions.
|
|
|
|
|
2012-02-18 01:16:14 +01:00
|
|
|
|
|
|
|
################################################################################
|
|
|
|
# #
|
|
|
|
# Other noteworthy stuff, DONATIONS #
|
|
|
|
# #
|
|
|
|
################################################################################
|
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
|
|
|
|
- NoCheat isn't perfect and won't prevent all forms of cheating. It's a best
|
|
|
|
effort approach.
|
2012-02-18 01:16:14 +01:00
|
|
|
|
2012-02-01 00:10:14 +01:00
|
|
|
- NoCheat may make mistakes. Don't see everything NoCheat says or does as
|
|
|
|
indisputable fact that somebody cheated. It's not possible to be 100% sure
|
|
|
|
if somebody is cheating or not, NoCheat will try to be right most of the
|
2012-02-18 01:16:14 +01:00
|
|
|
time.
|
|
|
|
|
|
|
|
Thank you for reading this file. It took hours to write it, so it's nice that
|
|
|
|
people actually take a look at it. ;)
|