Because my last attempt at an IRC gateway was "a bit" hard to install and to change (the gateway started the server and communicated using stdin/stdout, so one couldn't change the gateway while the server was running), I made a new one. This time, I added a feature to the engine to support it:

New cvar: log_dest_udp - contains a space separated list of IP addresses and ports to send all console output to (in the same format as QW rcon data)

Basically, my IRC gateway now is an external process that uses rcon to retrieve log_dest_udp from the server, adds itself to the list and uses rcon to send the changed value to the server (yes, this does have a race condition, but should usually not be an issue... as a workaround, one can regularily request that cvar and add oneself to it when needed, but my gateway is not doing this yet). Then it can see all console messages, and use rcon to talk to the server. So setting it up is much easier now - just point it to some Nexuiz server with a rcon password, and that's it.

It already supports color codes, special fonts, chat in both direction, and a somewhat clumsy but simple way to add plugins. The RBI KH server already uses the new gateway (that you can watch it on irc.oftc.net, #Nexuiz-Pwayers isn't a secret any more anyway). A newly added feature is notification about free player slots.

I'll release it shortly after the next Nexuiz release, which will be a minor one and quite soon.

That sounds very interesting, indeed. Just make sure to wait for Mr ATI Victim ™ to check out the update before its release

First test version of the gateway:

http://hagger.rbi.informatik.uni-frankf ... ew.tar.bz2

Not licensed for anything but personal use with or without modification yet, but it will be either BSD, GPL2 or GPL3 licensed, I have not decided yet. Note that it requires a DP build from svn - it does NOT work with Nexuiz 2.3!

wow I really like these closed open-source perl scripts
Closed, because a usual programmer who doesn't know perl won't get what is happening in your script.

GreEn`mArine wrote:wow I really like these closed open-source perl scripts
Closed, because a usual programmer who doesn't know perl won't get what is happening in your script.

Even perl programmers won't understand perl scripts written by someone else. That's what perl was designed for

Can someone explain how exactly this works?

I know what a gateway is.
I know what IRC is.

What does this thing do?

my guess would be that the term gateway is that this scripts offer a way for the nexuis server to communicate with the script, which again communicates with IRC.

I saw the one example where slot openings on the server would be announced in IRC.

So there would be a bot in IRC that communicates with the Nexuiz server?

Yeah.. the old irc gateway would connect to a server/channel and just post chat from the server and some important news like new maps to the channel. And allow people to 'say' stuff to people on the server.
Useful to keep a watchful eye on the server.

Whoa. People in IRC could talk on the Nexuiz server?
How would they do that? Would it be like sending a command to a bot?

That's very interesting

well the ircgateway would use the say command to say 'the chatters name and his text' to it appears like the admin would say (NICKNAME) TEXT

Just watch it on irc.oftc.net, #Nexuiz-Pwayers.

You can send chat to a server by writing "hectorNex: whatever" (so you actually talk to the bot). And whatever they write on that server, you can see in the channel.

Dokujisan wrote:Can someone explain how exactly this works?

I know what a gateway is.
I know what IRC is.

What does this thing do?

• pass chat messages between Nexuiz server and IRC channel
• spam scores at end of match to the IRC channel (actually, this is the hardest part, as it has to shorten nicknames to make the next fit in one IRC message)
• spam the channel about the server getting full or getting free slots again

What the RBI specific plugin does is:

• AOL calendar: when someone writes "d", it responds with the current time according to http://en.wikipedia.org/wiki/Eternal_September
• call a log file analyzer at the end of the match (for http://www.informatik.uni-frankfurt.de/ ... otals.html)
• log the results from map votes to a text file for further analysis
• detect high system load causing DP to slow down, and reporting that to me via E-Mail

I just added NickServ authentication as a feature. It works like this:

Code: Select all

> USER ...
> NICK mywantednick
< 433 nick already in use:
  > NICK somethingelse
  < 433 nick already in use:
    > NICK somethingelse
    ....
until:
< 001 welcome to the network
? If my nickname is not what I wanted:
  > MSG NickServ GHOST mywantednick password
  > NICK mywantednick
  < 433 nick already in use: then ghost again
  until:
  > somethingelse is now known as mywantednick
> MSG NickServ IDENTIFY password
sleep one second
> JOIN #channel


Can anyone tell me if the commands I use have an one-to-one equivalent on Quakenet? If they have, I will also add Quakenet support. I need the equivalents of:

MSG NickServ IDENTIFY password: tells services that you are indeed yourself so you get autovoice or autoop when joining some channels
MSG NickServ GHOST mynickname password: kills the one currently using mynickname off the server (or on some networks, just renames him to something like Guest309) so I can now take it myself

If there are really one-to-one equivalents, I will change my code to make the commands configurable in the configuration file, like

irc_nickserv_identify = PRIVMSG NickServ :IDENTIFY $p
irc_nickserv_ghost = PRIVMSG NickServ :GHOST $n $p

so Quakenet users can just override them with whatever Quakenet wants.

Maybe I should also make a identify-only mode that, if ghosting didn't work out, still goes ahead. Currently it would try infinitely to get the nick, but first thing I will do now is make an attempts limit for that.

Actually, I just implemented that part:

irc_nickserv_password = joshua
irc_nickserv_identify = PRIVMSG NickServ :IDENTIFY %2$s
irc_nickserv_ghost = PRIVMSG NickServ :GHOST %1$s %2$s
irc_nickserv_ghost_attempts = 3

Yes, the attempt limiting does work now too. BTW, this is %1$s and %2$s, because Perl's printf already provides this special syntax for the first and the second parameter (nick and password). Setting the attempts to 0 of course disables this ghosting.

for quakenet, the command to login :

Code: Select all

/msg Q@CServe.quakenet.org AUTH username password

You have to use your Q username , and an account can't be created by a script.

http://quakenet.org/faq/faq.php?c=1&f=51#51

divVerent wrote:Can anyone tell me if the commands I use have an one-to-one equivalent on Quakenet? If they have, I will also add Quakenet support. I need the equivalents of:

Quakenet doesn't have nickname reservation, so authenticating the bot on qnet is only useful if you want to give it voice/op/etc. automagically.
And i suggest you implement the challenge-response authentification instead of the simple auth command ronan posted
http://www.quakenet.org/faq/faq.php?c=52&f=240#240

Okay, then it may be working now.

irc_quakenet_authname = ...
irc_quakenet_password = ...

is how to configure it now.

Your quakenet support is working fine

New config file: http://paste.debian.net/33642

I finally found a way to make dp_listen an optional parameter (by getting the socket's local address after connecting it to the DP server). Only the six not commented out settings are required now. Also, unspecified port numbers are now regarded as 26000 for DP and 6667 for IRC.

Tarball updated, BTW.