Anti Fly (server side)

You are gonna want to check the Humanoid's FloorMaterial property and make sure it’s not nil for too long, because if it is, it means they have been suspended in the air for some time. You also need to average out the maximum amount of time a player can be falling in your game, and if it’s above that by some margin, then they should be flying.

I’m sorry to disappoint you but any exploiter can spoof their humanoid’ properties using meta tables and what not, so it’s best to stay away from using anything to with events and data with the humanoid. Ex: server sees player’s humanoid floor material as cobblestone, client’s is actually air, but spoofed from replication

1 Like

If you want to be hacky, you could have a fake invisible and uncollidable humanoid controlled by the server follow the player’s position, and check their FloorMaterial. I it would only require a HumanoidRootPart and a Humanoid, too.

Exploiters can spoof that humanoid’s properties as well… If it’s in the workspace, they can see it, no matter if it’s invisible or whatnot. Literally anything on the client can be spoofed, changed or exploited, which is why there is no one-stops-all anti exploit for flying or any exploit for that matter, usually involving physics.

Excuse me? I think you misunderstand. By having a seperately parented humanoid that is forcefully simulated on the server they cant spoof anything.

But I mean you could do something similar via raycasts

No, I did not misunderstand. Yes, the physics can be controlled and calculated by the server, but not properties like humanoid.floor material. It doesn’t matter if it’s separately parented, if it’s replicated to the client, they can still spoof its humanoid properties. It’s own player isn’t a exception. Besides, if you created a separate humanoid and humanoidrootpart to follow for every player in your game could cause performance issues if it is continuously following the player’s position, every second.

Yes you did misunderstand. I was indeed talking about an entirely separate humaniod and humanoidrootpart. FloorMaterials for seperate humanoids are not calculated by the clients unless the client is simulating them.

Is it expensive? Sure, hence why I said you could just use raycasts.

Actually you seem to be under the incorrect notion that clients can adjust the properties of entirely different humanoids. This is false, they can’t replicate those changes, and for those reasons unless they are given the network ownership of another humanoid they cant spoof it.

If you truly believe so, create a working step-by-step process to showcase it.

I apologize, as I just read up on humanoid.floormaterial and it seems to not be replicated by Roblox’s client/server boundary, so yes if controlled by the server, client’s can’t spoof it’s properties, only their own. But, clients actually can change the properties of entirely different humanoid’s only on their side, but I just made the mistake of assuming that it will replicate to the server. I apologize for my misinformation, I just had recently became interested in anti-exploits and preventing physics related exploits, so you are correct, but I don’t know why anyone would want to use that method.

1 Like

I like that idea, I’ll give it a try. :+1:

It was 75% a joke and 25% for fringe cases where certain collisions that keep a humanoid afloat may not be detected by a raycast.

Lol.
I must tell you this isn’t the most efficient way to check this, however it may handle fringe circumstances raycasts cant.

I don’t really understand what you mean? So, your saying this wont work 100%? I understand this wont work in cases where the exploiter is using tween service and animations… but what else could go wrong with this method?

Really depends, for example climbing, being kept from falling due to an oddly shaped part that misses the middle zone that the raycast checks, and etc.

I mean that could be solved with more raycasts though

I mean, this is probably wrong, but could you create a part and basically make it a humanoidrootpart with a humanoid inside a model, that is welded to like the player’s foot or something but is not a child of the character, instead of it having to follow the players position? Idk but I’m pretty sure the network owner should still be the server’s.

Dunno, but I am leaning towards no, because I am pretty sure assemblies are largely owned by a single computer.

What about creating your own character controller from scratch without humanoid? That could break lots of exploits and you would have greater control over it for implementing checks and etc.

1 Like

How would I do that? I’m not sure where to start with that.

For animations you could use AnimationController.

For movement you could use BodyMovers.

It may not be an easy task but it will definitely be a great learning experience. Though you should stick with the default one if you want players to have all the features that Roblox provides.