Dunedan

First of all there needs to be a consensus how this should work. Should there be one rating or one for 1vs1 and one for multiplayer games? Also I'm not sure how good results for rating multiplayer games would be with the current ELO implementation. Maybe it'd make sense to switch to another rating algorithm for that. Once all these details are clarified it's just a matter of enabling/implementing the necessary support in EcheLOn and enable sending of game reports for multiplayer games with more than 2 players in pyrogenesis.

These are just warnings. It should work nonetheless. There is already an open pull request, which will get rid of these warnings once merged: https://github.com/0ad/lobby-bots/pull/13

That's the problem, it should be this instead: muc_admin: - allow: admin - allow: bots

Of course it does and I didn't say otherwise. You likely didn't properly configure ejabberd, so EcheLOn doesn't get the JID of users joining the MUC room. To fix that you have to either ensure that the MUC room isn't anonymous or that the bots have MUC admin permissions. How to configure any of that is documented in the README. If you can't get that to work, posting your ejabberd.yml here would be helpful for further debugging.

My guess would be that you didn't open UDP Port 3478 in the security group of your EC2 instance. At least that port isn't reachable from the internet.

Sorry for being not clear. That means you should be able to join the lobby and chat there without the bots. With the bots correctly configured hosting games and having ratings available will work. When registering an account with 0ad not the provided password will be used as actual password of the account, but a hash of it. You can find this hash in the 0ad config file and can use it as password to connect with other XMPP-clients. As @Stan` already mentioned: That message is the topic set for the #arena26 MUC room on the Wildfiregames lobby server, so technically ejabberd is sending it to you. Right now this ejabberd instance is publicly available and everybody can create accounts there and connect to it. I'm not sure if that's intended. I just created an account there and can confirm: registering via 0ad works, login via 0ad doesn't. However login with other XMPP-clients works, which is something I haven't seen before. I did some debugging and figured out what the problem is: When you try to log in using 0ad, 0ad connects indeed successfully to the server, but when it then tries to join the "arena" MUC room it receives an unexpected response, as that room doesn't exist and the user is also not permitted to create it. So creating the "arena" MUC room should get 0ad to work. In case you were also getting "authentication failed" messages in 0ad, that's because 0ad does only seem to the password, when the connection to the lobby was made successfully, which isn't the case right now. Typing in the password again before connecting solves this.

At that point the bots play no role yet, so you can ignore everything related to the bots. Your problem must be related to the ejabberd setup or 0ad configuration. Even without the bots you should be able to enter the multiplayer lobby. What won't work without the bots is hosting games and rating of games, but connecting to the lobby and chatting there doesn't need the bots. To help you further we'd need some more information, like the 0ad configuration options you used, screenshots of the problem and a debug log from ejabberd. No, everything you need should be in the README (albeit some details might be outdated). You don't need PostgreSQL. ejabberd should be configured to use its included mnesia database and EcheLOn can use any SQL-database supported by SQLalchemy. It defaults to sqlite if you don't explicitly configure something else. There is no separate repository for the "lobby" itself, as the lobby is just ejabberd with the configuration mentioned in the README.

I believe that won't be necessary, as sharing accounts isn't permitted anyway and loosing access to a shared account does already happen right now when the account gets banned for any reason.

Changing your password 10 times in 2 minutes does not stress the server running the lobby at all. Much more often might, but we have rating limiting against such DoS attacks in place, therefore considering any additional rate-limiting isn't necessary.

Sorry for being not clear about that, but as @smileyalready clarified I was talking about changing the password after successful authentication. So this thread is not about a "forgot password" feature or how to also collect a users email address during registration, as that would be much more effort, but solely for allowing an authenticated user to change his password. That should be, as mentioned in my initial post, pretty straight forward. Please stay on that topic here and discuss additional ideas in other threads.

Up to now 0ad doesn't offer the ability for users to change their passwords for the multiplayer lobby. However, that'd be a great feature to have and has in fact been already a feature request for several years (https://trac.wildfiregames.com/ticket/2543). I had a quick look and believe this should be pretty straight forward to implement, as the server-side as well as the XMPP library used by 0ad already support that. So all left to implement it is to add some glue code to 0ad and build the UI for it. If you're interested in helping out and implementing this feature or have any questions, please reply to this post or send me a PM.

Yes, that would work as well, but I'd like to avoid that for the reasons you mentioned.

If you as a player see somebody you consider a smurf, why do you need any codified algorithm at all? Wouldn't just not playing with this player be sufficient? I believe this thread is more about automated detection, which helps detecting non-obvious smurfs. I'd suggest not taking any preemptive action on server-side anyway, but instead leaving it up to players if they want to get likely smurfs tagged in the UI or even excluded from their games. That'd then have to implemented client-side.

@Stan`: Sure, sounds good. You should also be able to change the message on your own.

