Search / View

[Joe Kari]

Ricochet PM me and asked me some information about programming a bot (like B3, or the Perl script made by The Doctor). Since it can be of interest for many people, I take the liberty to share my reply with every one.

(...) i would like to get started on some programming for bots. We talked about this very briefly some time back.

Can you point me to any ressources on how to write bots, catching events and the like?
(...)

Hi,

Well, I have done a lot of work for bot, you can start searching the Changelog. Sorry, there is no proper documentation at the moment, but the changelog list every feature. You can find it with the source code.

Also I have started few month ago to write a PHP class to manage basic stuff, but I can't find the time to finish it.

What is your coding langage?

I don't remember exactly what I've already said to you.
Basicly, I have added some Rcon command, but the most usefull feature to write bots is the minilog.
Try entering /poplog into the console and you will see what I meant. Tons of event are recorded.

This was designed with the idea in mind that one centralized bot could connect to various external server (unlike B3, if I'm not wrong, who need to be installed on the same server, because it analyse log written on the filesystem).

I will explain you more later, I'm exhausted today (too much work :/).

Also, I take the liberty to copy the discussion in a public area, there are some people who might be interested.

In case you don't know, The Doctor have written a Perl script for SG 1.0, if you want to go with Perl, he can eventually help you. On the other hand, his script can be improved a lot with those new feature introduced in 1.1beta5.

[Joe Kari]

Also, a good start could be to use the minilog event named SAY.
Everything that someone enter in the chat throw this event.
So if you want a bot that allow game moderator without rcon, you can analyse their sayin'.
For example, B3 catch every chat line starting with the exclamation mark "!", it is meant to be a command line rather than chit-chat.

Also I introduced the command /secret in 1.1beta5. This command does nothing except throw an event into the minilog. That's it: nothing is written on screen, nothing is logged on the filesystem, nowhere, except in the minilog. Obviously, the event is named "SECRET".

If I'm the player #3 of the server and I enter in the console "/secret test", the minilog will have the line:
SECRET: 3 > test

You can use it in conjunction with the SAY event, for example, to allow some moderator of your bot to enter command without being spotted by other players as a moderator.

EDIT:
The generic format for the minilog is:
<event>: <arguments> <arguments> <arguments> ...

"event" is always in uppercase.

Sometime you will see the arrow: "=>", it means that what is on the left side has caused the event on what is on the right side.

The KILL event for example:
KILL: 1 => 2 [MOD_SAWEDOFF]

... means that player with the ID #1 have killed the player with the ID #2 with a sawed off shotgun.

HIT: 1 => 2 (16) [leg] [MOD_SAWEDOFF]

... means that player #1 hit player #2 in the leg for 16 hitpoints damage with the sawed-off shotgun.

Be carefull, there are variation of KILL and HIT event, don't forget to catch them all: TEAMHIT, TEAMKILL, SELFHIT, SELFKILL, WORLDHIT, WORLDKILL.

Also a very usefull command to parse for a bot is the /clientid command.
The /clientstatus and /playerstatus command are more suitable for humans, it gives colorful information... I think admins will love them.

[dansh]

Great news. It will be very convenient to have a bot for control over the server. And even more convenient, if the this bot will work without a heavy database mysql
I hope your game-BOT will be publicly available for installation.
B3 has a way to connect remotely to the game server, logs read via ftp.

[Joe Kari]

Great news. It will be very convenient to have a bot for control over the server. And even more convenient, if the this bot will work without a heavy database mysql

I was planning to do my bot with PHP-MySQL, sorry
But there are good chance that someone else finish his bot before, since I haven't write a line in months...

[ricochet]

This helps a lot already and i see how a bot can be integrated. Requires a lot of RCON connections if the bot is to react quickly though. I dont know how robust SG is in that matter regarding scalability.

My language of choice is Perl mostly, but i could also imagine Python or Ruby if someone else liked to cooperate and doesnt like Perl
I do speak Java also, but i am not sure if i want to do that amount of text processing with it.

I would imagine a plugin architecture; a centralized service that loads plugins dynamically and passes on events with some subscription mechanism. Everything else is bound to fail anyway since the events from the minilog are consumed on read.

So what i can provide?
1) I could design and build the centralized service first of all, so one has not to bother with all the details of retrieving the events anymore. This might take a while, but after that functionality can be added very easily.

