-
Notifications
You must be signed in to change notification settings - Fork 47
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
Comments
At the moment I'm not familiar with the listeners. Someone else added them. |
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. |
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. |
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. |
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. |
Alright got it |
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. |
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
original code at the bottom portion
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!
The text was updated successfully, but these errors were encountered: