Krinkle

I like where this is going. It would certainly improve familiarity for JavaScript developers if we use a more common unit test framework rather than something in-house. I would suggest a few alterations so as to increase the value of the unit test: Run it from the command-line rather than from a browser. This will make it easier to run from Jenkins and extract the results in an automated fashion, and it'll be easier that way for developers to continue to (also) run it as part of "make test". The actual code is not meant to be run inside a web browser, which means trying to make it work there including file tracking and loader mechanisms, would significantly limit future developments and add on-going costs, without actually benefiting the game or code quality in any way. There's also the risk of false positives from tests passing inside a browser, but not in the actual game due to differences in environment. Run it using the SpiderMonkey engine (the mozjs engine that 0AD uses) and not V8, Chrome, or Node.js. There are significant differences in how these engines work internally, also with regards to syntax features and quirks etc. There is no need to run it in a different engine, that's kind of like testing a Firefox extension inside Internet Explorer. I believe a unit test is a test where you control (or inject) any and all dependencies and only act and observe a single subject (e.g. a class, module, or method). Thus not causing side-effects in global state elsewhere, and not causing dependencies to be implicitly pulled in. An integration test is where e.g. you act on and observe multiple subjects, and where e.g. you may let your application's entry point implicitly construct its dependencies and inject them, rather than doing so implicitly. In complex code bases, to achieve this, we often mock the dependencies and/or not load the primary engine, but to me this is by no means a logical requirement for something to be considered a unit test. When testing a Library class, it seems perfectly valid to me to test that by injecting an array of (stateless) Book objects into its constructor, and then only calling Library methods and observing its return behaviours. If Book is not stateless or if Book is difficult to instantiate, then it may be easier to mock it, but otherwise that would needlessly reduce the accuracy of the unit test. Likewise, I don't see an issue with exposing the Pyrogenesis engine to the unit test. Its native methods are conceptually no different from the native methods of the JavaScript runtime's own utility methods, so long as we use them within the spirit of a unit test. Beyond that, duplicating a lot of code would be busy work with little to no added value, unless for some reason we can't figure out how to load the engine, in which case we'd take on that added cost as a way to make unit tests possible at all. I think it's quite feasible to pull this off. We can decouple the current test target, and load a test framework like Jasmine there. We can also add code coverage reports by instrumenting the code first through Instanbul, and extracting data afterward. Then after the run we can use Node.js tooling to produce nice web pages as build artefact to visualise the code coverage reports. We can make compiling and importing the Pyrogenesis engine optional, so that we have a fast "make" target for unit tests, and a slower one for integration tests, but otherwise use the same JS engine, test framework, and code coverage pipeline. I'll try to put together a proof-of-concept over the next couple weeks to show what I have in mind.

Playing on Greek Acropolis. An epic hour-long 1v1 between the two medium players, iznogood and MadMax. 2019-11-30_0001_iznogood_MadMax.zip

In today's multiplayer test match (r22829) I noticed some shrubbery (bushes) hovering on the map. Map: Hell's Pass (mediterranean biome). According to @elexis it is likely one of these: "grass": "actor|props/flora/grass_soft_large_tall.xml", "grassShort": "actor|props/flora/grass_soft_large.xml", "reeds": "actor|props/flora/reeds_pond_lush_b.xml", "lillies": "actor|props/flora/water_lillies.xml", "rockLarge": "actor|geology/stone_granite_large.xml", "rockMedium": "actor|geology/stone_granite_med.xml", "bushMedium": "actor|props/flora/bush_medit_me.xml", "bushSmall": "actor|props/flora/bush_medit_sm.xml", "tree": "actor|flora/trees/palm_cretan_date.xml"

Fascinating, I had no idea! This offers a new strategy for me to expand my eco mid-to-late in the game, e.g. when one has sufficient wood and can afford the idle time of building farms. I do think it still stands that early in the game, when given a choice between adding a second unit to a farm vs idling until you have enough wood, that one absolutely should add more units to farms. Combining this with a need to expand population continuously and the speed at which citizens are trained, one should probably only rarely start farms with with less than 4-5 workers. But, that later in the game you can comfortably take one or two units away from a field and assign them elsewhere (e.g. their own farm, or wood/minerals). Strategies aside, I think what ultimately matters is "give opportunities to learn the mechanics and understand them". In this case, that means being able to see that adding a worker increases the throughput. But you're right that it would also be useful if they can see not only that it increases but also more precisely by how much, and perhaps develop different strategies based on that. For example, if one were to show some kind of estimate on the selection panel for a farm, about how much its workers currently gather per minute (accounting for number of units, diminishing returns, upgrades, and expected walking distance). That could be shown as a meter / progress bar (from a narrow fill in green, to a maximum fill in red or some such, indicating that it become less efficient), with perhaps a tooltip that shows more accurate numbers and reasons for why. @Nescio I'm unable to find this tooltip. I've got "detailed tooltips" enabled, but the tooltip only says "Current/max gatherers" on the field panel. I've clicked and hovered around a fair bit, but not discovered anywhere else that would show this information. (A23, Carthaginians).

When new players need food, they often go for farming. It is a separate issue that players are not encouraged to pursue more efficient food gathering methods first (e.g. land animals, fruits, and fish). Perhaps that's something the tutorial mode can caution for. For this thread, I'd like to focus on when someone is doing farming, to make sure they are given opportunities to learn the mechanics and understand them. Primary points we want to communicate: A single farm can have multiple citizens work on it (up to five even). The food gathering rate will increase as you add more workers. (That is, if you want to increase gathering, one should add units, not build a whole new farm). Secondary points: Not in scope for this thread per se, might be okay for intermediate players only, but to keep in mind: Able to have an expectation of how long it will take to collect a certain amount of food. Able to see that female citizens are better at food gathering than infantry. Able to see easily which farms are "full" and which are not. Able to see (if they are doing these), that from berry bush, fishing boat, or hunt, food is gathered at a higher rate than on a farm. Obstacles: Wheat icon for adding gatherer. Selecting a unit and hovering an existing farm shows the wheat icon. But unlike the Hammer and Sword cursors, I'm not sure that the Wheat icon alone explains that it is an "action" cursor that can make the unit do something. It mostly blends in with the background of the field, and even if seen, could be mistaken as meaning you can select the field itself or something. Hammer for number of gatherers. With a farm selected, a hammer can be seen with the numbers "1/5". The meaning of this is not clear to new players. Wheat or meat icon for carrying. With a farm-working unit selected, the numbers "x/20" are shown next to the meat icon. The meaning of this is not immediately clear either. For one, because unlike other gathering types, the cursor icon to perform the action did not match the resource (wheat icon vs meat icon). Using a meat icon for all food isn't bad per se, but the inconsistency around fields can be confusing. For all other resources, and all other food types we currently have consistency. Gathering rate vs walking distance. When closely observing a worker whilst selecting it, one might see the "x/20" go up and roughly deduce its gathering rate from that. But extrapolating that to number units on multiple farms is hard. Another factor is the walking distance. I've seen several new players (myself included), assume that the gathering animations and depositing are mainly just that - animations. And that the gathering rate is more constant internally. Even if you test it with two farms far apart and two different distances farmsteads, it's still hard to see which one is working faster (never mind the why). Also relevant here is that the number of workers (as seen from the field selection panel) goes down whenever a worker is walking to a drop site. Have you witnessed or experienced other obstacles for beginners around gathering food from farms? Share below! I have a few ideas, but I'd like to hear what others think first. And perhaps some prior discussions or considerations.

Nice Is there a dev build or source repo with that fix? I checked the git repo, but the last commit there is v1.6.22. Is there a different place I should look? Thanks.

I noticed that the player numbers (and order) is different between the perspective switcher and the overlay. This has confused me at times, should they be the same? On a related note, having team numbers in the overlay would be very useful I think, but.. I would understand if you think it would get too crowded. Just an idea

When installing autociv in addition to fgod, they cause problems for me. There is a red bar across the top, and the rendered cursor appears to be 100px away from where the cursor is actually interacting with the game. Sequence of steps: Install 0AD on macOS. Able to play single-player and multi-player without issue. Install autociv, enable it, start mods (restarts game). Works without issue. Uninstall autociv (discovered fgod, and instructions say to install fgod first). Install fgod mod, enable it, start mods (restarts game). Works without issue. Install autociv as well, enable it as well, start mods (restarts game). Stuff is now broken (per below image). Upon the next start of the game, the autociv mod has been automatically disabled again. So it appears to have detected that it didn't work well (yay). But I'm not sure why, or how it should be installed instead. EDIT: I got it to work by pressing "Save Configuration" between the "Enable" and "Start Mods" steps. This way, the actually problem still happened during the automatic restart from "Start Mods", but... after manually exiting and re-opening from that, the problem went away and with the mod still enabled and working fine.

Note that 0AD now uses Phabricator (also a modern open-source project with repository viewers and pull request functionality). It is installed at https://code.wildfiregames.com/. For an example change request with discussion and continuous integration, see https://code.wildfiregames.com/D157. Phabricator also supports Git, and also has issue tracking and wiki features (currently disabled for 0AD). So if the project will consider Git and/or to migrate away from Trac for whatever reason, I imagine Phabricator would be the obvious choice.

Some names picked from nodes on the Wikipedia link graph, going to or from an 0AD civilization: Xenophon: Xenophon of Athens (431 BC – 354 BC), a Greek mercenary and historian from Athens. Xerxes I: King Xerxes the Great (519 – 465 BC), was a Persian King and Pharaoh of Egypt of the Achaemenid Empire. Xerxes II of Persia Xerxes Canal: The Xerxes Canal was a navigator's canal built by Xerxes the Great (Persian Empire). Xanthos: Xanthus was a city and river in ancient Lycia. Persian Empire 540 BC. Later under Roman and Byzantine rule (c. 42 BC). Located in present-day Turkey. Xanthian Obelisk: The Columna Xanthiaca (also known as Xanthian Obelisk, or Xanthus Bilingual) is a 400 BC monument from the Persian Achaemenid Empire. It is believed to have a trilingual inscription. Located in present-day Turkey. Xanthippus: Xanthippus (525-475 BC) was an Athenian politician. The name means "Yellow Horse". Distinguished in the Greco-Persian wars that led to ascendancy of the Athenian Empire. Xulsigiae: The Xulsigiae were goddesses worshipped in Gallo-Roman religion (Belgic Gauls, c. 22 BC). Of these, I personally like the following two (somewhat less Greek): Columna Xanthiaca King Xerxes