advcfg.yml

#### Reflex Advanced Configuration #####################################
#
#   Welcome here! Looks like you want to change something, am
# I right? Before doing so, please note one thing: all the
# settings were tested a lot to work properly. If Reflex breaks
# after you touched anything, it's YOUR fault.
#
#   For any configuration assistance please private message
# DarksideCode on Spigot, open an issue at go.reflex.rip/bug
# or write us in Discord: g.reflex.rip/discord
#
#   PLEASE REFRAIN FROM TOUCHING ANYTHING WITHOUT SERIOUS REASONS TO!
#
#   Also keep in mind that this is ADVANCED configuration.
# One tweak can break everything. Literally. Even your arm.
#
#   Learn more about Reflex AdvCfg:
#   --> https://g.reflex.rip/advcfg
#
#   Useful links:
#
#       1. Report bugs/false positives/bypasses/console errors/other:
#          --> https://g.reflex.rip/contributing
#          --> https://g.reflex.rip/bug
#
#       2. Reflex Wiki (information about checks, lag accounting, etc):
#          --> https://g.reflex.rip/wiki
#
#       3. Reflex Discord server (quick live support, bug reports, etc):
#          --> https://g.reflex.rip/discord
#
#       4. Reflex on Spigot:
#          --> https://g.reflex.rip/spigot
#
#   With love, Reflex Development Team.
#   © reflex.rip, 2016-2021.
#
########################################################################




########################################################################
# BASIC ADVCFG FILE INFORMATION (META) — its name (a very-very brief
# description), its author (provider) and its version number/string.
#
# MUST BE CHANGED BEFORE THIS ADVCFG GETS USED!
########################################################################
name: 'Default Configuration'
provider: 'Reflex Development Team'
version: '4'




########################################################################
#    THE CONFIGURATION ITSELF
########################################################################

