Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanded Listeners #34

Open
rmrhz opened this issue May 22, 2013 · 7 comments
Open

Expanded Listeners #34

rmrhz opened this issue May 22, 2013 · 7 comments

Comments

@rmrhz
Copy link

rmrhz commented May 22, 2013

Hello guys, I wonder if this idea is ok or not but recently I've been doing some changes to enable the Listener to have custom triggers and custom actions

168
original code at the bottom portion

169

I know by doing this, this will defeat the purpose of Commands if it may be possible to combine them it will be great as it will be more extendable and organized in such a way, I don't need to switch files every once in a while whenever I'm editing a command.

This will also let me customize which part of the arguments to be used, it can be the user[1] the command [2] the parameters [3][4][5] so on and so forth.

I'm also planning to port it with database functions as for the logging and other ideas that my head is making.

Cheers!

@DanielSiepmann
Copy link
Collaborator

At the moment I'm not familiar with the listeners. Someone else added them.
Currently I'm focused on other projects, but this is still on line. If no one else answers I'll come back to you at time.

@rmrhz
Copy link
Author

rmrhz commented Jun 4, 2013

Not a problem, there's a lot more possibilities for listeners compared to commands and a lot more easier in managing commands and data alike.

@matejvelikonja
Copy link
Collaborator

When I was developing listeners, I had similar thing in my mind and in the long run I think we could drop commands and use only listeners, because as mentioned before, they provide more functionality than just commands.

@ElvenSpellmaker
Copy link
Collaborator

I'm not quite sure I get how you have expanded them, although they do need expansion. I would like to add timed listeners at some point that can go off at certain times or after a certain number of messages.

I don't think dropping commands is a good idea, however I think we need to unify the interface between them, which I and Hosh have started to do.

I really need to crack on with getting my latest release to be push worthy and then I'll upload it as a separate branch and make it default on my repo. Because I've made it two processes (connecting over a UNIX socket), I still need to work out a few more things that they need to communicate.

@NanoSector
Copy link
Contributor

I'm thinking of adding certain new types of listeners at a later stage and making them overall more powerful - I've set a reminder to tell you more tomorrow.

@rmrhz
Copy link
Author

rmrhz commented Jan 6, 2015

Alright got it

@NanoSector
Copy link
Contributor

Right. So in my own build of the bot I added a new type of listeners that scan the message for keywords. They work just like before, they just define a getMessageKeywords() function instead of getKeywords().

As for ways to make them more powerful, I'd suggest adding regex (although that could get very slow) and multiple keywords.

They're not major additions. Maybe other types of listeners (e.g. per-user) would be nice too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants