Leaderboard

Too micromanagement... I don't see the problem with this.

This mod shows current income per minute for each resource (food, wood, stone, metal) in the top bar, replacing the gatherer counts. Includes gathered resources, trickle income, and trade income. I've attached the mod to this post as a .zip. I also put it on mod.io, but that's pending approval. Why do you want to see current income per minute? Well, suppose you're doing some unusual builds with hunting or fishing. The food income will directly show you how your build compares to a more typical farming build. It can help you anticipate when you're going to have too much food or too much wood soon. A good rule of thumb in some parts of the game is to keep wood income around 30% higher than food income, so you can build houses/farms/storehouses as well as citizens. You can also use this mod to see directly how researching different technologies or building closer storehouses affects net gather rates. Or to decide how many barracks you need, to produce soldiers at the same rate as your income. This mod is compatible with either standard a26 or the Community Mod. However, if you want to use it with the Community Mod you'll need to make sure this mod appears below the Community Mod in your mod list - otherwise the Community Mod will clobber some files needed for this. A smooth and responsive estimate of income is obtained by taking a rate for every income source - every citizen chopping a tree or picking berries, every fishing boat and trader. The rate is the amount of income from each gatherer divided by the time it took for the gatherer to get that much income. You might wonder, why bother with that, why not just take a rolling average of total resources harvested? The answer is that if the average is taken over too long a period - say, 30 seconds - then it won't be very responsive to short-term changes in income. If the time average is too short - say, 10 seconds - then it won't be smooth, swinging wildly up and down because of random differences in when each worker returns to the dropsite. By instead summing up rates from each income source, we get the best of both worlds. Each gatherer's average rate is nearly constant over time, providing smoothness, and we can responsively detect when a gatherer starts or stops gathering. The time for the income estimate to respond to a gatherer starting or stopping is roughly the length of one gathering cycle. showresourceincome.zip

You're talking about a unit from the middle ages. Around (1250-1450 AD) https://en.m.wikipedia.org/wiki/English_longbow

Bit annoying to have to clone the game's entire folder to run the CI...

Well, it's just where the gatherer counts would be, only the numbers are bigger. Here's a screenshot of a replay. You can see that 1337rtslegend here has a food income over 1000/min from farms and berries and a wood income of only around 500/min. Indeed, fast forwarding the replay a minute, he ends up with 900 food he can't spend. So that's an example of how it could be useful to compare food income to wood income to anticipate a problem ahead of time. The second picture is myself in a similar situation, with too many on berries giving an income over 1000, and less than half that income of wood. Sure enough, a minute later I have way too much food.

Screenshots can sell the mod more.

Well, couldn't you have all the files in gitlab, but have a script that only copies over the changed files when it's time to put out a new verified patch version? Something like (bash, rsync): # make a directory to put just the community mod files that # are different from a26 mkdir ~/cm_minimal/ # If ~/cm/ contains the (non-zipped) community mod, # and ~/0ad/a26 contains a source distribution of 0ad alpha 26, # this command will gather all the files from the community mod # that are different from a26 or not present in a26, and put # the filenames in files.txt, while excluding cached.xmb files rsync -ric --dry-run ~/cm/ ~/0ad/a26/binaries/data/mods/public/ | cut -d " " -f 2 | grep -v "cached.xmb" > files.txt # this command will read the files from the previous step # and copy them into cm_minimal rsync -a --files-from=files.txt ~/cm/ ~/cm_minimal/

from gameplay experience, civilizations are fine to have different selections of units. I consider it an important part of civilization balance and differentiation from which strategies may be developed. I think the ranking of those civs depends largely on the player you ask, with higher skilled players probably agreeing somewhat on the top 3 to 5 civs. That is, in the community mod. If you ignore the community mod, its pretty clear that ptol dominate. The Seleucids are very well rounded. I can say for sure that most players would very much dislike all civs getting all the core units.

Huh... So they do! Points for consistency then. It seems to be a new feature since the last time I looked heavily into unit stats. I'll try to avoid making such authoritative claims in the future unless I fact check them first.

