Leaderboard

Hello today, Today I've spotted a funny bug. If you assign a blacksmith and temple to a hotket (group), UI presents to you 2 trainable unit (while you have only 1 temple). Good news is when you click on Druid unit to be trained, it gets trained only from temple (1 unit)

For what it's worth, I'm pretty sure that the speed difference is because missing arrows query units around them to try and find alternative targets, whereas successful arrows don't. The former is obviously much slower. Thus why it seems like 'overkill' is the problem, but it's in fact just that missing arrows are computationally expensive (and every arrow after the target has been killed misses). You'd probably notice different results if you used an attack with splash, since splash does range queries anyways (as in, just much more lag all around lol). See https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/components/DelayedDamage.js$71 I think you're also compounding the results by having a massive blob of units nearby, since that probably slows down the C++ range query. Overall, there is little easy gain to make here unless we got much smarter about immediate range queries.

The game suddenly crashed during a major cavalry battle. These are the logs and replay, please tell me what went wrong and how to avoid similar crashes in the future. Thank you. mainlog.htmlinterestinglog.htmlcrashlog.zip Only the command.txt remained after the game. commands.txt There is another minor issue I need to bring up: during the game, I charged my cavalry into an Iberian player's base and he deleted his CC. There were enemy units inside the walls, and it took me approximately 1 minute to kill all of them, after which, the Iberian walls decayed to gaia and all of my cavalry were trapped inside like a jail. This is hugely inconvenient despite being unlikely to happen. My suggestion would be, let gaia doors open to anyone who wants to pass through, meanwhile, if the doors belong to a player, they should only open to that player's allies and not their enemies.

Ok. I renamed it the "saucemod" Ranged units now capture. However, an issue that makes ranged units OP: They can shoot while capturing and while walking. This mod is just to see what gameplay is like when ranged units can shoot other ranged units, and build interest in attack-ground or attack-group. You can see my observations above. I think this does improve a number of other gameplay issues like pikes being OP and healers being often unused. saucemod.zip

Can confirm this bug on build 26198. And seems to be accross all civs not just macedonians. It keeps increasing the more blacksmiths you add to the group too. @Purgator_ thanks for reporting. EDIT: blacksmith does this do any building that can produce units. Trac Ticket

@Freagarach Its actually bug, it happens if another structure has nothing to train. Works with selecting also with foundation

I think you put 2 temples on the same control group without realising?

