Leaderboard

Wildfire Games, an international group of volunteer game developers, proudly announces the release of 0 A.D. Alpha 24: “Xšayāršā” (pronounced: Khsha-ya-ṛsha), the twenty-fourth alpha version of 0 A.D., a free, open-source real-time strategy game of ancient warfare. The release is named after Xerxes the Great, ruler of the Achaemenid Empire from 485 to 465 BC. Youtube: PeerTube:  Easy download and install Download and installation instructions are available for Windows, Linux and macOS. 0 A.D. is free software. This means you are free to download, redistribute, modify and contribute to the application under the same licences: GNU Public Licence version 2 (GPL v2) for code and Creative Commons Attribution Share-Alike 3.0 (CC-BY-SA 3.0) for artwork. Although you might find some people selling copies of 0 A.D., either over the internet or on physical media, you will always have the option to download 0 A.D. completely gratis, directly from the developers. No “freemium” model, no in-game advertising, no catch. Top new features Balancing adjustments Building snapping Renderer improvements Hotkey editor Formation improvements Status effects (and modifiers) World population setting Lobby improvements In-game user interface (GUI) improvements Unit behaviour improvements Reinforcement-learning interface Art: new models New Skirmish maps Under the hood Balancing adjustments With the help of several of the top-ranked players in the A23 lobby, hundreds of balance tweaks have been made in the past year and almost all units and structures have been adjusted. The end result is a sleeker, more balanced gameplay experience in A24: Civilisations have been rebalanced, giving players more viable choices. Late-game has been reworked substantially, with less snowballing and more viable champions, which means more variety. Heroes can only be trained once per game, so you’ll have to know when to use them. All civilisations now have a stable, for training cavalry and chariots, and an arsenal, for constructing siege engines. Fortresses can no longer train soldiers but have a territory root, making them more defensive structures and better at protecting your base. Female Citizens and Citizen Soldiers can now place the foundations of all structures. Many, many other small tweaks and corrections. Building snapping City-building fans will enjoy this new option: you can now easily place buildings next to each other with snapping! This functionality can be toggled with Ctrl, and you can choose whether you want it on or off by default, so it is, as always, up to you. Renderer improvements This release introduces anti-aliasing in the renderer: you can choose between no anti-aliasing, FXAA and various levels of MSAA, if you have the GPU power for it. A Contrast Adaptive Sharpening filter has also been added to the engine. For using these options we recommend your system supports OpenGL 3.3 or later versions. The ocean shader also received some tweaks, most importantly near the edges of the map, which now looks better Hotkey editor This new in-game editor will make it much more accessible to change your hotkeys. Further, the hotkeys have been reworked to use scancodes, so the default hotkeys will be compatible with any keyboard layout! Formation improvements Alpha 24 gives you new tools to work with formations: you can now pick a default formation to put your units in when given “Walk” and “Patrol” orders, and you can also choose to automatically disband formations when your units are ordered to Attack or Gather, etc. Status effects (and modifiers) Modders will like this one: you can now give status effects to your units, changing their stats in various ways. Stat modifiers can also be applied directly by triggers and in other ways, without having to hack around auras or technologies. 0 A.D. does not yet use them much, but this really gives you more power to make new custom maps and custom game-modes without having to create a lot of new templates, e.g., tower defence mods. World population setting Despite our best efforts, the game can still lag when there are a lot of units on the map. World Pop (Population) gives you one way to still have epic fights but good performance: choose a maximum total pop which. When one player is defeated, their share is distributed among the remaining players. Start a 4v4 with 150 pop-limit each, and the last 2 players can have 600 pop between them! Will you keep that poor enemy alive to hinder your opponent or can you use the extra population capacity? Lobby improvements This was requested a lot: you can now host password-protected games in the lobby! This makes it easy to play with your friends without having to find your external IP or setting up your router. Further, we’ve also improved your security by hiding the host IP until players have successfully joined your game, which drastically reduces the risk of DDOS by hostile players. In-game user interface (GUI) improvements We strive to make the game more accessible and easier to use, and this release is no different: You can easily see your number of active gatherers under the resource count. An overlay with ceasefire time has been added so you don’t get caught out. Tooltips in general have been significantly improved, in particular the resource gathering rates. Map browser For those looking for an alternate way of picking a map to play, Alpha 24 introduces the "Map Browser". Accessible from a button in the Match Setup interface, users can navigate through maps a little more intuitively than using a dropdown menu. Catafalque overview Those who play the “Relic Capture” gamemode will no doubt be aware that the "relics" in question are Catafalques - reliquaries of dead heroes encapsulated within wheeled carts - and each of these has a small selection of beneficial auras. Alpha 24 introduces a "Catafalque Overview" screen, accessible from the "Learn to Play" submenu of the Main Menu, which makes it easy to learn their different characteristics. Civilization overview The long-existing “Civilization Overview” screen has had some background improvements. Because most of the information is now pulled from the game files, it is now considerably more accurate than in previous Alphas. Game set-up There have been a few added capabilities to the game setup, such as choosing the landscape of random maps when several are available, and a more obvious indicator that the game will be Rated for Online Play. Unit behaviour improvements This alpha improves on many small things: Ship pickup has been improved and should require less micromanagement. Units no longer ‘slide’ at the end of their movement, and movement in general has been improved, with far fewer cases of units being stuck. Cheering has been reworked: instead of cheering when receiving a promotion, units now cheer when all enemy units in sight have been defeated. If you’ve played MP, you might have seen an annoying strategy called ‘Dancing’ where enemy units would easily avoid arrow fire and force you to micromanage your archers. This is no longer possible, making the game more fun for all players. Packing/Unpacking behaviour has been improved. Reinforcement-learning interface Reinforcement learning is a Machine Learning technique that can be used to train AI to play games, and now 0 A.D. has one. We’re excited about this new possibility, because the extensive and easy moddability of the game means you could set up many kinds of complex environments and RL agents without having to recode everything from scratch. We invite any AI developers, researchers or anybody else to help with our AI. More could be found in here. Art: new models The new art developments are too numerous to list individually, and include reworked meshes, animations (including new idle, attack, defence and gather animations), textures and materials for a large number of units, as well as new models, including new horse models, textures and animations, new shield models and designs, new helmet models and variants, especially for the Romans, Gauls, Britons and Greek civs. Many new and improved unit textures, weapons and props for a number of civs including, among others, the Persians, Iberians and Carthaginians. The Ptolemies now have a few more historically accurate Hellenized building models and the Britons have a new blacksmith, while the Gauls have a new, more historically accurate wonder and an assembly building that can train trumpeters to intimidate the enemy. New scaffolding, dirt and decal textures for buildings have been added. Many of the ships in-game have been entirely remodeled from the ground up. Siege artillery has been completely remodeled as well, including considerably improved animations. There is also a lot of new and improved flora, including trees, bushes and grasses. We have new cliffs, new particle actors for snow and clouds and a few new terrain textures, as well as new sounds, and voices. There is a brand new welcome screen, and there are also many improved icons, and unit portraits for the GUI. This is in addition to a myriad of smaller fixes, corrections and optimizations. For more screenshots and details on the new art in this release, see our last two development reports here and here. New maps 0 A.D. Alpha 24 has been enriched with 7 new skirmish maps. Atlas Valleys, Farmland, Obedska Bog (day/night), Oceanside, Sahyadri Buttes, Temperate Roadway, Vesuvius Under the hood New Requirements: Windows XP, Windows Vista, and anything below macOS 10.12 are no longer supported. The game also now requires SSE2. Furthermore, while ARM macs are supported, unfortunately the code running on them isn’t native yet, so users on this platform should expect a performance loss. Several modules of the game have been partly rewritten or extensively modified for Alpha 24, which will make them work better and make it easier to extend them in the future. Notable examples include the GUI GameSetup pages, the UnitMotion component, and the renderer has seen plenty of changes with the removal of the OpenGL 1.0, 90’s style “Fixed-Point” pipeline. Which in turn raised the lowest supported version to OpenGL 2.0. In addition, we started to fully use the ARB shader pipeline.(Modders, all of this means you will also find there are plenty of new cool things you can do!) Alpha 24 sees the adoption of Visual Studio 2017 as the main Windows compiler (Alpha 23B had Visual Studio 2013) , and we have upgraded our version of C++ standard from C++11 to C++17, allowing us to write faster and cleaner code. This release also saw major upgrades to many core libraries we use. Alpha 23 was released with Spidermonkey 38, released alongside Firefox 38 in May 2015. This time, we’ve upgraded to the last “ESR” version, Spidermonkey 78, released in June 2020! This means we can use newer Javascript syntax, and the engine bindings have been upgraded. Other libraries have been updated on macOS and Windows, which let us support more platforms but also required us to drop some. The name Xšayāršā Xšayāršā (pronounced Khsha-ya-ṛsha; IPA: /xʃajaːr̩ʃaː/) is a transcription of the Old Persian name (x-š-y-a-r-š-a), better known by its Greek spelling: Xerxēs. Xerxes I the Great was the ruler of the Achaemenid Empire from 485 to 465 BC. We decided to name Alpha 24 after this inspiring ancient ruler to celebrate the ancient Persian civilisation, and to reflect upcoming changes in the internal governance structure of 0 A.D. The Persian Empire was considerably larger than any preceding state anywhere in the world, and its administration system would have a long-lasting impact. It consisted of about two dozen satrapies (provinces), which were former kingdoms or conquered peoples. Each satrapy was headed by a satrap (governor or viceroy) and supplied the Persian King of Kings (emperor) with a yearly tribute and troops, but were internally largely autonomous. This organisation outlived the Achaemenids and was continued under the Macedonians, Seleucids, and Arsacids (Parthians). Xerxes inherited the empire from his father Darius I the Great. He continued his father’s reforms and expanded the imperial building programmes. Early in his reign, he led an ultimately unsuccessful invasion of Greece, with victories at Thermopylae, Artemisium, and Athens in 480 BC, but defeats at Salamis, Plataea, and Mycale in 479 BC. The rest of his reign was largely peaceful. The Persian Empire arguably reached its zenith under Xerxes. What’s next? This release cycle is the longest we’ve ever had as you no doubt noticed, and it was a bumpy ride. Despite this, we’re hoping to get back to a more regular schedule now. As usual, for the next alpha, we welcome fan suggestions for words relating to the ancient world beginning with the letter Y. Keep it original and related to the time frame portrayed in 0 A.D. (c. 500 BC – 1 BC). Post your proposal here ! For press/media inquiries, please DM @play0ad on Twitter.

Leather vest and patterned woven cloth armor. @Genava55

IMHO, you should not know the enemy civ (if 'Random'), until you either see or click on an enemy building or unit. For instance, the civilization and name should say "Unknown" for my Iberian opponents here: Until I've either seen or clicked on an enemy unit or building (whatever the devs prefer).

goats-1.m4v

Sunday fun, and possibly the most exciting game I've covered so far?

They are identical however I'd wait a bit as we need to make a small hotfix with the recent feedback. Nothing too serious.

The 0 A.D. Fandom articles are way outdated as well. Everything needs rewritten. I'll be making a new Fandom wiki for Delenda Est once everything reaches "Beta". I was thinking of writing an old school "Manual" in PDF format as well, once everything is mostly done. Inspiration: http://www.thealmightyguru.com/Wiki/images/9/9a/Age_of_Empires_-_W32_-_Manual.pdf I predict such a Delenda Est manual will reach 200 pages of awesomeness.

Greetings! The Trac articles on this game looks a bit messy. Do you need any help migrating some 0 A.D. on Fandom (formerly Wikia) articles to Trac? My Fandom username is the same as in this Forum. Just tell me how to upload images, create tables, etc. on Trac so I can get started with this project. Thanks!

hi guys (sa) first of all sory for my english . ı make mistakes guys ı think team maches should be ranking . like cs go or leage of legends because some people dont care tg ,when they are lose the game they are closing game and we stay 4 v3 or some people have high rate and never play 1 v1 so ı wish ranking team game what do you think about this topic guys

Own my mistak', an' start a'thing ower again, gin I was God. Wrong Doric. I'll be collecting here the Doric (specifically, Laconian) equivalents for the building (and later, units) for the Sparta faction. Laconian is Doric Greek, along with Cretan, Corinthian, Megaraean, etc., which itself is part of the West Greek dialects, along with North-West Greek. I will be mainly using Buck (1909), Introduction to the Study of the Greek Dialects: Grammar, Selected Inscriptions, Glossary and maybe Jeffery (1963), The Local Scripts of Archaic Greece: A Study of the Origin of the Greek Alphabet and its Development from the Eighth to the Fifth Centuries B.C., as well as the LSJ. The Doric dialects often retain the digamma (Ϝϝ) until late, pronounced /w/. I will transliterate them as w, as per the ALA-LC Romani(s)ation Table of Greek, which is listed in the 0 A.D. ground rules for Greek as a source. Since the heroes for Sparta are either 5th century, or early 4th, I will assume the dialect (and ortography) to be from around the same time. From around the 4th century, Laconian inscriptions begin spelling initial /w/ with Β instead. Long a is not part of the romanisation, but I will write them as ā regardless, in case clarity is needed for later. According to Buck, ε and ο were more open (/ɛ/ and /ɔ/) than in Attic (/e/ and /o/), Υυ was pronounced /u/, not like Attic /y/. Buildings Civic Centre Suggestion: unchanged (Agorā [Ἀγορά] /a.go.rǎː/) Justification: No vowel or consonant changes of Laconian are applicable. Surprising ending of -ā instead of -ē for Attic. Comments: None. House Suggestion: : Woikos [Ϝοἶκος] /wɔ̂i̯.kɔs/ Justification: Initial ϝ is often retained in Laconian, sometimes spellt with a β. Woikos not specifically attested to my knowledge in Laconian, but is present in Cretan, Delphic, Phocian, Elean (both ϝ & β), and Koine at Olympia (with β). Comments: None. Storehouse Suggestion: : Apothēkā [Ἀποθήκᾱ] /a.pɔ.tʰɛ̌ː.kaː/ : perhaps Laconian Awēr? [Ἀϝήρ] /a.wɛ̌r/ Justification: Attic and Ionic changed original ā to ē. Most other dialects maintain original ā, including, surprisingly, Attic. Apotheke comes from ἀπο-θήκη, which comes from τιθήμι (also ē in Doric). Ending of -η is Attic from -ᾱ, and a Laconian attestation (SGDI.4598) of -theka exists (though written by a Tegean), παρκα(θ)θεκα (Att: παρακαταθήκε). So, Apotheka seems like the right choice. However, according to Hesychius, ἀβήρ (ἀϝήρ) is 'οἴκημα στοὰς ἔχον, ταμεῖον Λάκωνες', i.e. 'room/chamber having a colonnade(?), Laconian ταμεῖον (treasury, magazine, storehouse, store-room, reservoir)'. A Laconian storehouse, apparently, but the LSJ and other dictionaries put it as the Doric of ἀήρ (air), so it's up in the air (badum-tshh) Comments: None. Farmstead Suggestion: unchanged (Epoikion [Ἐποίκιον] /ɛ.pɔǐ̯.ki.ɔn/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Field Suggestion: unchanged (Agros [Ἀγρός] /a.grɔ́s/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Corral Suggestion: : unchanged (Epaulos [Ἔπαυλος] /ɛ́.pau̯.lɔs/) : or Mandrā [Μάνδρᾱ] /mán.draː/ : or Ostrimon [Ὄστριμον] /ɔ́s.tri.mɔn/ (applies to other Greeks too) Justification: Epaulos = fold for cattle, Mandra = fold for cattle (oddly, the Attic didn't change to Mandrē). Ostrimon = byre (barn for cows), enclosure for cattle (Bailly also says 'stable'). None of these have Laconian vowel or consonant changes that are applicable. Comments: Neither myself nor @Nescio have a preference for any over another. Harbour Suggestion: unchanged (Limēn [Λιμήν] /li.mɛ̌ːn/) Justification: It seems to be a real ē, rather than ā>ē. I've gone nothing else. Comments: None. Barracks Suggestion: unchanged (Stratopedon [Στρατόπεδον] /stra.tɔ́.pɛ.dɔn/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Stable Suggestion: unchanged (Hippōn [Ἱππών] /hip.pɔ̌ːn/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Lookout Suggestion: unchanged (Prophylagma [Προφύλαγμα] /prɔ.pʰú.lag.ma/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Sentry & Stone Tower Suggestion: unchanged (Pyrgidion [Πυργἰδιον] /pur.gí.di.ɔn/ & Pyrgion [Πύργος] /púr.gɔs/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Palisade Suggestion: : Charakes [Χἀρακες] /kʰá.ra.kes/ : or Skolopes [Σκόλοψες] /skɔ́.lɔ.psɛs/ : or Charakōma [Χαράκωμα] /kʰa.rá.kɔː.ma/ (applies to other Greeks too) Justification: No vowel or consonant changes of Laconian are applicable. Charakes = pl. of charax (pale). Skolopes = pl. of Skolops (pale, stake). Charakoma = pallisaded camp. Comments: No preference. Thanks to @Nescio for the suggestions. Palisade Gate Suggestion: TBA Justification: TBA Comments: TBA Blacksmith Suggestion: unchanged (Chalkeōn [Χαλκεὠν] /kʰal.kɛ.ɔ̌ːn/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Temple Suggestion: : Naos [Νᾱός] /naː.ós/ but maybe change Athens' to Neōs [Νεώς] /nɛ.ǒːs/ Justification: According to Buck (41.4, 53, 54.f.), most dialects lost intervocallic or post-consonantal ϝ early on, by the fifth century, and suggests νᾱός for Doric. Comments: Thanks to @Nescio for the suggestion of intervocallic digamma, though I did not implement it. Market Suggestion: unchanged (Emporion [Ἐμπόριον] /ɛm.pɔ́.ri.ɔn/) Justification: No vowel or consonant changes of Laconian are applicable. Comments: None. Arsenal Suggestion: : Hoplothēkā [Ὁπλοθήκᾱ] /hɔ.plɔ.tʰɛ̌ː.kaː/ Justification: Same as Apotheka (see above). Attested Laconian (Tegean scribe) -thēkā. Comments: None. Fortress Suggestion: : Phrōrion [Φρώριον] /pʰrɔ̌ː.ri.ɔn/ Justification: The Attic Phrourion has a spurious ou diphthong, which would have been rendered as ō in Laconian (Buck 25). Comments: None. Theatre Suggestion: unchanged (Theātron [Θέᾱτρον] /tʰɛ́.aː.tron/) Justification: No vowel or consonant changes of Laconian are applicable. Surprising ā instead of ē for Attic. Comments: None. Wonder Suggestion: : (H)Iaron tās Artamitos Worthias [Ἱ/Ἰαρὀν τᾶς Ἀρταμίτος Ϝορθίας] /(h)i.a.rɔ́n tǎsː ar.ta.mí.tɔs wɔr.tʰí.as/ Justification: Mainly attested from late (2nd century CE) Laconian inscriptions (Buck, Laconian Inscriptions 70-73); however, they follow general rules present since earlier periods. Hiaron or Iaron from Attic Hieron are the regular forms according to Buck (13.1) and both are attested in the LSJ for Doric. Tās vs. Attic tēs is obvious. Inscriptions mentioned have Artemitos, but 70 has Artemidos; however, Artamis is the most common West Greek, and was only later replaced in Doric by Artemis (13.2). The -idos (vs. -itos) is probably Koine influence from Attic gen.sg. Artemidos. Mentioned inscriptions write Borthea, but 73 writes Worthea; however, it was common for Laconian to use ι for ε before another vowel (so, Worthia), and only later was the spelling changed back to ε (9.5), probably from Koine influence. The sound could have been a /ɪ/ if not outright /i/. Comments: None. Military Mess Hall Suggestion: unchanged (Syssition [Συσσίτιον] /su.sí.ti.on/) Justification: No vowel or consonant changes of Laconian are applicable, especially since it is apparently a Laconian word, present since at least Herodotus (1.65.5). Comments: None. Technologies Units

