Jump to content


WFG Programming Team
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Dunedan

  1. @rossenburg Are the changes proposed by @smileysomething you can work with for the UI part?
  2. The feature to be able to change the password, won't help such users at all, as they can't proof that the account they want to change the password for is their own account. There is a difference though between users who don't remember their password and don't have it stored in 0ad (these are the ones which can't change their password) and users who don't remember their password, but have it stored in 0ad (those ones can still log in and should also be able to change it). How would you do that? As you don't have their password you can't be logged in into their account, which is a prerequisite to changing the password. Essentially it's the same as for most websites which offer accounts: To change your password, you have to log in first. Once logged in there is somewhere a form you can use to change the password. Note that this is different from a password reset process which usually doesn't require a login, but something like a recovery email instead. That's a use case we can't cover for now.
  3. AFAIK neither gloox nor ejabberd support checking the current password during password changes, because you can change your password anyway only when already being authenticated. So to implement that you either have to check against a locally stored password or do some re-authentication during the password change. Checking against a local stored password is something which can be circumvented with a patched version of 0ad and isn't straight forward anyway, because storing the XMPP password is optional. Doing re-authentication with the XMPP-server during password change adds a lot of additional complexity and isn't as it's usually done with XMPP. Also keep in mind that most players which have stored their password in 0ad probably don't even know anymore what their password is and therefore wouldn't be able to change their password at all, if a password change would require typing in the current password. What would be the benefit of checking the current password anyway? In which situations would that provide a benefit? The only situation I can imagine right now is when granting an untrusted person access to your computer, but that's a case we shouldn't try to handle. If an untrusted person has access to your computer they can also simply install a keylogger and get the password that way. My suggestion is to keep the initial implementation as simple and straight-forward as possible. Avoid stuff which adds complexity in terms of code as well as in terms of user experience if it doesn't provide a significant benefit.
  4. While I'm not that familiar with the Pyrogenesis side of things, that sounds like it'd make a lot of sense. AFAIK changing the password is only possible after authenticating. I guess you're aware, but there are several Pyrogenesis related functions (like "ChangeGame" and "GetProfile") missing. As a disclaimer: I'm currently working on the server-side for PubSub (https://trac.wildfiregames.com/ticket/4203), which will require some additional changes for Pyrogenesis (like subscribing for the relevant PubSub nodes), however I believe that should happen separately and after such a refactoring.
  5. *bump* Anybody interested in contribution password change functionality? If there are any roadblocks regarding that just let me know.
  6. Please consider that @Stan` as the project lead might have a better picture of a situation than you do. The code for the bots is open on https://github.com/0ad/lobby-bots and contributions are always welcome. In case you're willing to contribute, but don't know what to tackle, feel free to reach out to me. Aside from the bots, contributions for the 0ad client side lobby code would be much appreciated, as I only work on the lobby bots and server-side lobby setup. A month ago I called for an implementation of password changing functionality in 0ad, but so far nobody has come up with an implementation. Please also be aware that I'm by no means blocked by technical topics, but rather how certain things are getting handled at WFG, but that's nothing to discuss here.
  7. No idea if the lobby code in pyrogenesis supports something like popups. Afaik announcements are currently displayed as chat messages from "system".
  8. 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.
  9. 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
  10. That's the problem, it should be this instead: muc_admin: - allow: admin - allow: bots
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Yes, that would work as well, but I'd like to avoid that for the reasons you mentioned.
  20. 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.
  21. @Stan`: Sure, sounds good. You should also be able to change the message on your own.
  22. 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?
  23. 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.
  • Create New...