elexis

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

(The rating GUI should become hidden in that case too some day. I guess I should speak to the simple ticket section.)

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

The github branch should be linked in #3700. 0AD does use enet, but the more crucial part is the way C++ interacts with JS. It uses the SpiderMonkey JS engine. The C++ NetClient and NetServer receive data either as strings, integers or some JS variable. The latter are saved in a ScriptInterface (just some place that holds all variables). You could start by reading NetServer.cpp and NetClient.cpp and trying to figure out what happens there. There are only a dozen of network message types with 0-4 variables each (handshake, chat message, game start command, ingame command, rejoin command and so forth, see NetMessages.h). > If net server is only in another thread of same process, their isnt any connection between host and main client, or am i wrong? The connection is via network, just like every other client, except that its the local ip 127.0.0.1, so you get like 6ms latency instead of 200-500ms (average to barely acceptable ping). However if the client freezes (i.e. that one thread doing everything is stuck in some kind of infinite or extremely long loop, such as "sunken ship lag"), the server will continue to perform while the client doesn't. Since the NetClient runs in the same thread as the renderer and simulation (which is the freezing part), then it won't get cycles to process and send the net packets, thus loses the connection to the server running in the separate thread (while possibly no other client loses the connection).

Having the lobby bots split in two separate processes communicating via xmpp means they could run on different computers too, so sounds like an advantage we might not necessarily want to revert. 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 (could be solved by saving the state to a file though). Perhaps @scythetwirler can you give you more specific feedback, as he implemented the split and has the most experience with xmpp performance.

(at leat I saw a resource-carrying tooltip stating 0/10 wood being transported. Edit: some time ago before a22)

Except in some places. Also implying some issues like units walking around with 0HP (also carrying 0 resources) or hellenic buildings with 10% bonus having 3301 HP. Not really urgent luckily.

> Also, pierce damage damaging buildings is really unrealistic. Didn't we come to that conclusion several times already, always increased the Pierce damage and are now at 99% and it's still too few? Anything speaking against making that 100%? (I guess the formula, but perhaps we can go to 99,99%)

The resource amounts per map didn't change

Wasn't the AI is in a separate thread? At least it has its own ScriptInterface and can't interact with the simulation, thus has to copy half the gamestate around frequently. The NetServer is running in a separate thread (which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that). (Mostly because I didn't spent further time on trying to figure out why and where it segfaults.) As Stan said, the entire simulation and the entire renderer are in the same thread. These two should be split and the pathfinder should run in a separate thread ideally. Needs considerable rewriting though (the current pathfinder approach is to compute paths consecutively afaik). The NetClient issue itself shouldn't be too hard to solve. One only needs to modify that one file to work the same wa as the NetServer (pushing things into a queue from the main thread, then letting the NetClient thread pull things from that queue and process the data just like before). andy created the queues already, so it just needs some testing and figuring out as to why this segfaults somewhere (probably some scriptinterface registration thing).

Tell me if it works, because we can make that timeout value a slider in the lobby options (which is the lazy mans fix).

The last word wasn't spoken there and the patch will be needed sooner rather than later. I was just fed up with running in the review hamster wheel for more than a year without getting to code something on my own. Luckily the NetClient code isn't really coded at and if, is easy to rebase, so it should be considered postponed. (Also had some joys trying create a custom ScriptInterface for XmppClient, but I aborted because it only segfaulted )

If the game is hosted by a Wildfire Games server, then every player could leave. Alternatively host migration, but that is also turning the code upside down I believe. While we're requesting improvements to the networking code to reduce the lag, we really need #3700. :-/

Yep, that what bb said. Random maps are the only ones where one can change the size and number of players dynamically and they are generated from a code script. Scenario and Skirmish maps are created with the map editor Atlas, so they have a fixed size and number of players. Scenario maps have every setting fixed (the player plays one specific scenario). But the player can chose matchsettings arbitrarily on Skirmish maps (in particular there is some code replacing the civic centers with that one of the selected civ).

Chill, JuKu the proposal was to change the default setting, not remove the ability to play with 300. You can even play with Unlimited (aka 10.000) currently. (About the other point, I like long games too, preferably with many unexpected turning points that resemble a story being told (rather than being able to predict the entire course of the game in the gamesetup and having a monotonous snowball effect).) And we won't reduce the default from 300 to 200 because someone gave a good reason not to currently.

Because it only allows someone to host who can already host, it defacto is a toy feature unless we rent a new server and host games ourselves. Readers of the ticket might also notice that prior to implementing a dedicated server, it would also be required that players can setup the game (as currently the first player to join the server is considered the controller of the gamesetup, yet the first player can leave the session without closing the server.)

Fixed. Also stick to one account.

In theory, a STUN connection should be as good as reliable. If you say that the connection is established only after retrying sometimes, perhaps the timeout in the config could be changed. (lobby.stun.delay = 500 in the user.cfg for instance), wiki/GameDataPaths Can you reproduce that observation reliably to determine whether the config change actually influenced the outcome? (That delay is the number of milliseconds that the appication freezes while waiting for a server response. If it's too short, the connection won't be established. But the longer it becomes, the more noticeable the freeze becomes. It should be threaded to avoid the freeze ideally.)

This guy, always looking for the OP unit composition the others didn't find yet.

Last time I checked its about 1 in 10 persons that can't connect to every game in the lobby. That can be solved by just connecting to some other game and playing with someone else or communicating with these players that person wants to play with. If we want to solve any issue anyone could have, WFG would have to host everything and rent one (if not more) servers. (To solve the rating fakery issues, one would also need a dedicated client which would require more CPU power, likely much more servers too). (Not really motivated to look at Voobly services and licenses now.)

Yes

Thanks for the fix!

I got this error with the most recent svn: ERROR: Failed to find matching prop point called "garrisoned" in model "art/meshes/structural/spart_sentry_tower.dae" for actor "sentry_tower"

This reminds me of a similar issue. Often the build restrictions allow placing a building only at one specific pixel on the terrain and then one has to move the cursor around for ages to find that pixel again. It sounds a lot like being the same issue here (though I don't know if walls being built with the wall-placement code have less restrictions than a single wall piece). The GUI could cache valid locations (until the terrain changed in that affected area) and then snap to possible build locations. Alternatively there would have to be a wall-specific solution.

(That's a classic annoying 0AD issue. If we can't fix it, we should at least make some memes for it.)