Leaderboard

Okay, I think I got it; hope it works. Includes metal and skin detection. Metal is enhanced by matching hue of diffuse and specular and ensuring that diffuse saturation is higher than specular's, but not much higher; and that specular value is higher than diffuse. Skin is enhanced by adding partial Fresnel specularity to it, of low gloss (skin is colored in diffuse, but shimmer-reflects white), and by adding a hack to make it seem like it gives a hint of red translucency. Unfortunately, skin and metal are very hard to distinguish by color, and sometimes they cross into each other. Also, patches of grass and other things may detect as skin, or as metal; but they don't look bad; just a bit shinier than they should be. Something no other shader has is a mega-hack to compute specular occlusion. That is, figure out if a sight ray reflecting off a shiny surface should reflect sky, or an object nearby. The common wisdom is that you need real time ray-tracing to get specular occlusion. Well, I got it to work based on the baked ambient occlusion. If you look at shiny pots or shields inside shady patios, you can see a limited reflection of sky on them that keeps facing you as you turn around the building. Also included is the latest water shader, with more realistic Fresnel specular and refractive factors, and with a hack to make coasts look wet. The terrains shader detects soils or tilings that are too white, and tones them down while increasing contrast. Ambient occlusion (ambient light self-shadowing) of buildings is better displayed. The material xml files are changed, in fact, to standardize the gain for ambient occlusion bakings to 1.0, rather than have manually adjusted gains everywhere. Also in the terrains shader there is a blue-tinted upward bias on ambient light, as most ambient light comes from above, and has a blue tint due to atmospheric scattering. For perspective, there are many shaders out there that do things like Fresnel; specular highlights, environment mapping and whatnot; however, they need to be told, via textures, what to do. The peculiar thing about this metal and skin shader is that it figures out what to do without being told... It's a way to enjoy a tiny hint of what will be coming next, without the work of adding new textures and all that. If there's any problems, shader not compiling, whatever, please report it to this thread. You may need to turn all the graphics options to maximum; I haven't even tested it non-maxed-out. metal_shader_set.pyromod

Hi, this topic is not used to explain a problem, but a big congratulations to Wildfire Team for the Amazing new Alpha 24! Keep it going! Don't give up!

Bueno/as días/tardes Antes que nada quería agradecer y felicitar a los/las desarrolladores/as por el lanzamiento del nuevo alfa "24" Entrando ya en temario , aquí unos bocetos de edificios mayas del preclásico; (Que haya hecho de 2 a 4 modelos para cada edificio por la diversidad de las Ciudades Estado y restos arqueológicos espero que no sea un inconveniente) -almacén maya ; -corral maya; -granja o galerón maya ; -aldea campesina maya ; -muralla y portón mayas ; (los mayas usaban una "especie de murallas" de capas de tierras sobrepuestas unas encima de otras sobre una base de rocas y recubiertas posiblemente de una empalizada de madera ,sobre todo en el clásico temprano-preclásico tardío pero las defensas más comunes eran fosos con agua [no creé los fosos porque no se como crearlos ] o construían las ciudades aprovechando la defensas geográficas como barrancos ...) Disculpen las molestias*

Some suggestions: 1. Projectile trails Right now projectiles are hard to see, especially when zoomed out. This is exacerbated by projectiles not having impact sounds, and the audio is out of sync so sometimes you have silent arrows or sounds that play midflight. Another easy way to fix this is by making the projectiles bigger (and I mean much bigger). 2. "I need [resource]" button for MP Perhaps this can further be expanded into a 'Give [resource]' button prompt (100 default, 500 shift click) - so you don't have to open the diplomacy panel - and/or a chat wheel system, with "Yes", "No", "Help", "Attacking", etc. 3. Visible production/research progress bar below the capture point IIRC this was in AoE 2 DE and I find this feature quite nice. Also useful to tell which buildings are idle thus maximizing APM count as well. In MP I see people queueing 5 women then forgetting about it. 4. Flags for unit destination Unless you're queue building houses it's hard to tell where your units are going. We already have flags for garrison so I think we can use that. Attached are what they could look like:

