I've noticed while testing, that the !mp start command doesn't work when not providing any arguments.
The client will just kinda... uhh... exit out of the match and teleport back to the menu, with the text There was an error while loading this beatmap....

This issue is part of the bancho rewrite (#17)

In some cases, multiplayer matches would lead to locking up the reactor (or the threadpool). I will have to figure out why that is the case.

This issue is part of the bancho rewrite (#17)

This issue is part of the bancho rewrite (#17)

When users are logging in for the first time, their country should be updated if it didn't update already.

This was probably not as useful as I hoped it would be...
I will probably replace it with a separate logging file, that only stores errors and warnings.

This issue is part of the bancho rewrite (#17)

This issue is part of the bancho rewrite (#17)

This issue is part of the bancho rewrite (#17)

This issue is part of the bancho rewrite (#17)

I am planning to host a http to tcp bancho proxy for osu.py bots to use. However, I don't want to have other people connect using e.g. 2023 clients.

There should be a table for every login attempt, including client hash, ip address, and so on. The user should also get an email when a user logs in from another device.

There should be a rate limit for chat messages to prevent spam. Automatic chat moderation of some kind would be nice as well.

This issue is part of the Bancho Rewrite (#17)

This issue is part of the bancho rewrite (#17)

The beatmap info packets are a bit confusing to me...
First the client sends a BEATMAP_INFO_REQUEST packet, which contains beatmap filenames and ids. Then the server responds with a BEATMAP_INFO_REPLY packet that includes all of the requested beatmaps with the following attributes:

• index
• beatmap_id
• beatmapset_id
• thread_id
• beatmap_status
• personal_best
• beatmap_md5

The wierd part is the index. The index should be there to identify the beatmap that was sent in the request. That all makes sense until you see that the index is only meant for the beatmap filenames? At the time of discovery I asked myself why the beatmap ids are even there in the request, because they are not used in the reply...

However, I recently discovered that the index can just be set to -1 and the client will just find the index by the beatmap id. That means that I should be able to use the beatmap ids from the request by just setting the index to -1 for every id in the request.

It is very difficult to explain, but in the end, I am the one who gets to implement it :D

Recently, there have been some crashes to Bancho, which I thought were happening because I ran out of memory. But just to be safe, I should be testing this again.

An interesting command that you could use to check if somebody was multiaccounting... This should probably only be accessible to admins.

As you can probably tell, this issue has been on my todo list for a long time. The IRC server will be necessary for clients below b282 and tourney matches that could happen in the future.

This issue is part of the Bancho Rewrite (#17)

This command should display the client version of a player

TODO: Add notes...

I am talking specifically about the infringements table, which stores silences and restrictions for every user. This will also be very nice for later frontend use.

I want to add a table for multiplayer match history. This could look something like this on the frontend part:

Or view the link here.

3 users online, but...

this should explain basically everything.

This issue is part of the bancho rewrite (https://github.com/osuTitanic/anchor/milestone/1)

This issue is part of the bancho rewrite (#17)

This has been on my list for quite some time. The tourney client was actually already implemented back then and could be accessed by supporters just like nowadays.
That also means I have to implement them :D

What currently happens is that only one client can connect to bancho, which is obvious. The other ones will just time out, just like normal clients do.

This issue is part of the bancho rewrite (#17)