Jump to content

Dunedan

Community Members
  • Content count

    17
  • Joined

  • Last visited

Community Reputation

6 Neutral

About Dunedan

  • Rank
    Discens
  1. There are now a two additional patches up for review in Phabricator, whose goal it is to get "the lobby" to work with recent versions of its dependencies: D1182 – Make XMPP-bots work with newer SleekXMPP versions D1208 – Update mod_ipstamp for current ejabberd versions I'd be really glad if someone could review these patches, together with the already mentioned D1177.
  2. bitodiego quitting rated games

    Attached are two replays of bitodiego quitting rated games. I heard other players have plenty of replays of the same situation as well. @Hannibal_Barca @user1 bitodiego1.zip bitodiego2.zip
  3. Different angle/perspective for players

    Both players having the same civ (and therefore the same CC height) doesn't seem to change anything. But what does change the angle is the position of the window on the screen. The only difference in the following screenshots it that the left window from the first screenshot is the right one in the second and vice versa.
  4. Different angle/perspective for players

    Here are two additional screenshot made from the "wall demo" scenario and the "oasis" map. Both should have the same heights for the CCs if I'm not mistaken. For me that still looks like a different camera angle as well. I'm also curious how a different zoom level can even happen when the only difference between the configuration of the two instances are the lobby related settings. Could that be related to windowed mode? I've the feeling this difference goes away once I switch to full screen.
  5. Different angle/perspective for players

    It happens every time I start a game. As I usually do that with "unknown" map I'm pretty sure it's not related to the height of the CCs. I also haven't changed anything configuration related.
  6. I just built the latest SVN and noticed that somehow the angle of viewing at the map is different. That change must have committed during the past few days and I'm not sure if it's a bug or intentional. The following screenshot is from the same multiplayer game, right after starting it with two 0ad instances in parallel. You'll notice the perspective of looking at the CC is different for the two players.
  7. Advertisment on 34c3

    Its the 34th Chaos Communication Congress (https://events.ccc.de/congress/2017/wiki/index.php/Main_Page), a yearly gathering of hackers organized by the Chaos Computer Club (https://www.ccc.de/).
  8. > here's a function to update ratings based on the Glicko system and using scythe's same signature. I guess the motivation is to have a better algorithm than ELO? Is there any previous discussion on this topic? > Since inactive time and rating deviation are not stored, I used the games played to compute the deviation. Aren't you neglecting the major advantages of Glicko compared to ELO by doing that?
  9. A first patch to let 0ad talk directly to EcheLOn is now available for review: https://code.wildfiregames.com/D1177
  10. While SQlite claims they're able to do that (https://sqlite.org/faq.html#q5) I did did a quick test to verify that it works for EcheLOn and edited the sqlite-database file using sqlite3 while EcheLOn was running and it worked perfectly well. Suddenly my test account had a a rating of 5000. ;-)
  11. I seriously doubt that the GIL is the problem here, but I'd be pleased if you prove me wrong. That's another possible solution. Would work for me as well, as the problems I currently see are based around the relay functionality. No question, that should be supported in any case. How does that relate to restarts of EcheLOn? Isn't that simply covered by removing the accounts from the database?
  12. Yes, that's an advantage, but is there any other reason for that than splitting the load onto two servers? Does it happen that EcheLOn needs to be restarted, while XpartaMuPP doesn't? If yes, I'd be interested to know why.
  13. 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?
  14. 【Fixed】SVN20325 compile error.

    Have you tried recompiling gloox as suggested a while back when you had a similar problem? https://trac.wildfiregames.com/ticket/4605
  15. 【Fixed】SVN20325 compile error.

    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);
×