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.
PlayersService should be PlayerService (probably a typo)
Twas’, I also technically changed it to PS.
I would suggest adding a preemptive command interpreter when the message is sent so you can split the message into say the base command and the arguments. You should also add compatibility for the suffix of the command to change.
1 Like
Interestingly enough, I’ve already had this idea in my mind, I just hadn’t got to it yet.
Also, I believe the term is prefix, not suffix.
Regardless, let me list down all of the stuff that I’ve been told to improve my programming here:
- Make sure to put locals before values that aren’t universal.
- Utilize
game:GetService("Players"):GetPlayers()to get an automatic table of players. - Try to unmitigate the usage of
elseif's so that it is not excessive. - Use modules for their more efficient usage.
- Shorten service abbreviations for better usage.
- camelCase/under_score_variables for optional additions towards style.
- Be more efficient regarding the naming of variables.
- Miscellaneous fixes towards my script (i.e, I have to be more wary).
Thank you all for feedback. If you want to give me anymore suggestions, that’d be appreciated. Otherwise, I believe I’m good for now.
1 Like
This code seems very messy, inefficient, and unorganized.
Why /e after every command? Why can’t you handle that inside of the .Chatted event?
This is very unnecessary as you can just run the code where you assign Allow.
This is unnecessary.
Why can’t you check if the message starts with the prefix rather than having the prefix specified in every line? Also, why does it always have to be in that capitalization, why not lowercase?
You use too much string.sub, when you can simply get the arguments of the command by doing string.split(msg, " ") and this will return a table. For example, if I have the command :SetServerLimit 5, it would return {"SetServerLimit", "5"} and you can just use tonumber().
I think it would be better to use break instead of return here.
You can just use if table.find(PlayersTable, Player.UserId).