Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Patrice Chevee]

Hello everybody,

For some years I have been developing a script under mirc which let people forget about a lot of the Anope commands.... The problem is , that this script analyses some words of the notices issued from the Anope bots in order to know what to do. And because of this way of working, my script is closely dependent on the Anope settings (parameters, language and so on).

Then I have a dream: I would like the Anope answers to be standardized, as well as the server raws, by sending with Anope message a raw number in connection to the situation. As an example: 404 means, on the web, that the file was not found. By this way, a simple number could be more explicit to robots which receive them than the accompanying messages. The irc servers already utilizes this way of working since the creation of the irc protocol. Should it be possible that this be, one day, transposed to the services?

I thank you for your attention, and of course, in advance for your answer.

PC

[katsklaw]

Anope's primary form of communication is a/notice which does not have a numeric value nor should it. As per the rfc, numerics are limited to 0-999 and already follow a standardized order. Numerics are for servers to communicate back to  client in a "canned" message format and for certain replies and errors only. Changing this to allow services to talk to users would break every client in existence.

[Patrice Chevee]

Thank you for your answer. Nevertheless, which client would currently care of an additional numerical value in the chanserv/nickserv/etc-serv notices? The interest is, according to me, that if the message was in english, french, turkish or serbo-croatian , every automatic system (like a script or a bot) would understand its meaning by simply parsing the numeric. This latter value could be (should be) different from the real numeric issued from the service to communicate with the servers network. I think, this idea is not completely silly, is it?

[katsklaw]

About half of the numerics between 0 and 999 are taken by rfc requirements or by various ircds. Currently you'd be hard pressed to find 10 numerics in a row that are not in use anywhere by some ircd or another. Anope supports several ircds and where one would have a specific value for a numeric another one would have it for something else.

I don't think your request is silly, it's just not very practical because of how irc is currently laid out. Not to mention the number of numerics is finite where as the number of/notices are not. If the way numerics were allocated differently i'd support your request and even work on a patch to add it to Anope 1.8. Unfortunately things are not different.

[Patrice Chevee]

Mmm… I don't want to be heavy, but I am not so sure to be understood… Please forget the RFC. Please also forget the limitation of 1000 messages (which is, I think, in the RFC). As far as I know, all of the messages Anope is able to produce (including additional parameters) are in a table, each message having it's own number. As an example, when I register my nick on NickServ, I receive something like (in english):

"Your nick %nick is now registered under your account %account. Your pass is %pass, please do not forget it"

If things are well done, I think the text above is likely recorded as is (with % parameters names) in a list of messages which could be sent as notices. Let 12 be, as an example, the numeric of this message; that means, its effective position inside the list. What I would like to receive after correctly registering my nickname is something like this:

Your nick blah is now registered under your account blah@blah . Your pass is blah, please do not forget it [IdMsg = 12]

On the opposite, if I did not correctly register my nickname, I would receive another notice with another IdMsg at the end of the message (likely depending on the reason for which the registration was not accepted). I repeat: the IdMsg's are neither depending on the RFC, nor limited by a number. Maybe we could have something like

Blah [Id = 45678]

Human beings would, of course, not take care of the additional numeric at the end of the notice. On the opposite, this info but would be very convenient for automatized systems like scripts or bots which manages Anope. Of course, it would be great to get an help file from the Anope developing team, giving the exhaustive list of the notice messages and their numbers.

I hope thing are clearer. If you need some extra explanation, please let me know…

Thanks in advance

PC

[katsklaw]

You should have explained it this way the first time because that has nothing to do with numerics at all.

[Charles Kingsley]

Hi,

Look in the lang files, you may find you could adapt/copy one of them and create a 'bot' language where you replace the actual text with numeric IDs but I'm not sure how much further that will take you though having the IDs on the end of every user message isn't going to be ideal for user experience and modifying the 1.8 language files is a dark art at the best of times.

Anyway, from en_us.l here's some examples you could ponder over:

# REGISTER responses
NICK_REGISTER_SYNTAX
        REGISTER ^_password^_ [^_email^_]
NICK_REGISTER_SYNTAX_EMAIL
        REGISTER ^_password^_ ^_email^_
NICK_REGISTRATION_DISABLED
        Sorry, nickname registration is temporarily disabled.
NICK_REGISTRATION_FAILED
        Sorry, registration failed.
NICK_REG_PLEASE_WAIT
        Please wait %d seconds before using the REGISTER command again.
NICK_CANNOT_BE_REGISTERED
        Nickname ^B%s^B may not be registered.
NICK_ALREADY_REGISTERED
        Nickname ^B%s^B is already registered!
NICK_REGISTERED
        Nickname ^B%s^B registered under your account: %s
NICK_REGISTERED_NO_MASK
        Nickname %s registered.
NICK_PASSWORD_IS
        Your password is ^B%s^B - remember this for later use.
NICK_REG_DELAY
        You must have been using this nick for at least %d seconds to register.

I kind of understand what you're trying to achieve but I'm not convinced you'll get enough autonomy to produce something that will standardise of last the test of time but in 1.8.x I cannot imagine any language changes so you should be able to base it in this for now.

Further in the future I do quite like the idea of an array of 'responses' which I guess is kind of how gettext is working in 1.9 but again I'm not convinced of the demand for such focus.

Good luck in your quest.

[Patrice Chevee]

Hey again, and thank you for your answer. I just realized the complexity of my idea by simply reading the piece of code that you wrote for me. In fact, I remarked that some messages issued from Anope can be obtained by the concatenation  of other messages. About my example , where the system sends you a notice after registering your nickname, this message is obtained by concatenating NICK_REGISTERED or NICK_REGISTERED_NO_MASK with (or without) NICK_PASSWORD_IS . The with or without is depending on the way the Anope system was set up.

May I suggest a new idea: instead of sending one notice (in English, French , German or any language) I suggest the service sends TWO notices, under the form:

Notice 1: Nickname blah registered under your account blah2@blah2. Your password is blah3 - remember this for later use
Notice 2: [NICK_REGISTERED blah blah2@blah2][NICK_PASSWORD_IS blah3]

In other words, the second line would give the structure of the human understandable message sent by Anope in a way that a script or a bot could easily understand. Of course, most of the irc clients could hide the second line, by hiding notices containing [...] .

Do you think something like I described above could occur one day?

Thanks once more for your support  and contribution,

PC

P.S. I don't know if there is a way to produce a specific "user" raw to be issued from the server, with *any* text,  on the basis of a command sent through the link (between the server and the service). I did not sufficiently read the RFC1459 to know that. In this case, it could be the best solution, since we could replace the second notice with a raw.

I illustrate: let 999 be the "user" raw (I don't actually know whether there is one or not). Then a command sent by the service through the link:

SEND_USER_RAW rototo :NICKSERV said [blah][blah2][blah3][blah4]

would result in:

:server-name.net 999 rototo :NICKSERV said [blah][blah2][blah3][blah4]

just visible by the client rototo, but hopefully filtered, or only visible on the status window.

Does it exist?

[katsklaw]

I don't see a need to alter anope at all for this. I've been scripting mirc script for almost 20 years and none of my scripts need anything special from services. My scripts and bot both parse the standard messages. In fact, in a single afternoon i can write a script that parses every anope message and assign a numeric to it to use internally and display externally.

Perhaps its best to change the way your script works instead of expecting anope to cater to your script because thousands of other scripts work it out just fine. Just sayin..

I do like Chaz's "Bot Language" idea though and I may look at writing that along the same concept NickServ's ACC command.

[Patrice Chevee]

Hello katsklaw,

thanks for your feed back. In fact, what you describe is precisely what I have done so far, since I cannot do anything else. Did the scripts you wrote take into account all of the languages? Since the situation may quickly become complex...

[katsklaw]

You don't need to take all languages into account, just keep bots on the default language. This would be an advantage of the bots having their own. It can get tricky with users that also run a bot on the same chat instance.

I should have time in a few days to look at doing a bot language file. Be advised though, in a bot language i will keep the responses extremely short to the point of being unintelligible but I'll include a msg reference for scripters.

Another solution would be for me to write a complete mirc script to parse all possible messages and add a few configuration options to make each user experience a bit more personal.

[katsklaw]

I've changed my mind on this. I'm going to stand by my original point of it's not so hard to script services messages instead of making a bot language.

To insure you get all of the core messages look at the language file source (.l file) and script an interface on your default language.

Good Luck.