Dunedan
-
Posts
96 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Dunedan
-
-
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
-
1 minute ago, potoelite said:
muc_admin:
allow: admin, botsThat's the problem, it should be this instead:
muc_admin: - allow: admin - allow: bots -
37 minutes ago, potoelite said:
I found that rating bot uses sql database, unlike you said before.
Of course it does and I didn't say otherwise.
39 minutes ago, potoelite said:Could you please explain how to fix this?
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.
-
23 minutes ago, potoelite said:
So this means that hosting/joining game is impossible even after all is configured well?
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.
26 minutes ago, potoelite said:But as the game uses encrypted password by itself, so I can't use the account create by game in other xmpp client as password is regarded incorrect.
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.
21 minutes ago, potoelite said:Also I'm wondering about who sends this message to the game client.
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.
24 minutes ago, potoelite said:I have configured ejabberd on aws ec2 instance.
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.
-
1
-
1
-
-
2 hours ago, potoelite said:
At this point, I have following problems.
- I can register new account to multiplayer lobby, so I can confirm this in ejabberd admin page also. But I can't login with created account in the game.
Login dialog keeps saying "connecting..." after the connection is established. Why I think like this is because the account which I used is displayed as online status in ejabberd web admin, but not in the game. In ejabberd log, it also says new connection is opened.
- Server returns nothing response.
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.
2 hours ago, potoelite said:I guess there is one more component to be installed for proper work of multiplayer lobby on my side.
No, everything you need should be in the README (albeit some details might be outdated).
2 hours ago, potoelite said:There isn't any postgresql db handler on my model and both source code of game and multiplayer lobby-bots don't contain any one of above strings.
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.
2 hours ago, potoelite said:Also, the weird thing is that github repo name is just "lobby-bots", not "lobby", which means entire name of system
There is no separate repository for the "lobby" itself, as the lobby is just ejabberd with the configuration mentioned in the README.
-
27 minutes ago, Darkcity said:
Thanks for claifying. When this feature being deployed, warn players about not sharing their account details with other players becasuse after this feature, they can change the password and will never share credential with original player :p.
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.
-
1
-
-
2 hours ago, rossenburg said:
And aside that, allowing users to change account passwords without any further verification (either there's active session or not) will just promote more stress on the server since i can change my password 10times in 2mins, unless maybe we think of adding something like throttle middleware or password reset cooldown to the whole process
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.
-
5
-
1
-
-
38 minutes ago, smiley said:
An alternative but slightly unattractive solution in terms of maintenance and dependency on ejabberd is writing up a module to handle some type of age query IQ.
Yes, that would work as well, but I'd like to avoid that for the reasons you mentioned.
-
19 hours ago, Sevda said:
There is one thing which I didn't understand: how can a smurf detection algorithm work on the server side? Smurfs are discovered by players who see a new account playing like experts and talking with 0AD jargons. I'm not sure how the server can tell these details.
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.
19 hours ago, Sevda said:Furthermore, even if you do install such an algorithm, I would recommend only allowing it to flare up smurf suspects to the moderators instead of pre-emptively taking actions themselves. AIs are quite likely wrong and the lobby would be a mess if it bans a moderator or WFGbot.
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.
-
1
-
-
-
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?
-
3
-
2
-
-
4 hours ago, Stan` said:
Fix here waiting for review by @user1
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.
-
7 hours ago, Stan` said:
Does Xmpp allow that somehow?
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.
-
On 11/07/2022 at 6:40 PM, Stan` said:
can we have a bot for this ?
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.
-
2
-
-
This issue is solved for now and the lobby is back up again.
-
1
-
6
-
-
16 minutes ago, Sevda said:
However, there is an issue: I became a 1200 player in A26; all of my previous points were left behind in A25.
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.
-
1
-
-
On 08/06/2022 at 8:27 PM, Sevda said:
- Can't see hosted games in the lobby
- Ratings don't work
Please try again. This should work now. Sorry for the inconveniences.
-
2
-
1 hour ago, Stan` said:
@Dunedan do you how it currently works? AFAIK it's a modified ELO system
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
-
1
-
-
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.
-
4
-
1
-
1
-
-
On 8/5/2019 at 1:16 AM, abc1 said:
Interesting!!! I watched that replay. And Dunedan was clearly breaking Plautus rules!!!
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
-
1
-
-
Also quite funny from lobby chat afterwards:
Quote[15:55:03] <Dunedan> plautus: I'm going to report you for leaving a rated game.
…
[15:57:56] <plautus> guys join DEAHTMATHC
[15:58:03] <plautus> im the invincible plautus-
2
-
Suggestion - 0ad should allow Team Registrations and Team Ratings.
in Gameplay Discussion
Posted
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.