Leaderboard

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.

https://code.wildfiregames.com/D1800

Hey guys! The Legend of Mali is a figurative Map of the Mediterranean and its surrounding land - namely the Aegean, the North African Atlas Mountians and the steppe of the Levant. However, it's siginifant to consider my intentions weren't to make an exact cartography of the Mediterranean, instead it is like my first map "The Legend of Avilava" rather a figurative depiction, like the people back then imagined when they've got told a tale about it - the Mediterranean. Therefore, Romans, Greeks, Persians, Seleucids, Carthaginians and Ptolemies may don't match to appear all toghether in a certain time period of history, but as I said, that's not what matters here. Furthermore, I want to give a you a short overview of the Players: Player 1 (Team 1): Although being as their civ Spartan, they have two seperate headquarters, one Athenian and one Spartan. The latter going in hand with a seaport. They are on the one hand protected by natural walls like mountains and the sea and on the other hand by a short city wall, protecting them from potential Roman invasions. They have a significant starting population of women and citizens alike whilst going in hand with lots of resources to gather from. Player 2 (Team 1): Being Macedonian, they seem to have captured Athens or something as they just start off with a big mountainous city Enjoying not only their coexistence with big quarries, woods and prepared fields to gather resources from (gather from or gather of? no idea), they're protected by a huge wall stretching from the mountains in the West to the seaport of player 1 in the East. Also, Player 2 takes advantage of a huge starting population of not only women but lots of archers and soldiers on the city wall. Player 3 (Team 2): Being set in the rough terrains of the Southern Atlas Mountains, the Seleucids start out with a persian styled city. Having a lower starting population and difficulty to farm crops, they're heavily relying on their advantageous position in the high mountains which is difficult to reach. Player 4 (Team 2): Also enjoying the beautiful view from up the mountain, the dense arrangement of city's buildings already suggest it's biggest problem: The lack of space of these Persians for fields to farm on. Nevertheles, the unreachable height of the mountains is their biggest ally - as the supporting army of player 3. Player 5 (Team 3): Being settled in the warm steppes of the Levant, the Roman capital is divided into two Players - Player 5 and Player 7, both Roman, both stationed next to the sea. Having set fields, a quarry and enough wood to prosper of, they are also in process of building a city wall. Player 6 (No Team): The Carthaginians - Set in the wild transition from mountain to coast, they are protected by the natural environment and city walls alike. Nevertheless, finding space for crop farming seems to be a problem at first - as long as you don't miss the berries! Player 7 (Team 3): The Northern part of the Roman capital has not only some territoral issues on which expanding is impossible, but they also face the threat of Greek invasions. Nevertheles, with sufficiently enough guardsmen they try to handle the problem. Player 8 (No Team): Sadly indeed, the Ptolemies neither have any starting city nor strong military power from the start - beside these two cute elephants. However, their surroundings provide resource availability at its best. Moreover, not only can they construct fields sufficiently, but they've also enough space to build their own city on. In order to give you a little overview of the Players (starting of with Player 1 and ending with Player 8) I'll "attach" some screenshots I just took in the following "space" (lol my English is dead by now haha) So, spoilers ahead! Some screenshots of the map in general: The entire map: I've now uploaded the second version in December 2025. I hope you have no problems with downloading it? Have fun! The Legend of Mali Second Version.pmpThe Legend of Mali Second Version.xml

After the victory, if you stay on the map, the "victory melody" starts and repeats endlessly. It would be nice if this melody was played only once, and then a regular game playlist was launched. The same thing happens after surrender. An endless melody of defeat.

to be super generic and straightforward you could do this: woman unit (unchanged) - gather rates better for food laborer (male model, costs more than woman due to opportunity cost compared to CS) - gather rates decent for food, but best for wood, stone, metal. CS - gather rates halved. then, all you would have to do is pick the right cost for the "laborer" (a generic term which would nicely encompass terms that might be more controversial). Then on top of that, you could use this for a civ bonus (start with 2 laborers instead of 2 ranged units). I'd say this would require the fewest changes to the game (besides just buffing women gather rates.) The only issue that remains is the controversy of encoding gender roles, which is generally historical, but some might take offense. This way you also don't have 4 visuals for eco units (as in 2 gender mod + DE)

okay, that's fine, but the range as given to the player is just a distance by which the entity will engage with enemy entities. It's a "behavior distance" or something to that effect.

