This looks great! Does this have a feature for adding custom commands and configuring it to your liking?
I thought you were talking about playtime at first, but I just realized you meant account age. That seems like a bug maybe just a one-time thing, or maybe not.
playtime is tracked only as long exe version 6 was in your game
account age may say 3 months (which the account happens to be) which when shortened looks like 3 minutes (UI display issue)
It’s just a typographical error; the “m” stands for “months”, but it will be fixed in the next patch (Build 602) since it has caused much confusion.
Oh yeah that makes sense now, Thanks!
Playtime displays how long they have been on the server. If the player rejoined the same server, the Playtime should just resume. However, if they joined another server, it will be back to 0.
oh that explains it, ty
however i raise concern that just like wolfy and I misunderstood, we assume term “playtime” saves player’s total time spent playing our game.
Yes, Exe 6 supports a wide range of possibilities in Custom Commands. In fact, we have a whole section in our documentation for Custom Commands. Hopefully, this documentation will help you create your Custom Command.
There exists a bug when Exe 6 is reading out the ID/global/UserIdList left by Exe 5.
The format of the table entry is as follows:
“bannedUserId;ExpirationTimestamp;modUserId”
However Exe 5 does NOT include modUserId so Exe 6 displays the expiration timestamp as if it was the moderator issuing the ban.
Notice how expiration date is unknown and the “mod’s” userid is a timestamp happening May 08 2025, precisely when the issued 31 day ban ends.
When you do finally load 650+ records and revoke the ban, it forces a full reload of the ban list with the loading window open which prevents you from using exe until the entire ban list has loaded again.
Since there already exists a large ID/global/UserIdList table, you could nearly instantly create a UI element for every entry and then defer loading slow information for later. For optimisation’s sake, load only what is within the view.
Because that table exists, you could easily render each entry in chronological or reverse order.
The search bar should attempt to convert the username into a userid to instantly access that specific record when you unfocus the textbox.
The whole point is to reduce the need for the whole ban list to be loaded in order to perform ban actions.
Don’t get me wrong, the UX is very good, but no game developer in their right mind would use a licensed, closed-source solution (of which the main advertised feature is UI) compared to estabilished, trusted, open source systems like Adonis, HD Admin or Commander.
The main reason why I don’t use Adonis as a ban system is the issue of datastore randomly clearing completely and my fellow dev friend had the same issue erasing their “16k bans on top of the last 15k we had” ban list.
Also, HD Admin isn’t receiving updates as of late.
We’ve heavily refactored the datastore aspect of Adonis, and it is built with safeguards in mind to access previous database versions.
There has been a vulnerability in how permission levels were checked following a commit that shouldn’t have been pushed to release, and all datastore keys have been automatically changed to prevent bad actors from escalating permissions.
If this could be the reason for your data loss, please check out the Discord server as you will easily be able to transfer data to a new datastore key
Nice! I’ll consider purchasing it.
The incidents I described happened as far back as 2020-2023 and I just stopped trusting Adonis to keep the datastore in tact.
There is a vulnerability: all custom commands have no protection whatsoever. Exploiters can freely fire the remote to give themselves tools.
game.ReplicatedStorage.EXE6_STORAGE.utilities.custom_commands.Tools:FireServer({["Tools"] = {game.ReplicatedStorage.EXE6_STORAGE.utilities.tools["Building Tools"]}, ["Recipient"] = {game.Players.Player1}})
Additionally, licensing is not very secure. The system checks if there is a “NetworkClient” attribute in workspace, which is placed by the plugin, to check if it is licensed.
Custom commands have their own customized events that we cannot secure, You are responsible of securing them (With your own commands), Now, The tools command will be fixed in a future version.
Add this snippet to ServerScriptService.EXE6_SERVER.CustomCommands:
local Auth = require(script.Parent.Auth)
function catchExploiter(moderator)
if not Auth.IsAuthorized(moderator.UserId) then
moderator:Kick()
error(string.format("%s (%s) was caught exploiting Exe 6 custom commands remote event.", moderator.Name, moderator.UserId))
end
end
Also,
I get it, but default custom commands shouldn’t be left without any security because hardly anyone bothers to change the defaults.
We know that, Its part from us and it will be fixed, I will discuss this with the owner.
I bought it, tested for a few minutes, did not regret anything. If I ever find an idea for a game, I will use it.