2) I would like to transfer Doc's ban script into a module for that service. Since a lot of the logic exists, this should be not very big task.

3) Next on my list would be a module for authentication using the SECRET command. This again would take quite a while since one would have to make sure that all kinds of bruteforce and code injection attacks can be prevented.

4) From there one could build an admin-tool that allows authenticated users to execute a (configureable) subset of rcon commands via SECRET. This would be a very handy feature i think. Given all of the above exists already, this can be done very quickly.

I dont know where you were going with your bot, Joe - if you were heading the same direction i should maybe consider to start working from your codebase. I have to admit though that the thought of writing php sends shivers down my spine

[Joe Kari]

As far as I remember, my PHP class was able to perform interactive rcon to a server.
Not a big, just a one-day-work.
If you are serious about this bot stuff, what I have already done is not enough to move you away from your favorite langage

Also I have had in mind 3 differents authentications system:
- IP
- GUID
- /secret !password command

For example, an admin may want to enforce an IP-based authentication... But what if one of its deputy doesn't have a static IP? Then he will be able to set GUID-based authentication for this particular deputy... Or maybe IP && GUID, or IP || GUID, or whatever it please him...

Something flexible sounds great to me.

Note that IP and GUID authentication are mandatory to kick banned cheater, so at the same time it could be used to autolog deputy too.

Also, in my mind, the /secret command should act the same than a mere chat command, I mean that the module should process SECRET event and SAY event the same way.
So IMHO, registering with its password should not be something like
/secret <password>
... but something like:
/secret !password <password>

The /secret command can be used to throw command without being spot.
For example you may use:
/secret !kick toto
... rather than typing it directly in the chat, so nobody will know who is the admin.

Just my 2 cents.

[ricochet]

As far as I remember, my PHP class was able to perform interactive rcon to a server.
Not a big, just a one-day-work.
If you are serious about this bot stuff, what I have already done is not enough to move you away from your favorite langage

Ok. I am somewhat glad

Also I have had in mind 3 differents authentications system:
- IP
- GUID
- /secret !password command

For example, an admin may want to enforce an IP-based authentication... But what if one of its deputy doesn't have a static IP? Then he will be able to set GUID-based authentication for this particular deputy... Or maybe IP && GUID, or IP || GUID, or whatever it please him...

I strongly disagree here. IP is ridiculously easy to fake with UDP, GUID is trivial to fake, too. Using either as single authentication mechanism is nothing i would ever implement and release to the public. They could serve as additional mechanisms (PASSWORD && IP) but i even doubt that the security gain you achieve with that outweights the implementation effort.

Note that IP and GUID authentication are mandatory to kick banned cheater, so at the same time it could be used to autolog deputy too.

Lets call that rather identification than authentication.

I like the approach of Doc's script and you may or may not know that we have a web-interface to manage the bans that are fed to the script. I am willing to make the code for the web-interface public as soon as i think it has release quality (i would of course make it public for other devs now on request). Together this makes quite a complete toolkit to manage bans across different servers.

IMHO the rcon/secret interface, be it ingame, be it via monster browser or xqf is much too cumbersome to manage bans, so i personally want to stick to the web-interface for that purpose.

But i see how other people might need to be able to manage their bans via rcon/secret. In the end this will have to result in one module to enforce bans and two interchangeable modules to manage bans. I am not sure i will implement both modules to manage the bans, but i will keep the desing open so it is possible to plug one in easily.

Also, in my mind, the /secret command should act the same than a mere chat command, I mean that the module should process SECRET event and SAY event the same way.
So IMHO, registering with its password should not be something like
/secret <password>
... but something like:
/secret !password <password>

Yep, that is exactly what i had in mind, too.

[Joe Kari]

