BeBot - An Anarchy Online and Age Of Conan chat automaton
Archive => Anarchy Online Archive => AO 0.6 support => Topic started by: Hyde on January 26, 2009, 06:51:40 pm
-
I've got a set of bots that I want to have share a userlist for permissions. They won't be in an org and their members will be in different orgs as well.
Is the right way to do this to edit tablenames so that all of the bots point to the same users table?
I just want to make sure this is "safe" and won't cause problems when multiple bots try to write it. On my orgbots it isn't a problem since I just set flexible groups to point to 1 org and enable alts for security.
If there is another way (like setting members in 1 bot and creating a flex rule for the others that say "if a member in the main bot") that is better I'll go with the flow.
Thanks.
-
On that note ... are there any tables that it -isn't- safe to share? The more I think about it the more I do want these bots to all be clones, so I could just point them all to the same prefix. I just want to be sure this isn't something that will cause problems down the road.
-
You can share users as long as no roster update messes them up. So for non-org bots it should be fine. But you'll need some notification system to inform other bots about an update. Otherwise their cache won't get updated.
Same for alts, security, and prolly several others.
Of the head I wouldn't share the timer table, as that could lead to unexpected behavior. Because whichever bot wins the delete/update on timer end will most likely be the only one showing it. Or several may show them, which may lead to strange updates for repeating timers.
You could try some setup with relay between the bots just for timers though, so timer are fully shared among all bots, each with it's own table. Though deleting a timer is a serious hassle right now.
-
But you'll need some notification system to inform other bots about an update. Otherwise their cache won't get updated.
I'd love a "hyde is braindead" pointer at how to do this.
2 options I can see:
1) extend the function that sets the memberlist so that whenever a bot updates it it notifies all the other bots (possibly in a group, like relay uses for autoinvites) to recache their lists ... and you know since these bots will all be in a pgroup relay ... it would even make sense that it issues something like "!gcrmember" in the pgroup to do it.
2) cron job that runs every X minutes on each bot to recache.
I have no clue to how hook in to either of those. I think I like option 1 alot.
Is there a way to have any command that modifies the user table to then fire off a message to the relay? I'm hoping anything that does this has a single choke point where the update is actually made.
like:
/tell bot3 !member add username1
{bot3 modifies user table}
[privgroup] bot3: !gcrmemberupdate
{bot1, bot2, bot4 all recache their user tables}
/tell bot2 !member add username2
{bot2 modifies user table}
[privgroup] bot2: !gcrmemberupdate
{etc}
The cron job would probably suffice though, and might be far simpler. Is there already a command that tells the bot to recache its user table?
-
I believe right now there is no easy way to accomplish this, as neither of your options is implemented in the bot. Most caches are updated once per hour, which might be a bit high for your case though. Reducing the time between updates could solve the problem, but will result in more SQL queries. Though once every 5mins for the caches shouldn't hurt the performance that bad on modern systems.
Check for register_event("cron", "sometime") calls in the constructors. And for update_cache() calls in the cron handler, I think they are called that in almost every case.
-
I believe right now there is no easy way to accomplish this, as neither of your options is implemented in the bot. Most caches are updated once per hour, which might be a bit high for your case though. Reducing the time between updates could solve the problem, but will result in more SQL queries. Though once every 5mins for the caches shouldn't hurt the performance that bad on modern systems.
Check for register_event("cron", "sometime") calls in the constructors. And for update_cache() calls in the cron handler, I think they are called that in almost every case.
Actually all of the tables I ended up sharing (mail, news, security_groups) seemed to update pretty much immediately in all bots.
Except for security_members, which is what I needed most (I thought it was handled by users, which is why I sidetracked there)
I waited over an hour, checking every few minutes, and "!security groups" never showed in bot2 the permissions I had assigned people to in bot1.
Could I beg you to toss me a quick module that would run a cron every 5min that refreshes the data that "!security groups" uses? I'm assuming its security_members that needs to be re-read. I can then adapt that to refresh any other tables that I find aren't working right either.
-
I'll put something together over the weekend.
-
The following should work:
class UpdateManager extends BaseActiveModule
{
function __construct(&$bot, $owner, $super_admin)
{
parent::__construct(&$bot, get_class($this));
$this -> register_command("tell", "updatecaches", "SUPERADMIN");
$this -> register_event("cron", "1hour");
}
function cron($delay)
{
$this -> bot -> core("security") -> cache_security();
}
function command_handler($name, $msg, $origin)
{
$this -> cron("");
return "Updated caches!";
}
}
I set the delay to 1h, otherwise it may have negative consequences on the performance, as building the security cache sets quite a lot of values.
For testing and priority cases you can call the !updatecaches command of the module, it will call the cron function to update the caches.
Possible extensions would be adding more caches (most core functions are cached) as well as adding settings to define which caches should be updated.
-
Thank you very much. I have to go on a business trip early tomorrow, back Wednesday, so it will probably be mid-week before I test it and report.