show game results screen

There is also no problem to do different things when won in single and multiplayer. The win conditions must also get more clever in 2v2 and therelike.

I'll provide the wrappings and the updating of the win conditions, just provide the C interface to do so and show me to it.

Where and how put the C interface? I have not really had a look at the lua things.

Currently I send the statistics from NetHost and NetClient. It take the game_statistic vector. I it a good idea to provide a function to GameController (GameController::report_game()) which does the actual work? This method then calls for network ggz game the right NetGGZ methods.

How do I get the data from lua?

I have not yet understood what data you would need from Lua. There is no way to poll Lua's state, only lua pushing info to the c interface.

My suggesting is something like

wl.game.player_lost(plr)
wl.game.player_won(plr)

called in the win conditions would then in call call something like

NetGame:report_game("hi. this player lost"). What more do you need from Lua?

Which data is needed depends on the wind condition. For defeat all I need only win/lost for every player. For collectors I need the points I think.

So I add two function to Game: player_lost and player_won. Lua calls the with player number and points (Should be enough I think). I can track the player states in class Game than and if all player have a state (won/lost/leaved) I transmit the statistics to the server.

Did I get this right? I think that all I need from lua for now.

You can add the functions wherever you want. On class Game, on class Gamecontroller. The most important thing is, what we want to transmit. I suggest making those functions flexible by taking a boolean value (win,loose) and an optional string from lua. Individual win conditions can then encode data in this string. For example for collectors, the win call could look like:

wl.game.player_won(plr, "points=1234")

or maybe more complex:
wl.game.player_won(plr, "trunk=12;raw_stone=3")

For now, i would expose them in the wl.game module. Or rather in the wl.game.Player class? And I'd prefer to collapse this into just one function, but I can't think of a good name.

Just let me know when the c backend is in place. I'll add the Lua functions then right away.

I have added the interface in the widelands-server branch as

GameController::report_result(int player, int points, std::string extra)

was a bit too fast. changed it to

GameController::report_result(int player, int points, bool win, std::string extra)

what will the player be? Like in the game from 1..NumOfPlayers or 0..(NumOfPlayers-1)?

it is Player::player_number(), which starts at 1..NumOfPlayers. There is no guarantee that the number is monotonic, as some player slots might be empty in a game.

My stuff is done, should I push it to widelands-server branch or to a private branch, so you can merge it later on? It is not tested though, as I do not know how I run a network game were I could test this.

just push to the widelands server branch. I will try to test it.

okay, I pushed it. Keep me updated, please.

The game reporting works. I had some test games now. Most were against ai only and I player collectors most of the time. It's the easiest to win :)

I played a test game with two human players and the metaserver registered the game. But I had a desync just a the you have lost message arrived on one pc. Seemed the host (other pc) realized the win condition a bit later.

The desync should not come from lua, as all lua packages are routed through the cmdqueue and are completely deterministic. Actually, I got a game with tribes together (which is the most complex of the three win conditions at the moment) with one other human player and 3 ai and had no desyncs.

I think it can not come from my ggz work as this does not have any affects on the game at all.

Did you test with two or more computers? Wit only one you will never get a desync. I just noticed (after the desync paused the game) that the client had the "you have lost" message and a first report (I print the calls to NetClient/NetHost::report_game) and on the host was nothing. Right after unpausing the host send the "you have won" message and called the report functions.

Yes, I tested with two computers on a extremely shaky wlan, but it was tribes together.

I double checked the collectors lua script and it does not alter the game state at all. Nor does it sleep (reschedule a message in the game queue) when sending out the messages, so it literally can't cause desyncs as it does not do anything.... strange, strange. Does the report function schedule a cmdqueue item? If so, those two would obviously be different.

 We have to watch this closely if it resurfaces.

maybe this was caused by something different.

The report function only updates an own playerinfo structure in NetGGZ and if all player have a result it sends data to the metaserver. That's independent from the rest of the game.

I got the desync multiple times now. It happens only with the "defeat all" win condition. I tried to track this but unfortunately the host stopped syncstream writing shortly before the desync because of low disk space :(

there has been some work done by nicolai on this. maybe this is fixed now. also, there is one instance in lua_map.cc where std::sort is used instead of std::stable_sort. I do not think that it is related to this problem, but who knows?

The last desync I had was with the changes by nicolai. I will try to create new syncstreams some soon. Testing the defeat all win condition is quite hard. Most of the time I used collectors to test the ggz reporting. And this did not desync yet.

The desync bug is likely fixed through the cmd that calculates statistics. What about this bug now? I think this could only be closed when we merge the ggz stuff which we decided on the wihack would not be too wise for build 16, instead rather shortly after. I therefore retarget this for build 17. Timo, please complain when your mind has changed on this.

this is directly connected to the rewrite of internet functionality and the remove of ggz. For now I set "in Progress" -> "Confirmed", as all work that has been done (besides the lua function returning the win results to the game class) can't be used for the new implementation.

I guess you are focusing on the games result screen? If you design this, make sure to use UI boxes instead of hard aligning all the elements (as they are in most menus right now). This is easier to maintain.

The infrastructure to save statistics on the server is not there yet - there are two widelands meta servers. One is in python (using twisted) and the newer one is in go (but not yet working). You can find both in the widelands-website project. Just in case you are interested to work on those too :).

OK, I will try to use boxes. But since I use a main menu background, I will need to hardcode some positions.
I have a working prototype to show this screen when status for all players are reported to the game controller, but I will first focus on other bugs for now.
I may check the metaservers code at some point, this would be a really useful feature!

I have my reservations about tracking statistics on the server - I doubt it would be very useful for Widelands. It's just a nice statistic to have. And it would be another thing that can fail (because it needs backends and frontends) and couples the website tightly to the game (we cannot update code there until a new realease - or really ever since we have to support old versions).

So, for me this is more a nice experiment, but I would not mind if we concentrate our efforts on other things. I guess it would be fun to write.

disclaimer: others think quite differently on the topic I think, this is just my opinion.

I opened a new bug report concerning the statistics (#1203560) so we can focus here on the game result screen.

Released in build-18 rc1.