Restore the original directory structure that was in the github repo.
Fix some problems in the tests.

The issue is instead fixed in D3944.

Slight cleanup.

you even have it in database, one attacks database and knows all passwords.

The passwords are transmitted and stored with the server using SCRAM

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.