SUCCESS!!!! Kind of ... Got the coasts to look wet. But the artifact I wrote about in the previous post is still there.

Not really a market - but a little "Hofladen" ...

My work on the water_high.fs shader is done; and it is released as a mod together with the "metal shader" (metal and skin, really), and the terrain shader that reins in ultra-bright textures and adds anisotropic ambient light. All of that as a package is available as a pyromod package in this forum post: The "water patch" is also updated by itself here: https://code.wildfiregames.com/D3603#157271 So, getting back to the new shader work, as I was saying many posts ago, what remains is really very little, and I'm going to include it below, though it's probably subject to change; none of this is compiling yet... // Main algorithm begins. vec3 incident_spec_RGBlight = incident_specular_light(v3_mod_normal,gndColor,Mat_RGB_diff,Obj_RGB_ao,RGBlight_bnormSky,Mat_SpecularPower,reflecting_ground ); vec3 fresnel_refl_color = SchlickApproximateReflectionCoefficient( is_metal, eyeDotNormal, 1.0, IndexOfRefraction ); vec3 incident_diff_RGBlight = incident_diffuse_light(gndColor,fresnel_refl_color,ao_color,aniso_amb,normal_hits_the_ground,rayDotNormal); vec3 color = specularly_reflected_light( Mat_RGB_spec, fresnel_refl_color, is_metal, incident_spec_RGBlight ); color = color + diffusely_reflected_light( Mat_RGB_diff, incident_diff_RGBlight ); // Main algorithm ends. #if USE_SPECULAR_MAP && USE_SELF_LIGHT color = mix(texdiffuse, color, specular.a); #endif color = applyFog(color); color *= getLOS(); gl_FragColor.rgb = mix(color,sqrt(color),1.0/3.0); // Re-gamma implicit de-gamma. } What I want to do next is dive deeply into the routines I never described or justified before. I call your attention to the fact that I have four functions that sort of work together. Two of them are for incoming light, namely incident_specular_light() and incident_diffuse_light(); and two "outcedent?" light returning functions, namely specularly_reflected_light() and diffusely_reflected_light(). These four functions are the heart of the shader. It is immensely useful to separate diffuse from specular completely, and it is even more useful to separate incident light RGB, material RGB reflectance, and reflected RGB light. Incident light multiplied by material color equals reflected light. You can add or mix light values; and you can mix or intermodulate reflective values; but you cannot mix or add a light and a reflectance, even if both are "RGB". This is why I like to tag my variable names with RGB or RGBlight... RGB alone stands for a reflectance, a material attribute, and its channels must span from 0.0 to 1.0, as materials can't reflect more light than what light hits them. But RGBlight values can go to the millions; there's no theoretical limit. Now, if you are not familiar with computer graphics, you might be asking "incoming specular?!?! ... Isn't light just light?". Yes: In the real world photons leave light sources and travel at the speed of light to meet their destiny by knocking an electron somewhere, and along the way get reflected diffusely or specularly, and they would not know the difference after it happened, never mind before. But a simulation of photons bouncing around is called a "photon mapper" and they are very good for some things, such as baking ambient illumination in complex scenes, but they make terrible solutions for real-time computer graphics. Heck, even slow and ponderous ray-tracers aren't photon mappers. What most computer graphics does is go the other way: from the eye to the light; yes, backwards. It is far cheaper to do so. And the difference between a real-time shader solution, and a slow ray-tracer, is basically the number and quality of bounces. Most real time graphics I would say computes "one point one bounces". First bounce being diffuse or specular. The second bounce is done where it is cheap to do by some humongous hack; and it is usually a diffuse second bounce from a diffuse first bounce; specularity be dammed. Add to that environment cubes and ambient occlusion bakes, and all together add up to about one tenth of a second bounce. Ray-tracers can go 7 bounces deep, if you are sure you'll live forever. But so we go from the eye, through the pixel in the screen we are rendering, into the virtual 3D scene, and hit the point on an object we are displaying currently. At that point we reflect this (backwards) "eye ray", bounce it off the object, as if it was a mirror, to see what direction we should reflect specular-ly. Once we know the direction, we can add up light coming from that direction; and that is what I mean by incident_specular_light(). Diffuse light coming to the eye from that point on the object does not need a reflection direction; it only needs to compute light arriving to that point from any directions, and how they angle relative to the surface normal. So, this sum of diffuse light from all directions is the incident_diffuse_light(). There's a few tricks to all this that very few shader programmers get right. For example, incident diffuse light includes environmental (ambient) light, and light from any light sources, typically the Sun. Now, say we have an algorithm to compute where shadows fall... those are computed from the Sun, so it makes sense to switch incident Sun light on and off as per the is_in_shadow() test; but it would make no sense to modulate ambient light by shadow test. That's not a mistake commonly done; but one mistake very commonly done is to modulate specular reflection by the shadow test, and that is a terrible mistake that looks awful, but few people can tell what's wrong with the rendering. Imagine you are in a room, looking at yourself on a mirror, and sunlight is hitting the mirror. Now your room-mate comes and makes a shadow falling on the mirror. Does that affect your image on the mirror? Of course not; it is only if the shadow falls on you that your image in the mirror changes. Some shader programmers are careful about that, and yet fail to be careful about a deeper subltelty: It would be a mistake to say that the is_in_shadow() test has NO place in the specular pipeline. Why? Because the specular pipeline includes two things: Environment mapping, where you read the pre-baked sky color that should be reflected, and Phong shading, where you add the Sun's reflection. The Sun's reflection will NOT be there if the point is in shadow. Another VERY tricky part is where the specular and diffuse pipelines sort of get joined at the hip, and that is with two-layer materials, such as paints, plastics, skin and green plant material. It may seem hopeless to try to separate them given that light that refracts into the transparent layer bounces off the underlying opaque material and then wants to come out again, but part of it is reflected back down, to bounce and be colored yet again by the opaque base. However, the multiple attempts at refracting back out can be accounted for by a single factor to multiply diffuse reflection by. In traditional Fresnel modelling of glossy paint, fresnel_reflection_factor = getFresnelReflectivity( ray, normal, n1, n2 ); fresnel_refraction_factor = 1.0 - fresnel_reflection_factor; Most people leave it at that. What I do is, when I'm in a hurry, fresnel_refraction_factor = fresnel_refraction_factor * fresnel_refraction_factor; Why? Because it takes as much effort for light to refract out as it was to refract in, assuming a specular bounce, of course, but what better can we do? Well, we CAN do better by considering that light that bounces back in gets colored again by the diffuse color base, and makes another run for the surface; so you have an infinite series, and if you solve it it becomes a very simple fractional formula. For a simple example, 1 + 1/2 + 1/4 + 1/8 + 1/16 .... = Sum[x=0~inf]{ 1/2^x } = 2 But anyways, my point is that you CAN pre-calculate the fresnel factor for diffuse from a light source, as well as for diffuse from the environment map, and the two pipes don't need to exchange data between them. In the next posts I will discuss each of these four routines. Why? Just so that there is documentation on them somewhere to be found. Unlike C and C++, where you are encouraged (in most communities, anyways...) to write a lot of comments; in glsl you are not so encouraged, since the file is compiled on the fly, at runtime, by the videocard's driver. Too many comments would increase compile time.

Se me olvidaron las referencias; REFERENCIAS; Ciudades ; -Ciudades de la cuenca del Mirador- Ciudad de El Lechugal ; -ciudades de la cuenca del mirador- ciudad de El Pesquero (templo) ; -ciudades de la cuenca Del Mirador- Ciudad de El Pesquero ; -ciudades de la cuenca del Mirador- ciudad de El Porvenir ; -ciudades de la cuenca del mirador- ciudad de Nakbé ; -ciudades de la cuenca del mirador- Ciudad de Tamazul ; -ciudades de la Cuenca Del Mirador- Ciudad de Tintal ; -ciudades de la cuenca Del Mirador- ciudad de Wakná ; - ciudades de la cuenca Del Mirador- ciudad de Xulnal; -ciudades de la cuenca del mirador- ciudad ejemplo preclásico medio ; -Ciudades de la cuenca del mirador- Mapa de ciudades ; -Defensas mayas; Disculpen las molestias*

Update: As probably all of you know already, the landing of Perseverence was a complete success. Not that it was glitch-free... There are debris that come out with the parachute deploy that were not supposed to be there... Something broke off the spacecraft; probably not too important. Also, when the heatshield falls away, it carries with it a spring it wasn't supposed be carrying away with it, but no harm anyways. And how do we know all this? Because unlike previous missions, this one was programmed to take video of the whole descent and landing, and we have the video, and it's awsome. But it was supposed to also record sound, but the microphone failed. But the back-up microphone is apparently working, and we got sound of Martian wind. Anyways, here's a video by this great science video youtuber, Anton, with a rough update of what's up with Perseverence: If you need to see the few things that went wrong with it, check out Scott Manley's video on it: And here's a long-awaited update on Schroedinger's Cat, by Science babe Sabine: --not that I agree; this "Superdeterminism" stuff sounds like a joke to me. Why do people keep trying to come up with new "interpretations" when Bell's Theorem already *proved* there's no need for anything beyond what QM equations describe?

