kaiepi / p6-psbot Goto Github PK

t/04-parser.t's test for |queryresponse| has tests for PSBot::User and PSBot::Room attributes when it should only be testing PSBot::StateManager.propagated and PSBot::StateManager.propagation-mitigation. I don't really feel like doing this right now

PSBot needs a $seen command to allow users to be able to tell when a user was last seen by the bot.

The current schema sucks ass. There should be a users table containing user IDs and a rooms table containing room IDs, and the rest of the tables should use their row IDs as foreign keys.

PSBot needs a $set command to configure the rank required to use commands.

The code's not completely screwed, there have just been some refactors that broke tests. They need to be updated accordingly

Mail and the future friends list features both require being able to notify users when the bot first becomes aware that they're online. Rather than duplicating code when friends lists get implementation, a notification plugin should be added that would be used by both features.

Some servers have custom groups, which are sent through the |customgroups| message currently. There are problems with using this that cannot be solved without changes to Pokémon Showdown itself though.

eval, evalcommand, say, nick, and suicide should not be able to be used with set or toggle. This should also allow #5 to be fixed.

Since PS isn't getting them any time soon, PSBot should have friends lists. Users who are friends with each other would be notified whenever either of them log in. Its API should look something like this:

• $friend request <username>

Send a friend request to the given user. They will be notified of the request the next time they're online or when they do $friend requests

• $friend requests

View your list of friend requests.

• $friend accept <username>

Accept a friend request from the given user.

• $friend decline <username>

Decline a friend request from the given user.

• $friend remove <username>

Remove the given user from your friends list.

• $friend list

View your list of friends.

• Some types of rules never use the includes/excludes attributes, so some more abstraction is needed
• Chat rules should be able to include/exclude users on top of rooms
• Rules should be possible to add dynamically through a command so they're not all hardcoded. This would be dependent on #12 and #13

Anything dealing with making HTTP requests or the database needs to be moved to a plugin so more of PSBot's routines can be marked pure and so PSBot::Commands can have a lower line count

PSBot needs a $mail command to allow sending mail to users while they're offline.

Put it in t/01-user.t

PSBot::Parser and PSBot::StateManager handle state that PSBot itself should be handling, since that's the part of PSBot that actually cares about it most. Moving it to PSBot would allow people to extend parsing and state management, but this should never be needed the way I plan on designing it.

PSBot::Parser should be a grammar. Its actions class would need access to PSBot itself, but this can be accomplished by binding self to a dynamic variable before parsing.

At the moment, rules are limited to certain types of protocol messages. They shouldn't be, as what rules really are are templates for grammars used when parsing.

Put it in t/02-room.t

Lately, I've been implementing stuff that needs to send replies to messages received, such as rules, games, and commands, by returning captures of arguments to pass to PSBot::Connection.send. This is too dependent on what its arguments look like and will be a huge pain in the ass to change if I ever change them again.

I'm thinking of using a PSBot::Response class containing a message and either a user ID or a room ID, along with a Reply subset of PSBot::Response or a List of PSBot::Response. This would never be directly used when writing rules, games, or commands; they'd implement a method that deals with creating the instance for you. The parser would handle the actual sending of the responses.

The settings command should return a list of the commands and whether or not they're administrative, what rank they require, and whether or not they're enabled.

Put it in t/03-state-manager.t

They should be accessible from outside the commands so #5 can be fixed.

• There should be a PSBot::Command class with attributes containing metadata and a CALL-ME method to run it instead of using our method and keeping metadata in constants in PSBot::Commands
• PSBot::CommandContext methods should be moved to PSBot::Command and the module removed
• Boilerplate at the beginning of commands should be handled from CALL-ME so they can be removed from the commands themselves
• Commands should allow an arbitrary amount of subcommands to exist
• Command names should allow any unicode, not just what's allowed in variable names