@Stan` c'est fabuleux, si on écrit le mot P E T I T S, la censure détecte ça comme une grossièreté à cause des quatre dernières lettres.

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.

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):

Even worse: Only a few tracks are played in replays, then it stops completely

This is check if entity is in parabolic range. x,z are posiotions range is basic attack range of entity sqrt(x*x+z*z) <= sqrt(range^2 - 2range*y) y is high difference between two entities The thing you see in tooltip is the difference between basic range and the average range where unit could be in parabolic range. Now give me mathematic prove that with height ( y + what is in template ) from tower template and basic range (range) will "always" give the same result as with (y-what is in template) and (range+13)

A hopefully simple example: Little Alice and little Bob are playing ball on top of Eiffel Tower. When passing the ball to Bob he fails to catch it and Alice shot falls all the way to the ground. Grown Robert picks up the ball, and has he is a grown up he has further range and is able to throw the ball all the way back to where Alice is if she where on the ground. Is Robert able to pass the ball back to Alice?

Epic start to a nomad game from spartan_299

They are already there and playable in alpha 27, there are only inconvenient warnings left when running, but nothing that prevents you from playing. WARNING: [ParamNode] Could not remove token 'phase_city' from node 'Techs'; not present in list nor inherited (possible typo?) WARNING: [ParamNode] Could not remove token 'phase_city' from node 'Techs'; not present in list nor inherited (possible typo?) WARNING: [ParamNode] Could not remove token 'phase_city' from node 'Techs'; not present in list nor inherited (possible typo?) WARNING: [ParamNode] Could not remove token 'phase_city' from node 'Techs'; not present in list nor inherited (possible typo?) TIMER| LoadDLL: 779.075 us

Really nice map @Yavin.

Please explain this relation since I have trouble comprehending. Shouldn't the default simply be "baked in" at 0? The additional height is not accurately reflected in the range or it is??? And, as @ChronA states, "it changes absolutely nothing about the game balance". Agree with that, however, it does have importance "strategically" as a "deterrent" feature with plenty of evidence supporting this from players successfully utilizing them. Example being that one can verify, (being able to visually confirm the ranges aura) before deciding placement location is of importance.

@hyperion you think i don't understand parabolas? That's a pretty cringe thing to say. In the above, green is the real range of the tower. Below, you can see the average bonus range is 13. How would it be ANY different to say instead: "basic range: 73" "average range bonus: 0", with the 13 meters already taken into account? I am not saying this is a catastrophic bug, but arguing to maintain the status quo is pretty embarrassing.

Well, they wouldn't be just circles anymore. There was a patch for a more accurate range indicator at some point, don't ask me what became of it. Because it wouldn't be correct in the general case as was pointed out, whether this is of concern we can argue about. Just because some people don't understand the relation between elevation and range isn't a sufficient reason in my eyes to throw away what we have tho.

Heyo guys Oh that's very kind of you @Lion.Kanzen! I really appreciate your offer! I'll think about this As for @Langbart, although I can't name a specific count of hours I spent building, I can make an educated guess - I'd probably say plus or minus 50 hours? I'm really not sure here, I wouldn't wonder if it were 30 or 70 hours. Nevertheles, I mostly built and tried the map whilst listening to podcasts or watching documentaries or something like that - and mainly, it was a lot of fun! Nice it works! Thanks for letting me know. Regarding the territory pulls - well thanks, I didn't even knew of them. They must be pretty great, especially with respect to the city wall of the Macedonians of this map. When I've time again, I'll definitely try them out and publish the results in the "Second Version"!

Connecting to the lobby from Linux with TLS-encrypted enabled, which didn't work after the migration with certain configurations (e.g. when 0ad got installed via flatpak), should work again now.

The map is loaded without any problems. How many hours of work did you put into creating the map? ---- PS: These undesired territory spots could be filled with a territory_pull. Screen Recording 2023-04-08 at 08.46.20_1000px_1.6x.mp4

testing...

Would there be a way to number units as they are built? Having units numbered is very important to controlling them, I usually number some archers 1, cavalry 2, infantry 3, and so on. It would be nice if I could auto queue a barracks to produce a type of unit and add them to a numbered group as they are trained, so when I need them I can just hit their number, hit call to arms (i made that hotkey c) and click where I need them.

It is simply incomplete on the back (which is pretty useless).

This is sooo wrong I had to share.