IMHO the rcon/secret interface, be it ingame, be it via monster browser or xqf is much too cumbersome to manage bans, so i personally want to stick to the web-interface for that purpose.

I don't see why it would be complicated to type: !ban <player ID>.
I understand that the unban process (or ban time adjustement) is easier to manage on a web application, but it is always good to be able to ban someone when you are still in game: the moment you catch him is when you have to ban him.

[/dev/random]

I strongly disagree here. IP is ridiculously easy to fake with UDP, GUID is trivial to fake, too.

I yet have to see a fully connected player from a fake IP (unlike q3fill and similar). And those are the only ones of interest to identify against a deputy database.
GUID in ioquake3 (without PunkBuster) was never meant to uniquely and securely identify each player in the long term.
You can however use (static) IPs and/or GUIDs in combination with a password (i.e. a login without an explicit username) to authentificate deputies.

What's it about writing yet another server bot? B3 is rather fully blown and already has all of the features you list (in combination with Echelon). There are also serveral similar, yet less featured, bots for Urban Terror, mostly open source.

Rcon is usually rate limited per IP. You should implement whitelist filtering to only allow your bot's IP and don't do any filtering for those IPs either.
If you'd need even more "rcon" input (which I doubt), you'd have to feed your commands directly into the sg_ded process, using a pipe (similar to com_pipefile) or some entirely new and yet-to-write mechanism.
Keep in mind that ioquake3 is single threaded, so flooding it with (your legitimate) rcon commands might actually hurt game performance.

[Joe Kari]

Keep in mind that ioquake3 is single threaded, so flooding it with (your legitimate) rcon commands might actually hurt game performance.

I can't see why a bot would flood. In my test, I was calibrating my script to get the minilog (/poplog command) every 2 seconds. In case the bot has something to do (like kicking a banned player), he will send another rcon. I can imagine only few rare cases where a bot would have to react with a lot of command, and it would be temporary (when all offending players are banned, we are safe again).
I think the CPU cost for a well written bots is really minimalistic.

What's it about writing yet another server bot? B3 is rather fully blown and already has all of the features you list (in combination with Echelon). There are also serveral similar, yet less featured, bots for Urban Terror, mostly open source.

Why? Few reasons:
- using SG's minilog feature that allow a bot to be on another server (yes I know Dansh told that B3 could work via FTP, but not many server's admin will setup a FTP for that).
- make SG's specifics things. For example in my fool's dreams, I imagined a server where you can shoot and play poker... Good poker players would be able to earn more money, so more fire-power... Money would be saved from a session to another. Sounds like a great idea to me! We can imagine many others ideas, like third-party game-mode done directly by bot: that's why I have introduced a lot of new rcon command (like adjusting someone's gold, etc)
- the fun of coding it

[/dev/random]

I can't see why a bot would flood.

If it is designed properly, it should not flood. I merely added this statement due to ..

Requires a lot of RCON connections if the bot is to react quickly though. I dont know how robust SG is in that matter regarding scalability.

.. which sounds like the command rate via rcon might not be enough.

- using SG's minilog feature that allow a bot to be on another server (yes I know Dansh told that B3 could work via FTP, but not many server's admin will setup a FTP for that).

I don't have the B3 manual at hand, but I guess you could just use SFTP as well, which you implicitly have setup with sshd.

- make SG's specifics things. For example in my fool's dreams, I imagined a server where you can shoot and play poker... Good poker players would be able to earn more money, so more fire-power... Money would be saved from a session to another. Sounds like a great idea to me! We can imagine many others ideas, like third-party game-mode done directly by bot: that's why I have introduced a lot of new rcon command (like adjusting someone's gold, etc)

Sounds like the ideal area for a B3 plugin.

- the fun of coding it

Ah, well. Can't say much against that Except maybe this; instead of everyone having his own, semi-finished bot, all devs could write the one and only perfect bot together instead

[ricochet]

instead of everyone having his own, semi-finished bot, all devs could write the one and only perfect bot together instead

There is some truth to that. I will take a look at B3 and see how easy it will be to integrate it with the minilog.