Restrictly V3 - Ban Functions

Resources Community Resources
, , ,
#41
  • I understand, not the best way to get the player.
  • I literally remember adding xpcalls to the DataStores. I’ll check that out right now.
#42

Update Log 3.4

Update Log 3.4
  • Added xpcalls to all Get and Set requests to DataStore.
#43

Also, what Datastore Key should I use instead of UserId, then?

It needs to be something that the User cannot change, and (preferably) able to be retrieved by Name or something similar.

#44

Then you should be able to just add option to use UserId directly instead of having to convert id to name and then having the module convert it back. You can just use typeof() to check if player is a string (name) or a number (userid)

#45

Alright, I will add this soon in the next major update. Until then, if you want, I can make a temporary function that uses UserId instead of Name.

Out of curiosity, though, why couldn’t you just insert the UserId in your browser and just input the name?
image

#46

I’m talking about situations where someone would want to use your module in a script that uses userid internally rather than player names. Without userid support, this script would have to convert id to name and then your module would just convert it back anyway what would be slower and could occasionally fail.

Obviously you’ll want to have your module as comfortable for users as possible

1 Like
#47

I am showing the basics of how pcalls work, which you would know if you looked back in the discussion. It is better because it logs the error if there was one. Why do I even have to answer this? I feel like my posts explains this itself.

P.S. look who I was responding to for that post mate

Also any call that makes any type of request to the internet like The ones you listed are bound to fail.

#48

Also any call that makes any type of request to the internet like The ones you listed are bound to fail.

Yes they are, this is why I suggest you retry them. Retrying when a pcall fails is good practice, because they mainly fail due to the server not being able to process the request so you have to retry for that.

It is better because it logs the error if there was one. Why do I even have to answer this?

You log the error after you have finished retrying the pcall and the pcall still wasn’t successful. You should know this already…

#49

i think pcalls are easier than xpcalls

#50

Just to let you know, this entire command can be easily bypassed with exploits.

1 Like
#51

Why use Restrictly over EZban and BanIt?
Is there anything special with Restrictly over all the other modules?

4 Likes
#52

I still use xpcalls, I find xpcall and pcall equally easy to do

#53

It’s your choice whether to use it or not on exploiters. However, I’ll try to come up with a better ban option.

#54

Well, over EZBan (unless I’m mistaken), there’s no Server ban/unban option.

#55

It’s probably not meant to be used against exploiters. If you have an exploiter, you’ll usually want to just ban them on sight anyway.

1 Like
#56

Should an option to ban, where you input UserId be implemented into Restrictly.Ban()?

UserId Ban Option
  • Yes
  • No

0 voters

If Yes, would you like a temporary ban option such as Restrictly.IdBan() whilst it is being implemented?

Temporary UserId Ban
  • Yes
  • No

0 voters

#57

That’s not a valid point over why people should use this module, the code has major flaws and is highly inefficient, yet alone useless functions.

#58

What do you mean by this? The only ‘useless’ function is the information command.

If you mean the Restrict and Unrestrict, they’re not useless. If you’re seeing this in a scenario where you’re using it against exploiters, you always have the choice not to, as pointed out by @Acu1000

#59

This is a cool module, but why should I use this module over say, adonis or EzBan or BanIt or any other ban/admin system out there? What are the pros of this system?

#60

I think for now it’s still in development so you shouldn’t expect anything too special yet

1 Like