User:TheNexusAvenger/Nexus Admin

'Note: Nexus Admin is in late beta. Expected release date is April 4th'

Nexus Admin is an open-API admin system, created by FromLegoUniverse, to be an alternative to the well known Kohl's admin. Kohl's admin is a full, closed-source system with a simple API for adding your own commands, but is very limited into what the admin command developer can do, such as checking the admin levels of a player, displaying hints integrated into the system, and other key features.

Setting It Up
Even as a person who isn’t a command developer, there is still a few nice features offered in the loader, for things such as groups, command level requirements, and admin levels. The one feature not implemented is a game pass that awards certain admin levels, as they are normally abused and no real developer sells admin without removing enough commands to make it not worth buying.

The Basics
In some cases, the person setting it up for their place may not even have to open the script. By default, no groups are given any commands, no commands are overridden, and the owner is given access to all commands. In Kohl’s admin, Scripth automatically gives himself full admin, while, in Nexus Admin, FromLegoUniverse gets level 0 commands, which is all debug commands, currently logs and the debug console. This can’t be overridden because seeing the server output is important to debugging.

The Config
The config is a table that can be found right under the Nexus Admin heading. It is simply started with, and in the table contains the following:

This will allow the changing of the default admin level that every non-admin gets. By default, it is -1, which allows access to all non-admin commands. Setting it to 5 makes everyone a creator admin, which isn’t ideal in an actual game, but is still there if you want to change it so everyone has no commands.

By default, it is set to “:”, meaning all commands will have to start with :. This is meant only to change the prefix of the included commands, and may or may not be used by the creators of command packs if they come up.

All of these are for setting the needed admin level for a certain set of commands. These probably won’t need to be changed in most situations, but are here since there is no other way to change the included commands.

Probably the most important part of the config. This allows the changing of admin levels on a per player basis. For future-proofing, it is id based, since a username can be changed at any time. For the table, you need to set the userid equal to the admin level, with decimal places working but not fully supported (ex: [261] = 3, which gives the person with the id of 261 (Shedletsky) the admin level of 3).

This allows for setting users with a certain rank in a group or above to have a certain admin level. The example in the loader does the best job at showing how to use it without using a lot of text.

This allows the banning players, as the config name says. For future-proofing, it is id based, since a username can be changed at any time. For the table, you need to set the userid equal to a ban message (in quotes), or true just to ban them without a message (ex: [261] = true, which the person with the id of 261 (Shedletsky) with no kick message, while [261] = “Being too awesome” makes their kick message “Being too awesome”).

This allows overriding the needed level to user a certain command. Setting a command to nil makes it the default, with setting to a number making it the overridden level requirement. It is best to look at the loader for all the included commands. Admin command makers shouldn’t reference it due to it not being designed for other commands.

Using :ban and :kick
In most admin scripts, admins can’t be kicked by other admins. This behavior is different with Nexus Admin. The kick and ban scripts are meant to allow lower level admins to be kicked and banned by higher level admins. This is for things such as moderating a server so one admin doesn’t abuse commands without a way to be dealt with. Currently, this can’t be disabled, but may change in the future.

Adding Commands
To make a script load the commands, place a ModuleScript into the admin loader, and type the code to load the commands there. It is the officially supported method by the system. You can halt loading or require other modules if needed since they are halt-able. If a module runs into the error, the system will warn the error rather than force the loader to stop so it can remain useful, especially for using !debug (for viewing the server output).

API (Server)
The main piece of the admin is the server API. It contains the needed API for adding commands, as well as other functionality to interact with the system. The API can be obtained using. The API contains the following:

Version is a string that contains the version of the API. It is more for displaying the version rather than comparing versions.

VersionNumberId is a number containing the actual version as a number for the API. This should be used for comparing or getting a build id, since it will increment by 1 every time behavior is changed or the API is changed.

EventContainer is a folder in ReplicatedStorage for storing RemoteEvents and RemoteFunctions. It isn’t anything fancy, just for organization. It isn’t required to use.

AdminItemContainer is a folder in Workspace to store any instance that you want to have cleared when :clear is called by an admin, assuming the command hasn’t been overriden to do something different.

