Vantha

Ok, maybe my statement was a bit biased. But still, other games usually count connection issues in rated matches as your fault too, no?

I haven't looked at the code yet, but I think we can detect the host closing the match on both sides and send the messages to the bot as usual, as elexis suggested. Or maybe just take note when the game server of the host suddenly disappears before receiving any messages. On the other hand, the case where the client leaves, and the host finishes (and wins) the match on his own is the tricky one. Adding "game start" messages as you suggested would allow us to know which players took part in the game. And if we additionally record clients leaving, we can tell when that situation occurs, and then just accept the game report that the host sends on its own (maybe except if the client was kicked). If we don't want to trust the host with it, we can still just automatically count it as a loss for the client, if he doesn't return within five minutes or so. Well, that could result in some lag, but they still shouldn't repeatedly lose connection entirely.

@Dunedan I made this thread primarily to see whether we could conclude that this is indeed the preferred solution in the first place, or what else. What's your take on this? About the implementation: Your idea of recording the game starts sounds pretty good to me. The rating taking a few hours to update would be suboptimal in my opinion, though, since players might not know or notice that it happens. I guess, better late than never, but maybe we can figure out a way to make it work without such a delay?

It wasn't included in R28 because we were already way to far into the release process by the time I opened the PR. But, yes, the implementations are done, what's left is reviewing, finalising, and eventually merging it. My goal is to get everything into R29. I'm working on it.

There is an ELO rating system implemented in the MP Lobby for 1v1's. A notorious problem with it is that it doesn't handle matches where one of the players disconnected before it was over, these matches simply aren't counted. Some players exploit this by leaving or closing matches when they realise they are about to be defeated, in order not to lose any rating points. This obviously goes against the rules, which is why this thread exists for reporting it: However, I think we can all agree that, ideally, bypassing the rating system like this wouldn't even be possible in the first place. This would save players the frustration and moderators the work of checking submitted replays. While talking about it in this thread the following idea came up: There are two cases of players quitting, firstly the one hosting the match, and secondly the one who joined the hosted game (the client). - If the client leaves, currently, the match continues, just without anyone controlling one side. If the host now finishes the match as usual by defeating the opponent (who doesn't defend himself anymore since the client left), it should still count as a win for the host and as a defeat for the client. If the client disconnected for a different, valid reason and planned to return, he should communicate that to the host beforehand. I'd argue it's the clients' responsibility to ensure they have a somewhat stable internet connection, so that they aren't completely disconnected frequently, and when they are, can still rejoin quickly. The downside is that it incentivizes hosts not to wait for the client to come back, since they no longer have to. - If the host leaves, currently, the match is immediately ended, without the client having a chance to continue the match in the same way as proposed for the host. In that case, the game should count as a win for the client. I know this sounds harsh, but as far as I can tell from the code, this only happens if the host manually exits the match or terminates the program. If the host only loses internet connection, all clients (one, if it's a 1v1) are disconnected from the match, but they are able to reconnect as the match itself on the host side persists. So the only way this can happen unintentionally is if the computer crashes, but again, that's probably something the host is responsible to ensure that it doesn't happen. What do you think? Is there anything I'm missing? An issue I can think of is that it enables hosts to exploit the system by starting a match, immediately kicking the client or blocking his connection deliberately in another way, and then being able to easily win the game and still be awarded rating points. Although, that's something that should just be reported as well.

Both of these would solve that, yes. But I personally wouldn't mind too much if the host was treated more harshly than the client, as @guerringuerrinsaid they have more responsibility already and the main thing is that either side can't ruin the game.

Ideally, yes, but I don't really see a way around it, since the client should be given the chance to reconnect, which isn't an option for the host.

During a MP match, the game state is always present on all clients. Essentially, all players run an ordinary SP game simultaneously, but receive the inputs from each other over the network. And each player simply "feeds" that input (received from the other players) into their own game instance and since the behavior of it is deterministic, all of the instances stay in sync. To be fully precise, it's not the mouse movement or button clicks that are shared over the network, but the game "commands" like moving or training units. What the host does in addition to that is manage the network connections to the individual players and e.g. letting them know when someone disconnects. Therefore as soon as the host leaves, the clients are cut off from each other, can't communicate, and the match is closed for everybody. With the proposed behavior, the disconnected player wouldn't lose anyway, as long as the other player(s) wait for him to come back. Could work I think, but might not be necessary. The problematic case is when clients leave when they're about to lose... then it shouldn't take the host too long to finish it anyway since they were about to win already, no? Depends on the victory condition, though.

Is there any specific reason why that isn't the case yet? I see it the same way: - If the client disconnects from the host, he should only ever do so for a good reason and communicate to the host that he'll return. If he doesn't do that, it should be possible for the host to just finish the game without anyone playing on the other side, win, and consequently gain rating points as usual. - If the host closes the game prematurely, it should simply count as resigning and therefore as a loss in the rating system.

Update: I ended up deciding for "haimaz". I explained my thoughts about it here: https://gitea.wildfiregames.com/0ad/0ad/pulls/8722#issuecomment-135305 I want thank you both for the research and debate, I think the debate itself is also valuable, not just the result. And let's stay on the ground and don't exaggerate the importance of this, after all it is just single term among hundreds in the game. And for the future, let's act in such a way that we'll never have to remove the "No historians were harmed" disclaimer...

Thanks. Can you tell me how you pieced them together?

Can you tell me which? It's supposed to be complete, but it might not have been updated consistently enough.

As hidden in the announcement, there's a mod porting guide on the Wiki (especially for the programming side of things):

@Genava55 Though, it would be nice to add proper Proto-Germanic names to the heroes; Teutobod, Lugius, and Boiorix.

Hmm, the AI names of the other civs are always the Latinized versions.