Lloid will respond with usage statements if you use existing commands incorrectly, such as !host via DM/channel, or host via DM, without arguments.

However, Lloid will not respond to gibberish, or commands that do not exist. asdf and !asdf do nothing on either channel.

We can remove this if people don't like it, but someone suggested that it might be more convenient to remind people what the description said when sending the dodo code.

One or both of self.get_user(task[0]) or task[1] in let_next_user_in may be None for some reason in the line below.
logger.info(f"{self.get_user(task[0]).name} has departed for {task[1].name}'s island")

This seemingly causes it to crash. The cause for a None user may be Lloid getting disconnected briefly by Discord, but the event for disconnection doesn't seem to be executed, only reconnection.

Follow speech patterns of Lloid from the game in messages. Every sentence must end with "friend" or "chum", or something similar--look for sample Lloid dialogue.

It's very annoying when people say !queueinfo in a crowded room. Don't let him encourage them.

Lloid ends up in a bad state if it's unable to send a message to someone. Do a sanity check at the start of any method that sends out messages.

There are some issues Lloid can't help with, but maybe we can still mitigate it more. Some common causes of congestion even when Lloid is working properly:

1. Requeueing (probably nothing we can do)
2. People overstaying (either make 'done' only respond to the last visitor, or make 'done' valid only within each visitor's 10 minute window)
3. People forgetting they were in a queue and joining in later (ask the visitor to react to the code message, or delete the code after 10 minutes)--in tandem with this, we should warn the people that the 10 minute warning could be as fast as 0 minutes.

Give host the option of being the one to control the flow of visitors by issuing the command
"next n" where it lets in the next 1 <= n <= 7 visitors.

Timers and "done" are to be disabled in this mode.

Guest queued up and told Lloid "done".
Guest received: "It sounds like either the market is now closed, or you're in line elsewhere at the moment."

"done" should never print this statement.

No other information available

The lloidbot.py file should only be for features specific to Discord, but it's started to contain a lot of logic. The queueing logic is more generalized and should be in its own set of easily-testable classes. Associating messages and reactions could be done in a more generic and testable fashion as well, without tying it too hard to discord.

The refactored queueing logic should go into its own class, and the contents of the queue class that exists in turnips.py should eventually be merged into that one as well.

If a guest isn't the most recent person to be let in, and they say done, then there's the possibility of too many codes being doled out in a short time (timeout flush plus a "done" flush). If we make it so that the command only works for the most recent guest, this problem should be alleviated.

Guests for whom it doesn't work should still receive a thank you message, though.

The code is getting cluttered up with long long strings (among other things). Extract them into a resource file of some kind.

Host should be able to prevent people from signing up without closing the queue. Proposed commands for this would be lock and unlock.

We have an array called recently_departed, which maps guest ids to owner ids--this allows Lloid to know whose queue to pause when a particular guest messages him "done". However, related entries are not being deleted when a queue closes, which means that anyone who neglected to say done is potentially in memory forever.

There are two ways I can think of. Either:

1. we have a single DM to the host which is continually edited to reflect who Lloid believes to be currently active, or

2. Lloid issues the list on demand, perhaps this is what !queueinfo can do on the host's end

The first offers info closer to real time, but I tend to prefer the second one.

Tracking and reporting the number of codes served per-queue would allow people to see how many people utilized their queue in the time that it is open. Reporting could be done periodically or once at queue close.

It is unclear what's causing this exactly, but according to the logs, the owner associated with the guest who says done isn't found in the sleepers array.

Use case

User wants to be notified if anyone posts that a certain item, DIY, etc. is in their town.

Operations

1. User requests to watch a phrase or phrases.
   1. User messages lloid watch "<phrase>" ["<phrase>" ...]
   2. lloid replies:

      Thanks, I'll look out for "<phrase>" ["<phrase>" ...] and message you if I hear about it.
      By the way, to list the phrases you've watched, say watchlist. To unwatch a phrase, say unwatch "<phrase>" ["<phrase>" ...]. It's that easy!

2. lloid finds a user's watched phrase.
   1. lloid reads messages in pre-determined channels, configured by the bot owner. If a message is posted matching one of the phrases (case-insensitive), lloid DMs the user about the most-recently-found phrase:

      Hello, good friend! "<phrase>" was mentioned in #<channel>. Follow this link to see what's up, pal. <link to message>
      If you no longer wish to be notified when this phrase is said, reply unwatch

3. User requests to list the phrases they have watched.
   1. User messages lloid watchlist.
   2. lloid replies with the phrases they have watched.

      I'm watching out for these great phrases you told me about:

      • <phrase>
      • ...

4. User requests to unwatch a specific phrase or phrases.
   1. User messages lloid unwatch "<phrase>" ["<phrase>" ...].
   2. lloid removes the phrase from phrases watched for the user and replies:

      Glad I could help. I won't watch for "<phrase>" ["<phrase>" ...] anymore. I hope you found what you were looking for!

5. User requests to unwatch the most-recently-found phrase
   1. User has received a DM notifying them of a phrase match.
   2. User replies unwatch to lloid.
   3. lloid replies:

      Glad I could help. I won't watch for "" anymore. I hope you found what you were looking for!

6. After lloid sends a notification to a user, the next message lloid sends to that user causes lloid to forget the most-recently-found phrase. This is to protect the user from accidentally unwatching something with an errant unwatch command.
7. User wants to unwatch all of their watched phrases.
   1. User sends the message unwatchall.
   2. lloid clears all watch phrases for the user and replies:

      I see. I'll unwatch all phrases you had watched.

8. User sends the message help watch, help unwatch, help unwatchall, or help watchlist.
   1. lloid replies:

      I can watch for a phrase with you if you say watch "<phrase>" ["<phrase>" ...]. For example:
      watch "ironwood dresser" or watch "ironwood dresser" "peach umbrella"

      I can tell you what phrases I'm looking out for if you say watchlist.

      I can unwatch a phrase if you say unwatch "<phrase>" ["<phrase>" ...]. For example:
      unwatch "ironwood dresser" or unwatch "ironwood dresser" "peach umbrella"
      >
      > I can unwatch all phrases you've asked me to watch if you say unwatchall.

Exceptions

1. Syntax error for watch or unwatch

   1. lloid replies:

      Something's not right with that command.

   2. Then lloid replies with the watch/unwatch/watchlist help string.

2. User attempts to watch more than watch_limit phrases (default: 10, can be set in bot configuration).
   1. lloid replies:

      Whoa pal! That's too many watch phrases. I can only watch for <watch_limit> phrases for you. Right now I'm watching <N> and you've asked to add <M> phrases. That's sum(<N> + <M>) phrases. List the phrases you have watched with watchlist then unwatch a phrase with unwatch "<phrase>" or reduce the amount of phrases you're asking to watch at once.

3. User attempts to unwatch the last phrase by issuing the unwatch command after the most-recently-found phrase has been forgotten, or never existed.
   1. lloid replies:

      Sorry buddy, we've been talking about other things and I'm not sure which phrase you want me to unwatch. List the phrases you have watched with watchlist then unwatch a phrase with unwatch "<phrase>".

4. User messages watchlist but they have not watched any phrases.
   1. lloid replies:

      I'm not watching for any phrases for you right now, but I would sure love to. Say watch "<phrase>" ["<phrase>" ...] to add phrases I can look out for. I'll let you know if I see 'em!

5. User attempts to unwatch a phrase they haven't watched or unwatchall when they haven't watched any phrases.
   1. The usual unwatch/unwatchall behavior occurs.

Implementation Thoughts

1. Add all watched phrases to an aho-corasick search. There is a python module: https://pypi.org/project/pyahocorasick/
   • Not sure best way to implement case-insensitivity. A way is to uppercase all search patterns and uppercase messages before passing them into the search.
2. Maintain a global dict where the keys are watched phrases and the values are the users who are watching those phrases.
3. Maintain a per-user dict with that user's watch phrases (for watchlist implementation).
4. When scanned messages hit a match, look them up in the global dict and DM the user(s).

To investigate:

1. Does discord have a concept of an offline user? Can a user's watched phrases be removed from the active list so that lloid doesn't search for them when the user isn't around to be notified?

Best guess: queue closed before guest could arrive, and Lloid possibly doesn't check that.

I'm not sure of the exact cause, but the logs indicate that the timers on old visitors might not actually be getting cancelled, so that might be it. Old visitors say done, letting in the next guest, but their timers expire after that, letting in another one. But it doesn't seem to be happening all the time.

It currently isn't possible to update the descriptions listed in the announcement channel.

Since it's possible for a host to have their situation change in one way or another, or make a mistake, hosts should be able to change the descriptions.

The bot should simply edit the announcement message in order to reflect this.

Example:

123 C0FEE 8 Hello this is my new description 

Idea:
!closewhen [minutes] -- Automatically close listing in x minutes. Use of this command will broadcast time remaining to all in queue, plus a warning every hour, and in the last 20 minutes.

!closewhen rollover -- Compute minutes left and automatically close listing at turnip rollover time. This feature was previously omitted because time travellers could extend their prices indefinitely. This is no longer the case, so there is a stronger case for it.

!closewhen exhausted -- Automatically close queue when queue size hits zero

Currently only checks when a user tries to queue. It's feasible that Lloid could break if someone changes their DM settings while Lloid is supposed to be interacting with them. This should be done in the refactoring.

If the queue is paused, have lloid say so upon use of !queueinfo.

A host somehow opened two queues. After he closed one, another was still there, but because it wasn't actually a valid queue, visitors got into a corrupted state where they couldn't queue up for anything if they queued up for the invalid queue, because they could never unqueue. There is now a sanity check to make sure the visitors don't get corrupted, but this does not fix the host creating two queues at once.

Attached is a truncated log file of user's message history with Lloid. Hopefully this will help us reproduce the problem.
lloid-oyster-2020-04-23-edited.txt

Truncated were several paragraphs of the text Lloid normally spits out, and omitted entirely were the lines where user queued up for someone else's island, as I'm fairly confident that this had no bearing on the bug.

A guest queueing up should be able to type defer to push them backwards a few slots.