[Discussion]: Export driven developer API in monitor script

[TasoOneAsia]

Scope

Developer API

Feature Description

Summary
Provide a public API for third party resources to trigger methods or fetch useful data within txAdmin.

API Scope
This export API should be limited mainly to txAdmin Game Script related functionality defined in the scripts folder. No relaying of data should be done through game scripts as a means of communicating with the txAdmin backend.

Possible Concerns

• What limitations should we establish for exposing internal methods & data?
• Should we tie txAdmin player state directly into a state bag, or should we prevent undefined behavior by not allowing for this data to be directly mutated by a user?

This API's structure and scope is not final and is open to feedback and comments from contributors and users.

Use Case

• Enables implementation of Suggestion: Timed Announcements/Chat Messages #390 through export calls
• Tie into menu state for correct handling of players (Ex. To check if a player has been frozen by a server moderator before modifying a ped's state)

We encourage you share any use cases for exports that you may find useful

Additional Info

Proposed Examples:

--- An export returning whether a player has a given txAdmin permission
--- if the player has the 'all_permissions' flag, this function will always
--- return true.
--- @param playerSrc number|string The target player's server ID
--- @param permission string The permission to check against
local function doesPlayerHavePermission(playerSrc, permission)
  return PlayerHasTxPermission(playerSrc, permission)
end
exports('doesPlayerHavePermission', doesPlayerHavePermission)

--- Add an announcement using the in-game menu announcement
--- alerts.
--- @param msg string The announcement message to display
local function addAnnouncement(msg)
  TriggerClientEvent('txAdmin:receiveAnnounce', -1, msg)
end
exports('addAnnouncement', addAnnouncement)

See the following somewhat related issues #179, #436

[TasoOneAsia]

As stated in the PR's description, none of the implementation details above are considered final and are open to suggestions

[MonsterZockerHD]

Sup, so basically what I would need and probably many others too are functions for:

• banning a player
• kicking a player
• warn a player
• send stuff to server log easily, not something like (TriggerServerEvent('txaLogger:DebugMessage', 'Goats are ugly')

Banning a player
Would be nice to have for Anticheats to trigger. Therefore, a function would need to contain:
script-label (to identify the resource it's coming from more easily), player, reason

Kicking a player
Would be nice to have for Anticheats to trigger too (And similar detection methods, like the ones included in some ESX-based scripts). Therefore, a function would need to contain:
script-label (to identify the resource it's coming from more easily), player, reason

Warn a player
Would be nice to have for Anticheats to trigger, in addition it could be useful for people using bad words in the chat or other similar stuff. : Therefore, a function would need to contain:
script-label (to identify the resource it's coming from more easily), player, reason

and the most important function:
Sending stuff to the log more easily. A function would need to contain the options:
script-label (to identify the resource it's coming from more easily), player, message, category

Feel free to reply.

[Druganov1]

Yes, this would be so nice, since right now we have 3 possible ways that player can get banned

1. TxAdmin
2. Anticheat
3. Fake triggers, we use el_bwh currently to ban people that execute fake triggers

It would make it so easier to just have a server event like

RegisterServerEvent('txadmin:events:banplayer')
AddEventHandler('txadmin:events:banplayer', function(playerid, reason, expire)
end)

expire, if you enter never the ban will be permanent, but you also can have syntaxes like 1d 1h 1j 1w 1m and so on

[DamonOnYT]

Playtime (Both Server & Client Hooks)

I'd love to see something that would allow me to easily get the playtime of a player, both in seconds (if its recorded in such way) and also the displayed date.

An example for a use case would be the following

AddEventHandler('playerConnecting', function(name, setKickReason, deferrals)

// defferal stuff here

	local license = ExtractIdentifiers(src).license;
        local playtime = exports.txAdmin:GetPlaytime(license, "seconds")
 
 // I would use it to give an ace perm here,

// end defferal
end)

[Alexr03]

**Playtime *(Both Server & Client Hooks ***

I'd love to see something that would allow me to easily get the playtime of a player, both in seconds (if its recorded in such way) and also the displayed date.

An example for a usecase would be the following

AddEventHandler('playerConnecting', function(name, setKickReason, deferrals)

// defferal stuff here

	local license = ExtractIdentifiers(src).license;
        local playtime = exports.txAdmin:GetPlaytime(license, "seconds")
 
 // I would use it to give an ace perm here,

// end defferal
end)

+1 this. Would be great to get this data

[ItsVinnyX]

**Playtime *(Both Server & Client Hooks ***
I'd love to see something that would allow me to easily get the playtime of a player, both in seconds (if its recorded in such way) and also the displayed date.
An example for a usecase would be the following

AddEventHandler('playerConnecting', function(name, setKickReason, deferrals)

// defferal stuff here

	local license = ExtractIdentifiers(src).license;
        local playtime = exports.txAdmin:GetPlaytime(license, "seconds")
 
 // I would use it to give an ace perm here,

// end defferal
end)

+1 this. Would be great to get this data

Uhm... yes PLEASE!

[XenoSphinx]

Sup, so basically what I would need and probably many others too are functions for:

* banning a player

* kicking a player

* warn a player

* send stuff to server log easily, not something like `(TriggerServerEvent('txaLogger:DebugMessage', 'Goats are ugly')`

Banning a player Would be nice to have for Anticheats to trigger. Therefore, a function would need to contain: script-label (to identify the resource it's coming from more easily), player, reason

Kicking a player Would be nice to have for Anticheats to trigger too (And similar detection methods, like the ones included in some ESX-based scripts). Therefore, a function would need to contain: script-label (to identify the resource it's coming from more easily), player, reason

Warn a player Would be nice to have for Anticheats to trigger, in addition it could be useful for people using bad words in the chat or other similar stuff. : Therefore, a function would need to contain: script-label (to identify the resource it's coming from more easily), player, reason

and the most important function: Sending stuff to the log more easily. A function would need to contain the options: script-label (to identify the resource it's coming from more easily), player, message, category

Feel free to reply.

Along with this I also suggest an API integration where the bot can come back with the status and connection info for the server (as of now I can add in the simple line of code to reply with the connection information. but would like to have it added where the API also returns with online/offline using a simple check of the server IP (I might be overthinking and thinking it maybe just something i can code into the bot to ping the IP address and have it return with online/offline.))

[NextZac]

This could come in useful for a lot of things. Currently working on creating a website where administrators can have access to not only FiveM Features, but also for other administrative things. This would let me create a resource where I could push data via Pusher to my Laravel PHP server and get info about Players and the Server itself. Allowing me to log and use the information to my liking. Having it stored in one place is quite a big thing for me, as it allows administrators to work quicker and not having multiple accounts for different things.

I get that I could already do this, but this API would make it so much easier for everyone.
Would be a great addition in my honest opinion.

Having the ability to use txAdmin accounts for checking permission in game would make it also way easier to identify when and who used a command/event. And thus being able to log it into one place.

[Alexr03]

This could come in useful for a lot of things. Currently working on creating a website where administrators can have access to not only FiveM Features, but also for other administrative things. This would let me create a resource where I could push data via Pusher to my Laravel PHP server and get info about Players and the Server itself. Allowing me to log and use the information to my liking. Having it stored in one place is quite a big thing for me, as it allows administrators to work quicker and not having multiple accounts for different things.

I get that I could already do this, but this API would make it so much easier for everyone. Would be a great addition in my honest opinion.

Having the ability to use txAdmin accounts for checking permission in game would make it also way easier to identify when and who used a command/event. And thus being able to log it into one place.

I'm in a similar boat. We also have a custom admin panel for our staff and our players to trade vehicles with eachother, do administrative tasks or for staff to screenshot players screens/kick/ban etc.

The main data I am looking to get from txAdmin is the Play time/session time and a REST API or exports to kick/ban players.
Something that allows me to sort my own player list of the most recently joined players. Turns out this is really helpful for catching hackers.

[Rhydium]

Sup, so basically what I would need and probably many others too are functions for:

• banning a player
• kicking a player
• warn a player
• send stuff to server log easily, not something like (TriggerServerEvent('txaLogger:DebugMessage', 'Goats are ugly')

Banning a player Would be nice to have for Anticheats to trigger. Therefore, a function would need to contain: script-label (to identify the resource it's coming from more easily), player, reason

Kicking a player Would be nice to have for Anticheats to trigger too (And similar detection methods, like the ones included in some ESX-based scripts). Therefore, a function would need to contain: script-label (to identify the resource it's coming from more easily), player, reason

Warn a player Would be nice to have for Anticheats to trigger, in addition it could be useful for people using bad words in the chat or other similar stuff. : Therefore, a function would need to contain: script-label (to identify the resource it's coming from more easily), player, reason

and the most important function: Sending stuff to the log more easily. A function would need to contain the options: script-label (to identify the resource it's coming from more easily), player, message, category

Feel free to reply.

In addition to this I (and probably many others) would also like to be able to request a player history (with their previous warns, bans, kicks, etc.).
So basically all the administrative tasks should be included.

[roobr]

Would be good to add in:

• an export for turning on and off the player whitelist from serverside export (ultimately use it in our own discord bot)
• an export to add notes to a player (ultimately use it in our own discord bot for out of game moderation)

For example:
we have a PVP server that is only up during a set timeframe and would like to automate the server to unwhitelist when the time frame has been reached, and also be able to write a bot to be able to allow people on discord to vote for the server to come up earlier (irrelevant to this)

I also agree with the playertime export, can be used really well to catch hackers (money vs playtime) and show up on the loading screen (we currently use the players.json and read it each time a player joins to do this without tx having any export in)

Thanks for your time

[menstruated]

Anything such as triggering a server event to restart such as txAdmin:RestartServer, allowing me to use a permission framework that would mean players with certain groups could trigger server restarts. Rather than relying on giving them perms via the cfg using identifiers. Would also make it dynamic, meaning I wouldn't have to restart the serve to allow people perms, nor give them access to the txAdmin menu entirely.

[Dalrae1]

All of these ideas would be awesome to add. Banning, kicking, warning, restarting, stopping, or starting resources, getting player info such as playtime and join date, as well as all player punishment history.
Settings such as the Restarter feature would be a nice add, however not something that I would consider to be very useful if a simple restart export is added.
A way to get server diagnostic data would be extremely useful too.

[tabarra]

Just a quick note here on the thread: We are not actively replying but we are 100% taking note of everything being requested.
Keep the feedback coming, they are great.

[TasoOneAsia]

A way to get server diagnostic data would be extremely useful too.

What data specifically are you looking to consume? @Dalrae1

[Dalrae1]

What data specifically are you looking to consume?

I was thinking everything in the "diagnostics" tab, so:

• Server uptime
• Enviroment details (Node version, operating system, CPU & memory usage)
• txAdmin version

General stuff like that @TasoOneAsia

[TasoOneAsia]

What data specifically are you looking to consume?

I was thinking everything in the "diagnostics" tab, so:

• Server uptime

• Enviroment details (Node version, operating system, CPU & memory usage)

• txAdmin version

General stuff like that

A lot of this data is already available through default APIs, in the same manner txAdmin retrieves this info. I'm concerned that such an abstraction would serve no purpose if it isn't only attainable through a txAdmin API.

[Dalrae1]

What data specifically are you looking to consume?

I was thinking everything in the "diagnostics" tab, so:

• Server uptime
• Enviroment details (Node version, operating system, CPU & memory usage)
• txAdmin version

General stuff like that

A lot of this data is already available through default APIs, in the same manner txAdmin retrieves this info. I'm concerned that such an abstraction would serve no purpose if it isn't only attainable through a txAdmin API.

I don't know what data you're referring to, other than "Server Uptime" (Which would require a separate resource to reliably get)
With environment details, it is possible to retrieve this info with c# or Javascript, though if using lua, a c# or Javascript wrapper would be required to retrieve any of that information.
Afaik, the txAdmin version is not externally accessible via any means.

Though much of the information is possible to get, having a separate resource (Such as txAdmin), which already uses this information, to act as an API to retrieve it would be very convenient. Similar to the "baseevents" resource included in cfx-server-data

@TasoOneAsia

[TasoOneAsia]

@Dalrae1 Thanks; we'll keep this suggestion in mind. My hesitation for adding an abstraction of this sort is just that it further increases the API surface that we need to maintain actively.

As you said, you can retrieve env information using a C# or JS resource implementation for the timebeing. If you'd like to retrieve the txAdmin version, you can use the following non-replicated ConVar txAdmin-version; keep in mind that this isn't formally documented and (although unlikely) may be subject to change in future versions.

Edit: At the end of the day, we would like to scope this API strictly to txAdmin functionality, and you can see how sys information abstraction of this sort does not fall under the scope of strictly tx functionality.

[Dalrae1]

@Dalrae1 Thanks; we'll keep this suggestion in mind. My hesitation for adding an abstraction of this sort is just that it further increases the API surface that we need to maintain actively.

As you said, you can retrieve env information using a C# or JS resource implementation for the timebeing. If you'd like to retrieve the txAdmin version, you can use the following non-replicated ConVar txAdmin-version; keep in mind that this isn't formally documented and (although unlikely) may be subject to change in future versions.

Edit: At the end of the day, we would like to scope this API strictly to txAdmin functionality, and you can see how sys information abstraction of this sort does not fall under the scope of strictly tx functionality.

Alright, that makes sense

[tabarra]

@JordanZABOT Nope.

[JordanZABOT]

Is this, or anything else in this thread, something that you guys are working on, or might be added in the future?

[JordanZABOT]

I can assist you guys with the resource I have made that parses the player data json to get connection time and playtime ect. Although the functionality implemented would be great to be able to ban ect Get Outlook for iOShttps://aka.ms/o0ukef
…

Can you please tell me more? Maybe link to get a hold of you regarding this?

[adweex]

Playtime extraction example. Used ox.lib callback for it.

--- Fetches the data from playerDB.json file
---@return string | nil -- or maybe table
local function getTxAdminData()
    local file_path = 'C:\\{where_is_your_server_located}\\txData\\{profile_name}\\data\\playersDB.json'
    local file = io.open(file_path, "r")
    if not file then
        print("Could not open file: " .. file_path)
        retur
    end

    local file_content = file:read("*a")
    file:close()

    return file_content
end

---@param source number
---@return number
lib.callback.register('rn-core:server:GetPlayerPlayTime', function(source)
    local name = QBCore.Functions.GetPlayer(source).PlayerData.name
    local data = getTxAdminData()
    if not data return 0 end
    local t = json.decode(data)
    for _, v in pairs(t.players) do
        if v.displayName == name then
            return v.playTime
        end
    end
    return 0
end)

[endlessrpfivem]

That's exactly what I did, the problem is that our playersDB.json is 12.9MB, causing a huge threadhitch. I actually just coded almost exactly what you have just last night lmao.

Citizen.CreateThread(function()
    while true do
        f = assert(io.open("C:/txData/default/data/playersDB.json", r))
        if f ~= nil then
            local contents = f:read("*all")
            decoded = json.decode(contents)
            f:close()
        else
            print("ERROR READING PLAYER DB")
        end
        Citizen.Wait(5 * 60000)
    end
end)

RegisterCommand("playtime", function(source)
    for k, v in ipairs(GetPlayerIdentifiers(source)) do
        if string.sub(v, 1, string.len("discord:")) == "discord:" then
            discordId = v
        end
    end
    if decoded ~= nil and discordId then
        for k,v in pairs(decoded.players) do
            for i,c in pairs (v.ids) do
                if discordId == c then
                    TriggerClientEvent("chatMessage", source, '[SYSTEM]', { 255, 0, 0 }, "Your playtime is "..disp_time(v.playTime))
                end
            end
        end
    end
end)

function disp_time(timevalue)
    local days = math.floor(timevalue/1440)
    local hours = math.floor(timevalue/60)-(days*24)
    local minutes = timevalue-(hours*60)-(days*1440)
    if days < 1 then
        string = hours.." Hours, "..minutes.." Minutes"
    elseif hours < 1 then
        string = minutes.." Minutes"
    else
        string = days.." Days, "..hours.." Hours, "..minutes.." Minutes"
    end
    return string
end

[adweex]

That's exactly what I did, the problem is that our playersDB.json is 12.9MB, causing a huge threadhitch. I actually just coded almost exactly what you have just last night lmao.

Yes, that is why i scrapped the whole thing. Well i wrote a server side script for playtime counting. Basically save the login time, and when the player exits then substract the two values then store it in the sql.

[czsquizer]

Hello, it would be cool to get any export to check if a player/player identifier is banned or not.
It would be usesful for scripts that remove player interiors/properties when they are inactive for too long -> to check if they are inactive or banned.

[zaneishurt]

You should design an API that serves as a powerful tool for RP servers, enabling staff members to efficiently manage user-related actions and monitor server activity directly from their custom websites, streamlining administrative tasks and enhancing the overall server management experience.

I've provided an example below of super useful information.

Endpoints:

1. User Information:

• GET /user/:userId: Retrieves detailed information about a specific user, including playtime, join date, last connection, ban status, ban history, warning history, current location, notes, recent actions, player identifiers, and hardware IDs.

2. Actions:

• POST /action/ban/:userId: Bans the specified user from the server. Requires providing a reason, duration, and optionally additional notes or evidence.
• POST /action/unban/:userId: Removes the ban on the specified user, allowing them to access the server again.
• POST /action/editnotes/:userId: Allows administrators to modify or add notes regarding the specified user for reference.
• POST /action/addwarning/:userId: Issues a warning to the specified user for violating server rules or guidelines. Requires specifying a reason.
• POST /action/removewarning/:userId/:warningId: Removes a warning previously issued to the specified user, if necessary.

Authentication and Authorisation:

• Token-based authentication for API access
• Role-based access control for API endpoints (e.g., admin-only actions)

Integration and Extensibility:

• Webhooks for real-time notifications of events (e.g., user bans, warnings)
• Integration with third-party services (e.g., Discord) for notifications and alerts
• Plugin system for adding custom functionality or integrating with other server management tools

Documentation and Support:

• Comprehensive API documentation with examples and usage guidelines
• Developer support and community forums for assistance and troubleshooting
• Versioning of the API to manage changes and backwards compatibility

[ZioMark13]

You should design an API that serves as a powerful tool for RP servers, enabling staff members to efficiently manage user-related actions and monitor server activity directly from their custom websites, streamlining administrative tasks and enhancing the overall server management experience.

I've provided an example below of super useful information.

Endpoints:

1. User Information:

• GET /user/:userId: Retrieves detailed information about a specific user, including playtime, join date, last connection, ban status, ban history, warning history, current location, notes, recent actions, player identifiers, and hardware IDs.

2. Actions:

• POST /action/ban/:userId: Bans the specified user from the server. Requires providing a reason, duration, and optionally additional notes or evidence.
• POST /action/unban/:userId: Removes the ban on the specified user, allowing them to access the server again.
• POST /action/editnotes/:userId: Allows administrators to modify or add notes regarding the specified user for reference.
• POST /action/addwarning/:userId: Issues a warning to the specified user for violating server rules or guidelines. Requires specifying a reason.
• POST /action/removewarning/:userId/:warningId: Removes a warning previously issued to the specified user, if necessary.

Authentication and Authorisation:

• Token-based authentication for API access
• Role-based access control for API endpoints (e.g., admin-only actions)

Integration and Extensibility:

• Webhooks for real-time notifications of events (e.g., user bans, warnings)
• Integration with third-party services (e.g., Discord) for notifications and alerts
• Plugin system for adding custom functionality or integrating with other server management tools

Documentation and Support:

• Comprehensive API documentation with examples and usage guidelines
• Developer support and community forums for assistance and troubleshooting
• Versioning of the API to manage changes and backwards compatibility

This should be done ASAP <3 i completely agree, this would change the way we moderate, follow and develop moderation tools for your servers

[SeaLife]

Just adding my idea: I'd like to dynamically add new admin accounts (and remove admin accounts) from a management platform.

We'r using Gitlab for our Script Hosting, Discord Roles for in-game permissions and discord permissions and the txAdmin account for additional features like noclip and stuff.

I'd like to create a management platform where i create the users accounts and the platform will then proceed and assign the required roles in discord, create a txadmin account and assign the required gitlab projects to the account, add the account to the grafana org, ... (and many more, just the beginning).

The point in doing smth like this: If a Admin leaves the team i dont want to delete the users everywhere. Currently i have a check list for me in case a team member leaves so no permissions will be left. (like blocking the user in the SSO server, blocking the gitlab access, removing the txAdmin user, revoking the discord roles, setting the user group of ESX back to user, ....)

For everything i can use APIs but not txAdmin so far :D

My proposal for this would look smth like this:

POST /api/users with a request body like this:

{
  "username": "SeaLife",
  "discord": 1,
  "fivem": "SeaLife",
  "permissions": ["all_permissions"]
}

And removing a user by its username:

DELETE /api/user/:userIdentifier (DELETE /api/user/SeaLife)

Using any identifier should be possible i guess, so fivem:SeaLife or SeaLife or username:SeaLife or discord:1

Regards

[tabarra]

@SeaLife For admin management, I would prefer to use some standard protocol... but there are so many, and most are old ugly legacy enterprise protocols.

[roobr]

Hi Tabarra, is there any apis open yet for stop/start ect? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: tabarra ***@***.***> Sent: Saturday, March 30, 2024 10:45:19 AM To: tabarra/txAdmin ***@***.***> Cc: roobr ***@***.***>; Comment ***@***.***> Subject: Re: [tabarra/txAdmin] [Discussion]: Export driven developer API in monitor script (#442) @SeaLife<https://github.com/SeaLife> For admin management, I would prefer to use some standard protocol... but there are so many, and most are old ugly legacy enterprise protocols. — Reply to this email directly, view it on GitHub<#442 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACFFR7PEGULKWMVVEXFDWLLY2X4I7AVCNFSM5DXZ4LEKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSG44DENJXHE3Q>. You are receiving this because you commented.Message ID: ***@***.***>

[Almighty-Show711]

I'd definitely be adding a function to our discord bot, allowing us to ban people in discord and txadmin at the same time. Would need:

API URL:
AUTH TOKEN:
Optional Message:

Would be muchly appreciated!
Definitely something we'd like to see added someday.

[IkonoDim]

I'd really appreciate seeing Things like:
Server shutdown, restart (POST /state)
Server stats (like cpu and mem usage) (GET /state)
Live Console (Websocket connection)
Player Screenshots (maybe also live transmittion via udp or ws conn in future)

[tabarra]

@IkonoDim The features you are requesting don't make much sense... you trying to replace the txAdmin ui?!

[IkonoDim]

@tabarra No. But here's a tittle explaination about how I'd use each of these features:

• Server shutdown/restart is self explainatory
• Server stats too
• Live console might be useful for e.g. a discord bot with the console or for instant error allerts to the admins
• Player screenshots would be cool for checking on ur players while ur not ingame

[Tfc538]

Our goal is to automate server updates, which would significantly streamline our workflow. The plan is to have a test server updated daily and the main server on a weekly basis, each tied to their respective Git branches.

A REST API would facilitate this process, allowing server management through endpoints like https://{server_ip}:{port}/api/v1/shutdownServer, with secure authentication via Bearer Token or User + Password. The challenge lies in ensuring TxAdmin remains operational during updates, which it isn’t if we need to shutdown FxServer in order to do this.

Also we can’t update while FxServer is running as this led to data corruption in earlier attempts.

[SeaLife]

Our goal is to automate server updates, which would significantly streamline our workflow. The plan is to have a test server updated daily and the main server on a weekly basis, each tied to their respective Git branches.

A REST API would facilitate this process, allowing server management through endpoints like https://{server_ip}:{port}/api/v1/shutdownServer, with secure authentication via Bearer Token or User + Password. The challenge lies in ensuring TxAdmin remains operational during updates, which it isn’t if we need to shutdown FxServer in order to do this.

Also we can’t update while FxServer is running as this led to data corruption in earlier attempts.

Hey, so we'r running a Pipeline with Gitlab CI for our scripts which works very well. The "Production" Server is restarted everyday at 10am. The Development-Server is restart every morning at 4am. With TxAdmin if you want to "restart" your Server from external, you could just "stop" the server by the console command "quit" and txAdmin will reboot it. (Is kinda klunky, but it works). We'r doing that on our pre-live server when updating ESX. (because ESX cant be restarted without konsequencens)

But, we'r running some custom pipeline scripts for this and our configuration for something like ESX looks like that:

spec:
  addon-name: es_extended
  directory: esx
  post-commands:
    pre-live:
      - 'quit "Updating ESX Framework"'
  dependencies: []

So you dont really need a restart API to do a restart if thats the only thing you care about.

[Tfc538]

Thanks @SeaLife for telling me this! Is there any way to then listen for when the Server is started again?

[SeaLife]

Thanks @SeaLife for telling me this! Is there any way to then listen for when the Server is started again?

Not as far as i know, but you could use a RCON library and check if the server responds to the RCON command as a workaround.

[tabarra]

Hey everyone, an API is finally on the works!

Very soon I'm starting the planning for the API, but no ETA on delivery just yet.
Thank all the 29 people that contributed for the discussion, and thank for your patience!

[xPiwel]

Hey everyone, an API is finally on the works!

Very soon I'm starting the planning for the API, but no ETA on delivery just yet. Thank all the 29 people that contributed for the discussion, and thank for your patience!

Hi there, any news on this ? :)

[ChickenDipper1]

Very much looking forward to delivery of this mainly so I can rely on one location (txadmin) for banning and tracking of bans.