Hello, I want to inaugurate this new A24 replay section by dumping a few of my multiplayer replays, showcasing the new unit balance and the increased diversity of units that can be reliably trained. I have a feeling sometimes players don't make use of all tools available to them. Champions, trade and siege (3v3).zip This teamgame showcases a lot of different unit types, but notably champions swordsmen, some champion archers, some trading, catapult+ballistas attack, and camel archer lategame composition on the other side. Roman sword cavalry champions (3v3).zip Features roman sword cavalry champions, quite a powerful unit. Cavalry and champions (3v3).zip Features sword infantry champions from Seleucids, cavalry compositions from mauryan and ibers (with a few firecav champions) Archer cavalry and roman champion cav (3v3).zip A teamgame that shows those 2 units in action. Valihrant (Koushites) vs Feldfeld (Mauryas).zip Small rush early game. Features town phase CC expansion, archers and elephant archers from Maurya, against archers and nuba skirmisher cavalry from Koushites Valihrant (Mauryas) vs Feldfeld (Macedonians).zip Features town phase CC expansion from macedonians. Skirmishers and champion infantry spearmen from mace against chariot archer champions from maur. Valihrant (Macedonians) vs Feldfeld (Athenians).zip Features a moderate early game rush. CC expansion from macedonians in the town to city phase transition. Gastraphetes from mace against slingers + ballistas from athenians. Feldfeld (Ptolemies) vs cl2488 (Ptolemies).zip Features mercenary swordsmen and mostly slingers against pikemen and slingers. StarAtt (Iberians) vs Feldfeld (Carthaginans).zip Features mercenary cavalry from Carthage. ElDragon (Kushites) vs Feldfeld (Carthaginans).zip Features village phase expansion from Carthage, with a composition of Sacred Band infantry supported by archers later. Archers and pikemen/spearmen from Kushites. You can download all replays bundled here: Feldfeld's replay dump.zip Hopefully that can address a few of the complaints I have read about the new version. For example, the diversity between civilizations has been reduced, yes, however keep in mind to compensate that the new balance between units should make some civilization specific strategies (eg. a unique champion, mercenaries) viable whereas it was not the case in A23 (which was notably a lot of slinger spam). About archers being OP: yes it is true that they have a very good accuracy, possibly making them OP, but they are less efficient than other ranged units against melee units (which have been improved in this version). Remeber there are other options than making citizen soldiers ranged units. Of course this doesn't mean we won't find OP units in the future. Champion melee cavalry look quite strong, champion archer cavalry maybe too.

