Use locals. Also you should make the commands in a module so u can make a cmds command easier and more organized.
2 Likes
For kicking them when checking players and slock, why not optimize and do this,
if #PlayersTable >= ServerLimit then
elseif ServerLock then
end
1 Like
He could also make alot of modules each one for a command
When putting the list in the string.find, I was using a loop, otherwise, I’d just get this (unless if I’m just being a buffoon, and I’m not putting it in correctly).
yeah but i dont do that. i put all commands in one module, reusable functions in a function module, and even admins in a module. yeah i like modulescripts.
why i dont do that? because require yields so…
The idea is that admins are only appointed via by adding their UserID towards this table.
I’m not quite familiar with modules just yet. Could you perhaps point me to a few resources regarding them?
Also, will do.
Oh then do what you were doing before with checking when they chat, checking before will not update with the table. In addition without using locals the allow will be set by different players creating problems.
Its actually pretty simple, reusable values.
Lets say we want to get a table of functions from a module right?
Lets do it
local commands = {}
commands.urfunction = function(args)
print(args)
end
return commands -- must return something,
-- so lets return the commands table
this one modulescript
local module = require(path.to.module)
module.urfunction("amogus")
-- amogus
this one script
Modules are very useful in development, Lets say you want to make a gun, we would use modules to easily update them all at once, reuse them all at once, cool and amazing right!?
1 Like
When referencing services most people say abbreviate, say for RunService they would do RS or for UserInputService they would do UIS, I would suggest abbreviating PlayerService with ps or p (ps could get confused with physics service).
1 Like
Alright, will do. Though, my original intention was that the administrators would be permanent from the development-side, and that they wouldn’t be adjusted until the game would be updated.
You could do either if you want, an :admin command would be really nice for you as you wouldn’t have to restart the server every time somebody became a person of administrative powers.
1 Like
Seems intriguing indeed. I’ll look into studying them more in depth when I can. Thank you.
1 Like
https://education.roblox.com/en-us/resources/intro-to-module-scripts
if you wanted to learn more
its also good for respecting the DRY rule
Another suggestion for variables naming which I use is a naming method called Camelcase, its where everyword but the first word is abrieviated such as, helloWorld, or another method which I use is just lowercasing most words and putting underscores between, I use these interchangingly. Though, your method works completely fine and these don’t affect the way your code runs or the efficency at all, its just a styling thing.
2 Likes
Also for the Number1,Number2,StringValue, etc variables it would be really nice to give them names as I have no idea what they mean, and it would be difficult for people of your team or you in the future to understand what they do.
1 Like
camelCase*
Yeah u should use that too, Also you should add a datastore for admins so you can directly give the user you want admin without restarting the game
Oh yeah its just style for cases, you can also use PascalCase, snake_case, and etc
But camelCase is the most recommended from programmers and most readabile
You could also still have a table of permenent admins to ensure that you couldn’t lose administrative powers.
Module scripts are like files kind of, where they just store data (can be functions,bools,number,strings,ect). The module is kind of like a function which is run which at the end returns a set of values, functions, tables, whatever. If you create a new module script in studio you can see an example and add, rename, or manipulate the values in the table. Note, you can return values that are not tables such as just functions numbers or string. (this thread is popping of)
1 Like
I apologize, my mind was a bit numb regarding writing those. They’re just miscellaneous values that fixes up my script.
They’re just essentially setting values for my string.sub if the player limit was more than 10 (i.e, the string would’ve then errored due to the length of the string increasing).
Nethertheless, I’ll be more efficient regarding naming those values.