Dunedan

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:

I joined one of plautus rated 1vs1 deathmatch games. All settings, including my civ, were his choices. Nevertheless he quit the game as soon as he recognized that he's going to loose. @user1 @Hannibal_Barca commands.txt metadata.json

Look at the victory condition messages at the top. First line glitches away if there are too many of them. @s0600204 maybe?

They use the sword, so I guess it's intended.

Roman spear cav shows sword animation when hunting.

> The clients might send any kind of garbage and we get JSON errors repeated. Usually we solve this problem by removing the broken game, but it's probably better to add conditions all over the place in the long run. Clients should never show such errors in case they receive garbage in my opinion, as that's a sign of insufficient input validation (input as in data received) which can also be an wide open door for vulnerabilities, especially as it's input received via network. And we already had such a problem at least once. So I'm definitely in favor of adding proper input validation.

Tried some stuff with mixed a22 and a23 code/lobby. Seems like it basically works properly. So opening a22 lobby in a23 shows all games greyed out as it would do for incompatible mods as well I guess. There are some small bugs though. While the mixed a22/a23 case isn't relevant I guess they are valid when listing mods as well: Selecting a running a22-game in an a23-lobby causes the following error message to be shown: WARNING: JavaScript warning: gui/common/gamedescription.js line 466 reference to undefined property playerData.AIBehavior Trying to join a a22-game in an a23-lobby causes the following error message to be shown: ERROR: JavaScript error: gui/lobby/lobby.js line 1181 SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data joinButton@gui/lobby/lobby.js:1181:24 __eventhandler165 (mouseleftdoubleclickitem)@gamesBox mouseleftdoubleclickitem:0:1 or (if you clicked the join button instead of double clicking): ERROR: JavaScript error: gui/lobby/lobby.js line 1181 SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data joinButton@gui/lobby/lobby.js:1181:24 __eventhandler160 (press)@joinGameButton press:0:1

Found a little graphics glitch. Notice how the text isn't properly rendered.

Awesome. Same as the dimension of the picture, so 1278x1368. That's half of my screen in width and the full height of my screen minus status bar and window decoration. That's the setup I usually use in gamesetup before I switch to full screen when the game starts.

I just wanted to make a little thread with some small bugs, glitches and annoyances which are currently present in SVN and thus likely relevant for A23. Let's start with two issues: in gamesetup when the window is higher than wide, the settings take too much space, thus leaving to little space for the chat (see attached screenshot) the "Babylonian Scythed Chariot" the persians have available got a new "walking" sound (maybe other units as well). While that sounds fine for single units it sounds horrible if there are more than a dozen units walking at once.