Someone might ask, "is it necessary to derive exact formulas for things like LOD bias?" The answer is a qualified yes. What most engines that even use LOD bias do is just fudge it. Just like they fudge a rough formula for Fresnel. The problem with fudging things is that eventually you arrive at a visible inconsistency. One possible inconsistency here is between environment mapping's reaction to specular power, and sunlight's reaction to specular power. One blurs by LOD biasing the cubemap with trilinear filtering. The other one blurs by computing the Phong formula. And the two have to agree. If they don't, your visual cortex will know it, even if your prefrontal cortex denies it. The same goes for the light intensity relationship between diffuse and specular. Everybody fudges that. But the day you see a shader that doesn't fudge it, that matches them mathematically, something about it seems cinematic in quality, and you don't even know what it is. And the light intensity between diffuse and specular match perfectly when specular power is 1.0, and reflection falls by 1/2 at 60 degrees from the half angle, just like in diffuse it falls to 1/2 at 60 degrees between light and normal vectors. Yes, these things are important, both in relative and absolute terms. I know because 20 years ago I worked on all this and came up with a shader that was utterly unbelievable. I had been working on all the math on faith that it would make a difference; and in the end it far exceeded my wildest expectations. THIS IS PHYSICS-BASED RENDERING, by the way; not all those other pretentious parties out there with far more money than brains. Anyways, let us continue: How about we calculate blur radius for four other specular powers, namely 4096, 256, 16 and 1.0, and see if we see a pattern? Using the formula Radius = arccos( 0.5^(1/n) ) where n is the spec power, SpecPWR radius (rads) /2.35 blur 2/x=rez log2(x) 10-log2x=bias ================================================================ 65,536 0.00459924964 0.00195713 1021 ~9.99 0.0 4,096 0.01839651273 0.00782830 255.5 ~8.00 2.0 256 0.07355492296 0.03129997 63.9 6.00 4.0 16 0.29223187184 0.12435399 16.0 4.00 6.0 1 1.04719755125 0.44561598 4.5 ~2.22 ~7.8 These calculations were painful, but certainly not wasted. How in the world an arccos of a funny power comes so close to a much simpler formula, I don't know, but seeing is believing. Bias appears to be equal to 8 minus the log2( sqrt( spec_power ) ). But the log of a square root is 1/2 the log of the thing, so this boils down to ... float LODbias_from_spec_power( float spec_power ) { return clamp( 8.0 - ( 0.5 * log2(spec_power) ), 0.0, 7.78 ); } Now we need to get a formula from AO. Remember that the AO is basically a measure of solid angle expressed in hemispheres. White, in AO, means a full hemisphere of visibility, which happens to be 2 pi (6.28) steradians. Next post ...

Reconstitution of various La Tène scabbards and swords:

There's another math issue to resolve before proceeding to the next stuff, namely the environment cube fetches. There are two main reasons to read the env_cube: specular reflections, and ambient light. Ambient light?! Well, yes; the env_cube IS our ambient. Reflected ambient light at any point in a surface is nothing but the light it reflects diffusely from the part of the sky its normal points to, multiplied by the ao. Naturally! So the AmbientLight uniform is not needed when we have an env_cube; the slot can be used for Ground Color... ;-) So, we have two fetches: one for reflection, and one for ambient lighting. But now, obviously we don't want the color of an exact point in the sky for ambient; do we? We want a very, VERY blurred sum of a portion of sky, --up to half of it, if the ao is 1.0. But how do we read half the sky? Well, that's easy, actually. We simply read the env_cube with a lot of LOD bias. The deepest LOD represents the entire sphere of sky with 6 texels. If we don't have LOD's in the cube_maps, no problem, there are free tools that can generate them. It will only take an afternoon to add LOD's to the cube-maps. So then you read the cubemap with an LOD parameter, which is a floating point number; the fetch is tri-linearly filtered. In the case of specular reflections, we also want to calculate a bias, as such reflections are blurred by the roughness of the surface, the inverse of smoothness, of specular power. To each specular power there is a corresponding blur radius. And to each LOD in the env_cube there is a corresponding blur radius. We need to compute a bias that will match them. Now, the problem is how do we compute the bias? In the first post in this forum thread I derived a formula to relate specular power to solid angle. So, we need a formula that relates solid angle to cube-map LOD. If we were to assume no filtering, solid angle for an LOD would be texel size solid angle. However, being a cube, the solid angle for a texel in the middle of a face is larger than for a texel near a corner, which is why cube-maps MUST --ABSOLUTELY MUST-- have spherical blurring applied. And I believe the absolute minimum effective blur diameter is 2.5 texels --of the ones in the middle of a face. A radius of 1.25. So, assuming our cube-maps are 1024 x 1024 x 6 at LOD zero, the angle of 1.25 texels is what? Hmmm... It would be the arctan of 1.25/512 = 0.0024414014 radians. From the first post, my formula relating shininess to radius was n = ln( 0.5 ) / ln( cos(SpotRadius) )... cos(0.0024414014) = 0.99999701978 ln(0.99999701978) = -0.0000029802244 ln(0.5) = -0.6931471806 0.6931471806 / 0.0000029802244 = 232582.2 Yes; that's a specular power equivalent of 232,000 and change. Which is not impossible, in principle; a good mirror probably has specular power in the millions, if we were to calculate it; funny they don't use that for marketing; it's just that we cannot represent it in the game. I think I designed the Smoothness mapping to get 64k at 255 channel value, so no reflective surface in-game will come even close to the most detailed LOD (level 0). How about we go the other way? Let's find out what blur radius we need for a given spec power. Maybe we can get away with much smaller environment cubes... At spec power of 65536, SpotRadius = arccos( 0.5^(1/n) ) = arccos( 0.99998942347 ) = .00459924962 radians. tan( 0.00459924964 ) = 0.00459928207 The inverse is 217.426771381 blur radiuses per half a side, or 434.85 radiuses for full side. Okay, so we can use 1024 cube maps, just keeping the blur radius to 2.35 texels, which is good; I was worried about not being able to blur the cube-map enough to prevent DXT compression artifacts; it seems we HAVE to do a nice blur. EXCELLENT! So, I was going to say that the shader needed to be passed the cubemap size and blur radius as uniforms, but I think there is not much room to play with those parameters; I think what these calculations are saying is that cubemaps HAVE to be 1024, AND HAVE to have a blur radius of 2.35 texels, or 0.0046 radians, at LOD 0. So, let the shader assume these numbers, and I'll make sure our cube maps meet these specifications. Okay, so now we know that for a specular power of 65,536 we need an LOD bias of zero. But what is the general formula? Stay tuned.

