May
23
KDE4000 of irc.localcoast.net found me yesterday. That network is running a highly modified version of botzilla, which is exciting to see. localbot is superior to botzilla in a number of ways, so I hope I get to see more of its code.
He had thought that timed events for modules/ziggis were broken, and I wasn’t really sure because I don’t make much use of them. Let’s take a look.
After whipping up a small test case, I determined that timed events still work, but I did find something small to fix that bit me. The one “cron” (infinitely repeating event) that my company used was turned off after a while because it was annoying as hell.
For some background on timed events, they used to be in the core bot. A module would send a packet out of the pipe that the bot stored internally. When the time was right, the bot would send it back through the command processor. This was good because any module could pick it up and run with it, but I didn’t like the idea of the core bot handling a module’s business. So in the current version, the module handles its own events, but at the cost of modules talking to each other.
The fix that I applied to my own instance is in the module’s isEmpty method. I like to have if($this->isEmpty) return; as the first line of my modules. This was supposed to save on substring overhead, because parseBuffer gets called regularly even if everything is idle. If a buffer contained an event, this method still thought the buffer was empty. bad bbby. I changed it to:
function isEmpty()
{
return (trim($this->getText())==” && trim($this->getEvent())==”);
}
addTimedEvent takes two arguments: some arbitrary data of any type, and an integer for the number of seconds to wait.
$this->addTimedEvent( $some_data, 30);
“Events” are a separate key in the buffer array, so it has its own getter method. In my test, I wrote a handler method to keep parseBuffer clean:
#in parseBuffer()
if($this->getEvent() != FALSE)
$this->readEvent();
The buffer containing the event pretty much has that data only. When “activated”, the other keys in the buffer are populated with the event data. The handling method can get the event with getEvent() and then do anything it wants with it. In my test, I’m passing an array just to demostrate that any data type can be had.
addTimedEvent returns an integer representing the event’s index in the modules timedEvents array. This is similar to javascript’s setInterval method. This number is handy for cancelling and accessing the event data.
“crons” (a bad name) work the same way, except you set them with a repeat interval time.
Timed events in general should not be confused with the alarm class available from this site’s plugin repo. That class uses absolute time, while these events use relative time. There’s been a bug in that class on my company’s server for events occurring the same day as a restart, and I’m hoping to resolve that this weekend if I am able.
My test code can be found at http://botzilla.org/event_test.php.txt
Please comment if this isn’t working for you as it should.