This functionality is really useful, but I have a question, is there a way to clear the history of player bans? In some cases, this may be necessary, for example, if you have tested a ban system when your game is private and want to clear your ban history or perhaps the tester’s bans history
This seems like a really good update but I have some questions:
How are we supposed to manage ban appeals? Does this mean we can have a link off site to our own appeals system like on Discord?
Can banned accounts and alt banned accounts still engage with the experience? Such as downvoting it, purchasing from the store, etc.?
“Suspected alt accounts” leaves the idea that there is room for error. Will we know these accounts and why they were banned in case there is an issue with a false ban?
I mean it leaves some questions but overall I’m pretty happy about it.
How to use :GetBanHistoryAsync()? In studio it sends a HTTP 403 error and if you use it in a game in dev console it doesn’t tell you anything about the ban
Found out some interesting things about the new Ban API for those who care… I haven’t looked over the entire thread, so I might repeat information that’s already stated.
BanAsync and UnbanAsync cannot be used at all while in studios. Attempting to do so will throw errors/messages. First one is when trying to run it through command bar and second is when running it via a script.
When a player is banned from the game and attempts to join. Roblox flat-out rejects the player from making contact with the game itself. This prevents PlayerAdded() from being fired, and the game will not make a new server at all! It leads me to believe the order Roblox does this is Player attempts to join game → Checks for ban → Allows to join/create a server if no ban is present.
When you use BanAsync, it will attempt to kick a player from every server before implementing the ban. This is nice so you don’t have to be in the same server as the target for this to work. This was only tested using public and reserve servers, but I have no doubts it also works for private servers.
You can unsoftlock yourself if you ban yourself by making an unban script, publishing it to the place, and then having an (unbanned) friend join the server. This is more so for those who don’t want to use OpenCloud.
Ban History cannot be cleared or manipulated since there is no way for developers to write/save to the Ban History besides banning someone.
This alt detection is so easy to bypass, you just need to change your pc MAC address. And it barely even works, I don’t even get alt banned anymore. I’ve made a testing game btw Testing Alt Ban Api - Roblox
Ok so hear me out.
I’m not 100% sure if anyone else has issues with dislikebotting but if I ban somebody’s main account from my experience will they also be prevented from rating the experience?
I’m out of options because Roblox support tells me they can’t remove dislikes.
Having a sibling misbehaving while playing one of your favorite Roblox Experiences isn’t going to end well, right? I don’t believe Roblox will be able to tell the difference between an alt and another family member’s account.
I feel that developers shouldn’t be allowed to permanently ban people and their “alts” from their experiences, due to false positives on which are alts and which are just another family member’s account. I know the FAQ says that the system is currently set up to minimize false positives. “Minimize” still means false positives, and it’s understandable that there will be false positives since it’s all guesswork.
I know it’s possible to contact the developers of that Experience if your account has been falsely accused of being an alt and then getting banned, but the developers can’t feasibly check if that person is a liar or if their account really has been falsely accused of being an alt. Maybe I’m just missing something obvious?
But, even if there was a cap on the length of time that a player and their alts can get banned for (which is the situation I’d want, if it wasn’t for a major workaround), then the programmers could still get around this by setting up code to temporarily ban that player and their alts again. It would work like this: Once the ban is over, the alts would be able to play again, but if the originally banned player shows up again, the code could automatically ban that player and their alts again. The code will be able to do this if it is set up to save information to a Datastore that signifies that the player got banned in the first place (or just check their ban history), and when that player joins again, the code will check that Datastore and automatically reinstate the temporary ban again, resulting in the original player and the assumed alts being temporarily banned again.
TLDR: I’m not really sure how to feel about the combination of permanent bans and alt banning due to the false positives that are going to happen. I definitely understand the use case for people who just make an alt account to avoid a ban they’ve gotten, but I’m scared of the bans that the “alts” that are actually just a sibling’s account will get, and how hard it’s going to be for the developers to tell these two situations apart when they appeal their ban.
Will there be a way to disable this feature for an experience? This could allow abuse from backdoors or team create developers abusing the API to ban other developers/owner.
Alternate accounts can be unbanned without the root account being unbanned, it was mentioned somewhere in this post.
Any anti-alt system can have false detections. Valorant (Riot Games) uses HWID bans, which is similar to a Roblox poison ban, despite the side-effects of the system it succeeds in keeping the game (mostly) cheater-free.
The alternate account detection isn’t forced upon developers, they are able to chose to not use it, but ultimately it’s also not up to Roblox who the developer bans, so making the argument that other users in the same household may be banned, so we shouldn't give them anti-alt at all doesnt really make sense.
Finally, it’s already been tested and i’m fairly sure the anti-alt doesn’t rely on the HWID of a user, nor the IP (or account switcher… or anything device based for that matter). also making the above argument void as it would be caused by device-wide bans.
so banning my main and then logging on an alt in an incognito tab bypasses this.
to be fair though, im against fingerprinting through browsers, and it certainly has no place on a children-friendly website. it’s a double-edged sword though, because this api is banning a total of zero alts. i doubt there’s use of IPs, HWIDs, or even cpu startup time when trying to detect an alt.