To clarify some assumptions about what information we store server-side and can make available to 0ad clients: 0ad only sends game reports for rated 1vs1 games to the lobby bots (see https://github.com/0ad/0ad/blob/3faa301ee914b82b1bfd89f2e89bc6392e244997/binaries/data/mods/public/gui/session/lobby/LobbyRatingReporter.js#L55-L56). Therefore we have no record of unrated or multiplayer games with more than two players in our database. That's because the bots were built for two purposes: enabling multiplayer functionality and keeping track of ratings. For both of that keeping track of unrated or non 1vs1 games wasn't necessary. Detecting smurfs wasn't a requirement back then. I'd be open to store reports of unrated and non 1vs1 multiplayer games as well, to be able to provide more information like aggregated values of play rated and unrated games to 0ad clients, if the consensus is that this would be useful. Doing so would not only require changes to 0ad, but to the lobby bots as well. Regarding the account creation date: We do store the date when players create an account, but that's not accessible to the lobby bots right now. Here is the database structure EcheLon, the bot responsible for handling rating related stuff, uses: https://github.com/0ad/lobby-bots/blob/8549e62dd40fd582412b4c8fc829fc672e8ddd17/xpartamupp/lobby_ranking.py. From that you can see that players have no date associated with them. You might also notice that we don't store the date for when a game happened. My proposal here is to change that so that EcheLOn stores the date whenever he gets the first request for returning player information (which happens immediately after player registration) and to store the date a game finished, based on the time its reports get submitted to EcheLOn, as well. I believe storing the dates is a no-brainer and something we should do in any case. After implementing that, we could return the registration for all players created after the change to 0ad clients. Independently from smurf detection that's probably something which would be interesting to display in the player profile. Last but not least there is some point I'm wondering about, which hasn't been addressed yet (unless I've missed it). In this thread there seems to be the assumption that the logic for smurf detection will be integrated into the 0ad client. I wonder if it wouldn't make more sense to do that server side, as that'd allow adjustments of the "smurf detection algorithm" between 0ad releases and would allow incorporation information into the algorithm which might not be suitable to return to 0ad clients (e.g. for privacy reasons). When doing the detection server-side only some kind of "smurf likelihood score" would need to be made available for 0ad clients. What are your thoughts on that?

Actually reviews by everybody who feels confident assessing the changes of such PRs are appreciated. I'll also soon merge this and some of the other PRs, no matter if somebody looked at them or not, as otherwise the development of the bots is blocked too much by waiting. Please mind that merging this PR won't result in the bug being fixed in the actually lobby immediately, as the bots running there have to be updated to use the new code and that might still take a while until we have a better process for that.

You can transport arbitrary data over XMPP, so that would certainly be possible using XMPP. However, any webservice exposing an HTTP-endpoint to submit such information to would do as well.

I believe reporting and having mods deal with it is the better way to handle that. When talking about writing code, I'd rather prefer reporting functionality directly integrated into 0ad to make it easier to report offenses with all contextual information already attached in a standardized way.

This issue is solved for now and the lobby is back up again.

The ratings will be migrated once A26 gets released. The dev version of 0ad always uses a separate ratings database as the server-side lobby code (and possible the database structure) differs from version to version and might break something for the currently released version.

Please try again. This should work now. Sorry for the inconveniences.

Yes, it's based on ELO with some modifications. The current logic can be found here: https://github.com/0ad/lobby-bots/blob/master/xpartamupp/elo.py

Just to chime in with my opinion: I barely play anymore, because a24 just feels dull and boring, as civs are now all (more or less) the same. I really liked the kind of differences between the civs before. Aside from that the most annoying changes for me are the sounds as well and the reduced movement speed of units.

Just to clear things up: plautus' rules for this game were: no bolts, no catapults and no slingers. There was no rule about not entering the opponents base or something like that. That's again one of the cases where including the ingame chat log in the replay would be beneficial, as I proposed a while ago: https://trac.wildfiregames.com/ticket/5070

Also quite funny from lobby chat afterwards: