Jump to content

Dunedan

WFG Programming Team
  • Posts

    93
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Dunedan

  1. > The clients might send any kind of garbage and we get JSON errors repeated. Usually we solve this problem by removing the broken game, but it's probably better to add conditions all over the place in the long run.

    Clients should never show such errors in case they receive garbage in my opinion, as that's a sign of insufficient input validation (input as in data received) which can also be an wide open door for vulnerabilities, especially as it's input received via network. And we already had such a problem at least once. So I'm definitely in favor of adding proper input validation.

    • Like 1
  2. Tried some stuff with mixed a22 and a23 code/lobby. Seems like it basically works properly. So opening a22 lobby in a23 shows all games greyed out as it would do for incompatible mods as well I guess. There are some small bugs though. While the mixed a22/a23 case isn't relevant I guess they are valid when listing mods as well:

    • Selecting a running a22-game in an a23-lobby causes the following error message to be shown:
    WARNING: JavaScript warning: gui/common/gamedescription.js line 466
    reference to undefined property playerData.AIBehavior
    • Trying to join a a22-game in an a23-lobby causes the following error message to be shown:
    ERROR: JavaScript error: gui/lobby/lobby.js line 1181
    SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
      joinButton@gui/lobby/lobby.js:1181:24
      __eventhandler165 (mouseleftdoubleclickitem)@gamesBox mouseleftdoubleclickitem:0:1

    or (if you clicked the join button instead of double clicking):

    ERROR: JavaScript error: gui/lobby/lobby.js line 1181
    SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
      joinButton@gui/lobby/lobby.js:1181:24
      __eventhandler160 (press)@joinGameButton press:0:1
  3.  

    1 hour ago, stanislas69 said:

    Sound issue was fixed this morning :)

    Awesome. :thumbsup:

    1 hour ago, feneur said:

    What are the dimensions of the window?

    Same as the dimension of the picture, so 1278x1368.

    That's half of my screen in width and the full height of my screen minus status bar and window decoration. That's the setup I usually use in gamesetup before I switch to full screen when the game starts.

  4. I just wanted to make a little thread with some small bugs, glitches and annoyances which are currently present in SVN and thus likely relevant for A23.

    Let's start with two issues:

    • in gamesetup when the window is higher than wide, the settings take too much space, thus leaving to little space for the chat (see attached screenshot)
    • the "Babylonian Scythed Chariot" the persians have available got a new "walking" sound (maybe other units as well). While that sounds fine for single units it sounds horrible if there are more than a dozen units walking at once.

    screenshot0024.png

    • Like 1
  5. 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.

    matrix-projection-oasis-same-civ.thumb.jpg.344825e82ece65560f37075fd07f68ce.jpgmatrix-projection-oasis-same-civ-reversed.thumb.jpg.c9e379165c061a0a4dea9b255082261c.jpg

     

  6. 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.

    matrix-projection-wall-demo.thumb.jpg.eeff72b6161de22d2f31f97d9e0ef3c4.jpgmatrix-projection-oasis.thumb.jpg.c79eba6698189b296a6a6f874a2dfe5e.jpg

    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.

  7. 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.

    matrix-projection-intented.thumb.jpg.6d2b892c117c9ce44a55bfdefdc23407.jpg

  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. 25 minutes ago, elexis said:

    If it's the cse that the sqlite db is hotloaded when edited externally, then I wasn't aware of that.

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

    • Thanks 1
  10. 6 minutes ago, leper said:

    Using threads also will not solve anything since the bots are still in python and the GIL is still existent.

    I seriously doubt that the GIL is the problem here, but I'd be pleased if you prove me wrong.

     

    5 minutes ago, leper said:

    What would most likely make more sense is to stop forwarding rating messages and instead send them directly to the corresponding bot.

    That's another possible solution. Would work for me as well, as the problems I currently see are based around the relay functionality.

     

    8 minutes ago, leper said:

    Also being able to run a lobby without ratings is something that should be supported […]

    No question, that should be supported in any case.

     

    16 minutes ago, elexis said:

    Restarting the rating bot without losing the game list, because creating smurf account is such a fun thing to do on the lobby.

    How does that relate to restarts of EcheLOn? Isn't that simply covered by removing the accounts from the database?

  11. 50 minutes ago, elexis said:

    Having the lobby bots split in two separate processes communicating via xmpp means they could run on different computers too

    Yes, that's an advantage, but is there any other reason for that than splitting the load onto two servers?

    50 minutes ago, elexis said:

    Furthermore two processes mean you can restart one of them without restarting the other, which means the gamelist is not lost if the rating bot is restarted

    Does it happen that EcheLOn needs to be restarted, while  XpartaMuPP doesn't? If yes, I'd be interested to know why.

  12. 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?

×
×
  • Create New...