3 posts were merged into an existing topic: Slight rant — The problem with the Roblox devforum in 1 picture
I do remember a recent fling exploit which required tools (with handles). From what I saw in both the script and in-game, the exploiter would teleport to a player, drop the tool (making the player pick it up) and then do something with welds before teleporting into the void, taking the player with them. Un-equipping the tool before teleportation would stop them from teleporting you. Your game has quite a few tools with part/meshpart/union handles, so perhaps this could be your exploit?
Overall, this isn’t doing anything serverside but rather exploiting physics and tool>player welds.
1 Like
That is called “FE FLING”. Made by a user named JackIsTheBest15. It’s pretty easy to fix the fling though.
2 Likes
I have a copy of the script here that a friendly exploiter on my game sent. Would I get in trouble posting it for people to pick apart?
Nope! It’s merely a script. You can post it.
The issue at hand is not really something FIXABLE on a developers side - patched at most. One way to prevent users abusing physics would be to use CollisionGroups to make players phase through each other.
I don’t think Roblox will fix this issue any time in the future - this problem exists just because of how the physics & networking is structured, and I don’t think Roblox plans on redoing this anytime in the future.
2 Likes
What’s annoying about the collision group solution is some games NEED player collisions to work (think something like gang beasts).
I hope roblox finds some good way to stop client ownership of the character.
1 Like
For the time being I will simply check every frame and reset the player’s velocity to 0 if it’s ludicrously high.
@ScriptOn I have no idea why this post is flagged. I was sad about it, but I’m wondering if I structured it improperly or maybe some exploiter/hater out there just wants this thread gone 
You can do this yourself, though it would create a bad player experience, as the player would have to wait on their connection lag for a response to their movement controls.
You can put the server in control of a character’s physics by passing nil to Part:SetNetworkOwner. For example:
character.HumanoidRootPart:SetNetworkOwner(nil)
Just remember that for some reason, a player can equip a tool to reset physics control to themselves.
1 Like
On the server, try checking the velocity of a character’s HumanoidRootPart every frame and resetting it to 0 if it is unreasonably large. (Leave room for the character to be flung far off though.)
If you want, you can also annoy non-cooperative players by using Part:SetNetworkOwner to take away physics control for a few seconds.
1 Like
I actually dealt with FEKill not long ago and supposedly, it just uses a BodyThrust and turns off their own character part collisions so it allows players to be affected by simple physics. The only thing I could tell you is to check for any BodyThrust Instance created as I do not know if there are different types of physics that are abused.
2 Likes
There’s like 100 different methods for killing someone. There’s the tool method, body thrust, animations, just to name a few.
The body thrust wouldn’t replicate to the server so you would have to check from the client. However, the exploiter can just disable the script that does that so it’s pretty pointless. As soon as one exploiter releases a method to bypass it then all the script kiddies will be using it, simple as that.
1 Like
I’d handle this like noclip (generally.) I personally cast rays to their current position from their last position and keep track of this. Now if they extend outside of a buffer range within the casts, I don’t bother to cast rays and just teleport them back. So I’d simply track positions and if they get too far away, I’d TP them back to a position they were at. You could even track the players within this player’s radius, and if it happens multiple times within X amount of time. I’d add them to collisiongroups to prevent those specific players from touching each other.
So I’ve had a look at your post and I hear that you want to keep your collisions active. This is just a fix I thought up off the top of my head, so if anyone has any critique feel free to comment.
The Issue:
You want to prevent players from flinging other users and causing issues as described above.
A solution:
Use collision groups as alot of people have said.
Collision groups do not have to be active all the time, if you create an algorithm that tracks the speed of which a player’s humanoidrootpart is rotating (whether you do this on the client or on the server is up to you, doing this server side is better), you can set the spinning players parts to a collision group that doesn’t collide with players, and thus they can’t fling anyone.
In the future however, if you don’t mind disabling collisions, you should do so! I found that once I did that, the number of exploiters who did use FE kill decreased in numbers because they couldn’t disrupt gameplay, and thus didn’t enjoy it. I know you are a capable dev but for anyone else who experiences an issue like this and wants to disable collisions, @Dandystan made a handy dandy script you can use or modify pretty easily!
6 Likes
Howdy! I appreciate your input a lot. After The Flash is a roleplay game and interpersonal communication/reactions is pretty crucial. I like to have character collisions on because bumping into people and talking is something that happens frequent enough.
I’ll try the velocity clamping method first, and if that doesn’t work I’ll have to resort to changing their collision group.
1 Like
Perhaps one way of dealing with this would be to monitor the velocity delta of each player’s character and whenever two characters collide with each other - if one’s flung and it turns out another character touched them just before, kill the suspect character or do whatever else you deem necessary. However the exploiters cause it, a recurring theme here seems to be someone gets flung at high velocity.
1 Like
Be careful with that idea though. I’ve been flung out of the world many times due to funky physics, and I’ve accidentally flung others into the sky a few times myself. (In my general Roblox gaming experience.)
1 Like
This has been common within many games. Not really a scripter, but I’m pretty sure that I gave @Beartikal the script used for this exploit in the pre-bloxton patching. I’ll converse with them. They might be able to provide a helpful tool or two.
Players have the freedom to manage their characters in almost every area. The client can freely manipulate the contents of their character such as physics and scripts. This is implemented mainly for user experience, however it is a security flaw. Network ownership is probably responsible for this exploitable behavior as mentioned above it’s most likely to be a physics exploit. You may want to consider making players uncollidable or add server and client checks for any physics that may seem unlikely such as spinning faster than a certain speed. While client checks may seem useless since exploits are getting worse everyday, it would still mitigate the issue somehow since the client is the root of the exploit. Server checks for physics are usually hard to design due to the fact that it’s normal behavior for clients to freely manage the replication of their characters, unless you want to take the time to create a custom character/humanoid.
3 Likes
I got this from a Google search, if you wanna try and pick it apart this apart this is the closest I can find:
R15 Version
– Made by JackMcJagger15
power = 500 – change this to make it more or less powerful
game:GetService(‘RunService’).Stepped:connect(function()
game.Players.LocalPlayer.Character.Head.CanCollide = false
game.Players.LocalPlayer.Character.UpperTorso.CanCollide = false
game.Players.LocalPlayer.Character.LowerTorso.CanCollide = false
game.Players.LocalPlayer.Character.HumanoidRootPart.CanCollide = false
end)
wait(.1)
local bambam = Instance.new(“BodyThrust”)
bambam.Parent = game.Players.LocalPlayer.Character.HumanoidRootPart
bambam.Force = Vector3.new(power,0,power)
bambam.Location = game.Players.LocalPlayer.Character.HumanoidRootPart.Position
R6 Version
– Made by JackMcJagger15
power = 500 – change this to make it more or less powerful
game:GetService(‘RunService’).Stepped:connect(function()
game.Players.LocalPlayer.Character.Head.CanCollide = false
game.Players.LocalPlayer.Character.Torso.CanCollide = false
game.Players.LocalPlayer.Character[“Left Leg”].CanCollide = false
game.Players.LocalPlayer.Character[“Right Leg”].CanCollide = false
end)
wait(.1)
local bambam = Instance.new(“BodyThrust”)
bambam.Parent = game.Players.LocalPlayer.Character.HumanoidRootPart
bambam.Force = Vector3.new(power,0,power)
bambam.Location = game.Players.LocalPlayer.Character.HumanoidRootPart.Position
(On mobile so sorry for any formatting issues.)
1 Like
You can use the RunService.Heartbeat event to clamp Velocity. Heartbeat is always run after each physics frame so you’ll get 100% accurate results. On Heartbeat you’ll simply want to check if the player’s root part Velocity.Magnitude is greater than their max speed (the maximum value of either WalkSpeed or JumpPower for Humanoid based characters).
If the velocity’s magnitude is too large simply reset their velocity to Velocity.Unit*maxSpeed. This will prevent the player’s velocity from being too high on the server 100% of the time. The downside is if a player somehow manages to travel faster (intentionally or not) they may be lagged back as their velocity changes on the client.
This also does not prevent teleportation but that is similar. The player should not be able to move faster than their Velocity.Magnitude times Heartbeat’s deltaTime give or take a few frames. You can simply add a few studs per second (10 sps is reasonable) on top of this to account for lag. (deltaPosition should be <= Velocity.Magnitude*deltaTime + 10 for example)
Also note: I believe I remember that a client can reparent a tool with a handle to make it collectible by another player while the tool stays attached to them so if you use a tool with a Handle for anything you might want to check that.
You can also apply this to rotation if you want to but keep in mind that Shift Lock sets CFrame directly so you may only want to apply this to rotation speed.
4 Likes