Leaderboard

Yes, I think the game could use more unit specific technologies. I think it is too easy to just fully upgrade all units, rather than pick and choose upgrades strategically. If we could assemble a chart of these upgrades (unit type in rows, phase 2 and 3 tiers in the columns with price for each listed) I think these upgrades should be pretty impactful, but also very expensive ( @BreakfastBurrito_007 suggested prices are fine I think, but if its a particularly strong upgrade, the price could be increased a necessary) they also shouldn't outshine the blacksmith techs too much.

Hi everybody, no version update here, just a little piece of information from the author of the LocalRatings mod (me). The next LocalRatings version (v0.26.1) will be released as soon as the new 0 A.D. Alpha 26 is out. I am impatient to play the new Alpha26 and to see how players' statistics change. As you may know, there will be a new civilization, the Han Chinese and it will be interesting to see how players perform with it. And speaking of civilizations... here's a preview of what you will find in the next LocalRatings version! Yes, per-civ statistics. Cool, isn't it? This is one of many new changes and features I have been working on. It will help giving a more concrete idea on civilization balance and I'm very curious to see what the Han Chinese civilization will reveal! I will provide a full list of new features when the release day comes. For the moment, if any of you wants to try it in advance, you can download the zip file of the development version (or download it manually from the GitLab page). It runs on both A25 and A26. I appreciate any feedback, in particular regarding the new explanatory page, that can be opened from the "About Local Ratings" button on the top of the page. Surely more content can be added and the English might not be perfect (my mother tongue is not English), so I appreciate any suggestion in that sense. Other type of feedback is welcome too. Should you have any thought, feel free to send me a private message. Thanks and... see you on A26!

Hey folks, To get the hang of things here is the model and texture for the european bison. I worked from a 3000 tri model and a 2k complete texture and for the game the I tried to follow the bovidae specs found in the game file. I more than welcome feedback on any aspect. I got the textures from wiki commons and can provide the originals. I think I the back legs should be higher for the european bison but really after tweaking I could't tell. Engine compliant (i hope) version. 574 triangles, a slight more than the bovidae Eye candy hp and 2k texture version The files themselves Source Texture, used a mix of those.

There are some optimizations that could be done according to @vladislavbelov

XMBs are binary versions of XMLs. They aren't necessarily smaller, but they are more efficient for the engine. XMBs should not interfere with an XML that you mod. Your mod should overwrite them.

@Sevda, in biome like Eurasian Steppe, it looks like those ground trees are completely removed, just to know, was it intentional? or you are working on it

when two mods that focuses on GUI modifications are enabled at a time, the one that was enabled last overwrites the one that was enabled first, so literally all mods overwrites the actual 0ad files provided its the same files you are modifying in your mod folder. What is causing this is, i think BoobGUI added those squares in a different file whiles God's Eye uses different approach so it doesn't override. Best thing to do in this case is to either remove the star or square from the code manually if you want to run starGui with BoonGui. Some feature "may" be overridden in relation to the mod you enabled last if both mods modifies the same file

Could we maybe get a different icon/portrait for the Harmya? That pair doesn't really tell me anything like palace/royalty. @wowgetoffyourcellphone

@seehat a first glance the issue does not seem to be related with the LocalRatings mod, but arising from somewhere else. I am not using any of the mods you listed but I'll give them a look to see where the issue is originated. One thing you can try to do is to run mods in a different order, 0 A.D. allows to do that (from the Mod Selection page). If this works for you, please leave a comment, other people might be affected too.

by all means we can give them a different name and bring them back e.g. infantry_special_swordsman_b Just the standard naming makes problems

thoughts on this nerf? 30 pierce per 3 sec -> 28 pierce per 3 sec 10 dps -> 9.33 dps

@seeh please disable BoonGUI when using StarGUI. They are incompatible with each other and will cause funny effects. So far the mod only aims at Mainland, temperate biome. More will come later. The green trees exist because I can't find their model so cannot turn them purple, otherwise everything would be purple. I missed the fig trees... thanks for pointing that out. Which map is that?