# Advanced KillAura options
ka:

  # Advanced options for component ka.cbd
  #
  #     Combines all other Killaura components and looks at general
  #     violation density. Used to detect "half-legit-half-blatant" hacks.
  #
  # Accuracy:   ★★★★★  (5/5 - awesome)
  # Efficiency: ★★☆☆☆  (2/5 - useful in some cases or for some certain types of cheats)
  cbd:

    # How many violations* does a player need to score within
    # {period} ticks in order to be flagged? This check is used to detect
    # blatant cheaters that are suspected very often but not heavily.
    #
    # * [Each check gives 'individual' (usually dynamic) number of
    #    violations, which also often differs from the one shown in
    #    verbose, because VLs going to ka.cbd and VLs going to player
    #    are different. The basic rule is same, though: the more the
    #    check is trusted, the more violation points it gives.]
    threshold: 35

    # Checking period in ticks*.
    # (!) NO '/REFLEX RELOAD' SUPPORT: requires full server restart to update!
    #
    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]
    period: 600

  # Advanced options for component ka.clk
  #
  #     Monitors players' clicking rates and detects various non-vanilla
  #     behavior, including fast / double-(multiple-) / consistent clicking.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★★☆☆  (3/5 - efficient for certain types of cheats)
  clk:

    # Maximal allowed number of clicks players are allowed to
    # do in one second (20 ticks). Legit jitter is usually ≤ 16
    # (keep in mind that Reflex's CPS calculation is kind of "unusual" and
    # therefore the CPS it shows will be different to CPS shown by CPS meter
    # software/mods; 18+ CPS should be impossible for a legitimate player to
    # get on **Reflex's** click rate meter)
    max_cps: 18

    # Minimal allowed clicking variance. Used to detect consistent click rates.
    # Higher - more strict. Lower - more lenient. 0 - disable the check.
    # NOTE: this check is very stable and is not known to have any false positives.
    min_click_variance: 2

    # Minimal delay that Reflex will enforce between clicks, in milliseconds*.
    # If a player constantly clicks at delays lower than this, then they are
    # very likely to be using double-/triple-/N-click cheats or AutoClicker.
    # For example, clicking with delay of 20 ms is approximately equal to
    # 1000/20 = 50 clicks per second, which is absolutely not legitimate.
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    min_click_delay: 25

  # Advanced options for component ka.heu
  #
  # Uses a neural network with pre-trained (by us, the developers, with
  # help of you, the community) datasets ("samples") to detect a wide
  # range of combat cheats like Aimbot and Killaura/"LegitAura".
  #
  # (i) Settings regarding the Heuristics check do not affect the
  #     core (the NN and datasets) itself, but its "extra" checks
  #     added in release "10.9". Those parts are combined to compute
  #     a CP (Cheat Points) number based on neural network output.
  #     The number of cheat points is always shown in ka.heu verbose
  #     messages like "cp: N". CP is always a natural number, N∈[0..20].
  #     The Heuristics check takes its final decision based both on
  #     NN output and on the number of cheat points, among with some
  #     other factors like lag status and recent behavior of a player.
  #
  # Accuracy:   ★★★☆☆  (3/5 - known to have some false positives in some cases)
  # Efficiency: ★★★★★  (5/5 - awesome)
  heu:

    # If CP number of a player is greater than this (and the core decision
    # is "cheater"), then, no matter the other factors, the player is considered
    # cheating. This means that that player triggered too many "extra" checks
    # at a time and, at the same moment, has been classified as a cheater
    extreme_cp_threshold: 6

    # If the core decision for a player is "cheater", they are not lagging
    # (have a stable/"good" lag status) and have got a number of CP greater
    # then this, then the final decision is going to be "cheater".
    # Does not trigger on players whose lag status is considered "bad"
    stable_cp_threshold: 3

    # If the core decision for a player is "cheater" and moreover the NN
    # is very sure about it (extremely high confidence), and the player's
    # number of CP is greater then then the one set in this option, then
    # the player is considered cheating. High confidence is pretty difficult
    # for a legit player to achieve. When the NN is really "certain" the
    # player is cheating, then most often they really do
    certain_cp_threshold: 2

  # Advanced options for component ka.ra
  #
  #     Monitors many combat behavior aspects of a player and utilizes
  #     a variety of techniques in one to detect practically every KillAura
  #     that gives cheater any significant advantage in fights. Unlike many
  #     other checks, this one should be nearly absolutely accurate and safe.
  #
  # Accuracy:   ★★★★★  (5/5 - awesome)
  # Efficiency: ★★★★☆  (4/5 - pretty efficient, detects many known types of cheats)
  ra:

    # How many hits do players have to do before their combat patterns are analyzed?
    check_time: 10

    # Based on many factors, this check computes average "cheating probability"
    # percent for players' combat. If the computed probability (that is, the
    # likelihood that a particular player has used KillAura in a particular fight)
    # is greater than or equal to this number, they will be given a suspicion and
    # a few violations (but never more than a few tens).
    max_probability: 85.0

    # After how many milliseconds* will ka.ra's suspicions be forgotten?
    # See options above and below as well.
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    suspicion_lifespan: 90000

    # If upon getting a new ka.ra's suspicion player's number of suspicions from this component
    # within the last {suspicion_lifespan} milliseconds is greater than this {threshold}, then
    # this player will be given a lot of violations (enough for an instant kick/punishment).
    # Properly configured, this check will never flag legitimate players enough for a kick.
    threshold: 1

  # Advanced options for component ka.ray
  #
  #     Combines hitbox (attack angle & range), block raytrace (attacking through
  #     non-pierceable blocks), and entity raytrace (attacking through fake client-side
  #     entities/bots) checks. Works by basically raycasting player's direction vector
  #     through the world until the cursor intersects with bounding box of a block or
  #     an entity or until the configured limit of steps is reached. Makes it impossible
  #     to use really blatant KillAura/Reach/Hitbox cheats.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★★★★  (5/5 - awesome)
  ray:

    # Player direction vector multiplier. Smaller numbers will result in slightly more
    # accurate raycasting but will make the process slower (more performance impact).
    raycast_precision: 0.05

    # The number of blocks Reflex should artificially expand hitboxes of entities by.
    # Smaller = stricter, but more false-positives-prone.
    hitbox_expansion: 0.195

    # If the raycast "cursor" did not intersect with any bounding box within the following
    # number of steps (iterations), then the hit will be considered invalid (out of legitimate
    # attack range or player not looking at the target properly).
    max_raycast_steps: 70

    # How many violations should Reflex give to players when they attack
    # an entity out of legitimate range or without looking at it properly?
    hitbox_weight: 1

    # How many violations should Reflex give to players when they attack an
    # entity through a non-pierceable block (such as stone, bricks, etc.)?
    # 0 = disable block raytrace checking.
    block_raytrace_weight: 2

    # How many violations should Reflex give to players when they attack
    # an entity through artificially created invisible bots (fake players)?
    # 0 = disable entity raytrace checking.
    entity_raytrace_weight: 5

    # The maximal number of suspicions a player is allowed to obtain in
    # {suspicion_lifespan} milliseconds before being flagged for cheating.
    # See excessive_violation_weight.
    threshold: 11

    # After how many milliseconds* will ka.ray's suspicions be forgotten?
    # See excessive_violation_weight.
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    suspicion_lifespan: 20000

    # If a player receives more than {threshold} suspicions on any of the ka.ray's
    # subcomponents within {suspicion_lifespan} ms, they will instantly be given the
    # following number of violations.
    excessive_violation_weight: 16

  # Advanced options for component ka.yrt
  #
  #     Looks at players' aiming/rotation style during combat and finds
  #     any suspicious patterns in it, and then computes a "probability of
  #     hacking" using the `{suspicious_rotations} / {total_rotations} * 100
  #     formula. Detects some Aimbots and Killauras very quickly.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★★☆☆  (3/5 - efficient for certain types of cheats)
  yrt:

    # How probable (in percent, %) does a player need to be cheating
    # according to the ka.yrt check in order to be flagged for KillAura
    max_probability: 70




# Advanced BlockActions options
#
# (i) One may want to reduce the values here a little bit in case of many
#     "ultra-professional" players on the server who are "known" (trusted)
#     to be able to build very quickly without any mods, autoclickers, etc.
blckact:

  # Advanced options for component blckact.sfd
  #
  #     Checks for ScaffoldWalk hacks and enforces a bridging speed limit.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★★★★  (5/5 - awesome)
  sfd:

    # Minimal delay between placing blocks when bridging horizontally (in ticks*).
    # Higher - more strict. Lower - more lenient. 0.0 - disable the check.
    #
    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]
    min_hor: 5.0

    # Minimal delay between placing blocks when bridging diagonally (in ticks*).
    # Higher - more strict. Lower - more lenient. 0.0 - disable the check.
    #
    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]
    min_dia: 5.0

    # This option specifies whether Reflex should check players' bridging accuracy or not.
    # It is impossible for most legit players to be absolutely accurate while bridging really
    # quickly. However, if there are many players on your server who claim to be able to bridge
    # really fast without a single mouse drag (which is really difficult), set this to false.
    check_accuracy: true

  # Advanced options for component blckact.tw
  #
  #     Checks for Tower hacks and enforces a towering speed limit.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★★★★  (5/5 - awesome)
  tw:

    # Minimal delay between placing blocks when towering up (in ticks*).
    # Higher - more strict. Lower - more lenient. 0.0 - disable the check.
    #
    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]
    min_tw: 7.5




# Advanced InvActions options
invact:

  # Advanced options for component invact.mov
  #
  #     Prevents cheaters from walking/rotating with open inventory.
  #
  # Accuracy:   ★★★★★  (5/5 - awesome)
  # Efficiency: ★★★★☆  (4/5 - pretty efficient, detects many known types of cheats)
  mov:

    # For how many milliseconds* are players allowed to move and/or
    # rotate with open inventory? Reducing this number will speed
    # detection of InventoryWalk hacks up, but may increase the number
    # of false positives in various situations.
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    open_wait: 500

  # Advanced options for component invact.fiv
  #
  #     Restricts inventory-clicking/chest-looting rates.
  #     Prevents cheaters from using very blatant ChestStealer/AutoLoot hacks.
  #
  #     NOTE: Reflex only counts clicks at items in different slots WITH SOMETHING IN THEM.
  #           Clicking at the same slot OR at slots without items is NOT checked.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★☆☆☆  (2/5 - useful in some cases or for some certain types of cheats)
  fiv:

    # Most checks in Reflex, including the main invact.fiv subcomponent, are packet-based.
    # That is, instead of listening to Bukkit events which provide no proper ways for a smooth
    # lag accounting system, this check only watches packets sent by players and analyzes them.
    # However, due to some changes made to the game protocol in 1.9, it became impossible to
    # create a proper packet-based check on new versions. That's why our nicer (packet) check
    # only works on 1.8x, sadly.
    #
    # In order to provide some basic (though a bit worse) protection for servers running new
    # Minecraft versions, there is also a "classic" (event-based) check in Reflex. This option
    # specifies whether you want to use that check or not. We advise you not to run both packet
    # and event checks concurrently - that's useless and may cause problems.
    #
    # Possible values:
    #
    #     (a) auto  - let Reflex decide for you (RECOMMENDED). The check will be automatically
    #                enabled on 1.9+ and disabled on 1.8x.
    #
    #     (b) true  - enable the event-based invact.fiv check.
    #
    #     (c) false - disable the event-based invact.fiv check.
    #
    # Reflex will self-disable with an error if an invalid value is set here.
    enable_event_check: auto

    # If a player does more than one click in the number of milliseconds* specified below,
    # they will be suspected and given violations. This only affects the event-check, and
    # therefore also requires the event-check to be active (either with 'auto' + 1.9+ server
    # or with 'true' set on the 'enable_event_check' option above).
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    min_event_click_delay: 75

    # If a player does more than one click in the number of ticks* specified below,
    # they will be suspected and given violations.
    #
    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]
    min_click_delay: 2

    # If a player will receive more than {const_clicking_threshold} consistent clicking
    # suspicions within {const_click_lifespan} milliseconds*, they will be given many
    # violations (failing this check 2-3 times is enough to be kicked from the server by default).
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    const_click_lifespan: 2250

    # If a player has clicked more than {const_clicking_threshold} times in a row
    # at an approximately equal ("consistent") rate, they will be given a suspicion.
    # Learn more about this option by reading comment to the one above ('const_click_lifespan').
    const_clicking_threshold: 17




# Advanced AntiKnockback options
vel:

  # Advanced options for component vel.act
  #
  #     This check gives players small random velocities when they open
  #     any inventories (including chests, crafting tables, etc.) and makes
  #     sure they respond with a proper move. If a player did not move
  #     as expected, they are given a suspicion. Receiving more than {threshold}
  #     suspicions within {suspicion_lifespan} ms means that the player is very
  #     likely to be cheating, and therefore they are given a lot of violations
  #     at a time (a number that is enough for instant kick).
  #
  # Accuracy:   ★★★★★  (5/5 - awesome)
  # Efficiency: ★★★☆☆  (3/5 - efficient for certain types of cheats)
  act:

    # Maximal allowed X/Z  distance (in blocks) between knockback locations
    # that Reflex predicts and players' actual knocknack locations
    max_offset: 0.024

    # The maximal number of suspicions a player is allowed to obtain in
    # {suspicion_lifespan} milliseconds before being flagged for cheating
    threshold: 2

    # After how many milliseconds* will vel.act's suspicions be forgotten?
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    suspicion_lifespan: 30000

    # How many ticks* should Reflex wait after "fatal" flags before dealing
    # violations and showing the necessary verbose message(s)? For example,
    # if this is set to 100, and a player scores over {threshold} suspicions
    # in last {suspicion_lifespan} ms, then Reflex will wait 5 seconds before
    # actually notifying about this in verbose and giving that player many
    # violations (kicking them). This option is very recommended to be something
    # high (100 is high enough, though it could even be higher if you wish) as
    # it confuses cheaters and hardens their understanding of kick/ban reasons
    # (because cheaters will be kicked "randomly", not right on their violations).
    #
    # (i) This does not affect "low" ("non-fatal") violations which only
    #     add 1 violation and exist simply to show verbose messages - these
    #     will always go without any delays.
    #
    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]
    flag_delay: 100

  # Advanced options for component vel.adr
  #
  #     Checks for illegal movement direction changes in midair.
  #     This is normally impossible for legit players but often
  #     happens if a player is using knockback or other movement
  #     cheats, including BHop/Strafe.
  #
  # Accuracy:   ★★★★☆  (4/5 - may have a few very rare false detections)
  # Efficiency: ★★★★☆  (4/5 - pretty efficient, detects many known types of cheats)
  adr:

    # Maximal allowed angle (in degrees) between player's current and
    # their last movement direction vectors (180 degrees = full reverse;
    # also, 180 degrees is the maximal possible angle (1 side: 360/2=180, just maths))
    max_angle: 35.0

    # The maximal number of suspicions a player is allowed to obtain in
    # {suspicion_lifespan} milliseconds before being flagged for cheating
    threshold: 3

    # After how many milliseconds* will vel.adr's suspicions be forgotten?
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    suspicion_lifespan: 7500

  # Advanced options for component vel.hrz
  #
  #     Checks whether players are being knocked back properly after being hit
  #     (horizontally — there is a separate, vel.vtl, component for vertical velocity
  #     monitoring), and if not, teleports them where they should normally be knocked
  #     back. Being teleported forcefully too often indicates that a player is most
  #     probably cheating, so when that happens, Reflex adds them a significant number
  #     of violations so that they are kicked for AntiKnockback soon enough.
  #
  #     Before deciding whether to teleport a player or not, Reflex performs several
  #     checks, which all add different number of "pre-vl", and then looks how many
  #     "pre-vls" did a player get during checking. If that number is greater than
  #     {prevl_threshold}, the player is considered cheating (using Velocity hacks).
  #     When a player is considered cheating, they are added one suspicion. If that
  #     player gets more than {threshold} suspicions within {suspicion_lifespan} ms,
  #     they will be added real AntiKnockback violations, which will later lead to
  #     them being teleported (forced knockback) or removed from the server.
  #
  # Accuracy:   ★★★☆☆  (3/5 - known to have some false positives in some cases)
  # Efficiency: ★★★★★  (5/5 - awesome)
  hrz:

    # Maximal allowed number of "pre-vls" a player is allowed to
    # score during check before being flagged/teleported/kicked.
    prevl_threshold: 3

    # The maximal number of suspicions a player is allowed to obtain in
    # {suspicion_lifespan} milliseconds before being flagged for cheating
    threshold: 2

    # After how many milliseconds* will vel.hrz's suspicions be forgotten?
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    suspicion_lifespan: 5000

    # Reflex attempts to predict where players should land after being hit,
    # and teleports them there in case they seem to be ignoring server velocity.
    # If you want Reflex to simply monitor and kick, without forcing anyone to
    # knock back properly, then just enable the "silent" option in config.yml.
    forced_knockback:

      # How strongly should Reflex teleport players horizontally?
      # 0.0 - teleport to location on hit (no forced knockback).
      # Higher values - higher teleport distance.
      hor_multiplier: 4.0

      # How strongly should Reflex teleport players vertically?
      # 0.0 - teleport to location on hit (no forced knockback).
      # Higher values - higher teleport distance. The overall Y
      # teleport distance is limited, see {max_ver_dist} below.
      ver_multiplier: 2.0

      # What's the maximum distance (in blocks) Reflex can teleport players
      # vertically? Teleportation is made relatively to player's position ON HIT
      # (at the moment when the check started). If the Y distance between that
      # location and predicted location (plus {ver_multiplier}) is greater than
      # {max_ver_dist} blocks, then the player is only teleported {max_ver_dist}
      # blocks vertically. This does not affect horizontal teleportation.
      max_ver_dist: 1.7