causative made his own `TrueSkill' taking into account 0ad replay metadata. Here's an implentation https://trueskill.org/ Some mod (nani's?) already adds an autobalance command, no idea if it works

Some news coverage https://news.ycombinator.com/item?id=26207191 https://www.gamingonlinux.com/2021/02/open-source-rts-0-ad-alpha-24-is-out-now-with-plenty-of-new-features https://www.phoronix.com/scan.php?page=news_item&px=0-AD-Alpha-24 Well, if anyone finds a convenient way to get all the coverage, let me know. I only used Searx and searched for external links. href:https://play0ad.com/new-release-0-a-d-alpha-24-xsayarsa/ Noteworthy: Wolframalpha play0ad.com vs ageofempires.com

Ratings have not been migrated yet. The ratings you see now are the ratings from the start of a23

Why has rating reset in a24? It only shows the 2 1v1s I played in a24 and none of the previous 60 I played in a23. I saw quite a few people with their rating reset but at the same time a lot of people didn't have their rating affected at all. Why is this?

Thanks a lot for your work on Spidermonkey!

That would work for the current situation, though if at some point mercenaries are made civilization-independent, we'll re-encounter that headache. Anyway, something to worry about then and there. It's not just the different sound changes I'm worried about, that part is fairly certain (at least for Doric), however, there is also vocabulary, e.g. Doric has κέστερ, Attic νεανίας ‘young man’. A dialect is more than just a respelling. Likewise, when converting British English to American English, changing centre and colour to center and color is the easy part, but maize vs corn is harder to spot. And English variants are very similar to each other, much less so e.g. Luxembourgish or Swiss German vs Standard High German, or Tsakonian vs Modern Greek. Yes, Linux makes a lot of things much easier. Nevertheless, surely Windows must have an option to choose a different keyboard? If switching from English to Spanish is possible, or from QWERTY to DVORAK, then it should be possible to use a layout with AltGr?

Maybe some more explanation. The framerate effects both, GPU and CPU. Every frame which is calculated by the GPU is "prepared" by the CPU. I you have no framerate limiter, you get as much as possible frames as your CPU and you GPU can provide. One of them will limit your framerate. No framerate limit (in 0 A.D.) means you set the framerate limiter to maximum. If you lower this limit, your framerate will be limit to the chosen framerate. If your hardware is limiting the framerate before reaching the set framerate limit, you wont get the set framerate. If you choose graphic effects, you will generate additional workloads for your GPU and CPU, so your framerate decreases. Some of the effects will have a greater impact to the GPU, some more to the CPU. Depends on the effect, but mostly the bigger effect is on the GPU. Current PCs are mostly CPU limited in 0 A.D., because the game is not multi threaded yet. That means they mostly only use 1-2 cores. As graphic effects mostly effects the GPU, you can chose the higher graphic effects without a lose of performance (on newer PCs). In addition to what I said about heating of the hardware (see second post of this thread), there is more to say about it. Heating of hardware leads to thermal throttling of the hardware. This effect is mostly known on mobile PCs. If the hardware gets to hot, the hardware limits it's performance until the hardware is cooled down. So a limited but constant framerate is mostly favored than a framerate which is oscillating because of thermal throttling. At last, VSync will limit your framerate to the framerate of your monitor (I guess 60 frames/herz) too. German translation: Vielleicht mal eine ausführlichere Erklärung. Die Framerate wird durch die GPU (Grafikkarte) und die CPU (Prozessor) beeinflusst. Die CPU "bereitet" die Bilder vor, welche von der GPU berechnet werden sollen. Ohne Frame Limiter werden so viele Bilder (Frames) wie möglich berechnet. Dann wird entweder deine CPU, oder deine GPU die Framerate begrenzen. Um den Framerate Limiter in 0 A.D. auszuschalten muss du den Regler in den Einstellungen auf Maximum setzen. Wenn du ein Limit setzt wird die Framerate auf dieses Limit begrenzt, das schont deine Hardware. Dieser Framerate Limiter garantiert dir aber nicht die gewünschte Framerate. Das heißt wenn du den Limiter zu hoch einstellst, dann wird eben deine Hardware, und nicht der Limiter deine Framerate limitieren. Die einzelnen Grafikeffekte die du auswählen kannst erzeugen eine zusätzliche Last für die GPU und CPU. Manche der Effekte haben dabei einen größeren Einfluss auf die CPU, manche einen größeren Einfluss auf die GPU. Das kommt auf den jeweiligen Effekt an, wobei die meiste Last schon auf die GPU geht. Aktuelle PCs werden in 0 A.D. normalerweise durch die CPU limitiert. Das liegt daran das 0 A.D. nicht so gut mit Multicore CPUs umgehen kann. Da die Grafikeffekte meistens zu Lasten der GPU gehen kannst die Grafikeffekte in 0 A.D. bei einem aktuellen PC meist recht hoch drehen ohne das es einen großen Einfluss auf die Performance hat. Zusätzlich zudem was ich schon im zweiten Post zum Thema Abwärme gesagt habe, möchte ich noch was ergänzen. Wenn die Hardware zu warm wird, dann führt das zum "Thermal Throttling". Das heißt deine Hardware limitiert ihre Leistung damit die Hardware abkühlen kann. Das kennt man vor allem im Bereich der Notebooks und anderer mobiler PCs. Das Thermal Throttling führt dann dazu das die Framerate stark fluktuiert. Meistens wird deshalb eine niedrigere, dafür konstante Framerate bevorzugt. Hierfür kann man dann eben ein Framerate Limit in 0 A.D. einstellen. Btw. VSync ist auch eine Art Limiter. VSync begrenzt die Framerate auf die Bildwiederholungsrate deines Monitors (also meistens 60 fps/Hz).

Sounds like a nice idea. Your image is down though.

I'd say that's a good thing! Mild confusion can easily lead to learning. I think to avoid any headaches, we basically make the names from the point of view of the faction. Athenians will call things by their names in Attic, Spartans, by their names in Doric. Even though that would remove any Petthalian dialect from the game, my personal favourite . I understand where you're coming from, but this is a bit too strict in my view, especially in regards to Doric, which is very conservative in comparison to East Greek. Most changes found in the Attic and Ionian dialects are very regular, and very particular to those. The main changes would be ᾱ>η, ô>ου vs Doric ô>ω, σσ>ττ, verbal stuff which is not needed here, and phonology. In these cases, the odd ones are Attic and Ionic, and most other dialects would preserve the original forms. This means recreating a non-Attic equivalent would be very easy, and doubtfully incorrect, even if we don't have literary attestations (even then, some Attic Greek words are attested only a handful of times sometimes, as you probably know). However, I will still try to be as thorough as possible and justify all changes as clearly as possible. As you can see, serendipitously, they're not that many. That's a Linux only feature. Windows is dumb and doesn't do that. Maybe I'll set up an autohotkey. Will make changes. Thanks for the feedback! Thanks! will help when I move on to units.

Ok, will do. I wasn't sure where. I made one for Doric Greek here in this subforum, I guess one for the Celtic lang would be ok too. No disagreement here.

Current issues still going in A24 for the Gauls: - Removing round shields as props everywhere for the buildings, mostly the houses. - Moving the iron scabbard on the right side for the Gauls (elite spearman, champ. swordsman, ...) - The Gallic heroes are still a bit fantasy. - The Gallic temple is still not really accurate. The Britons still await a complete overhaul.

It seems fine. Although on the left one I see a kind of collar looking like a "torc" texture. Is it intended? I totally agree. There are multiple ways to wear it. Here a few Gauls: For the Gauls yes. It could be a way to differentiate them. The topic of the scabbard is still an issue for both factions.

@Rahman 1441 hi tell him please to update his windows, see solution section here https://helpx.adobe.com/download-install/kb/error_on_launch.html

You'll need to edit petra/config.js also. Perhaps you can convince someone to make this change in vanilla 0 A.D.?

Reproducible: #6052 thanks for the report Phab:D3588

To upload images judt add them as attachments to the pages see the markdown detail https://trac.edgewall.org/wiki/MarkDown Hit me up if you need anything

After going through the absurdity of your posts, I think my brain automatically filtered out the ____. From a game experience point of view, I don't see how any of it hinders fun for the sake of gameplay in anyway. Have you even played the new alpha? Alpha 24 is officially out too, play it. Is your perfect scenario of 0ad a game where all units are replaced with one singular unit and all civs are essentially a reskin of one another? Check out AOE 2 for that. And coming to realism, first of all, realism is indeed a big part of this project, easily the most historically accurate ancient rts out there, but at no point can realism be a bigger priority than gameplay. Gameplay first, while doing the best to keep it realistic. Also, honestly, I don't see what you fail to understand. A swordsman can outperform a spearman in a 1v1 in real life too (owing to the mobility and the versatility). However, in real life sword wielding required much more skill and were more expensive. Siege received nerfs , mass catapults doesn't even work now , which used to be the ideal-noob-turtling-Roman strategy. Also, capturing has become a better functioning mechanic, a great alternative to siege. And wdym by "notorious" combo. What's the rocket science involved in pairing up two village phase units with great synergy. If it isn't unbalanced, what's wrong with the combo? . "Camels have a weakness???" Wuhaaat! Guess what, every unit has a weakness. And this might blow you away, but according to recent leaks and rumors, every unit has a strength too ( ikr, I couldn't believe by ears). Rams will become unnecessarily underpowered if spearmen ( an ideal trash unit) got too effective at taking it down. It's understandable why you're probably ~800. Unit counters is quite basic and quite intuitive if you click on "learn to play the game"---> "structure tree", then just hover over units. Don't worry, I used to be quite bad too but instead of blaming the system, I tried to understand the system better. Welp, I am still not too good, but I have basic game sense. Rest assured, the game is in great hands and the balancing team did such a great job ( even art and other teams) and fixed unit dancing, the cheapest and least honorable of all techniques I am not even hyped for AOE 4 anymore. As for your last point, I can clearly say you haven't played enough 0AD to start threads about such topics. Not that you're totally wrong about infantry being mostly fodder, but really, launch 0AD more often than once a lifetime .Spec pro games. tl;dr: a24 nerfs siege quite a bit. having spearmen being able to effectively take down siege would make rams a waste of metal.

My user name P_J Opponent daltanius it was a rated game and he quit without resigning. @user1 commands.txt

OBJECT TEXTURES REVISITED (take 2) Object textures are what defines an object's appearance other than material, as mentioned before. Normal_U 8 bits "Forms.png" (PNG sRGBA; no mipmaps) Normal_V 8 bits " Normal_W 8 bits " Height 8 bits " Emit_red 5 bits "Light.dds" (DXT5) Emit_grn 6 bits " Emit_blu 5 bits " Occlusion 8 bits " Faction 5 bits "Zones.dds" (DXT3) DetailMod 6 bits " ???????? 5 bits " Alpha 4 bits " EUREKA! 3 Object Pack textures, with one channel to spare. What I particularly like about it is how the channels hang together: Normals and height are interrelated; they are both form modifiers. Same thing goes for Emission and Occlusion, both of which have to do with light and are "baked" in similar ways. (I don't mean that lightbulbs and torches are baked; I mean how they illuminate the object is something that can be and should be baked. And this baking can be modulated by the CPU; thus, a flame sequence for a torch can have an intensity track which in turn can be used to modulate the baked emissive. And if you worry about actual lights in the emissive texture that should not be modulated, worry not; I dealt with that problem a long time ago; found a trick to decouple light sources from baked illumination. ) Finally, the Zones texture has three zonings. Faction tells where to place faction color. DetailMod tells where and how to add detail noise (0.5 will be NO detail; 0.0 will be max smoothness detail, 1.0 will be max AO detail. For a ground or a very rough surface, AO detail can be best. For a smoother surface, smoothness detail shines). And alpha, which is also a zoning. The reason I chose DXT3 instead of DXT5 for Zones.dds is that the alpha channel does not need ANY precision, in fact, I would have been happy with a single bit alpha for alpha testing, and instead it really needs to NOT be messed up by correlation expectations of the DXT algorithm. And all the stuff that doesn't mipmap well at all, but require high precision and low artifacts, namely the normalmap and the height for parallax, those two are together uncompressed and bi-linearly filtered. I'm particularly happy about keeping the normalmap uncompressed, rather than try the roundabout way of Age of Dragons, of using DXT5 RGB for U, then alpha for V, and computing W on the fly. Like I said, I came up with that VERY idea 20 years ago, EXACTLY same idea, and implemented it, but the results were far less than satisfactory, and eventually we decided to go uncompressed and un-mip-mapped. No need to repeat that long learning experience. The way it is here, the normalmap format is entirely standard, unproblematic, and the alpha channel has the height channel, which is the way it's been done for ages by engines using parallax. Why reinvent a wheel that works well? Those two things, normalmap and height, go well together. To summarize, I have two DXT5 textures for materials, and then one uncompressed, one DXT5 and one DXT3 textures for objects 5 textures altogether, only one of them is not compressed, and the channels they pack MAKE SENSE together. Yes! Compare this with the glTF abomination, which uses 3 UNCOMPRESSED textures, plus one compressed texture that mixes (object) AO with (material) attribute channels, making it useless to any engine that has the good sense to appropriately separate the concerns of objects and materials with separate UV mappings. But so, DXT3 and DXT5 being 4:1 compressed formats, this boils down to glTF being about TWICE THE SIZE of this packing (in video memory terms), and it doesn't even have such material channels as index of refraction, surface purity or passivized layer thickness; and it doesn't have object texture channels such as height, faction, detail texture modulator or even a friggin alpha channel !!! You get not even half the goodness, but have to pay TWICE the price, in video memory consumption, with that glTF stupid garbage ... ( And it pretentiously calls itself "physics based" but doesn't even have a channel for index of refraction. What a joke! ) Here, even the names of textures, and the names of channels, make sense: albedo.dds, optics.dds, forms.png, light.dds and zones.dds. Where else in the world do you get so much clarity? "Smoothness" for specular power, "Gloss" for index of refraction, "Purity" for surface lack of diffuse impurities, "Thickness" for rust thickness ... Any system you look into, nowadays, they intentionally misname things to mystify and pretend. Nobody gives you clarity like this. NOBODY. Couple of closing notes: I worked for years with an engine that supported only 1 UV mapping, Vegastrike, and back then I thought it was good. But it didn't take me 5 minutes around here to realize what a great idea having 2 UV's is. Separating the Material and Object concerns is a Win-Win-WIN, with the added advantage that pixelation concerns are minimized when two uncorrelated mappings are blended. The ability to overlap islands in material space is invaluable, as it creates an appearance of great detail at minimal cost, and reduces artistic work enormously. Imagine if for every building that uses brick or wood you would have to re-create, or at best copy and paste, bricks, or wood. It is insane. Don't throw away the best thing your engine has to offer. Question, instead, the self-proclaimed authorities that came up with that glTF TRASH, --as it will be remembered (if at all) once all the the marketing dust settles. Note that materials don't have Emit, in this system; here temperature is an object-related thing; not a material attribute; such that a lava flow would have to be an object, and have emissive color from the object texture pack, and with (non-emissive) volcanic rock as the material. Which may simply boil down to the terrain, as an object, having an emissive burgundy color painted on the lava flow, to make it glow. Regarding translucent plant leaves, fires, plasma drives and glass, all that will be served by another shader; the "fireglass" shader, as I called it 20 years ago (yes, I coded it back then; but I don't have the files; will have to code it again). (Coming after this one ...) Comments? Opinions? ((But please, keep it to technical merits; don't start telling me I should be a sheeple and follow what "the big guys" do; I would rather kill myself.)) If nobody has anything to add, subtract or point out, I will start working on the shader tomorrow. Regarding exporting materials from Blender, I can't see what problems there'd be. Blender has Index of Refraction, specular power, etc., built in; Cycles has them too. I could come up with a set of nodes for rendering to ensure they follow the exact same math as the shader, and therefore be sure renders look exactly like what objects will look like in-game. Easier to debug in the shader first, THEN transfer to Blender, though. As for texturing in Blender, we could simplify the workflow by using color codes for materials. So you select, say, 16 materials you will need, assign them color codes, then in Blender you paint using color codes, but when you hit F-12 the colors are replaced by actual materials for rendering. Just an idea, and it would probably need a lot of manual touch-up after export due to filtering aritfacts. I'd like to write a tool (in C++) to convert png to DXT1/3/5 better than other tools out there do. I don't know that they DON't do what I would do, yet; but I'm guessing they don't. You know what dithering is? It's basically a recursive algorithm that, given a quantization limitation in a texture, and given a higher precision values texture than is representable in the lesser texture, rather than throwing away data by rounding, tries to spred the errors a little bit among neighboring pixels, so that the overall effect is more precise. Well, I think the same algorithm could be, and should be applied to a texture before DXT compression, except for the peculiar 5,6,5 bits of DXT color representation. So you dither down to where you have the three lowest bits of red an blue channels at zero, and green channel's two least significant bits as zero, while maintaining texel neighborhood color accuracy as much as possible, then DXT-compress. Furthermore, I think in some situations it may be better to NOT use nearest points in the line to pick end colors, but allow the end points to move if it helps the overall matching accuracy with two bit indexes. I'm sure NOBODY is doing these things... Furthermore, where the 16 points form a cloud that's very difficult to linearize, a good algorithm should skip the texel, continue with the others, and once the neighboring texels are worked out, perhaps choose the same line orientation as one of the neigbors, or average the orientations of the neighboring texels. EDIT (day or two later): Zones texture rearranged: Faction 5 bits "Zones.dds" (DXT3) Ageing 6 bits " DetailMod 5 bits " Alpha 4 bits " The reason for this change is that Microns, (oxide layer thickness for iridescent reflections), is actually a "zone" on an "object", rather than a material characteristic. On the other hand, it is but one type of rust metal can exhibit. Rusts can be black, red, orange, greenish for copper, or clear. If we use the albedo alpha channel to encode for a rust color, then this "Ageing" rust mask channel can tell where to apply it and how thick. For colored rusts, Ageing acts like an alpha-blend. For clear rust, it acts as thickness of dielectric film. Perhaps it could be used to also add staining to non-metals. The idea is that if Ageing is fully on (1.0), if AgedColor is a color (below 0.75), it will overwrite albedo and set MSpec and Purity to zero. But if AgedColor is clear (1.0), MSpec and Purity will be maxed out. How this would look on non-metals I don't know and at least for now I don't care.

Facebook event for learning the Gaulish language (in French): SATURDAY, FEBRUARY 27, 2021 AT 19 UTC Celtica - Rencontres Hivernales Free · Facebook Live https://www.facebook.com/events/753715408910273/

Do I really have to repeat this? I opened this thread to make this exact point, it's nothing about resources and balance, it's about game experience and realism. Camels have weaknesses, I agree, I never said they are unbalanced, I just said they are part of a notorious combo... everybody knows that. Anyway, noone deploys swordmen to counter pikes. Apart from anti-siege missions, melee units are generally regarded just as target dummys, and that's where pikemen excel.

Man Playing Trombone on Motorbike.mp4

illustration of a warrior with a shield based on the Salisbury hoard, a sword based on the hilt from Hod Hill and on the scabbard from Isleham and finally the shield from Leicestershire on the side. Note that the warrior is also carrying a javelin with a bonehead. Finally, this artist is producing a lot of fantasy material but I like the bodypainting of the warrior: https://www.deviantart.com/dewitteillustration/art/Warhammer-Albion-Brightwoad-Bearer-794994101

I know it aint my call, but imho there doesn't need to be another non skiritai hoplite if you pick Agis. From a gameplay standpoint, (not a historical one) it makes this risk/reward of picking Agis more clear. If you know you can boom and build more troops than usual, then pick Agis. If you aren't confident that you'll have the time to build a large force, don't pick Agis. Including another hoplite makes this less risky, and kinda diminishes the gravity of the gameplay choice.

They probably should be unarmoured; Caesar describes them as running along and fighting in tandem with cavalry.

https://museum.wales/collections/online/object/bba3484d-6428-3bb9-8423-9342623ac868/Early-Iron-Age-bronze-helmet/?field0=string&value0=cerrigydrudion&field1=with_images&value1=on&index=1 Could be a champion helmet, i think it would fit the chariot unit (Would look out of place on the armored champion swordsman).