I followed the instructions on your main page but Debian 10 won't update to version 24, it only sees v23. I made sure to update the repo before attempting to download but all I see is version 23. Am I missing something or is the game not yet available on Debian Buster?

Here are some results from tests done one year ago. #Protocol - 50 games 1v1 on mainland with a set of predefined (random) seeds, for each couple of civs, both players positions test - players are AI - tested on a fork of zeroad #Win-Loss results For each couple of civs, we compute the difference between number of wins and number of losses. In that context: - rome, brit, gaul are far ahead - kush, mace, pers are far behind There is perhaps an high civ unbalance or it is related to the way the AI use them. #Trading score There is the potential bias that it's easier to trade when wining the game. Pers, despite losing a lot of game, shows high trade income. That reflects there high trading bonus. #Trained support citizen #Trained infantry cavalry ratio From AI point of view : - Brit, sele, ptol look like cavalry civ - Athen, spart look like infantry civ #Siege and champions Elephants are counted as champions. It's strange that mace that is expected to be a siege civ don't produce a lot of siege. Kush and maur don't have siege units. One can notice that maur gained some by capturing an enemy structure. AI may miss something or the civ is too late at phase 3. Enjoy! PS: That's a quick approach, there was some extreme games messing the means.

Any thoughts on this one? Or do you have your own? Disclaimer, this is meant to represent a post-20 minute battle.

I almost missed it, myself. Sounding the heads up, so we all watch it live. https://youtu.be/sty0e6l3Y3Y By the way, the UAE sent a probe to orbit Mars, and it arrived safely a week ago or so, but since it's the UAE that did it, it gets no media attention. It is, however, not just a "we did it" thing; it is full of valuable instruments. https://emiratesmarsmission.ae/

A Screenshot from Blender 2.92.0 - no problems found until now ...

#6074

