Restrictly V3 - Ban Functions

Resources Community Resources
, , ,
#21
  1. Might just be me, but I’ve never seen DataStoreService break (like on Roblox’s servers). So I’m not sure what would happen.
  2. Yes, it still bans them!
#22

Does this support inputting UserId instead of name?

1 Like
#23

Unfortunately, no. This is because it uses UserIdFromNameAsync. If needed, however, I can make a special ban for offline & online players that uses UserId.

Edit: Out of curiosity, why would you need to input UserId?

#24

UserId is used internally by most scripts so I believe it should support that. Also you should save the player UserId, not Name since players can change their name.

#25

Also wrong. Shared and _G are the exact same thing. If you find yourself using either of these, there is likely a code smell.

#26

It’s just you. There is a lot that can go wrong with a datastore call. Either some data is not serialized, API access isn’t enabled, server is crashing, or sometimes just something goes wrong internally by Roblox. Calls like these should be wrapped with pcalls and should have retry logic that abides by datastore request limits and rules stated in the DevHub.

#27

It appears he is new to scripting, let’s provide him with some feedback. I agree there is a lot of optimizations and poorly written code here, but he is learning.

#28 
local isEnabled = pcall(function() 
  local dss = game:GetService('DataStoreService')
  local ds = dss:GetDataStore('farter')
  ds:GetAsync('farty nil')
end)
print(isEnabled)
#29

Yes here is a better version.


local DSS = game:GetService(“DataStoreService”)
local PlayerData = DSS:GetDataStore(“PlayerData”)

local success,response = pcall(function()
    —// if it was successful, success will equal true and response will equal the retrieved data.
    —// if it was not successful, success will equal false and response will equal the error encountered.
  return PlayerData:GetAsync(“KEY_HERE”) — Optional second parameter of scope
end)


if success then
    — Success!

    — Do whatever you want here with the data, the data will be under response variable
else
    — Failure!
    warn(response) — response is equal to the error encountered
end

or for even more advanced pcall stuff:


local DSS = game:GetService(“DataStoreService”)
local PlayerData = DSS:GetDataStore(“PlayerData”)

local success,response = pcall(PlayerData.GetAsync, PlayerData, “KEY_HERE”)


if success then
    — Success!

    — Do whatever you want here with the data, the data will be under response variable
else
    — Failure!
    warn(response) — response is equal to the error encountered
end
1 Like
#30

No, I’m not. I am new to making modules and things though, guess my code isn’t optimized.

#31

I meant if DataStoreService goes down, I misunderstood them.

#32

It doesn’t save the name. It saves their UserId. It uses GetUserIdFromNameAsync

#33

How is that a better function? You aren’t even retrying when the pcall fails.

@THECOOLGENERATOR, GetUserIdFromNameAsync is a asynchronous function which is bound to fail, even if you use pcall and retry failed pcall attempts, it isn’t guaranteed that it will be success and you would end up saving data under a completely different key. player.UserId is a much better option.

#34

Well, the way the program works is that it checks if the Player is ingame, and if they are it uses Player.UserId. If they aren’t it uses GetUserIdFromNameAsync. So it only uses it if necessary and the player isn’t in game.

#35

The module does use xpcalls, though. It’s protected when getting and saving data.

#36

That still doesn’t prove your point correct, you still should use player.UserId.

#37

I’m not saying it proves it correct. The purpose of this module is to ban online and offline players. If the player isn’t in-game, it wouldn’t be possible to use Player.UserId, as the player’s UserId can’t be fetched any other way (atleast in my knowledge)

#38

If the player isn’t in the game, you can search up their name and get their user id easily, that is nothing hard to do and you obviously don’t want to have unexpected behaviours within your module where it saves data under a completely different key.

It’s literally listed in the link:
image

#39

The feature to use name instead of UserId was requested in the V2 of this module. I agree with you about how easy it is to get the UserId, but it’s more convenient to use name (according to the community).

#40

I literally mentioned the flaw of using user names and then converting it to a key, but you just ignored it :|. If you want to have unexpected flaws within your module and can’t accept criticism, then sure.

I would also like to point out other major flaws within this module:

Restrictly.Restrict is easily bypassable, setting their walk speed, jump power and making their screen black literally won’t do anything if its an exploiter. An exploiter can just delete the GUI, reset their walk speed back and jump power constantly or use other methods of moving and jumping like body movers.

Another major flaw is within your source code:

image
image827×257 14 KB

  • You ae using FindFirstChild to get the player, but after that you’re literally using a for loop to get the player again.

  • You aren’t pcalling SetAsync nor handling any of its failures.

There are other many bad practices / flaws in this source code, due to which, I won’t consider this module. Such bad code leads to bad developer experience, and you have a lot of unexpected flaws within this module, which are literally unexpected.

2 Likes