Dunedan

As some of you might know I started looking into the lobby bots (EcheLOn and XpartaMuPP) a while ago with the goal to improve on some of their shortcomings. While I have nothing to share yet, I already cleaned up the code base and made it work with current versions of its dependencies and ejabberd (including mod_ipstamp), amongst several smaller improvements in various areas. There is one detail that keeps me thinking: Is there really a need for two separate bots? If my understanding of the original intention (see #3022 [PATCH] Split rating from lobby bot into another ) is correct, it was done for two reasons: 1. Allow to run the lobby without ratings functionality. 2. Remove load caused by the rating logic from the bot who's responsible to manage games. While these goals are noble, I'm not a friend of their current implementation. As currently implemented 0ad sends all lobby-related requests to XpartaMuPP. When XpartaMuPP realizes that it's something concerning ratings (rate a new game, fetch ratings to show to players, ...) it'll relay this request to EcheLOn. That relay-functionality causes a lot of complexity, makes it unnecessarily complex to fix issues like #4812 XpartaMuPP doesn't use original id for responses and causes load on XpartaMuPP which wouldn't be necessary. What I like to propose is to merge the two bots again in future and implement the following measures to fix the original issues: 1. Add a command line flag to enable/disable rating functionality. 2. Make more use of threads to distribute the load better. What are your thoughts about that?

Have you tried recompiling gloox as suggested a while back when you had a similar problem? https://trac.wildfiregames.com/ticket/4605

Relevant changeset: SVN20321. I'm afraid I can't really help here, as I'm neither really familiar with C++ nor do I have Windows available for testing. If there's anything I can help with I'm glad to do so. Just a shot, but can you check what happens if you apply the patch below? diff --git a/source/lobby/glooxwrapper/glooxwrapper.h b/source/lobby/glooxwrapper/glooxwrapper.h index 6b2f33a374..b6afe2bd6d 100644 --- a/source/lobby/glooxwrapper/glooxwrapper.h +++ b/source/lobby/glooxwrapper/glooxwrapper.h @@ -394,7 +394,7 @@ namespace glooxwrapper bool connect(bool block = true); gloox::ConnectionError recv(int timeout = -1); - std::string getID(); + const std::string getID(); void send(const IQ& iq); void setTls(gloox::TLSPolicy tls);

Ok, that was to early. The problem appeared back again, but this time I noticed that it's not related to 0ad at all. Apparently that problem appears whenever compositing for my DE gets enabled or disabled. As running 0ad disables it, it looked like it is related to 0ad, while it is not. For somebody running with KDE it should be fairly simply to check: Start Firefox and open some page, switch compositing with CTRL + Shift + F12 and you should see blank pages in Firefox.

Just wanted to point out that this problem went away for me without touching 0ad. So I believe some updated Debian package fixed it.