I do not want to break all current passwords unless we have a plan in place to address that.

Yes, it seems to work well. I tested everything I could think of. Unit tests pass. Ratings work. Spotted a couple white space problems in the bots' chat responses.

Now based from ps/trunk/

The patch was not working properly. I just recopied the files. I'm still not sure why the last attempt produced garbage.

This patch still isn't working correctly. Please standby; I'm having to figure out why svn diff is producing something unusable. Anybody have any thoughts?

Why don't you generate the patch in the root https://code.wildfiregames.com/source/0ad/browse/ps/trunk/

instead of https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/tools/lobbybots/

Per elexis' suggestion, this patch doesn't rename or move things anymore.

In D2630#111281, @Dunedan wrote:

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

In D2630#111114, @Dunedan wrote:
Invalidates as in requires additional changes to this revision after merging?

That will need to be changed to be correct after this is applied.

Because to have systemd unit files seems still be to be desirable to me.

Yea I think so too.

Missed some copyrights

I used svn mv to move and rename the files. This way allows comparison of the files.
I also updated the copyright year.

added tests folder

https://github.com/Dunedan/XpartaMuPP/commit/014f52bc4d8f36fc570d3139b4fd90f54c072e47 Initial commit with code from SVN

The markdown renders well and the document reads well. Unfortunately I did not get a chance to go through all the steps on a fresh install of ejabberd.
One area that I tested on ejabberd was the mod_ipstamp installation instructions and those worked out very well and saved me some time. TY elexis. :)
It seems obviously a big improvement over what we had before.

I'm going to fix the 11. 12. 13. thing and then commit this.

Links are not being rendered because you're putting them in codeblocks instead. Do you want me to mark them?

@Dunedan Yes. XpartaMuPP would relay the profile lookup request with a recipient element. EcheLOn expects to see recipient included with the profile command and (strangely) parses that for the lobby.wildfiregames.com/0ad portion. When that was missing, the command would throw an exception and cause EcheLOn to send ProfileNotFound.

Besides, was there anyone who spammed more than 20 messages more than once per year?

I think we could just have an option to allow unauthenticated clients and that would enable the host to decide when it's OK.

Now it's clear we only support the old version of ejabberd but it's also kind of implied that we will soon support newer versions.

I tested this and the OOS I was having does seem to be resolved.

We only support ejabberd 2.x for the time being. I've indicated that near the beginning of the document and I inform the user that it's available in Debian wheezy.

Yes I'm running ejabberd 16.01.

This version uses pound sign (#) instead of sudo.

Added sudo to several lines and rephrased lines 90-96.

I guess it's ok to assume sudo is installed if it's installed by default on the most popular Debian-based distributions.

Now I've just looked closely at the textual changes made and found a couple issues.

I tested the markdown output and it looks good. 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.

Yes the certificate thing appears to be caused when I upgrade sleekxmpp to 1.3.1.

Can we add to the title of this something like 'and convert to markdown'.
Then let's keep this revision focused on the conversion and feature some simple text cleanup if necessary. When we decide the markdown is good we can get this closed.
We can then address the other concerns about how it should read with newer versions of ejabberd config in a separate diff. Also note upcoming necessary change related to #4540 if that issue's latest proposal is adopted.

Seems good and it tested well for me.

It's probably fine. The only thing is that there's been no testing of the fix and testing it might be tricky prior to release... maybe I should raise a concern on that commit instead..

Updated programming.json.