elexis

Which is a different from the originally reported bug. Did you load some savegame or get this in a newly started game? Got a replay?

There was some reason for these properties to be extended. The mapsize for instance is shown above the description, so it would be redundant to show it twice. Hence the boolean should not be removed in the current state. But with your patch hiding all options including the mapsize under a tab, all properties should be seen, hence the extended would always be true and can be removed. Then we can even merge the push calls, possibly to the point of creating an array directly without later modification by possibly using ...(biome ? [{...}] : []) for optional options.

On windows, right? Then you don't need to compile. Did you update the root directory with tortoise svn? If the pyrogenesis.exe and mapgen.js file are of the most recent svn version, it should work correctly. So maybe delete the .exe and revert with tortoise svn again.

A different tooltip depending on the vertical position of the cursor within the same hovered dropdown item (map description for instance)

Noticed that too some days ago. IIRC @vladislavbelov wrote the hover-text feature. More buttons imply more mouse movements (cursor aiming) in between. Hotkeys (currently only escape) could tremendously reduce that user interaction time as well later. Does the gamedescription in the gamesetup display all information currently (iirc it filtered out only the information that is visible elsewhere in the gamesetup page)? If all information is visible to the clients there, then it shouldn't be an issue to keep track of the host changing things.

There shouldn't be unused GUI space as seen on the third screenshot. Should be possible to mitigate by having an equal amount of rows in both columns (maybe only having one checkbox per row) and centering/maximizing the tab buttons and game description frame. Having tabs also has the disadvantage that one has to click through every tab to see which settings changed if one cares to only ready up after reading the settings. Scrolling on the other hand also means that one can't see all options (perhaps its easier to keep track, dunno).

This is what the game looks like when having the JS code of rP20396 but running the binary from the prior source (and is what I expect Vladislav to have experienced too when he mentioned a bug on irc). So update and/or compile.

Yet you can't do much without the simulation components of the public mod. If you first create a mod, you can distribute something that only contains your files. Afterwards you could remove art files from the public mod and keep the things (like simulation code). Given that in some future century we might want to start coding on the 500 A.D. thing, it might be reasonable to separate 0AD logic from the things that are close to the engine in a separate mod (maybe a "pyrogenesis" mod?) So people can easily exclude the 0AD GUI, textures and models while still using the logic to move units, health and attacks which is present in about every RTS and non-RTS game. The GUI is currently a monolith. The spirte and style definition files should not have the name of the style in their names, i.e. ModernTextLeft should become TextLeft. That's the only way how the themes can become independent from game code. Some of the GUI functions are usable for any mod, but many are hardcode 0ad or rts logic. At last we annoyingly have some 0AD flavor in the C++ code, which should also be removed eventually (for instance properties of 0ad game properties in the lobby code iirc).

Yes. Replays don't have a chatlog.

The reference you are looking for is the first one in the first sentence: D957 (hint: phabricator). Could (since there was this E.T. case), and probably not nonfree, but if so, too free. Also its ambiguous as there is public domain data that appears to be identical, so, dunno, didn't get to it yet.

(About the other proposals, the rattail of the rallypoints-in-playercolor proposal still has to be fixed)

> Too bad also that this is happening on a nonfree map that had to be removed from a23 (apparently the scripts were derived from proprietary scripts, I don't know how that's possible, if anybody knows what the story behind this is, let me know). If there are questions about a commit, lookup the commit message and almost always there will be an explanation there and links to more information. I don't know if this is a nonfree map (more the converse depending on interpretation). I don't know if it will be removed from a23, because a23 wasn't released yet and the days only have 24 hours. Also I dont know if the scripts count as derived from properitary terrain data, hence we removed them until we know more.

You mean the biome json files (that still miss a new wiki page, potentially a new biome)? A biome consists of terrain textures, simulation templates and actor names.

Typically (as in other games) the skybox doesnt move when the user moves and is rendered first (so the size of the skyset and map doesn't matter and it appears indefinitely far away).

I can't reproduce it on unix unless that is a function calling itself indefinitely. Try "init = function" for the init overwriting instead of "function init" - that worked at least when doing it in the public mod in my test.

First all JS files are loaded and executed in alphabetical order. (i.e. first session.js can set the global init, then a file of your mod could replace that init with a new one that calls the previous one and your civChoicesInit). After that the engine calls the global init function, whatever it may now contain. Basically var oldInit = init; function init(args) { oldInit(args); modInit(); } Not a beauty queen, but would avoid the duplication. > it's loaded Ah, good.

fcxSanya, the session.js copy sounds like trouble. It already misses out some of the recent changes to it. As far as I see its only use is calling initCivChoicesDialog. We should find some mechanism to avoid that copy. If the file was renamed to be loaded after session.js, we could probably replace the init function with a new init function that calls the old one and the init function of the mod. Afaics, that mod misses a session.xml copy loading that civ choices file until D619 is committed.

@LordGood, as reminded by leper, you might want to commit the blender or whatever files to https://trac.wildfiregames.com/log/art_source/ (so others could modify the models properly in case you are not available.)

Walls are tough to balance, since we don't want to make early fights impossible and only want siege engines to destroy them. (We thought about wooden rams in age 2 some day)

If one is particularly interested in networking, the said improvements are still valid. But the main performance issue is making the pathfinding able to thread and running the renderer independently from the simulation. There are similar design documents about 0AD and the developers took inspiration from AoE design documents like this too. Actually I think exactly that one was (or could have well been) part of it.

You can install Alpha 21 alongside with Alpha 22 though.

The nr of resources depend on the map (some maps spam resources, others have 1-2 extra mines for 8 players to share) and the mapsize (nr of res quadratically increase with the mapsze on random maps). How fast they are depleted depends on the gathering technologies (notice the last one gives +50% gathering rate). Finally you have more choices to spend resources on, more units. You require siege engines (and champions became more relevant) in comparison to some alphas ago where one could take down buildings with citizen soliders that only cost food and wood. Setting the nr of mines and trees arbitrarily (low, default, many, very many) in the gamesetup were fun. Also want gaia survival waves and nomad on all maps. Well, going back to the rmgen code now.

The github repository or branch of andy5995 contains the net threading code (not the official github mirror). The local client works like every other client. Besides having the advantage of being able to put the server on some other machine, it also means actually having less complexity, as there is only one mechanism that servers every player equally. 127.0.0.1 networking overhead is completely negligible. Replacing spidermonkey with something else will be as simple as changing about every file. 0ad uses the enet protocol which implements reliable communication via UDP. The lobby part works via xmpp. enet does use peer vocabulary and easily allows p2p communication, but don't let that vocabulary fool you - the 0ad protocol still implements a NetServer and a NetClient, i.e. a star architecture / hierarchy https://en.wikipedia.org/wiki/Star_network. The single point of failure issue is addressed by every clients hashing the simulation state and thus being able to determine that noone is messing with the gamestate (otherwise the hash fails and people can assume to not really play in the same gamestate anymore). "Reduce lag" -> Forget about the networking unless we're talking about a some special kind of situation that shows up as actual network lag in the top right hand corner. (Though lost packets should also be displayed there sometime). The 0AD game stuttering happens just as well in singleplayer and replay mode often because there is more data to process than the CPU can handle. There are only few kilobytes sent via network (the commands, no state).

Doing things depending on the angle sounds like an idea that might be explored further. I thinkt the skyset is also visible with the default angle when zooming out far (probably further than the default config values permit though)

"But only one process can be making changes to the database at any moment in time, however." (which sounds like breakage if someone rating was changed simultaenously)