Returns a table containing the configuration from the loader. It will never by nil, and should not be relied upon because it is mostly for internal use. Command pack makers should make their commands use a config inside their own ModuleScript.

Returns a table of admins. If GetRaw is true, it returns a table with all the userids equal to their admin level. If GetRaw isn’t true (false, nil, blank, etc), it returns a table of all the players in game equal to their admin level, assuming it is above -1.

Returns a bool saying if the system is fully loaded or not. If DataStore calls are done by other commands before loading, they may stall load times, however this is not done by any included commands.

Returns a number value of the admin level. It accepts an id or a Player instance, and will return -1 if the player isn’t an admin.

Inserts a log with the given string. Mostly for commands such as :logs. Only 500 logs are stored at any given point.

Returns a table of strings which contains the logs given by.

Able to invoke another command without the need of a player having to type it in. It is used internally by :batch and !keybind, but can be used by other commands. Command is the command string (such as “:fling” or “:kill”), ArguementString is the string of arguement (such as “me”, “This is a test”, or “all Message”), and ReferenceMe is a player to reference the admin level and “me” and “others” if it is getting a list of players. The need for ReferenceMe is needed to make sure a command pack user doesn’t try to invoke a higher level command if the command pack maker decides to try to give themselves full admin.

Creates a line of text on the top of the screen for the given player. The message is the message given, and DisplayTime is an optional argument for how long it displays. By default, it is dependant on the length of the string.

Creates a message for the given player. The text at the top is the given title, and the message is the given message. It will display for the given DisplayTime or will be dependant on the length of the message if no DisplayTime is given.

Makes the script instance given to all players when the enter the game, or just gives the script if they are already in the game. Used internally for the main local script, but this is publicly usable. It puts the script into PlayerScripts.

Parents the given script to the player’s PlayerScripts. This command exists because PlayerScripts can’t be accessed by the server.

Returns a string giving the Hour, Minutes, Seconds, and Part of Day (XX:XX:XX AM/PM). Based on Eastern Standard Time with daylight savings time based on 2015 (may be disablable in the future since not everyone uses it).

Creates a new command to load when the system is loading. This should be in the module required by the system to ensure it will get loaded, because it is impossible to add new commands after the system loads to prevent a security issue. The CommandData table can contain the following:

Prefix (Optional) - Prefix for the command.

Keyword - Keyword for the command. Important for players to index the command. Should contain no spaces.

ForceOverride (Optional) - If true, it will override any other command with the same Keyword and Prefix, assuming that the command to override doesn’t have Unoverridable true. This is optional if you don’t want to override another command, such as if it fully implemented or someone else uses it.

Unoverridable (Optional) - If true, the command can’t be overriden, even if ForceOverride is true.

AdminLevel (Optional) - Minimum admin level to use a command. If it isn’t given, it defaults to -1.

ArguementsHelp (Optional) - String that goes with the command in :cmds/:commands/!cmds/!commands to help show the arguements for a command.

ExtraInfo (Optional) - Tooltip used by :cmds/:commands/!cmds/!commands. No tooltip is shown if ExtraInfo isn’t given.

CommandGroup (Optional) - Used for organization in :cmds/:commands/!cmds/!commands for grouping with other commands. Goes under “Ungrouped commands” if not given.

OnCommandLoad (Optional) - Function invoked when a command is loaded. This is useful if a command doesn’t override another or if another command overrides it.

Arguments (Optional) - A table of arguments that OnCommandInvoked will be given. There is a more in depth explanation below.

OnCommandInvoked (Optional) - Function invoked whenever the command is used. It will have the parameters of the player that invoked the command, the original message said (useful for storing the log), and any additional parameters specified in Arguments.

Using Arguments
Arguments is a pretty robust system for picking the parameters to appear in OnCommandInvoked, with the table able to include:

LongString - The rest of the given message.

String - The next word (not separated by a space) Number' - A single number

TableOfNumbers - A set of numbers (ex: 6,1,8,7)

Bool or Boolean- A bool value (speaker can say y,yes,t or true for true, and n,no,f, or false for false)

TableOfPlayers - A table of the players in the game by name.

TableOfAllPlayersById - A table of all players that have entered the game by their id (with the matching names given by the person who said the command)

TableOfAllPlayersByName - A table of all players that have entered the game by their username (with the matching names given by the person who said the command)

Color3 - A Color3 (formed by Number,Number,Number in a command)

Vector3 - A Vector3 (formed by Number,Number,Number in a command)

Table of the previous arguments - For cases where a command can accept more than one type of argument, a table can be given that it will go through to see if it can give that argument, starting with the first entry until the end. If none fit, it gives nil

API (Client)
Similar to the server API, it can be obtained by using. This API is for the use in LocalScripts only, with the API given below:

Version is a string that contains the version of the API. It is more for displaying the version rather than comparing versions.

VersionNumberId is a number containing the actual version as a number for the API. This should be used for comparing or getting a build id, since it will increment by 1 every time behavior is changed or the API is changed.

EventContainer is a folder in ReplicatedStorage for storing RemoteEvents and RemoteFunctions. It isn’t anything fancy, just for organization. It isn’t required to use.

Returns the ScreenGui in use by the main local script. More for organization or not having to create your own. If there is no current ScreenGui, it will create a new one and return that.

Creates a message for the player that the local script is assigned to. The text at the top is the given title, and the message is the given message. It will display for the given DisplayTime or will be dependant on the length of the message if no DisplayTime is given.

Creates a line of text on the top of the screen for the player that the local script is assigned to. The message is the message given, and DisplayTime is an optional argument for how long it displays. By default, it is dependant on the length of the string.

Used for getting data via the server without overbloating the API on the client. It will not return an error if an invalid name is given because it is just networked to the server. Currently contains:

CommandLogs - Returns the logs of the commands. Stores up to 500 entries.

Bans - Returns a table containing the banned users by UserName

Admins - Returns a table containing the admins by their username.

CommandsDataByGroup - Returns a list of commands usable by the local player. The original table contains a set of tables, with the key being the group the commands are sorted under, and the table containing tables with all of the command data.

Creates a scrolling list box, same used for logs, with the name being the name of the box, RefreshFunction being a function for when refresh is hit and first rendering, given the parameter of the scroll frame, and OnCloseFunction being an optional function that is invoked when the gui closes.

Returns the text bounds given the font, size, weather it is wrapped at the ends, size of the textlabel, and if it clips or not, with the given text. Currently creates and destroys a TextLabel, but will move to the GuiService if it becomes unlocked.

Creates a TextLabel with the given text (can be multiline using \n) that will show when the mouse enters the given frame. It automatically clears whenever the instance is removed.

Returns a string giving the Hour, Minutes, Seconds, and Part of Day (XX:XX:XX AM/PM). Based on Eastern Standard Time with daylight savings time based on 2015 (may be disablable in the future since not everyone uses it).

Features
The admin system is meant to have a lighter presence on the server rather than the alternatives. The main feature left out is game pass support for awarding ranks, because they don’t serve a purpose in full games using the system unless it is a low quality game relying on sales of admin game passes for profit.

Also, there is no integrated perma-admin or perma-ban commands because the system does not have an DataStore presence, at least for the standard commands. There is still a lot of IsInGroup calls depending on how often players enter a game and how many groups are in the group admin list.

”Anti-Exploit”
There is restrictions in the API for a good reason. An API to change admin levels, having InvokeCommand not require a reference user, and being able to load in a new command at any time, are all heavily exploitable, especially in non-FilteringEnabled games or FilteringEnabled games with command packs.

Also, there is no anti-exploit system in place for one reason - they either fail or punish players who aren’t exploiting, and also have a massive overhead in terms of performance. This should only be concerning to non-FilteringEnabled games, since FilteringEnabled games normally don’t see exploits outside of no-clipping and speed-”hacking”. The way around this is to make a game work with FilteringEnabled, then the lacking of anti-exploit methods is not an issue. Command packs can be added to fill in the missing part, but no guarantee that they will do as they say.