Topic: bot "forgetting"

[nullerman]

now some wired stuff is going on here with my org bot, it is forgetting access levels, i can startup by starting the bot. then is says owner logged on.
and 5 minuts later it dosn´t remember that im owner, and tells me that the bot only listens to members of the bot.

what to do, help me... please...

[Ebag333]

Make sure you're a member of the bot (in the users list).  Is the bot running a roster update and wiping you?

What we really need to know is what happens when the bot "forgets" you.  Watch the console, and spam the bot !help or some command, and see what happens when the bot starts to ignore you.

[Tichy]

I can confirm a simular problem. It occurs since 0.4.1 as far as I remember.

The bot is running as an orgbot on RK3. Sometimes I (the owner) has no access to the bot. If I do simple thinks like !whois in der org channel, it is not threaded as command (and so it is relayed to pgroup/IRC). Other guys in the org being ordinary members are effected by the same issue from time to time. If an effected player relogs or the bot is restarted everything will work again.

I did not yet catch any usefull debug infos since this occurs not to often.

[Ebag333]

If a !rosterupdate (if you're running the trunk version) fixes it (or resetting the bot and forcing it to do a roster update), then it's the same problem I have.

Basically what I'm seeing is that the bot thinks everyone (or most everyone) has been rerolled.

I've added a lot more technical commands into the trunk version to try and track it down.  The problem is that it's not a very common problem (maybe on 1 out of 3+ roster updates it happens).

Next time it happens I *SHOULD* be able to catch it (or at least that's my hope ) and see what happens.

If I can track it down, we'll probably port it from trunk to the 4.X branch (depending on how complex it is).

[Blueeagle]

This has been fixed by Alreadythere today and has been merged with the 4.0-branch along with numerous updates.


_{Edit: to make ebag happy since he's made me happy all morning.}

[Ebag333]

Note that not all the changes made their way into the 4.X branch, mostly because the larger change involved touching 22 files.

Still, the change Alreadythere made *SHOULD* fix it, but if you keep having problems you might want to try nabbing trunk, and that should take care of it.

[nullerman]

that is sweet,
isn´t it about time to make a new build?
cus im having problems finding heads and tails in the trunk version.

/nuller

[Ebag333]

Just an update, Alreadythere's fix isn't working to correct the problem.

Still trying to track it down, but it's very difficult since it can't be replicated on demand.

[Ebag333]

Okay, looks like I got it.  *crosses fingers*

It appears AOChat was returning 0 for the UID (in get_uid).  Long story short, AOChat now returns false instead of 0.

Even so, if you are running 4.x, it won't handle it totally since some of the calls to get_uid might not handle a false return all that well.  Anyway, the trunk version handles it a lot better (if it fails it goes to the whois cache).

The only file you need for this change is AOChat.php.

[Khalem]

Correct me if I'm wrong, but last time i checked, FALSE is nothing more than an alias for 0 or NULL. So the sane thing to do would be to have it return -1 and trap that.

[Ebag333]

That's probably a better solution, but everything's coded (well, that's done right ) to expect false if it fails.

That was really the problem, was the AOChat was returning 0 and some stuff was catching !($uid) (which matches on 0 and false) and some stuff was $uid !== false.

Anyway, hopefully it's fixed.

[Tefnacht]

You are wrong, Khalem.

FALSE is boolean, that is its own type Since PHP4. NULL is also a special type. Returning (int) 0 is NOT the same as returning (bool) FALSE. (int) 0 is considered FALSE, but its still a different type.
(float) 0.0, empty strings, objects without member variables and NULL (special type) are also considered FALSE and everything else is considered TRUE. But the types don't match. (int) -1 would also be considered TRUE.

If you return boolean FALSE on error and a integer otherwise, you always have to check the result with the === or !== operators, to make sure the types match. 0 == FALSE is correct but 0 === FALSE is not!

Many PHP functions use exactly this method to return errors. strpos for example can return (int) 0 if the needle you're looking for is right at the beginning of the haystack, or (bool) FALSE if the needle is not found at all.

To see a boolean variable act different than a integer one do this:

Code: [Select]

<?php
$foo = TRUE;
$foo++;
echo "1 + 1 is ".$foo."\n"; //1 + 1 is 1
?>On the other hand:

Code: [Select]

<?php
$foo = TRUE;
$foo = $foo + 1;
echo "1 + 1 is ".$foo."\n"; //1 + 1 is 2
?>will give the correct answer, since PHPs automatic type conversion silently converts the boolean to a integer here.

[Diablo]

Not sure if this is same issue but the other day our relay bot dropped one of the org bots as a member. When i checked member list it wasnt there no more. Once i added it back it started relaying again. Not sure if this has to do with the others issue or not?

[Ebag333]

I've noticed this too.  Seems that there's something up with the raid roster as well.

It hasn't happened in a while for me, so it might have just been a fluke.

[Pinkishpunk]

Just gotten bitten by that bug here on House maadiah`s bot, it seemed to have forgotten all org members, and a restart didnt help, I didnt a dump of the DB before I wipe it so I`ll try and figureout that happened.
I tried to use the 0.4 pulled from svn, but seems to be a error regarding module/whois.php, seems the referance at line 133 for the bot functions have be changed, crashes the whole bot if whois is used.