thanks for your work again @Sevda. i bit wondering about the tree colors. other colors really interessting mainly i want to promote 0ad usage, that more people use it, and that it's easy to use. I understand that you see an opportunity for a new game here and think it's good. but I hope that you can do your development in such a way that you can serve both needs at the same time. UPDATE1: nevertheless i will do stay a while longer with version 7. just for trying it. see how i feel with it in ohter words i could say i in the phase of a beginner with version 7 UPDATE2: i needet reAdd mod boonGui bit later and it works then for me UPDATE3: i needet reAdd mod customrating bit later and it works then for me (seems if mods are overwriten not work like expected it helps sometimes do reanable them again ) in my test colors of trees was a bit strange. maybe works not good with boonGui? may see my first test: whey some tree are blue and some green? is this useful?

Amazing photo! Even the light sabre can be seen hanging on his belt. To the Romans: 'These are not the Judeans you are looking for.'

INTRO: To recap, the "psychic" shader is abandoned; it will never happen. During discussions in that thread, it was agreed that the way to go is to complete the eye-candy "metal detecting" shader (which now detects human skin, as well, and applies dielectric shimmer to it) and keep it as a better shader for existing art assets. This shader is now complete and ready for review and adoption. I include here how I described it in the D3555 update: The Next Shader last mentioned is the subject of this forum topic. New art assets will NOT need re-interpretation by the shader; no need for "detections" of materials; and it will embrace a more comprehensive texture stack capable of specifying all the important parameters needed to describe a material, such as metal/non-metal, metallic specularity in the case of a metal; index of refraction and surface purity in the case of a non-metal. We should also make sure that each channel has appropriate bit depth as per the criticality of its value accuracy or resolution. For example, specular power, in my experience, is a parameter well worth of its own texture channel, and it needs good resolution, as our eyes are quite sensitive to subtle changes in specular power across a surface. Other channels are less critical, such as rgb diffuse color. Another goal I'm setting for myself, with the new shader(s) is to reduce their number by making them capable of serving all the needs provided by a multitude of shaders presently. Another goal of mine is to get rid of as many conditional compilation switches from the shaders, with the following criteria: Conditional compilation is okay to have when it pertains to user settings in graphics options, which are settings affecting all materials generally. Conditional compilation is NOT okay to change compilation per-object or per-draw call, based on object parameters. Why? For one thing, the confusing rats' nest of switches in the shader becomes intractable. For another, it is effectively changing the shader from one call to the next, causing shader reloads, which are expensive in terms of performance. My tentative ambition is to produce two shaders: one for solids, and one for transparencies (excluding water; the current water shader is beautiful; I mean "glass" literally). SHADER CAPABILITIES (FOR ARTISTS): Without getting too technical, the "Next Shader" we call it for now, will be able to depict a wide range of materials realistically. If you want a vase made of terracotta, there will be a way to produce a terracotta look. If you want a simple paint, or a high gloss paint, or a painted surface with a clear varnish on top, you will be able to specify that exactly. The look of glossy plant leaves, the natural sheen of human skin in the sun, all of these will be distinctly representable. Cotton clothes, silk clothes, leather, granite... And there will be a huge library of materials that all artists can draw from, so that all artists are working on an equal footing vis a vis, for example, the albedo of the the assets produced. For an example of where albedo is not consistent, at present, Ptolemaic women have a good skin tone, but Greek and Roman women's skins are so white they saturate when they are in the sun, even as other assets look too dark. This kind of inconsistency will be avoided. You may notice I have not mentioned metals. The reason for that is that metals CAN be represented correctly by the current shaders using diffuse and specular colors, but hardly a soul on this planet knows how to do it right. So metallic representation will not be a "new" capability, per se; but inclusion of most metals in the materials library will be. And the most important feature of this shader is that it will be physics- and optics-based; not a bunch of manually adjusted steampunk data pipes and hacks. However, it is important to state what it will NOT be capable of: Although it will try to have some clever tricks to achieve things like specular occlusion (reflections of objects blocking the environment), it is not intended to be a ray-tracing shader. It will NOT use auto-updating environment boxes with moving ground reflections or anything of the sort. There's better things to spend GPU cycles on. The ground reflection will just be a flat color. It will NOT feature sub-surface scattering. Too expensive, and there are some cheap hacks that can be made to look almost like SSS. It will NOT feature second light bounces. Too expensive for what it's worth. It will NOT include things like hair or other complex material-specific shading. It will NOT support anisotropic filtering. Vynil records had not been invented yet, in the first century, anyways Possible new features: Not only shadows (as the present shader does) but also environmental shadowing (this may need props). Detail textures: These are textures that typically contain tile-able noise, and which are mapped to repeat over large surfaces, such as a map, modulating the diffuse texture, or the normalmap, or the AO, at a very low gain, almost unnoticeable, but make it seem like the textures used are of much greater resolution than they are. That's why they are called "detail textures; they would seem to "add detail". Very effective trick, but they need to have their gain modulated from the main texture via a texture channel, otherwise their monotony can make them noticeable. Long story. Possible test version of the shader, for artists, that detects impossible or unlikely material representations and shows them red or purple on the screen. Possibly have HDR... One thing this shader will NOT indulge on: Screen-space ambient occlusion. These are algorithms that produce a fake hint of ambient occlusion by iterative screen-space blurs of Z depth -tricks. They are HACKS. In my next post I will discuss texture packing, and give a few random examples for how materials will be represented. OTHER... I paste below a couple of posts from the "psychic" shader as a way of not losing them, as they are relevant here: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem Number 1: One issue that I seem to be the only guy in the world to ever have pondered, is the fact that the Sun is NOT a point-source; it has a size. I don't mean the real size, but the apparent size: its diameter, in degrees. If we were on Mercury, it would be 1.4 degrees. From Venus, (if you could see through the darned clouds), it would be 0.8 deg. From Mars it looks a tiny 0.4 degrees diameter. From Earth: 0.53 degrees. This should be taken into account in Phong specular shading. The Phong light spot distribution (which is a hack; it is NOT physics-based) is (R dot V)^n, where R is the reflection vector, V is the view vector, the dot operation yields the cosine of the angle between them, and n is the specular power of the surface, where 5 is very rough, 50 is kind of egg-shell, and 500 is pretty smooth. Given an angle between between our eye vector and the ray of light reflecting from the spot we are looking at, if the alignment is perfect, the cosine of 0 degrees is 1, and so we see maximal reflection. If the angle is not zero, but it is small, say 1 degree, the cosine of 1 degree is 0.9998477, a very small decrement from 1.0, but if the specular power of the material finish is 1000 (very polished), the reflection at 1 degree will fall by 14% from the 0 degree spot-on. But with a perfect mirror, --a spec-power of infinity--, a 1 degree deviation (or any deviation at all) causes the reflected light to fall to zero. But that is assuming a point-source light... If what is reflecting off a surface is not a point source, however, the minimum specular highlight spot size is the size of our light source. This can be modeled by limiting our specular power to the power that would produce that same spot size from a point source. But this limiting should be smooth; not sharp... Problem Number 2: This is horrendous graphical mistake I keep seeing again and again: As the specular power of a surface finish varies, specular spotlights change in size, and that is correct; but the intensity of the light should vary with the inverse of the spotlight's size in terms of solid angle. If the reflected light is not so modulated, it means that a rough surface reflects more light (more Watts or Candelas) than a smooth surface, all other things being the same, which is absurd. As the specular spots get bigger, they should get dimmer; as they get smaller, they should get brighter. But the question will immediately come up: "Won't that cause saturation for small spot-lights?" The answer is yes, of course it may. So what? That's not the problem of the optics algorithm; it is a hardware limitation, and there are many ways to deal with it... You can take a saturated, super-bright reflection of the sun off a sword, and spread it around the screen like a lens-flare; you can dim the whole screen to simulate your own temporary blindness... Whatever we do, it is an after-processing; it is not the business of the rendering pipeline to take care of hardware limitations. Our light model is linear, as it should be, and as physics-based as we can get away with. If a light value is 100 times greater than the screen can display, so be it! Looking at the reflection of the sun off a chromed, smooth surface is not much less bright than looking at the sun directly. Of course it cannot be represented. Again, so what?! So the question is, how much should we set the brightness multiplier as specular power goes up? And also, at what specular power should the brightness multiplier be 1? Research: The two problems have a common underlying problem, namely, finding formulas that relate specular powers to spot sizes, where the latter need to be expressed in terms of conical half-angle and solid angle. If we define the "size" of a specular highlight as the angle at which the reflection's intensity falls by 50%, then for spec power = 1, using Phong shading, (R dot V)^n, the angle is where R dot V falls to 0.5. R dot V is the cosine of the angle, so the angle is, SpotlightRadius(power=1) = arccos( 0.5 ) = 60 degrees. Note that the distribution is equivalent to diffuse shading, except that diffuse shading falls to half intensity at 60 degrees from the spot where the surface normal and the light vector align, whereas a specular power of 1 spotlight falls to half intensity at 60 degrees from the mid vector between the light and view vectors, to the surface normal. But the overall distributions are equivalent. We can right away answer one of our questions above, and say that, Specular power of 1.0 should have a light adjustment multiplier of 1.0 How this multiplier should increase with specular power is yet to be found... But so, to continue, what should be our formula for spotlight radius as a function of specular power? For a perfectly reflective material, Ispec/Iincident = (R dot V)^n If we care about the 50% fall-off point, we can write, 0.5 = (R dot V)^n (R dot V) = 0.5^(1/n) So our spot size, in radians radius terms SpotRadius = arccos( 0.5^(1/n) ) We are making progress! Now, specular power to solid angle: Measured in steradians, the formula for solid angle from cone half-angle (radial angle) is, omega = 2pi * (1 - cos(tetha)) But there are 2pi steradians in a hemisphere, so, measured in hemispheres, the formula becomes, omega = 1 - cos(tetha) If we substitute our spot radius formula above, we get omega = 1 - cos( arccos( 0.5^(1/n) ) ) which simplifies to, SpotSizeInHemispheres = 1 - 0.5^(1/n) where n is the specular power. Now we are REALLY making progress... Our adjustment factor for specular spotlights should be inversely proportional to the solid angle of the spots, so, AdjFactor = k * 1 / ( 1 - 0.5^(1/n) ) with a k to be determined such that AdjFactor is 1 when spec power is 1. What does our right-hand side yield at power 1? 1/1 = 1. 0.5^1 = 0.5. 1 - 0.5 = 0.5. 1/0.5 = 2. So k needs to be 0.5 So, our final formula is, BrightnessAdjustmentFactor = 0.5 / ( 1 - 0.5^(1/n) ) where n is specular power. Almost done. One final magic ring we need to find is what is the shininess equivalent for the Sun's apparent size. We know that its apparent diameter is 0.53 degrees. So, its apparent radius is 0.265 degrees. Multiply by pi/180 and... SunApparentRadius = 0.004625 radians Good to know, but we need a formula to translate that into a shininess equivalent. Well, we just need to flip our second formula around. We said, SpotRadius(radians) = arccos( 0.5^(1/n) ) so, cos( SpotRadius ) = 0.5^(1/n) ln( cos(SpotRadius) ) = ln( 0.5^(1/n) ) ln( cos(SpotRadius) ) = (1/n) * ln( 0.5 ) n = ln( 0.5 ) / ln( cos(SpotRadius) ) Plugging in our value, ln( 0.5 ) = -0.69314718 cos( 0.004625 radians ) = 0.99998930471 ln( cos( 0.004625 radians ) ) = -1.0695347 E-5 Finally, SunSizeSpecPwrEquiv = 64808 ... (make that 65k ) So, we really don't need to be concerned, except for ridiculously high spec power surfaces; but it's good to know, finally. EDIT: Just so you know, when I worked on this, decades ago, I obviously made a huge math error somewhere, and I ended up with a Sun size derived specular power limitation to about 70 I think it was. I smooth-limited incoming specular power by computing n = n*70/(n+70). I knew it was wrong; the spotlights on flat surfaces were huge. What was cool about it was the perfect circular shape of those highlights. It was like looking at a reflection of the Sun, literally; except that it was so big it looked like I was looking at this reflection through a telescope. EDIT2: One thing to notice here is the absurd non-linearity of the relevance of spec power; maybe we should consider encoding the inverse of the square root of spec power, instead. This way we have a way to express infinite (perfect surface; what's wrong with that?) by writing 0. We can express the maximum shimmery surface as 1, to get power 1. At 0.5 we get 4. At 0.1 we get 100. We could even encode fourth root of 1/n. Edited Sunday at 09:39 by DanW58 @hyperion Another way to go about it, that you might care to consider, is to incorporate this shader now (if it works with all existing assets), but to also include a new shader with NO metal detection, and encourage artists to target the new shader. Different texture stack, channels for spec power, index of refraction and detail texture modulation, etc. So this shader and the new one would be totally incompatible, textures-wise, and even uniforms-wise. This path removes the concern about people getting unexpected results with new models. New models would NOT target the metal detection shader. It would be against the law. I could come up with the new shader in a couple of days; I got most of the code already. So, even if there are no assets using them, people can start targetting it before version 25. In this case, I'd cancel the "psychic" shader project. Channels needed for a Good shader: Specular texture: rgba with 8-bit alpha specular red specular green specular blue specular_power (1 to infinity, encoded as fourth root of 1/spec_power)is_metal Diffuse texture: rgba with 1-bit alpha (rgb encoding <metals> / <non-metals>) diffuse red / purity_of_surface ((0.9 means 10% of surface is diffuse particles exposed, for plastics)) diffuse green / index_of_refraction (0~4 range) ((1~4, really, but reserve 0 for metals)) diffuse blue / detail_texture_modulator is_metal Normalmap: rgb(a) u v w optional height, for parallax Getting Blender to produce them should be no issue. Note that I've inverted the first and second textures, specular first, with the diffuse becoming optional... For metals, the first texture alone would suffice, as diffuse can be calculated from specular color in the shader. Artists who want to depict dirt or rust on the metal, they can provide the diffuse texture, of course; but in the absence of diffuse the shader would treat specular as metal color and auto the diffuse. Also, when providing diffuse texture for a metal, it could be understood to blend with autogenerated metallic diffuse; so you only need to paint a bit of rust here, a bit of green mold there, on a black background, and the shader will replace black with metal diffuse color.

I personally like it as well. Now we just need animations. I asked people on Social Media maybe someone will step up.

Yes ! Finally, working. Thanks for the feedback, and keep it coming. The File : europeanbison.rar Ok, next time it's going to be quicker. Had to tweak the tail to avoid backface culling, and the overall size of the beast was changed to feel more like a true bison. Cleaned the vertex groups and the xml. Everything is fineeeee. The template is based on the muskox. And added an icon trying to emulate the style of the other ones with the halo. I'll just for the sake of it. Also here is some eyecandy. Edit: also the blend file eurpeanBison_shared.rar

Back ! So the bison is updated, new texture, more detail. Bovidae skeleton to conform to the rest, sorry folks I'm not still cut to do animation. I almost choked myself. Now I don't get why I can't import it into Alas. The file with I think the correct hierarchy: public.rar I can't make them work, gosh darn it. I don't get it. And the error message is really generic, can't load. Someone wants to help an artist in need ?

Okay, got it. Took me an hour but I managed to get the model in game after modifying with the feedback. So the back is more flat and the legs a bit higher (minor tweaks). At first I took the scale of the bull but then I read that speciemens tend to be 1.8m to 2.2m hight so here is a ingame screenshot from the Atlas. Added the horse actor and iberian hero swordsman as a scale. Also there are the files in the respectives folders. I just used copy paste on the main art in mods/public for my convienience. I don't know how you want to receive it. About the naming convention, I went for animal_latin-name_variantion . Should it be otherwise? Lastly, I have two questions: - I got that I can rotate entities in the atlas but I don't know how to make them, any help, any use? - Animations are already listed even if the model doesn't have those. Is it because they are limited, and should I fit mine into those already describe (like th hawk that 'walks' by flying) ? art.zip

It looks promising! Yes, Wikimedia Commons usually has many nice images, in this case https://commons.wikimedia.org/wiki/Category:Bison_bonasus I'm certainly no expert, but to me it seems wisents have a more-or-less horizontal back and belly and a large hump at their shoulders: Yours, in contrast, seems to have an upward-pointing back and belly and two humps but a hole at the shoulders:

Thank you. I'll add the animation during the week if the model is validated. I imported the .dae from the bovidae to try to get the same skeleton but I'm wondering if I can't make a more versatile quadripede skeleton as I intend to model more animals from the list?

Which biome? Using the latest version, all fruits are shown in Mainland Balanced, identical to mainland.