On the social network VK, there is this page with a lot of interesting pictures: https://vk.com/scythians There is also the account of Evgueni Kraї: https://vk.com/id387122112

The advantage of it being a copy of public is easy to review patches and for them to be easily backported to vanilla. I agree with @causative that a filter when building the mod for mod.io would be reasonable, tho I'd build it around git diff --name-status

https://code.wildfiregames.com/D4973 The community forum must know... Just a copy paste: No comments on the code necessary - Just a first working version. This adds support for visual status effects ( mostly meant for fire ) by actually just spawning an entity that symbolized the status effect. This has the added benefit that the spawned entity (the "status effect") can attack other entities -> so the fire can spread. (Imagine this in combination with D4771 ... forests could actually be destroyed by a wildfire) Current problems/ todos / points of thoughts: The fire is spawned as Gaia, which means by nature of attack.js it won't attack any other Gaia units. To solve this one would need to implement a way to force attack any unit. Note that it's not the attacker specifying which entity is spawned, but the attacked entity. This is necessary 1) for using different size flames for different objects; 2) make this work with stationary as well as moving objects. Note that this also makes it a little bit more complicated. Is this even something that will actually be used in the vanilla game? Just balance wise? Because with the current implementation, where the fire can actually spread, this would completely shift balance and strategy of the game.

