In D1663#204741, @Stan wrote:

@lyv @Dunedan @user1 @defc0n this pretty nice what do you think?

As there haven't been any more feedback on this revision and we had various cases where people got confused which code is the current one, I went ahead and committed the changes now.

I am in a bit of a pickle. Should this be committed regardless of string freeze?

Yes, that's still relevant. I just opened a PR with a fix for that: https://github.com/0ad/lobby-bots/pull/10

In D1661#193330, @Stan wrote:

@Dunedan anything still useful here?

In D4262#181756, @Langbart wrote:

20:51 < Langbart> @tell Dunedan In D4262 I would like to include "Engine.SendGetBoardList();" to get the top100 players for autocompletion. Is this an idea that causes more stress on network traffic and should not be included?

Found the lobby bots mentioned in the licensing information for the tools and removed it there as well.

And in case it wasn't clear from the code, the trigger script spawns wolves, the wolves receive Move orders making the wolves attack the players units - so basically zombie wolves. It was added to make the map less boring. The wolves are Domestic because currently only Domestic animals can follow move orders […]

Sorry, but I don't get your point. Clearly non-domestic animals are as controllable right now as are domestic animals. So what's the problem with this patch from your point of view?

If it needs to be a breaking change anyway, why not to remove the whole logic for generating the actual password by hashing the username and password and instead just using the password as password? Wouldn't this result in the same logic as other XMPP clients use as well?

Looks good given the current constraints for the password generation logic. 👍

@user1 : Did you verify the code now doesn't just apply but also works with this patch?

In D2630#111282, @Stan wrote:

I believe the patch doesn't have the correct root folder. I assume those files are in source/tools/lobby?

I can't apply the patch to current SVN. Am I doing something wrong or is it incomplete?

In D2630#111116, @elexis wrote:

I would suggest to rename "utils" to LimitedDict or similar, otherwise it invites developers to add many unrelated things. We can see in binaries/data/mods/public/gui/common/functions_utility.js an example of this, and then the difficulty to split it into logically cohesive components accumulates.

The following revisions are lost because of this:

r22460 | 2019-07-12 13:40:40 -0400 (Fri, 12 Jul 2019) Fix lineendings. (partially lost)
r21927 | 2018-11-07 12:32:21 -0500 (Wed, 07 Nov 2018) The files in this path were not marked as moved in rP21926...

As already mentioned I don't see a benefit in using a sysvinit script. I'd just use one systemd service template for each bot and one systemd service instance per bot instance.
Such a systemd template would look like:

[Unit]
Description=XPartaMuPP Pyrogenesis/0 A.D. Lobby Bot %i
Documentation=https://trac.wildfiregames.com/
After=network.target ejabberd.service

Why to use systemd services to call sysvinit init scripts? Why not just using systemd services? That'd make everything easier.

In D1659#65939, @elexis wrote:

We need two bots per room, not two bots per server.

In D1659#65912, @elexis wrote:

The pid/logfile is handled by systemd.
There is one logfile and pidfile per bot, at least one bot per room, but one systemd service handling all bots.
I don't see a better place to put them rather than the directory for that room for that bot, do you know one?
(Every bot instance needs an own code copy to provide the correct version for everyroom).

In D1659#65867, @elexis wrote:

Perhaps it makes sense to have the bots in the same python installation package.

In D1659#65858, @elexis wrote:

A folder named XpartaMuPP should not contain EcheLOn.
I propose to use a separate folder for XPartaMupp and EcheLOn. The directory is becoming quite messy. Not going to upload a diff with moved files, but I do propose:

@user1: Do you have any more details regarding this?

In D1177#58260, @elexis wrote:

Does this throw any kind of error if EcheLOn is offline? (Guess not, given how few code this diff changes)

Rebased to account for some lobby changes in SVN.

In D897#52116, @Imarok wrote:

If we recieve an unexpected lobbyauth token, we should just ignore it. Everything else will be far too complicated for no benefit.

In D897#51842, @Imarok wrote:

Reply with an empty result.

In D897#51174, @Imarok wrote:

So this would be ok for you?:

The stanza currently sent will become a request of the type set.
The servers xmpp client will respond over xmpp with an ack or whatever that the receiver will just accept and ignore.

In D897#50538, @Dunedan wrote:

• The child element of IQ-stanzas should be named query, instead of auth.

Easy to answer:

• I wasn't aware that there are already other schemas for XML documents in 0ad (I might have searched for XSD only).
• XMPP extensions are usually defined using XSD (e.g. here is a random example: https://xmpp.org/extensions/xep-0092.html#schema)

In D897#50757, @Imarok wrote:

Could you show me the part of the standard that says a response always must be a answer to a query? I couldn' t find it the last time I looked into it.

XSD for game results is still missing.

In D897#50646, @Imarok wrote:

Then most of our code is not valid. I think it's valid enough...

It's intended that he stanza sent is a response and not a request. Exactly to follow this request-response rule. (With the exception, that the request from the server wasn't sent via xmpp but via enet)

In D897#50427, @Imarok wrote:

It's missing cause the stanza is printed before gloox adds it.

In D897#50124, @Imarok wrote:

Edit: This is how an iq-stanza sent for lobby auth should look like:

SendIqLobbyAuth [<iq to='imarok@lobby.wildfiregames.com/0ad' id='uid-1f75c630-00000005' type='result'><auth xmlns='jabber:iq:lobbyauth'><token>CABE93B117739A47</token></auth></iq>]

An alternative is to connect using a regular XMPP client instead of a second instance of 0ad. As the second XMPP client uses another resource identifier it's not causing any problems.

In D791#49737, @mapkoc wrote:

Dunedan, I see a problem with that. If you open a second window and join multiplayer, both windows would fight to auto reconnect. Maybe it's best to give the user the decision.

For whatever reason the changes for EcheLOn were missing. This update to the patch adds them

Why showing a dialog in the first place at all and not automatically reconnecting in the background (with exponential back-off, ...) and only showing a dialog of that continues to fail?

For me this patch doesn't work applied to current master. When setting up a new game with enabled "Require lobby authentication" the game setup page never opens and instead it gets stuck at the "Registering with server" dialog. What I can see in the background is that there is a IQ-stanza sent via XMPP, but this stanza doesn't even contain a recipient (and might have some other problems, but more on that once it works). For me it looks like the game tries to authenticate the hosting player as well. Is that intented?

Step 1. Apply the patch and install python3-sqlalchemy-utils on the server.

In D1208#49232, @Itms wrote:

I'm facing a blocking issue before even testing this: I cannot install ejabberd from the backports on a fresh Debian VM...

@Itms: Apparently there is already a note in the README about the supported ejabberd versions. Enough for you to continue to review or even approve this patch?

I feel like this patch is in some kind of dead-lock right now.

Improved docstrings

Fix diff

As suggested changed the if to a for loop.

In D1197#48522, @elexis wrote:

Can you try to take a look to unify that, preferably by just updating the pattern?

In D1197#48513, @elexis wrote:

XEP numbers and links should be documented in the code (see ticket, see documentation of the function).

I like the idea of optional message for created/finished games, but I'm not a big fan of the other two. What I'd rather like to see a brightness change get used for is for the message backlog when joining the room.
I think the dots and brightness per status add to much clutter to the chat window, especially as they dynamically adjust to the current player status. They also don't provide any information which isn't already available from the nick list.

I tried it out and it works as advertised. While I like the idea in general I find the two-names-per-chat-message a bit too much. What about showing the lobby-username only in the summary screen and using the multiplayer name for the chat messages, no matter how the multiplayer game was set up?

In D280#47719, @elexis wrote:

Dunedan if you have any code updates, please upload them.

The README instructions are correct for ejabberd version 2.x but not later. I think we can start work on that in a trac ticket discussing changes (code and readme changes) needed for upgrading ejabberd.

I tried it out and it works like a charm. A little, but a really nice improvement. ?

The following commands should work:

The following commands should work:

+1 for min_message_interval for the lobby, because that does enforce such a limit on server side, thus not allowing a player to remove it.

Added myself to the credits.

In D899#37200, @Imarok wrote:

Ok, then wanna make a ticket about that?

In D899#37194, @Imarok wrote:

As said in irc already, it should probably be checked before why we don't get back the correct id when sending iqs to the bot.

First: the PMs containing "secureLobbyAuth: " are filtered out, so no player will receive Thema.

• The files included in the patch are the only XML-files in the whole 0ad-repo with encoding ISO-8859* (except for ./binaries/data/mods/public/gui/common/init.xml, which already got deleted in f2c16d1cdae273df86530a6b49b4a6c6cdee3549)
  • checked with: find ./ -iname '*.xml' -exec grep -l -i -E 'encoding=.*iso-8859' {} \;
• None of the files above contains non-ASCII-characters:
  • checked with: for f in $(find ./ -iname '*.xml' -exec grep -l -i -E 'encoding=.*iso-8859' {} \;); do grep --color='auto' -H -P -n '[\x80-\xFF]' $f; done

A custom iq stanza would be the cleanest way to implement it (and avoid the secureLobbyAuth: string), but sounds like work.

I've no knowledge of the background of this, so please bear with me that's a stupid question, but why is there the need for a separate handshake, when each player is already authenticated to the lobby with its unique XMPP JID? Can't that, or something derived from it, be used as GUID?