feat: Add onlinemembers and player command

[ShadowCat117]

/onlinemembers <guildName> shows the current online members sorted into guild ranks. It supports entering guild name or prefix, case insensitive though so if there are multiple matches it will return whatever is found first. (Players in /stream are shown as offline in the API but still show in guild total hence 12 online here but it says 13)

/player guild <username> shows the guild a player is in, their rank and how long they have been in the guild for.

/player lastseen <username> shows if a player is currently online and their current server, or when they were last online if they are currently offline.

The /player commands also have support for the multi selectors where there can be multiple players with the same name in the API. Clicking a UUID will run the respective command with the UUID to get the correct result. As guild names are unique this shouldn't be necessary for /onlinemembers

Wynntils/Static-Storage#108

[kristofbolyai]

I think this looks good. I only wonder if there the command parsing should be moved from the command, to a Service (or a Model..? This is in a gray zone between the two). We've not done anything like this before, so we have not figured out where commands like this really fit into our overall design. Since these are going to be the only commands of this kind, Overall, I think we should hold off on refactoring this into a new higher-level abstraction of some kind, until this type of command appears a few more times.

[magicus]

I only wonder if there the command parsing should be moved from the command, to a Service (or a Model..?

I think this looks okay..? Maybe I skimmed the code a bit too quick, but I did not understand what you were reacting to. All our commands implement (or extend, I do not remember) a Command baseclass (or interface), and we have some general framework to hook into the vanilla command thingy. It is somewhat complex, and I have been thinking about making it easier, but it is difficult. Even though it is a bit heavy-handed, the vanilla system is rather well-designed and it is hard to make anything much better, at least as long as you want it to be Java-only.

[ShadowCat117]

I only wonder if there the command parsing should be moved from the command, to a Service (or a Model..?

I think this looks okay..? Maybe I skimmed the code a bit too quick, but I did not understand what you were reacting to.

I may be wrong but I interpreted it as the parsing of the json into the response for the user to see should ideally be handled elsewhere, usually when we make calls to athena or download static data it's all handled inside a Model or Service, but this is done inside the command

[kristofbolyai]

I only wonder if there the command parsing should be moved from the command, to a Service (or a Model..?

I think this looks okay..? Maybe I skimmed the code a bit too quick, but I did not understand what you were reacting to.

I may be wrong but I interpreted it as the parsing of the json into the response for the user to see should ideally be handled elsewhere, usually when we make calls to athena or download static data it's all handled inside a Model or Service, but this is done inside the command

Yes, this is what I meant.

[magicus]

Aha, I see. I checked too quickly before. Yes, I agree. It should most likely be a model, according to the idea that a model captures something "Wynncraft knows about", and what we get from their API is by definition something they know about.

[kristofbolyai]

Aha, I see. I checked too quickly before. Yes, I agree. It should most likely be a model, according to the idea that a model captures something "Wynncraft knows about", and what we get from their API is by definition something they know about.

Sure. If @JamieCallan117 wants to refactor this now, go ahead, if not, I think it is not a pressing issue until we need those API calls for other features.

[ShadowCat117]

I won't do it now, want to get the filter screen done and it's giving me some trouble but after that I can