Thanks! I made it so its that way just in case I ever added on to it to add an unbanning system, where it would be set to false to unban players.
I’d recommend you adding an option to give a reason for a ban, and add all them into a data, so you or any admin in your game, would be able to see who got banned and why.
Cool tutorial! May use this for my games.
Yeah, but when you’re in game, you want to instantly ban him with a reason.
I don’t understand what you’re saying.
Also, I don’t think that using a ban hammer should be the one and only way to ban a person. If you would want to customize the reason, use chat commands or an admin panel.
I have to admit that it would be cool the ban hammer had a feature where you could customize the ban reason.
ummm… i still don’t get the point of your post, yeah you can edit the kick message but the edited kick message in the script will show to all players that i’ve been banned from the game.
Just make it so when you hit someone with the hammer a text gui where you put the reason in. You can save the reason in a string value and do
hitPlayer:Kick("You’ve been banned”…plr.reason.Value)
Something like that
because, you’re basically telling the script to display the kick message when you ban the player, so whatever you change the kick message to will display to all the players that are banned from the game
Okay, but you should probably tell the OP that. Not me.
@Valkyrop Feel free to make your own add-ons, such as a custom reason! The script is open-source.
can i edit the script? i’ve made a system like this before
Of course! Its open for taking. I just made it quickly, so it is simplistic, but if you’d like to add on to it, go for it! @The_Finished
Yeah, that’s what I meant
Make a gui with a remote to be fired, etc…
If you do not mind my asking, what is the difference between task.wait()
and wait()
?
Its similar to RunService.HeartBeat()
task.wait() updates 2x faster than wait(), therefore more accurate
It isn’t similar to RunService.Heartbeat:Wait(), it is exactly identical when used without a provided time constraint. You will wait out the task scheduler’s current iteration, and resume after the next game simulation (Heartbeat is the final consistent step of the task scheduler- it happens after physics simulation, after garbage collection, after rendering at large).
The difference comes into play when you provide an ideal wait time. The functionality doesn’t really change if you understand how cyclical Roblox is, but this is the actual difference if you don’t know how task scheduling works:
- The thread will still be suspended based around
Heartbeat
, that is in nature how this function works. - The task scheduler will run regardless. Your thread will be resumed when the given time is recognized as elapsed (which will be more accurate in comparison to
wait
) and the next heartbeat is reached.
You should not use wait
anymore, it is on strong track for deprecation.
Well it is identical in functionality, but not service. Its a built in function, from what I understand.