This tutorial covers configuration and tuning of the Teleport Cheating detection module for the service. When setting up the service for your game, the long configuration file can be a little daunting. Here, I will break down each section with explanations and practical examples of how to use it and code samples for usage.
When setting up the anti-cheat service for the first time, it’s best to enable debug mode for testing. This way you can see what the anti-cheat service is observing from the player. This can help you tune how strict you want to control the player teleportation in your game.
You’ll find the settings for this near the middle of the configuration section for Teleport Anti-Cheat. To enable the detection, simply change the values to this:
--[[
Set this to false if you want to turn off all Teleport Cheat Detection Server Wide
Default = true
--]]
teleportCheatDetectionEnabled = true
To enable the in-game Debug Window, simply change the values to this:
--[[
Set this to true if you want the server to output Debug info for Teleport Cheat Detection.
This is helpful when trying to fine tune settings for your game through testing.
Default = false
--]]
debugTeleportCheatDetection = true
With this enabled, cheat detection for teleport cheating will be enabled server wide for every player and an in-game debug window will display real-time info about the players in your server similar to this below.
maxLongRangeTeleport
This is the maximum distance your players should ever be about to move on their own in 0.2 seconds. It does not matter if they move through an open space or through a wall, once this distance limit is reached, it results in immediate punishment to the player.
-
What is the best way to use this configuration setting?
This serves as a last resort to various forms of teleport cheating. It’s easy for developers to test via the debug window what the normal, highest value that could occur within their own game. It’s basically like where can a player fall the fastest or run the fastest or drive a vehicle the fastest?
Example: Your game contains a fall that accelerates the player to a terminal velocity of 500 studs per 0.2 seconds. You could safely use a setting like 550 and know that no player can ever move more than 550 studs distance in 0.2 no matter what they do; knowing that no player would normally activate this cheat detection by accident.
maxShortRangeTeleport
The maximum range that a player can push through a collide-able object without setting off a cheat detection event.
-
Why would I want to have a way for players to push through thin objects without setting off the cheat detection?
This is really more of a convenience for players and false detection events. If one player walks by another player close enough to graze a body part or accessory sticking out that was collide-able, this can cause a false detection. If a wall was thinner than the developers’ setting, a cheater could teleport right through it without penalty. If all of your walls or doors or any collide-able objects that you don’t want a cheater to pass through are larger than this size, they won’t be about to teleport cheat through it normally.
-
When would a cheater be about to exploit this range setting?
A cheater can exploit this by moving really slow through a wall or door. Slow enough that they are not breaking the limit set by the developer every 0.2 seconds. If you want to slow down cheaters, you can use lower and lower values like 0.5 studs or 0.25 studs if moving through solid objects is more about fairness and less about keeping those cheaters out of rooms or parts of your map that they should not be allowed to enter. A race game or fighting game would put this kind of cheating at a disadvantage if they are a slow/barely moving target while trying to perform the cheat. -
What if I want to be very strict and make sure it’s impossible to teleport to my restricted areas of the map?
Simply set this value to 0 and basically anything a raycast can hit will count as a cheat detection followed up by punishment. Keep in mind, depending on your map design, your players might get a false detection when rounding sharp corners while running or small parts of your map stick out that the player might hang on.
ignoreTeleportOtherPlayers
Ignore teleport detection through other players. If your game allows players to walk through each other, it can set off false teleport detection events. Enable this with a true setting and anything on the player model will be ignored when moving through another player.
-
Why would I want to enable this?
If your game allows players to walk through each other, this can set off false teleport detection events. Enabling this allows any part of a player model to be ignored when players are walking around each other. There is a range limit of double the player models size in the X,Y,Z extents that another player is walking through. This helps to stop cheaters from using other player models to teleport through other solid objects next to them
-
Why would I want to disable this?
If your players have to walk around each other as solid obstacles already in your game, this is just an extra check to avoid cheaters using other player models as a means to teleport through other solid objects. This is also useful if your game has some type of race where players have to more around each other rather than walk through or cheat through the other players.
ignoreTeleportExceptionModels
Ignore teleport detection through specific models chosen by the developer. This will ignore all descendant parts of this model. The model needs the attribute “KM_TELEPORT_IGNORE_MODEL” set to true. This can be assigned in Studio via a boolean attribute or manually during run-time with a script if preferred.
-
Why would I want to enable this?
This feature is useful for developers that need to ignore certain collide-able objects within a model. The best example would be a driving game. The player is seated in a vehicle, but the vehicle is not part of the player. The player only drives the vehicle. While driving, the player will be “colliding” with the vehicle if moving fast enough to overlap teleport detection scans.
With this feature enabled, you can set an attribute on the vehicle model that will make it transparent to the ray check scans for solid objects between the previous and current player position.
This also has the added benefit for developers that want to ignore “nuisance” false detection in their game by models that don’t matter if the player moves through or around them like decorations, sharp corner meshes, sharp corner objects, etc. -
Why would I want to disable this?
You probably won’t enable this feature unless false teleport detection is an issue in your game. Otherwise, you can leave it disabled to save a few CPU cycles. -
What are the limits of this feature?
Only the 1st Model encountered set with the ignore attribute will be excluded from the teleport cheat scan. If there are more than 1 models in between scan locations, then the second model and any collide-able parts that are descendants will still trigger a cheat detection. This was done to prevent unknown performance issues should a large number of models, each with a large number of descendants; were to get in the way. This also helps to prevent any possible routes to exploit this feature by cheaters trying to overlap many models at once to create a “bridge” to bury the scanning ray cast. All ignore attributes must be set from the Server, anything set by the Client will be ignored, for obvious exploit reasons.
invisibleFenceGlobalSafe
Invisible Fence is a developer set X,Y,Z (or mix) axis coordinate(s) that confines the player between it. If the player moves beyond your set limit, 1 of 3 actions may take place. If no safe coordinate is set for the player object, it will check if a global safe coordinate exist. If no global safe coordinate exist, it will use the last scan location as a fallback. A cheat detection event is triggered and the player is teleported back to the either the developer chosen safe coordinate or the last scan that did not violate the set limits.
-
Temporary Exceptions and Trust Based Exceptions will not work for the players that trigger this system. Think of it as a final line of defense against extreme forms of teleport cheating.
-
To modify the Global Safe Coordinate anytime, set a new Vector3 on the attribute “KM_IVF_GLOBAL_SAFE” located directly on the workspace.
Example:
workspace:SetAttribute("KM_IVF_GLOBAL_SAFE", Vector3.new(1,2,3)) -
To create a player specific Safe Coordinate, create a new Vector3 attribute on the player object named “KM_IVF_PLAYER_SAFE”.
Example:
oPlayer:SetAttribute("KM_IVF_PLAYER_SAFE", Vector3.new(1,2,3)) -
Why would I want to enable this feature?
For certain genre of games, it’s important that the player be contained within the valid “play” area designated by the developer, such as a vehicle racing game that load new tracks every level for example. Players that are able to get far outside of the play area, whether by accident or via cheats can cause game play issues for themselves or other players in the game. This allows the developer to create a virtual fence to force the player back in to a designed safe coordinate set by the developer, such as the start of the map for example. It can also be used in creative ways to fight back against cheaters that abuse the areas outside of the game play area. -
What is a practical example of this feature in action?
You have a game map with a death void underneath. Using just the Y axis, you can catch players that fall out of your map and send them back to a starting area to avoid killing them.
Another example, you have a racing game with a track that has jumps. Sometimes, players can glitch/hack out the jump and go skyward at a nearly unlimited distance. You could use the Y axis to set a “ceiling” that if the player hits it, drops them back down or sends them back to the start of the race for cheating.
invisibleFenceXAxisP
invisibleFenceXAxisN
invisibleFenceYAxisP
invisibleFenceYAxisN
invisibleFenceZAxisP
invisibleFenceZAxisN
Enable or disable which axis you want to setup your Invisible Fence in regards to the virtual space. If you want to disable scanning of any single axis, make sure both positive and negative values are set to 0 for that axis. These values represent stud distance in Roblox.
-
invisibleFenceXAxisP, invisibleFenceYAxisP, invisibleFenceZAxisP is the Positive Max used for that axis.
invisibleFenceXAxisN, invisibleFenceYAxisN, invisibleFenceZAxisN is the Negative Max used for that axis. -
The positive and negative Max do not need to be opposing positive and negative numbers. The invisibleFenceYAxisP could be set for 10 and the invisibleFenceYAxisN could be set for 2 as an example. This is only to help visualize how the 3D space will be evaluated by the anti-cheat service. Big maps might have need of large positive and negative numbers, like 1000 studs high and -1000 studs deep is an example.
-
These initial configuration settings can be modified during a live game by the developer. You need only change the values and the anti-cheat service will recalculate the invisible fence limits on the fly.
You can find number attributes on the workspace:
KM_IVF_X_AXIS_P
KM_IVF_X_AXIS_N
KM_IVF_Y_AXIS_P
KM_IVF_Y_AXIS_N
KM_IVF_Z_AXIS_P
KM_IVF_Z_AXIS_N -
You can now use those same attributes above and create them on the Player Object. This allows you to create a “personal” Invisible Fence specifically for that player that will over-ride your global settings. If you want to revert the player back to the global settings, simply delete the attributes from the Player Object.
KM_IVF_X_AXIS_P
KM_IVF_X_AXIS_N
KM_IVF_Y_AXIS_P
KM_IVF_Y_AXIS_N
KM_IVF_Z_AXIS_P
KM_IVF_Z_AXIS_N -
What is a practical example of how to use these settings?
If your map has the void death fall set for -100 studs, you could set the invisibleFenceYAxisN for -50 and the invisibleFenceYAxisP for 100 (if your map has no reason for any player to be above that elevation) with a global safe coordinate set for the map starting area. If any player falls out of your map by accident, this will catch them and teleport them back into the game play area, avoiding a game interrupting death for the player.
sendTeleportCheaterBack
This will send the Teleporting Cheater Back to their Last Location before the Teleport Cheating threshold was reached. If a player was standing behind a locked door and teleported through it, this would force teleport them back to the previous side of the door. Setting this to false will ignore this punishment and you can implement your own form of punishment. If you want both soft punishment and custom punishment, this is possible by setting this option to “both” using full quotation marks. All custom punishments are stored in the “KnightmareCustomPunishment” script file that comes with the service. How to create your own custom punishments will have to be for another tutorial as it is beyond the scope of this one. 
Common Questions & Answers:
-
What if I want my Admins or Developers to be immune from any Teleport Cheat Checks?
You simply set an attribute on the player object from the server with the name “KM_IGNORE_PLAYER_TELEPORT_CHEAT” and set the value to true. -
What if my player model does not have the Roblox default R6 or R15 Meshparts?
You can create a boolean attribute “KM_MESHPART_SCAN_POINT” set to true in Studio or during a live game on your custom player model Meshpart objects and the anti-cheat service will use those as additional scan points for detection, helping to decrease the chance of false detection events. -
What if I want to give a player a temporary exception to teleport cheat scanning?
You simply set an attribute on the player object from the server with the name “KM_TELEPORT_TEMPORARY_EXCEPTION” and set the value to true. This will give the player one freebie exception if the player is detected as teleport cheating. Afterwards, the anti-cheat service removes this attribute from the player object so it can’t be abused. This is often useful when you need to teleport a player in your game such as player re-spawning, player teleporting to new areas, or even a teleport power for the player, etc.
NOTE: This exception remains active until used, so if you set this and it’s possible that it won’t be used, consider removing it later to avoid a case where a cheater could find a way to exploit this.
This concludes the developers guide, hopefully the in-depth exploration and explanation of the settings can help developers tune their own games to be as strict as possible against teleport cheaters but also prevent good players from being punished by accident. 
Other developer guides to explore the other modules within the anti-cheat service will be written in the future and posted in the tutorial section as well, I just wanted to make sure I focused on each module in detail.