Best way to prevent exploiters from changing others Humanoid Display Name property?

They don’t have to remove it, they can just stop the code. Just assume that exploiters can do absolutely whatever they want with client sided stuff

2 Likes

I’m not sure if this will work 100% of the time, but Try creating a report system in game that submits a chat log of players to something like discord, then require players to say in the video description the time that they reported someone, and reference the chat log with the video. If the chat log and what the player says in the video don’t add up, then you know who to ban.

1 Like

Yikes. I mean surely there has to be some type of workaround for exploiters framing other players.
if there wasn’t I feel like it would be very much abused in a lot of big games.

The best solution is to probably just have stricter exploiter report requirements, such as needing to show the player’s name on the leaderboard/playerlist

1 Like

thats a smart solution but what if the person decides not to chat.

really? I get your point but this never happens. There is literally nothing you can do.

1 Like

it could simply be abused the same way but the player just has to be in the same server.

Anything on the client can be exploited past just deleting a local script.

1 Like

What kind of game is this for? Military Roleplay? City Roleplay? FPS?

1 Like

you can probably also make a trust system, whenever someone does something suspicious (walkspeed, noclip, etc) you can mark them, and if you also happen to receive reports on that player then you can be pretty sure that they are exploiting.

when red is sus

1 Like

A hardcore survival game where dying results in loss of stuff so I can’t really sleep on exploiters.

Well, you can narrow down the exploiters to just PC players. And a leave and join log would be useful, or you could require more than one account of the exploit before banning someone, just don’t tell them that it requires two different accounts with different videos. But honestly, its not all that common framing other people for exploiters.

1 Like

Yeah. I was thinking of maybe creating a log which can check which server a player is in, their location, and other relevant information. The log would be sent everytime a player moves X amount of distance from the location that was previously saved to the log.

I haven’t used discord bots before. I know webhooks have a rate limit which would make it impossible to achieve but do you know if actual discord bots have a rate limit? Or am I free to do this.

1 Like

you can just have all the individual logs combined into a single one and save it somewhere after they leave the game

thats a good idea actually, thanks :slight_smile:

So how often does a scenario like this happen? Where someone tries to frame someone else for cheating by changing a display name?

Is this a solution in search of a problem? Or is this really a problem?

And why can you just cross reference logs to see that the player actually did play (or didn’t) when this incident allegedly occurred?

2 Likes

In other games I’ve seen it happen and I wanted to try my best to prevent it from happening to mine.
Even if its unlikely somebody will do that I want to try and prevent it at all costs.

And the solution is to create logs to be used. So thats what I plan on doing.

One of the most important things you should learn in development is prioritization of work by risk versus impact.

Low risk = not likely to happen. Example: hacker manages to compromise your game.

High risk = very likely to happen. Exploiters ruin game play for others by taking advantage of your client side scripts.

Low impact = no damage or easy to fix. Example: game disruption is limited to the few servers where the exploiters are playing, and it really doesn’t prevent others from playing.

High impact = large “blast radius”, lots of people impacted. Example: game gets banned.

If you focus on low risk, low impact items, you will never have time to deal with the high risk, high impact items. If you are considering spending time and effort on addressing risks, make sure you categorize those risks first then prioritize.

Also, theres and old saying that goes “perfection is the enemy of good.” Don’t strive to make perfect software. Make it good first.

1 Like

Thats a very good way to look at it and I will definitely use that for future reference.

With this issue though although it is rare but it will almost 100% be attempted eventually.
and if someone tries it and it works out for them. They can become a repeat offender pretty quickly.

But I do plan on working on anti-cheat very soon so I will keep what you said in mind when I do.
I’ll probably create a list of what to prioritize before I work on it too.

Thank you very much :slightly_smiling_face:

1 Like

Yeah they could go LocalScript.Source = ""