Quote from: Riccarr on July 10, 2009, 12:32:54 am

Are you all getting the bot to connect/run now after Chaoz's recent update?

I'm still getting the RPC header error. 

I'm having the same problem still.

If you are getting the RPC error, are you sure you have the correct server and port specified in the config?  When I try to connect directly to the Set server IP, I get that error.  Remember we are not connecting directly to the chat server now, but we actually have to log in first.  You should set your server to be "Us" or "Eu" (somewhere in the code the value from the server list gets converted to a proper case or something with the first letter upper and the rest lower, so watch your casing).  Sorry if you already tried that.  I have read too many posts on this stuff recently to recall who has done what.

works without problem (0.6.3)

Hi,

Having some strange problems with guild chat, cant get it to send output to, or read input from guildchat in AoC.
Every command is just ignored silently, same with !say cmd in tells.
Running Ubuntu 32bit with 0.6.4.rc on PHP 5.3.0RC1

This is what happens when the bot connects:

Muffin [LOGIN]  [STATUS]        Connecting
Muffin [LOGIN]  [STATUS]        Authenticating
Unsupported rpcpacket type (in, 5)
Unsupported rpcpacket type (in, 4170821964)
Unsupported rpcpacket type (in, 1334945164)
Unsupported rpcpacket type (in, 1525492320)
Bot is now logged in.
Muffin [ERROR]  [AOChatWrapper_Core]    I was unable to get the user id for user: 'Muffin'
Muffin [SETTINGS]       [LOAD]  Loaded settings from database.
Muffin [LOGIN]  [RESULT]        OK


All the chatter in guildchat show up in console, so afaik it can read it ok, but it is being totally ignored.
Could it be that the remove of privategroup breaked guildchat somehow?

Dobstah

I have posted a pre release version of BeBot 0.6.4. We are gearing up to release this soon, but would ike to have it receive some more AoC testing as we only have one developer with an AoC account.

You can find it at https://launchpad.net/bebot/0.6/0.6.4.rc

Please take it for a test spin and let me know if it works for you or not.

Preliminary changelog for this release:

• Modified the network protocol to work with AoC 1.05. Please note that PrivGroup relays are no longer an option for AoC due to chatserver changes.
• Reversing stripping of control characters on text from IRC for now.
• htmlspecialchars_decode text going to IRC to decode & and similar.
• IRC join/part/quit messages now properly prefixed on IRC and are also relayed over guild relay if UseGuildRelay is set for IRC module.
• IRC part/quit messages are now relayed ingame.
• Fixed flip command
• Added the option to make reason required for !ban add
• Added a check for botname_rules.txt before getting rules.txt
• Lots of Changes to Raid module, lots of new function and features including restart/crash support, raid logging, raid control interface,  punish raiders, move countdown, min level and also fixed alot of problems with output to wrong place or unnessesary spam
• Lots of Changes to Bid module, lots of new function and deatures including using points log, !bid cancel, !bid all, and more
• Corrected some color codes and time zone for "last online" in !whois (AoC only)
• Backported some fixes from trunk to make it bearable to enable E_ALL logging
• Changed help for !aliasadmin (which didn't exist) to !alias admin
• Bot doesn't tell people that there are "No news." upon login any more. Only if they ask for "!news".
• Added more spam protection (e.g. when double clicking tell links) to message queue.

Big thanks to Chaoz for providing a patch for the 1.05 protocol changes.

Extracted tar.gz with new files over old install with "overwrite all".

Got the same messages. The bot is up and running but it only listem to tells and do not see the Guild Chat.

[edit]

Also I have noticed that some lines in log begins with "guildmessage..".

Usualy it looks like:
Mybot [TELL] [INC]   Mychar: !whois Someone

and sometimes (no rulle atm) it looks like

guildmessage..Mybot [TELL] [INC]   Mychar: !whois Someone

Do not know if that matters, but it starts to appear form Chaoz second patch (or at least I have never saw anything like that before).

Still:
Mybot [LOGIN]   [STATUS]        Authenticating
Unsupported rpcpacket type (in, 5)
Unsupported rpcpacket type (in, 4170821964)
Unsupported rpcpacket type (in, 1334945164)
Unsupported rpcpacket type (in, 1525492320)
Bot is now logged in
Mybot [ERROR]  [AOChatWrapper_Core]    I was unable to get the user id for user: 'Mybot'

But now it is talking on Guild channel.

I'll let it work for some time and post if anything unusual happens.

@rmb

Those notices should be perfectly safe to ignore. I believe they are RPC packets that BeBot does not need to worry about and they are left in there by Chaoz for debugging purposes.

I am running into a problem after the bot has been logged on for a minute.  I get spam about mysql errors and then the bot restarts.  I believe it goes from 1 to around 1160 (seems to vary).  I know it is connecting and able to do things at some point as there are tables created and populated with data.  I also double checked and the db user has all privileges.  Note I am using the changes in revision 84 and added the one from 85 (same result).  System is Linux 64bit, kernel 2.6.28-9.16, PHP 5.2.9, MySQL 5.0.75.  I can post or send a full log if wanted.

Code: [Select]

Mybot [2009-07-10 14:21:45]  [LOGIN] [STATUS]        Connecting
Mybot [2009-07-10 14:21:46]  [LOGIN] [STATUS]        Authenticating
Unsupported rpcpacket type (in, 5)
Unsupported rpcpacket type (in, 4170821964)
Unsupported rpcpacket type (in, 1334945164)
Unsupported rpcpacket type (in, 1525492320)
Bot is now logged in.
Mybot [2009-07-10 14:21:50]  [ERROR] [AOChatWrapper_Core]    I was unable to get the user id for user: 'Mybot'
Mybot [2009-07-10 14:21:50]  [SETTINGS]      [LOAD]  Loaded settings from database.
Mybot [2009-07-10 14:21:50]  [LOGIN] [RESULT]        OK
Mybot [2009-07-10 14:22:21]  [SETTINGS]      [LOAD]  Loaded settings from database.
Mybot [2009-07-10 14:22:21]  [ROSTER]        [UPDATE]        Roster update ran less than 6 hours ago, skipping!
Mybot [2009-07-10 14:23:22]  [MySQL] [ERROR] (# 1) on query: Database not found or insufficient priviledges!
MySQL server has gone away
I also found one error that showed a segmentation fault:

Code: [Select]

Mybot [2009-07-10 14:23:23]  [MySQL] [ERROR] (# 708) on query: Database not found or insufficient priviledges!
sh: line 1: 21378 Segmentation fault      /usr/bin/php -c ./ Main.php

Could you please show me output from "php -v" using the same binary as the bot.

Your error indicates that the MySQL server allows the bot to connect, but does not allow it to select the database. Try checking your MySQL log for more information.
The code in question as far as the bot goes is on line 137 in Sources/MySQL.php
if(!mysql_select_db($this -> DBASE, $conn))
{
$this->error("Database not found or insufficient priviledges!", $initial);
return false;
}


Im not sure if there is a big difference or not, but do you have a php-cli binary on your system?
That particular php version is compiled for fastcgi usage and not command line usage.

I've made a modified MySQL.php you can try if you wish with some additional debug output:
http://pastebin.com/d4fa9bcc7

The logic in that one is pretty much the same, we just go about checking in a different manner.

Ok. Judging from the log output you are still running with the fcgi version of PHP. Please note that the StartBot script will fall back to the system default php binary which in your case is a cgi based php. Either manually change StartBot.php or start the bot using Main.php directly.

For some reason your php does not behave as it should for mysql_connect, it simply does not detect that it no longer has a valid connection to MySQL and as such tries to keep using it causing the errors to occur.

I can only think of two possibilities aside from making sure you are running a CLI version of PHP which might or might not make a difference.
If your MySQL server is on the same physical server as your bot there are two ways to connect. One is by TCP/IP (127.0.0.1) and the other is using the unix socket (localhost), try changing from the one you are using to the other and see if that helps.

If none of the above helps, try changing your error function to look like this:
function error($text, $fatal = false)
{
                $this -> close();
$msg = mysql_error();
$this -> error_count++;
$this -> bot -> log("MySQL", "ERROR", "(# " . $this -> error_count . ") on query: $text\n$msg", TRUE);

// If this error is occuring while we are trying to first connect to the database when starting
// rthe bot its a fatal error.
if ($fatal == true)
{
exit;
}
}

This should force MySQL to close the connection if an error occurs, meaning the SQL call will still fail, but it should force the bot to try and reconnect with a clean connection.