Only misfire onto present users

[henke37]

When you miss and hit another user, you can hit some random dude who has never showed up for months.

As such, there is a large chance of the event not having the full impact it is meant to have.

As a solution, only pick from currently online users to give a higher chance of the event having the impact it is meant to have.

[Diagamma]

IMO this is not a good idea, since it would limit a lot the people who can be shot.

Plus, some people are always in "invisible mode", and that would mean they'll never get shot.
And being shot has no impact whatsoever on the victim, it's only a addition which adds some diversity/randomness.

The bot already makes sure that the victim has played DuckHunt at least a bit (issue #17), and I think that's enough.

I'm not closing the issue though, I'll wait for @paris-ci's (and maybe other people?) opinion.
(sidenote : as always, please excuse my approximative english)

[paris-ci]

I agree with @Diagamma, for 1 more reason, the life insurence shop item needs a fair distribution of the players that get killed.

[cfi2017]

• inactive player: Player that has not [sent a message in [guild/channel?] / played DuckHunt] in [x] time.

What I gather from this issue are the following points:

• Shooting a player that is inactive is fairly pointless.
• The issue proposes not to shoot inactive players, however:
  • It might be technically difficult to determine whether or not a player really is inactive [1]
  • For life insurance to stay useful, the number of active players has to be large enough to prevent abuse of the item and players shouldn't be marked inactive if their life insurance is still valid.

Therefore, I propose the following changes:

• A clear definition of an inactive player should be made and enforced.
• A player can only be marked inactive if there are at least [x] active players. [x] can be a dynamic value, possibly something like: (5 + [server_member_count / 3]). This kind of formula would solve the life insurance problem, since it would force a server to have at least 5 players / active players, while the number climbs rapidly for larger servers.

[1]: The bot should store message timestamps in the database, but only periodically for each single player or on bot shutdown. Each time a player sends a message, the bot checks the players persisted last message timestamp against the timestamp it just got. If the offset is [x] time, it should persist the new timestamp.
If the accuracy of this is too low (perhaps because the offset is too large), you could additionally store the last message timestamp in memory, and persist it on bot shutdown. This would mean a higher accuracy should the bot have to shut down for maintenance, although the gain is only very small.

[paris-ci]

I'll reopen this, the changes suggested can be implmented with the giveback var. However, I'll still have to check if the check is not too heavy CPU-wise.