The first release (https://www.moddb.com/mods/incas-0ad) in the future will be released to the public a mod idealized by @Trinketos (https://github.com/0ADMods/pre-colonial-mod) with these civilizations and with some gameplay changes. I believe that this mod will be from the year 1000 to around 1500 thus involving the Incas, Aztecas and Mayas post classics.

Muy guapos todos

This is off-topic here, but it would be great to have most pre-Columbian American civilizations in a mod. Among them the Inca, who came up with advanced food preservation techniques for their defense. This could be a source of inspiration for expanding gameplay elements. The Inca had very mobile armies moving around "at random" along fronteer territories. The farmers in those regions were instructed to provide food for the armies by burying it in secret locations. It had to last until an army came around, so there were techniques that had to be observed to make sure the food kept fresh until then. I think they invented dry tomatoes and soups you just add water to.

I think that I'm one of the responsibles My original suggestion was to choose from one alliance and stick to them among the rest of the game. Then IRC, the implementation was that embassies were limited to 2, so you could train two of the three factions. Then I think that the limit was increased. But my proposal was more among the lines of AoM minor gods, where you choose a path and you get units and techs, as a special feature of Carthaginians

Works on a24 now

Works on a24 now

Maybe I need to finish #557/D657 I suppose we could have particle trails for slings but it will have a perf hit I guess. I'm not sure how hard those are @Imarok @Angen @Freagarach @wraitii

Great! Thanks for all the patience, and enjoy. This set has the latest water shader in it.

Generally I do this kind of folder setup by making a temporary 'staging' folder somewhere and then replicate the folder structure and copy in my files. Once this is done, you can install this as a mod into your own copy of 0 A.D. and instead of directly modifying game assets, you just modify your 'mod' files instead. If you need to add more files to the scope of the mod, just copy them out of the game files and into your mod and modify there. This is very useful for sound stuff at least, where I can A/B test new and old sounds by disabling the mod, no need to uncomment lines or even move around files. I can imagine you might find the approach useful too. I would start with Stan's mod file, extract the contents and/or install it, and then replace the files in the folder structure he's already made for you with the latest files you've updated. Continue work as usual working only in this mod folder, with the mod installed. When you have a new version for people to check out, pack up as a .zip and upload for everyone to try, no need for fancy archive management.

I like that render @Mr.lie

Also, I was the one who did the rush. It was micro and unit production mismanagement by dakeryas and reza. Once you get ahead, it is easy to rack up kills

@Stan`@Alexandermb@wackyserious@Mr.lie@Sundiata Blender 2.92 is released https://www.blender.org/download/releases/2-92/

Yes, the issue with languages is primarily that not many people are willing to record the voice over lines, and some languages do not yet even have proper translations. Here is the list of voice actor lines: https://trac.wildfiregames.com/wiki/Audio_Voice_List There is also an old list on the forum and much discussion about which words to use: People contributing translations or voice over lines is most welcome. Even if the voice recording quality is poor, it can still be used to show people who have a better recording setup how to pronounce the lines correctly. However, even the official list is somewhat outdated as features like Capture have been added, which do not have words in the lists.

I prefer upgrading the outpost to a sentry tower-like stone (or more wood) building, as in Delenda Est. Agreed, there should be a production trickle or related idle command. The language choices for the Achaemenids were supposed to be Old Persian and Avestan, the latter probably exclusive to the magi. I believe these are just placeholders until a willing voice-over can produce the needed sound files. You mean no siege engines in the Roman siege camp? Thanks for your comments!

I had some ideas, it's not a complete suggestion but maybe i can get the discussion running:) Right now there are only 3 kind of diplomatic relations, which are Neutral, Enemy and Ally. I think it might be nice to add "unknown", as I've seen people many people requesting here on the forum. Further, right now all three diplomatic relations are balanced. Adding uneven relations, like Vassal state / Hegemonic state could add some dynamics to the gameplay. The idea is, that when you have heavily damaged an opponent, you can make him your vassal and focus on other opponents, while still being able to have some control over him. On the other hand the vassal has the opportunity to come back to power in later game. As far as i see in alpha 24 there are three variables to be controlled, which are whether attack is possible, shared vision and shared dropsites. More possible variables could be: Territory invasion: Make it unpossible to move units into another players territory (unless support units). This could also prevent some sneaky moves Continious tribute: Paying a percentage of all gathered resources (not at once, but like out of 10 wood gathered 1 goes to the hegemonic power) Production ban on siege: Make it impossible to produce rams, catapults etc In the end this could look like this: This is only a basic idea, other ideas are welcome:) Allied and team might be one too much, out of Protectorate and vassal state one might be enough too. Historical correctness might be improved. So far all relations only have effects between the two parties, maybe an effect on the relation with others is desired, like abolishing trade with a third party and so on

Hopefully this thread can address a few of the complaints I have read there: I won't go into details about the others yet. Personally I'm fine with the gameplay being slower, including unit movement speed. Sometimes in a23 I had the feeling maps for teamgame were quite small, the enemy could be reached very fast (in bigger map size settings was not an option due to lag). Now with the slower movement this looks more like AoE2 in term of 'map size feeling', and I think this alpha puts more emphasis on map control in general, something I felt was missing in a23. Regarding a balance patch mod, there are a few problems with that. - Potentially difficult to get people to use it - Very easy to disagree with the changes there - Most importantly, it will necessarily diverge from the changes of the new a25 version. First of all, a number of the changes that would go to the balance mod would not be changes that can get in the next version of the game, due to consistency and historical accuracy requirements. Secondly those changes would be more like a patch, and not enhancements to gameplay, which is still an objective for the next version of the game (= more divergence). Thirdly, engine changes can affect how the game is played. All in all, those points will make it so that the balance reached with such a patch will have to be thrown away for the next version of the game, so they could end up not being helpful for tuning the a25 balance. To end this post, I would like to point out that the state of the balance of this a24 version has not been figured out yet (see the thread I linked to have explanations and examples). I also think like @Nescio that we should give it one month or two before being too critical with this new version. There are a few things I don't like of course but all in all I think a24 is an improvement.

Sometimes it's so much fun modelling an eyecandy .... Learning about array, mirroring and so on ...

Believe in the process, the first release that actually accounts for balance taking player experience into consideration will always be controversial. It had to start from somewhere, remember all cav or all champ metas, how is it that different? If you feel a game is slower you can make proposals, e.g. decrease economy requirements overall (buildings/training cost) etc... Granted, 0ad does not make it easy to provide accountable feedback, no continuous testing mechanism or a better platform (forum is too difficult to track and prioritize channels and discussions). Testing dev version requires dealing with SVN some technical prowess, synced rev, etc.. Hopefully with 6-mo cycle it will be more straightforward (though I'd better have a weekly release, make an AppImage for linux, exe for windows built by CI gg). The only thing that has turned me away are the sounds, maybe I'm a bit autistic but I can't absolutely play with those sounds so preeminent in the foreground (unit selection, unit move, fight actions, etc). Maybe I'll play when there is (or I make) a mod to have unit selections/actions sound fader.

Hi, many thanks to everyone involved in the development of 0ad. I enjoy the game very much. If feedback is desired, here is my opinion on the current status (a24 vs a23). Things i like Unit balance (especially bow and ranged Siege weapons) Champions are viable now Quality of life features (especially Building snapping, Hotkey editor) Anti dance, new Cheering Things i don’t like Action sound (fells like quiet war, spooky and unreal, difficult to notice and thus to orientate) less unique gameplay mechanics (Civisation Boni) Accessing different types of siege weapons is too easy and less unique game fells slower, less dynamic (possibly through unit speed and training time) Harder to cavalry rush (cav is too close to target unit for hit and run with new anti dance) Outpost (no outposts vision tec, unit in outpost need more armor) Training several units from several selected buildings (same or different building types) does not always work: When multiple buildings are selected, units are trained in one building, in the buildings in which no training is currently taking place, or in all buildings. Often only one building is used for training, although other selected buildings are empt.

The Delenda Est repo is fully compatible with A24. I just haven't finished hero selection for all civs yet (I have a few civs to go). And I'm debating removing the Noba civ for now until there's a way I can remove them from Random selection.

Heros1. "Touman"; ---------------------------- ----- (Tūmān)2. "Modu”; ------------------------------------ (Mòdún)3. "Laoshang"; -------------------------------- (Jiyu) This information about the Xiongnu (Duileoga) could be applied to this next release. I am willing to help. Alem has ideas about that.

The Village is growing ...

Buenas ; Nuevos bocetos para edificios "Mayas Preclásicos"; (que conste que no he abandonado el desarrollo de Arsacids/Parthia "Arsácidas" y tampoco" Lusitanos") -Hice 2 modelos de 2 colores haciendo un total de 4 modelos para cada edificio; Centro Urbano; Barracas /Cuartel; Casas; Edificio especial- " Cancha de Pelota"; Fortaleza; Mercado; (serán mucho más bonitos con los adornos de mercancías ) Puerto; Templo; En sí , estos son los edificios sin decoraciones , les faltan las decoraciones propias de cada edificio , como escudos y lanzas en las barracas/cuartel , mercancías en el mercado , utensilios domésticos en las casas etc... pero como no sé si estos bocetos serán aceptados , por eso no los he puesto... Disculpen las molestias*