# Advanced VehicleMove options
vehmv:

  # Advanced options for component vehmv.boat
  #
  #     Enfores vanilla boat movement mechanics. Checks fall
  #     gravity and movement speed and acceleration in order to
  #     detect BoatFly/BoatSpeed cheats.
  #
  # Accuracy:   ★★★★★  (5/5 - awesome)
  # Efficiency: ★★★★★  (5/5 - awesome)
  boat:

    # What's the maximal allowed number of blocks a player is allowed to move
    # on boat per tick* in normal conditions (still surface or in midair)?
    max_normal_speed: 0.52

    # What's the maximal allowed number of blocks a player is allowed to move
    # on boat per tick* on flowing water (waterfalls, flowing streams)?
    max_flowing_speed: 0.58

    # What's the maximal allowed number of blocks a player is allowed to move
    # on boat per tick* on ground (yes, it is possible to drive boat like a car
    # on ground in Minecraft)? This does cover ice blocks - see options below.
    max_ground_speed: 0.26

    # What's the maximal allowed number of blocks a player is allowed to move
    # on boat per tick* on frozen surfaces (ice, packed ice)? NOTE: it is possible
    # to use boat like a sportcar on ice in Minecraft - love its physics.
    max_ice_speed: 2.08

    # What's the maximal allowed acceleration (in m/s^2, metres per second square)
    # a player is allowed to reach on boat? NOTE: acceleration is basically same in
    # any conditions - on (flowing) water, ice, ground and even in midair (partially).
    max_acceleration: 0.06

    # * [1 second = 20 ticks, 2.5 s = 50 ticks, etc.]




# Advanced ElytraMove options
eltr:

  # Advanced options for component eltr.mv
  #
  #     Enfores vanilla Elytra movement mechanics. Strictly
  #     limits the direction and speed in which players are
  #     allowed to move in different situations with Elytra.
  #     Detects Elytra+/ElytraFly/ElytraSpeed and similar.
  #
  # Accuracy:   ★★★★★  (5/5 - awesome)
  # Efficiency: ★★★★★  (5/5 - awesome)
  mv:

    # If a player gets teleported back for violating ElytraMove more than
    # {setbacks_to_unequip} times within {setback_lifespan} milliseconds*,
    # Reflex will forcefully take off their Elytra. See regular config.yml
    # for details on "take off".
    #
    # NOTE: only takes effect if all of the following is true:
    #     (1) "elytramove.silent" in config.yml is disabled;
    #     (2) "elytramove.unequip_elytra" in config.yml is enabled (which itself also requires (1) to be true).
    #
    # * [1 second = 1000 milliseconds, 2.5 s = 2500 ms, etc.]
    setbacks_to_unequip: 12

    # See comment to the above option (`setbacks_to_unequip`).
    setback_lifespan: 3000