We have some old but relevant (because of our audience and we don't have LODs) rules about polycount: https://trac.wildfiregames.com/wiki/ArtPolyCountGuidelines, but sadly some new models broke them in a bad manner

Yes, that is probably. As far as I know there isn't much information about linothorax apart from the statues and the drawings of the ceramics.

how do you guys do the .zip upload? i can only do commands.txt + metadata.json separately, and sometimes they get mixed up if i upload 2 games at once i think. chris vs vinme 0/2 commands.txt metadata.json commands.txt metadata.json

Since I don't see a specific promotion subforum I'm posting here, let me know if I need to move this post somewhere else. To promote 0AD, BAR and any other Open Source RTS game there's some initiative from BAR to organize a bi or triathlon with BAR and 0AD as participants. We had a lot of success in the past with this format, one can find a previous iteration here: https://www.beyondallreason.info/news/rts-triathlon-bar-pa-faf-coming-this-saturday-5th-of-june From BAR side we can contribute with streamers, promotional material and effort, we are wondering if there would be any intent from 0AD to participate? I'd love to see top tier players from both games duking it out on each others main games. Let me know what you guys think.

I remain the opinion that the only way to content all groups is this (or anyways, the idea of 'splitting our civs into balancing groups that are internally balanced but externally not so much') You make the balancing problem much easier, which lets you make much larger roster changes because you don't have to make sure that Kushites won't be OP against Romans or something, and that lets you have some actual gameplay variety both between and within groups. I think people have made the other points already.

I think I can make a patch for the shield "variant" files if you commit some new textures. If you make 1 to 1 replacements, then the existing actors can look better immediately.

Nee! Father is not JC! AlbertBorla is JC, and Father is likely Wally or Phew. I have watched at least 1 1v1 game between Father and JC and they play completely differently. Key indicators of JC: Collecting chicken with women Always playing as the Spartans Concentrating everything at one point and leaving their base empty Shouting nubia nubia nubia and blaming their teammates Anti-vac chat as usual. Hosting on Nubian biome with many relics Father never showed any of these features. Also it is possible that Father is a shared account as their skill and playstyle varied hugely from game to game. There is also 0 point in banning someone as they can just create a new identity for themselves and come back. But JC never tried to hide himself; you can easily tell who he is from his username.

I have found a link to a scanned part of the book "Armas de la antigua Iberia" writed by Quesada Sanz, the most important expert on pre-Roman weaponry in Spain, and illustrated by Carlos Fernández del Castillo... Only one problem, it is on Spanish: https://www.academia.edu/35385190/F_Quesada_Sanz_2010_Armas_de_la_Antigua_Iberia_De_Tartesos_a_Numancia_Madrid_La_Esfera_de_los_Libros

This page, from the Universidad Autónoma de Madrid, contains information about Iberian and Celtiberian weaponry and their evolution, also some illustrative images: https://www.uam.es/FyL/TiposDeArmas-Defensivas/1446788699134.htm

Just had this idea, and I think it's good, so I wanted to share this... Current situation As you may know, the AI is currently designed to ultimately be run in an asynchronous manner, in the background, over possibly n turns. A reference is this interview of @quantumstate for example, but it's also quite obvious from the architecture. The Idea was that thus the AI wouldn't be blocking for the simulation even if it was slow. Based on the fact it currently runs once per 8 in-game turn (about 1.5 seconds in SP, about 4 seconds in MP), we can assume that this is a reasonable time-frame for such a threaded AI. To support this, the AI receives a copy of the simulation state, through AI Proxy components on most entities and AI Interface. Consequences This is nice in theory - I've never questioned it and I don't think anyone questioned it in the past few years. However it has several significant drawbacks: The AI wouldn't be able to be run more than once every n turns (n=8 right now). That makes it basically impossible-by-design to micro efficiently, for example. Note that our synchronous AI can, but that's not how it should work (and it doesn't leverage that). Copying the simulation state is slow. AIProxy listens to most messages, all entities have one. It can easily take up several ms per turn (in fact I had a diff for that which I didn't keep as it was kinda broken.). Copying the simulation state is error prone. We have to do it manually. Techs in particular were a real pain to handle. Mitigations for multiple AIs (the common-API) are a mess. Copying the simulation state is greedy and custom. If the AI wants new information, we have to add it to its state. If it doesn't care about some information that we've added, we've payed the price anyways. The above flaws are all fundamental to the design. The second and first can be mitigated, but at great cost, and only up to a point. Proposed Change The biggest change is simple conceptually: we run the AI synchronously. It fixes all the fundamental design flaws above: we can run it every turn if we want to. This fixes point 1. we no longer need a copy of the whole simulation state. This fixes points 2/3/4. The AI can call into the Engine directly (using QueryInterface or something similar) - in a read-only manner. This can be by setting a flag or by copying only that relevant bit of data it's asking for. If the AI remains in its own context, we can use structured clones. The problem of this design is that if the AI wants to do something slow (and it does sometimes), it will lag. There is a solution. We let the AI run specific computations asynchronously, over a specific number of turns, using an interface similar to worker threads. Then if the computation isn't done, we block, otherwise we return the result and process it synchronously and deterministically. For these computations only, we copy whatever state is necessary. What I hope this achieves A speed-up of several ms per turn on both SP and MP. A much simpler AI interface (basically no interface). Still the ability to run longer computations asynchronously.

I'm implementing this at http://code.wildfiregames.com/D3769