Author Topic: suggestions for next version (Read 13214 times)

Wanuarmi · « **on:** December 03, 2005, 10:49:07 pm »

I have a couple suggestions I will be dropping in this topic

cant remember all of them now though

- same helpfile for multiple commands
- callers command to use !caller name to add callers like !member does
- not sure its possible but reload modules without restarting the bot
- ability to hide some commands from !help

secondary
- banlist with reason

my todo list (nothing to see here)
- player points history (when, why, who added)
- raid name
- whine raid is open etc every xx
- personal player logon/logoff notify

Alreadythere · « **Reply #1 on:** December 03, 2005, 11:15:03 pm »

Quote from: "Wanuarmi"

secondary
- banlist with reason

Check in this thread, I posted a PrivGroup module with banlist, !ban name some reason why will save you the reason too.
Perhaps you can adapt it for your needs.

Wanuarmi · « **Reply #2 on:** December 03, 2005, 11:32:56 pm »

thanks Ill take a look at it

Khalem · « **Reply #3 on:** December 04, 2005, 12:07:52 am »

Few nice things there, some of which i had planned myself.

As for reloading modules while running, its unfortunately not easilly done with interpreted languages. I seem to recall a discussion on the Ruby mailing list not too long ago about it being theoretically possible to archieve something close to "reloading" methods, but it wasnt exactly easy to archieve. And im not sure that approach discussed would even be possible with PHP, given PHP isnt even designed to be a scripting language on the level where its used today.

Akarah · « **Reply #4 on:** December 04, 2005, 12:38:25 am »

i was thinking about that specifically myself.. unfortunately my knowledge of php is still limited enough that i have no idea if it's possible to un-define functions and classes and such (since redeclaring a function causes the script to exit, it'd be necessary to be able to actually completely unload it then reload it)

definitely would be a cool feature, but i'm not sure it's possible

mookie · « **Reply #5 on:** December 04, 2005, 01:49:38 am »

I have a suggestion, maybe I need to look into it.

Dont spam the Org channel when initializing a new member table in the database.

Akarah · « **Reply #6 on:** December 04, 2005, 04:18:33 am »

Quote from: "mookie"

I have a suggestion, maybe I need to look into it.

Dont spam the Org channel when initializing a new member table in the database.

lol good idea!

actually it would be cool if we could NOT announce signon/signoff of any -new- member, because i noticed it does do that currently. if a member is "new to the bot" maybe dont announce any events for 10 minutes for that member (signon/signoff)

they could still show up in the online list and such..

hmm maybe we could add a column in the member table to mark when a member was added.. or create a new table of members.id,add_date or so..

skeezix · « **Reply #7 on:** December 04, 2005, 04:37:48 am »

I thought about adding a variable that waits for x minutes before allowing logon/logoff messages

Also... this is untested, but seemed to be funky. Might just be me

While messing around with the bot and restarting, I moved the bot files to another machine and edited the SQL info to access the mysql server through a network name instead of 'localhost' where it was running. During the next startup, it still seemed to run through the full member list when re-building the members table, but was only sending out tells to people actually online instead of spamming the whole roster logging off.

I might take a closer look at this and make sure it's not just some whacked out fluke that happened at the same time I made those changes, because it also moved the bot from running on a p3 450 to a 2.6ghz p4 and it might have taken care of other things before running the roster update and such quicker than the other machine.

Aside from that I think there's an extremely high demand for !cyber, !sex, !beer, and !leet commands. Without these an org can fail miserably!!

Khalem · « **Reply #8 on:** December 04, 2005, 10:07:52 am »

A more generic solution would be preferable. Ie a small check that says if number of logouts exceeds x, then stop announce for x seconds.
This because such floods also occur on chatserver issues where the bot wont get disconnected, but the buddylist will "reset" causing it to spam logoffs.

Akarah · « **Reply #9 on:** December 04, 2005, 10:55:10 am »

very very true khalem..

perhaps a flood limiter like i put into the towerattack module?

like a var that gets set to time() when someone signs off, and don't send the signoff message unless time() > ($var + 20) or something. but then we might not send signoffs for people.. maybe only have it trigger if like 5 signoffs are detected within 5 seconds.. but then i'm not exactly sure how to accomplish that, so.. *groan*

hehehe

mookie · « **Reply #10 on:** December 04, 2005, 12:02:48 pm »

So.. what??

Wanuarmi · « **Reply #11 on:** December 09, 2005, 04:34:22 am »

can someone remove mookie's message? I reposted his module here

Nik_Doof · « **Reply #12 on:** December 09, 2005, 05:33:31 pm »

Re: reloadable plugins, it may not be as complicated as you think. No need to undefine functions and classes and reincluding php files, just use the handy eval() function.

Anyone who has used PHP to some degree will be screaming at the screen now, but just listen me out

While i an't any PHP wizard i know a few bits, this maybe possible and i'm going to try to create a concept tonight.

eval(); works in the context of the main script, and as PHP4 variables for classes dont pass byref by default you could exploit this.

eval(); returns a variable of the last return statement, so in theory you could have your php file define the class, then use a return statement at the bottom to fire off a instance of the class:

$bob = new Class;
return $bob;

as its byval, the eval() function will return a copy of the class, which you can throw into a array of objects etc. etc.

All you would need to do is change the API slightly to have a init() and uninit() functions as a addition to the constructor function. init() will deal with the linking into the commands list, and receiving the $bot instance. uinit() would clean up its link into any part of the main objects.

So, create object:

$rs = open(file);
$contents = read($rs);
$obj_tmp = eval($contents);
$objs['file'] = $obj_tmp;
$objs['file']->init($bot);

destroy:

$objs['file']->uninit();
unset($objs['file']);

(the code wont run like, but you get the idea

Unless my basis is amazingly wrong, i'd see this as a method which would work.