Getting a bit tired of that argument, but for the sake of it they do have an elevation bonus. (And it's easy to check) trac:template_unit_cavalry_ranged_archer.xml#L17 trac:template_unit_champion_infantry_archer.xml#L17 Why?

wait what? please explain more, I must have misunderstood.

of course

there are very few countries in which it is controversial.They are less than 7 countries. Isn't it more controversial to kill people? Or the weapons?

I agree that in the future the community mod should do as you suggest. As for immediately doing what you suggest, there are adoption hurdles associated with a changing mods, and I think there is a general desire to not do too many updates unless we have to (because of adoption fatigue issues). Doing as you request would require all players to download a new version of the community mod, which may or may not happen, and would cause confusion within the playing base as to what is new in the new version of the mod. A lot of people have a lot of ideas they want to launch in the next iteration of the community mod. Given timing, however, it's probably easier to just wait until "coming soon" comes.

Don't know if this is accurate.

Some thoughts then. Special Technologies: "Skirmishing Tradition" 200 food, 200 wood Village Phase Civic Center Javelin Infantry and Cavalry -50% experience needed for promotion. "Rhomphaia" 400 metal Town Phase Forge Unlocks the Rhomphaiaphoros Sword Infantry, an elite-ranked fast Swordsman from the Barracks. "Hellenistic Reforms" 600 metal, 400 food City Phase Barracks Cavalry +1 all armor types (actors swapped to armored variants, thureos instead of pelta, etc.) Mercenaries: Getae Mercenary Cavalry Mercenary class Archer Cavalry Mercenary Greek Hoplite Mercenary class Spear Infantry Barracks Units: Mercenary Greek Hoplite Triballi Light Swordsman Thracian Peltast Thracian Slinger Rhomphaiaphoros Elite Sword Infantry (unlocked by tech) Stable Units: Odrysian Heavy Cavalry (spear cav) Thracian Skirmish Cavalry (jav cav) Getae Mercenary Cavalry (archer cav)

I won't post pictures because I am tired of dealing with direct links on this forum. But in general terms. The most common helmets used by the Thracians are the Chalkidian and the Phrygian helmets. Phrygian helmets could have facial protections, as it was found with later variants discovered in noble burials. The most common armors are “bell-shaped” cuirasses (similar to archaic Greek cuirasses) between 600 and 400 BC. Then there are armors with metallic scales and neck protective plates, like the armor found in Golyamata Mogila tumulus. Also the scaled armors depicted on Thracian plates, notably those from the treasure of Letnitsa.

I wanted to share some details about the migration of the lobby we did on Friday and what went problems we encountered while doing so. That'll take a bit to explain so I suggest grab a cup of tea and some cookies before you continue to read. The motivation for migrating the lobby to a new server was to get it into an up-to-date state and to improve its performance. The operating system on the previous server was already getting older and as it got manually updated over the past years, there was lots of stuff on the server, which wasn't really necessary for operating the lobby. Therefore, to start with a clean slate, we decided to set up a new server from scratch. Server in this case means a new virtual machine as part of the infrastructure Wildfire Games has available to host everything related to 0 A.D. Instead of manually configuring the new server, we wrote so called playbooks for a tool called Ansible, which are instructions written as code how to configure such a server. We did so to increase transparency and documentation what's running on the lobby server. Going forward instead of doing manual changes on the live lobby, changes are written in Ansible code and can be reviewed like any other code related to 0.A.D. as well. This also improves the ability to test changes in an isolated environment instead of having to use the live lobby for that, as the written Ansible code makes it easy to configure other computers the same way. With an additional tool called Vagrant, which allows easy creation of virtual machines running on your local computer, it's now easy to get a nearly identical copy of the official lobby running for testing purposes on your own computer. If you're interested in the details regarding that, please check out the git repository where we published all of that: https://github.com/0ad/lobby-infrastructure/. If you're interested in participating and improving the infrastructure behind the lobby, contributions are always welcome there as well. While having the configuration of the lobby available as Ansible playbooks means that configuring a new server is just a matter of running a single command and waiting a few minutes, that's only true for a new lobby without any existing state. State in this context means lobby accounts, ratings and certain logs we wanted to keep. As migrating the state takes additional time and care and because unexpected things might (and in fact did) happen during such a migration, we planned a quite long downtime of 4 hours. However, the actual migration only took roughly one hour and once everything looked good again we made the lobby available for all of you again. Unfortunately, that's when we and some of you started to notice some problems, which took us quite a while to debug and fix. Here is a list of the most critical and interesting problems we encountered: Games becoming invisible Once more and more of you joined the lobby after the migration, eager to play again, we quickly noticed that something wasn't right. Games would become invisible or wouldn't even show up in the first place. After searching for a while, we figured out that this was caused by rate-limiting of messages getting sent through the server. There is rate-limiting in place to avoid spamming of large amounts of messages. That means that each user can only send a certain amount of text per second. During the migration we made a mistake in the configuration and applied the same rate-limiting which applies to all players to the bot managing the games as well. While you don't see many written messages from WFGBot, it's actually a pretty busy bot and sends out a lot of messages which get processed by 0.A.D. to be able to show you the list of games. With WFGBot not being able anymore to send all messages it wanted to send, this meant the list of shown games would be outdated or even completely empty, because your instance of 0.A.D. wouldn't get up-to-date information of the available games. We didn't catch this problem in our testing prior to the migrating, as our test setup had too little volume in terms of online players and hosted games to trigger the rate-limiting. Fortunately the fix for this problem was easy and just required fixing the mistake in the configuration. Lots of stale and outdated games being shown With invisible games not being a problem anymore, the list of games constantly grew and quickly started to show games whose hosts had already left the lobby. That's no new problem, and you've probably seen such stale games in the past already. That happens when WFGBot doesn't get a notification when a player hosting a games leaves the lobby, as WFGBot then doesn't know that that player isn't hosting a games anymore. We don't know why that happens sometimes, but it does and when it does it leaves behind such stale games. To avoid this problem going forward we added a filter to only show hosted games whose host is still online, which fixes this problem. Windows users not able to join anymore with TLS-encrypted connections Another problem which became visible was that Windows users weren't able to join the lobby anymore if they had TLS-encrypted connections enabled in the settings (which is the default and a good idea to have set). To explain why that happened I have to back up a bit. Core of the lobby is a protocol called XMPP. At its core XMPP is an extensible chat protocol. When you connect to the lobby using 0.A.D., it'll establish an XMPP-connection to an XMPP-server running as part of the lobby. Such connections can be unencrypted or encrypted with TLS. TLS is the encryption protocol also used when you visit websites whose protocol is HTTPS, like your beloved https://play0ad.com/. TLS is available in multiple versions. For historical reasons 0.A.D. up to Alpha 26 on Windows only works with TLS v1.0, which is deprecated nowadays and usually already disabled by default. Connecting to the lobby with TLS-encrypted connections didn't work for Windows users right after the migration, because the lobby XMPP-server didn't offer TLS v1.0 anymore, but only more recent TLS versions. However, the configuration of the XMPP-server was fine. What we missed during the migration of the lobby was to enable TLS v1.0 in OpenSSL, the library the XMPP-server uses for all the heavy-duty TLS-related work. Interestingly, even if we hadn't missed that it wouldn't have worked, because the configuration for OpenSSL required slightly different parameters than before thanks to it being a newer OpenSSL version. Nevertheless, this problem should have been surfaced during testing before the migration, but didn't because we simply forgot to test with Windows. The fix was once again straight-forward and just involved setting the correct OpenSSL configuration after we figured out what exactly the culprit was there. Going forward we'd love to disable such old TLS versions, but we'll have to wait with that until all recent 0.A.D. versions support newer TLS versions as well. Some Linux users not able to anymore with TLS-encrypted connections With login for Windows users fixed, we received reports from some Linux users not being able to connect to the lobby with TLS-encrypted connection enabled. Figuring out what was causing this took us a while, as it did work for the majority of Linux users, but not for all of them. The culprit in this case were the TLS-versions supported by the XMPP-server again, but this time not an old version was missing, but a new version causing problems in certain cases. As part of the migration we enabled the most recent TLS version TLS v1.3. This usually works without having to change clients, because only clients supporting such a version will use it. The client which didn't work correctly was gloox, which is the XMPP-client library used by 0.A.D. We don't know yet why it doesn't work, but it apparently doesn't. The interesting piece is why that was so difficult to track down. Contrary to Windows it's common with Linux that application don't contain all of their dependencies, but rely on them being provided by the operating system in one way or the other. The version of gloox adding support for TLS v1.3 got released less than 4 weeks ago and Linux distributions usually don't include software which got just released a few weeks ago. That's why the majority of Linux users had no problem, as the version of gloox they were using didn't support TLS v1.3. The affected users were mainly users which did install 0.A.D. as Flatpak application, as the Flatpak app for 0.A.D. included such a new version of gloox. Our workaround for this problem was to disable support for TLS v1.3 again on the lobby server, as that makes gloox and therefore 0.A.D. happy again. That's of course just a workaround, as we'd like to be able to offer support for TLS v1.3 in future as well, but to enable it again, we have to figure out why it's currently not working with gloox and get that fixed first. Conclusion As you can see preparing and carrying out the migration of the lobby was quite some effort and not without challenges. While most of the problems which appeared during the migration could've been avoided, that's always easy to say in hindsight. I'm personally very satisfied with the result of the migration though, as it's a great base for further improvements and the performance of the lobby is even better than before as well.

From a historical pov, Thracians were: Known for their peltasts and their ability to ambush and harass their enemies. Known for their light cavalry. Not known for their heavy infantry, their light infantry and light cavalry were able to fight in close combat but they didn't have the same efficiency than the heavy infantry and cavalry from the Greeks and Macedonians. Although their light infantry were able to use kopis and other curved swords to defend themselves. Known at some point for their slingers. Hiring Greek mercenaries/auxiliaries in some occasions, including hoplites. Hiring Getic mercenaries, known for their use of horse archery in some occasions. I really encourage @Duileoga, @wowgetoffyourcellphone and @Ultimate Aurelian to read the following excerpts, I really think it will interest you and help you to figure out the strengths and weaknesses of the Thracians. A few excerpts: Thracian Warfare, a chapter in A Companion to Greek Warfare (2021): Odrysian Cavalry Arms, Equipment, and Tactics (2003):

Epic start to a nomad game from spartan_299

@Stan` @wowgetoffyourcellphone

0ad mods now have github actions thanks to @andy5995 to generate pyromods on the fly

Big no for the outpost. also, it make outpost useless and free to capture.

@Sevda I don't see that ruling the seas. btw: That's a Gurkenkahn!

I feel a bit sorry for this uneducated person: