Leaderboard

First, I would like to praise the 0 AD team for making a great engine, as well as for making it so accessible to modders. The vanilla game is very enjoyable, the music is great, even if the AI nearly always massacres my towns. Also the use of JavaScript is a great choice, as I use it recently a lot in my work, so I don't have the bad feeling of playing too much... But I have to admit, being no real fan of AoE series, the game was attractive for me for the modding options. There were no wizards and dragons, so I thought about making some for the game - https://drive.google.com/file/d/1hqaAKNebBjikWZtog9-GRmMbbYmwbWPC/view?usp=sharing The mod basically adds a new faction of "Scytho-Slavs", which are very roughly based on 6th c. Sclaveni, as they are described by Byzantine authors, but the name is from Leake 1814 (recently deleted from archive.org ), so the fantasy aspect is more important - from rhomphaias and bronze armors to dragons and thunderbolts. I was even thinking about making Red Sonja the faction's main hero. In short, as a "civilization", they are somewhat simplified: units can be trained only in the central building and the fortress. There are no barracks, no stables (cavalry needs the Corral), no "female citizen" unit (all units choose a gender variant randomly at training). On the other hand, basic infantry is cheaper than most units in vanilla and trains slightly faster. Units can also be healed in houses (3 at a time) from the beginning. The mod is far from being finished, but I wanted to ask for advice about some features. 1. Instead of temples, the faction can build an idol: a wooden statue of a god. As in Age of Mythology, the player has to choose one: Peraunu or Welinˀsu, which provide units with different upgrades. The idol decays in time, but can be repaired by a shaman (the healer/magician unit) dancing around. The decay is provided by a global aura, which is "researched" automatically when an idol is built. Even if there is a limit of one idol per player, the aura destroys any subsequent idol, if the first is lost. Is it thus possible to "unresearch" it or otherwise deactivate a global aura? 2. One of the functions of both idol and its shaman is to serve as a drop-off point for a new resource called "skulls". I got an inspiration for this new functionality from an older game called Sacrifice, where you collect souls of defeated enemies to strengthen yourself. Defeated enemy combat units have a chance to drop an "intact skull", which can be gathered by your units and brought to the shaman or idol. Only skulls from enemies (technically, the dropped skull is an entity granted to the player, who killed the unit) can be collected. The skulls can be used to upgrade your units, e.g. with rhomphaias or dragons (btw, now you need a fully trained Champion and 30 skulls for one). The problem is the gathering itself: to prevent combat formations from running away from battle, I set the scripts so, that only one skull is gathered at once. Also, for some reason, the units are unable to find nearby skulls dropped by dead enemies for gathering. Why does the gathering AI ignore them? 3. Concerning the dragons: presently, it is rather unwieldy to control them, they land and take off again each time a new target is selected, they don't always correctly face their targets, and can use only a melee attack. The flying script is somewhat hard to follow, and it somehow overrides attack AI of the unit. Is it possible to set up a simpler flying motion using the UnitMotion component? Or at least without the circling around coded for the P-51? 4. Another solution for the dragon problem would be to make it a "packing" unit: it could have a walking mode, in which it would use a melee attack, and a flying/floating mode, in which it would throw down flames. The problem was, that packing uses a new entity, so a new visual is generated. This affects only the rider, which is small anyway, but I plan to add more variation to the mount too. Is it possible to use the packing feature and preserve entity visuals? 5. There is also a horse archer upgrade, available to Raiders with the Peraunu idol. As I looked for a way, how to make them capable of shooting on the move, I made them to contain two entities, i.e. a horse with a dummy attack and a "turret". Visually, it is not ideal, as the 1. prop did not place the turret entity correctly unless it was parented to root, and 2. it dies separately from the horse. As I saw that some nomadic factions are in making, are there any more elegant solutions for such a feature? Thanks for any advice, and feel free to try the mod if you wish.

I don't think the balancing needs to be that deep. In addition, the balance should not encroach more than necessary on design and creation.

small update to 3.2. featuring a slight transparent main menu, experimental new logo design and other small fixes people mentioned.

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)

Some screens from the current build: https://github.com/stereotipo/millenniumad

Standards appearing over battalions looks really nice and do help with gameplay. Now, I wonder how to make them civ-specific. I tried using the waypoint/rally point flag hack in the actor, which names variants based on civ codes ("athen", "spart", "cart", etc.). It works for the waypoint actor (obviously), but not for my formation standard actor. In the above screenshot, you see that the standards pick random variants instead of the civ-specific one. Both flags should be the "athen" variant, but they are not. Also, a new flag variant is chosen each time the formation is created. Here is the waypoint flag code, which works: <?xml version="1.0" encoding="utf-8"?> <actor version="1"> <castshadow/> <float/> <group> <variant frequency="100"> <animations> <animation file="mechanical/waypoint_flag_idle.dae" name="Idle" speed="30"/> </animations> <mesh>props/waypoint_flag.dae</mesh> </variant> </group> <group> <variant name="hele"> <textures> <texture file="props/banner_greek.png" name="baseTex"/> </textures> </variant> <variant name="pers"> <textures> <texture file="props/banner_persian.png" name="baseTex"/> </textures> </variant> <variant name="celt"> <textures> <texture file="props/banner_celt.png" name="baseTex"/> </textures> </variant> <variant name="cart"> <textures> <texture file="props/banner_carthage.png" name="baseTex"/> </textures> </variant> <variant name="iber"> <textures> <texture file="props/banner_iberians.png" name="baseTex"/> </textures> </variant> <variant name="scyth"> <textures> <texture file="props/banner_scythians.png" name="baseTex"/> </textures> </variant> <variant name="xion"> <textures> <texture file="props/banner_scythians.png" name="baseTex"/> </textures> </variant> <variant name="rome"> <textures> <texture file="props/banner_romans.png" name="baseTex"/> </textures> </variant> <variant name="imp"> <textures> <texture file="props/banner_romans.png" name="baseTex"/> </textures> </variant> <variant name="spart"> <textures> <texture file="props/banner_spartans.png" name="baseTex"/> </textures> </variant> <variant name="mace"> <textures> <texture file="props/banner_macedonians.png" name="baseTex"/> </textures> </variant> <variant name="athen"> <textures> <texture file="props/banner_greek.png" name="baseTex"/> </textures> </variant> <variant name="brit"> <textures> <texture file="props/banner_celt.png" name="baseTex"/> </textures> </variant> <variant name="gaul"> <textures> <texture file="props/banner_celt.png" name="baseTex"/> </textures> </variant> <variant name="maur"> <textures> <texture file="props/banner_mauryas.png" name="baseTex"/> </textures> </variant> <variant name="ptol"> <textures> <texture file="props/banner_ptolemies.png" name="baseTex"/> </textures> </variant> <variant name="sele"> <textures> <texture file="props/banner_seleucids.png" name="baseTex"/> </textures> </variant> <variant name="theb"> <textures> <texture file="props/banner_thebans.png" name="baseTex"/> </textures> </variant> <variant name="epir"> <textures> <texture file="props/banner_epirotes.png" name="baseTex"/> </textures> </variant> <variant name="han"> <textures> <texture file="props/banner_chinese.png" name="baseTex"/> </textures> </variant> <variant name="kush"> <textures> <texture file="props/banner_kushites.png" name="baseTex"/> </textures> </variant> <variant name="noba"> <textures> <texture file="props/banner_kushites.png" name="baseTex"/> </textures> </variant> <variant name="sueb"> <textures> <texture file="props/banner_germans.png" name="baseTex"/> </textures> </variant> <variant name="goth"> <textures> <texture file="props/banner_norse.png" name="baseTex"/> </textures> </variant> <variant name="zapo"> <textures> <texture file="props/banner_maya.png" name="baseTex"/> </textures> </variant> </group> <material>basic_trans.xml</material> </actor> Here is the Standard code, which does not work: <?xml version="1.0" encoding="utf-8"?> <actor version="1"> <castshadow/> <float/> <group> <variant frequency="100"> <mesh>props/standards/formation_pole.dae</mesh> <textures> <texture file="props/kart_standard.png" name="baseTex"/> <texture file="props/kart_standard_norm.png" name="normTex"/> <texture file="props/kart_standard_spec.png" name="specTex"/> </textures> </variant> </group> <group> <variant name="athen"> <props> <prop actor="props/units/standards/formation_flag_athen.xml" attachpoint="root"/> </props> </variant> <variant name="cart"> <props> <prop actor="props/units/standards/formation_flag_cart.xml" attachpoint="root"/> </props> </variant> <variant name="spart"> <props> <prop actor="props/units/standards/formation_flag_spart.xml" attachpoint="root"/> </props> </variant> </group> <material>no_trans_parallax_spec.xml</material> </actor> formation_flag_athen: <?xml version="1.0" encoding="utf-8"?> <actor version="1"> <castshadow/> <group> <variant> <mesh>props/standards/formation_flag.dae</mesh> <textures> <texture file="props/standards/athen_infantry_1.png" name="baseTex"/> </textures> </variant> </group> <material>player_trans.xml</material> </actor>

I noticed a short slowdown, maybe the files were just cached causing the slowdown.

In fact, doing physics simulation most likely makes them much more efficient than us. In 0 A.D., arrows are actually purely graphical, the "hit" itself is a timer (this, by the way, has a number of odd consequences, e.g. #5965 or #5964). The consequence is that on timer hit, we must query units around us and check collisions in JS manually (sorta). if there are 100 arrows, this will do 100 range queries. In a physics-system approach, the arrows would move each "physics update" through the world, a very local phenomenon that can be highly optimised. Detecting a hit is a fast operation by itself, and there is no need to do range queries. Thus arrows are not _specifically_ slow, just part of the whole physics engine. 0 A.D. does not have a physics engine at all, and it probably wouldn't work that well for us because of our 200ms turns. I suspect BAR uses a much more fine-grained "physics turn" of e.g. 10 or 20ms (edit: based on 500ms being 15 turns, 33ms) , so their physics-related lag is less 'spikey'. -- We could update 0 A.D. to have more turns and do fewer things on each turn, which would end up making it more possible to use a physics engine (though there are floating point / determinism concern), but that's a lot of work given where we come from. --- That being said, this doesn't prevent us from changing how projectiles work -> it's probably a semi-good idea to consider moving stuff to C++ and making them behave more realistically, given that the current code ends up being slow-ish anyways.

No promises, but I'm working on that

Mission 12 is now converted and re-vamped for a25. Thanks all for the help and of course, thanks to the original creator of the city that Alexander conquers in this scenario.

Range queries are done in C++ through the CCmpRangeManager class. That class component is attached to what we call the SYSTEM_ENTITY. Those calls can be made from JavaScript and C++ by creating a range query. The issue is when 1 000 units start a range query at the same time. As far as I know the processing is sequential. From my recent testing of wraitii's patch to unthread the ai though not having to copy the whole simulation over to the AI makes a huge improvement on performance. https://code.wildfiregames.com/D3769

But Britons can do this: That looks cute and other factions would need more walls to surround there CCs.

I have recently learned that the time span we are working with goes from the 6th century BC to the 1st century AD, a longer period than I had imagined. So I'm going to contribute some new images. South-eastern Iberian mercenary chief at the ending of the 5th century BC by José Luis García Morán. The duel of Porcuna (a couple of sculptures from the 5th century BC) recreated by Carlos Fernández del Castillo.

Attack ground: Harder to implement (properly). Attack group: GUI only code change needed (for the case of selecting a unit in the group randomly and keep attacking that until it is dead). As such, it seems easier to implement.

From https://trac.wildfiregames.com/roadmap *Due date is for feature freeze, actual release might happen a month later. (Hopefully not) I did my best to advertise it a bit (on Discord mostly), but I can't post it on social media, because it's highly experimental.

I would assume they are much smarter about collision detection They probably have much more persistent data structures for collision detection in such a manner, because otherwise the game just wouldn't work. For example, they can probably first consider all formations (of which there are very few) to decide a new target to pick, where we must consider all individual units. Or another example: for the most part, they don't have to consider new units joining the battle (I think this may be somewhat different in TW WarHammer but it remains limited). That probably enables them to use some clever hacks that we can't so easily use. There is a lot of stuff happening in combat. If the target dies, UnitAI needs to choose a new target, which is by itself rather slow -> range query + filtering for preferred targets, sorting, etc. That's not even mentioning the fact that yes, dying by itself could be a bit slow. This is indeed an area of possible improvements, and some work has been done (e.g. rP25102) To be honest, the arrows range query could perhaps be improved by having some in-turn caching or some other logic to batch missile hits (so that multiple missiles landing in the same area don't do multiple range queries or something), but that doesn't sound entirely trivial to do without breaking in some edge-cases. It's always a question of code complexity, accuracy, edge-cases with these kind of optimisations. --- Edit: Also, while such "in a vacuum" performance profiling is useful when you're working to optimise a specific function, be careful about generalising. In an actual MP replay, you'll most likely see a much more nuanced picture.

You’re statements on attack group aren’t true. If you select a large area, attack group just makes you shoot father projectiles that are less likely to hit. If it also acts as a tower that randomly selects then that means that it will attack random units walking through the area that you probably don’t mean to target and are less likely to be hit because they’re moving. If attack group selects random units that you aim at until dead or at units that are nearest in that area then You will have to regularly re micro as that area will have units disappear and range units will go back to default attacks if nearest unit. Plus if you do attack group then new arriving units will need to be microed to attack group or they will just default to nearest units. This provides the benefit of being able to target ranged units in the back which is why this whole discussion exists so idk why you don’t think it provides player benefit and as I describe above it also requires regular micro and skill. I described these pros/cons in my initial comments on this thread. I believe those possibilities should be re-examined. The only person who spoke in opposition to that said they thought my proposal would be OP (despite no reason given for that) and that they preferred attack ground bc it would hit the footprint, which is obviously true but equally obvious that that would make attack ground only useful in the very limited situation where extreme chock points exist (which also probably creates balance issues that something like attack group with target of nearest unit doesn’t have a problem with) Not trying to say I told you so here, but attack ground has some very obvious deficiencies that makes it use extremely limited. And these deficiencies are severe enough to mean in the vast majority of situations on the vast majority of maps attack-ground won't address anyone's original concerns that led to this discussion, namely that range units overkill meat shields. If you want it, fine. But it is not something that excites me at all.

This is very much expected. In multiplayer the game needs to be synchronized over the internet. In order to do this, any command you send needs to be shared with all clients before processing it. More precisely, a client need to send the command to the host, then the host shares it with all clients. Hence when you give a command it is only executed a little while later. IIRC this "delay" is hardcoded to be .6s (or .4s?, whatever). In future we might implement having this time "dynamic" i.e. it would be as low as possible depending on the used network connections (this also related to the idea of "variable turnlengths"). This would make the game more responsive in some situations, in particular two computers on the same network. However do notice that there will always be some delay. In particular, if you are playing with someone on the other side of the globe, you will have at least .133s delay (we need to travel from the client to the host and back, so basically travel a full circumference of the earth). Simply by the laws of special relativity (nothing can move faster than the light). Likely this will be even higher, since your signal probably will travel slower and with some detour.

AAAAahh thanks so much man!!! it's really a great motivation to hear this!! since I was pretty much my own boss in this little project I had no much idea how it could be from "outside". Very happy to hear that is heading towards the right direction! About the AO maps yeah! Totally right! I tried to solve all the rest before but now I'm getting to that stage where I can tackle all these final details (and also clean-up the .xml files.. some are probably a bit messy with my many attempts ahahaha )

hi all, I had this idea, lets make a thread for map creators where they can get inspiration from. Many of you probably know alot about history especially around 0ad timeframe, and know about interesting battles that have happened or places to recreate. The idea is to share that information here, so that a map creator can pick it up and start working on it. To keep things clear with a nice overview it's probably best to use a format e.g.: ---------------------------------------------------------------------------------------------------------------------------------------- Name: Battle of Thermopylae Type: Historical Battle - Sources - Docs Source Vids Source Pictures Source Source Maps Source Comments/explanation ---------------------------------------------------------------------------------------------------------------------------------------- If you wish to contribute i'm sure the map creators will be thankful, at the very least i am. Copy and paste the format from above and start sharing (Keep the comments/explanation in a spoiler tag please, for better readibility of the forum). Looking forward to learn some new history. A few last notes. If you as a map creator decide to start working on one of the projects, please call it out in the comments section to prevent more than 1 person working on the same thing. If you decide to share a battle/historical place make sure your sources are solid, i learned from battle of thermopylae that alot of sources are not credible and often contradictory. Sometimes more than others you will get fed biased information/stories much like the spartans themselves did.

Exactly!! Lopess also made me notice that! I was already reviewing some files for this reason. I'm also baking all the AO textures that were missing .. I was waiting to reach some sort of "final" stage with the models but now is the right time to finish that part. Thanks so much for taking a look into it!! I definitely looked a lot also at Delenda Est as inspiration. So it's really great to get suggestions from that side! I don't know if you liked the mod so far. I would love to reach a polished stage that could possibly be published alongside some future a26 release. It's quite challenging but lots of fun too!

Make sure if a structure actor uses a material with "ao" in it, that you specify an AO map in that same actor, else choose a different material. Example: <?xml version="1.0" encoding="utf-8"?> <actor version="1"> <castshadow/> <group> <variant name="civic_center"> <mesh>structural/Byza_CC_revamp.dae</mesh> <textures> <texture file="structural/byza_texture_C.png" name="baseTex"/> <texture file="structural/byza_texture_C_NRM.png" name="normTex"/> </textures> <props> <prop actor="props/structures/decals/dirt_7x7.xml" attachpoint="root"/> </props> </variant> </group> <group> <variant frequency="1" name="alive"/> <variant name="death"> <props> <prop actor="props/structures/decals/dirt_7x7.xml" attachpoint="root"/> <prop actor="particle/destruction_smoke_med.xml" attachpoint="root"/> <prop actor="particle/destruction_dust_med.xml" attachpoint="root"/> <prop actor="particle/destruction_dust_med.xml" attachpoint="root"/> </props> </variant> </group> <material>player_trans_ao_parallax.xml</material> </actor> The <material> here asks for an ao map, but one is not specified in the textures. I looked in the textures\skins\structural\ao folder, and there are a couple byza textures there to choose from.

Hello! Someone (very kindly) has tried the current mod but reported me some problems with his version. The game was launching as usual, but at the moment of launching a new match the loading time was apparently taking too long than normal and the game was running very slow and sluggish. This happened on a m1 mac. It's quite strange because I never experienced such problems even using a mac myself (even if Intel). Anyway does anyone would like to download and try it and see if they have any issue on their machines? https://github.com/stereotipo/millenniumad That would be quite helpful! Thanks anyone! (also: if it works correctly I hope you can have some fun playing it too! ehehe)

@the-x I agree that this is an extremely important topic that goes beyond alpha to alpha balancing. I think there are three general categories where improvements will do the best to make the game more fun: civ diversity/ uniqueness creative and powerful team bonuses (for example britons current team bonus is -25% hero cost and train time) battle mechanics (right now is very simple: melee die, then ranged die)

Another bit from TarnishedKnight:

Some insight from TarnishedKnight on BAR:

it's not only that. the fact that territory expansion is so expensive makes the game meta dwindle between turtling and aggro, because you basically only have your starting base anyway. no other strategies are viable.

OP can be adjusted for. As long as the feature is an improvement in behavior.

I also like A25 a lot. Many thanks to the developpers! I agree with Acanthis that there should not be too many changes for next alpha. Some of the small changes I found since the release to improve the game and its playability are: The images for the armor upgrades in the blacksmith would be better, if they also had Latin numbers on them, even if they look different I still cannot distinguish them in the pace of the game after all the time I played. :/ It would be cool to see the progress of units ranking up when garrisoned in barracks or stables. It would be also nice to have a counter how long the upgrading of an sentry tower to an stone tower still takes like you have for the most techs. Lions follow there first unit they see endlessly, which I find not very clever of the lions. Why should they do it? They should stop after some time! It would be cool to have the option to choose the starting position of the players in an online game. When attack moving and enemy domestic animals are close your units also kill the animals, priority should be to attack military units and maybe not attack the animals at all. I observed a strange thing with formations: When fighting in formation in some circumstances, after units die, soldiers move around to adjust formation to new group size, which might make them not attack and die. If an enemy has a wall but you already broke it on one spot your soldiers do not find the way around walls and try to go trough the closed door of the enemy. Maybe this can be fixed. If you are Britons and have stables and reached the POP max but still can build dogs, it would be really cool when the queue would build the dogs even when other units are in the queue before the dogs. A good temple feature would be to have a button/shortcut to just ungarrison the healed units. After joining an online game and host changes some settings you get a comment that game settings have been changed. It would be great to read what the host changed! e.g. map size changed to large, game changed to nomad game When playing with A.I. it would be great to get a notification of your A.I. allies where they are located as players do it in multiplayer games via telling the position on map like it is a clock or by flaring or better both. Lately I observed that cartography gives you the landscape your allies scouted but not all the buildings of the enemy he saw. But this needs further validation. I just saw it on a replay, or better I didn't see the colony my ally already saw. Shouldn't I see all my allies see with cartography? Considering tech upgrades pleas stop making more of them. Maybe some faction specific or for balancing. I really like 0 A.D. and the difference to AOE2 where you have so many upgrades. To be honest I don't like 3rd level upgrade in the blacksmith because they make the game to much focused on getting them to have an advantage over your enemy or to don't have a disadvantage against your enemy...

Obviously attack group is better than attack ground, i never doubted that. But do you really want to take away such skill/interaction from the game? It seems like you do, but honestly i don't and there are people on both sides. You say attack group requires micro and skill but i honestly doubt that in realtime, it would pretty much be a simple repaint of an area once in a while. There is pretty much no risk involved with attack group. There is no misusing attack group other than letting your ranged get eaten by swordsmen for example, which would be bad in all occassions, even without attack ground/group. Micro should give you an edge over your opponent, and attack group takes too much from it. You might aswell make it their standard attack behavior unless manually commanded otherwise. People who don't like micro will get balanced by elo tbh. Besides, units are clustered on the battlefield all the time, not just on choke points. A one time volley on a resizable circle attack ground would be a pretty useful thing to have imo, with the choice of a continious one with a combination of a hotkey (for all ranged units, just to be clear, not just archers). But with risk of misusing / poor judgement and without it being the new standard way to play. Attack ground will also give usefulness to formations whereas it wouldn't with attack group. Also attack group needs a heavier rebalance than attack ground but whether that's a problem or not depends on the balancing team.

Zeus or Zarathustra would be my favorites.

FreeBSD provides alsoft, but without pulseaudio support. I have rebuilt alsoft from sources with pulseaudio support and 0ad runs now as expected. Thanks a lot. Best regards, JB

When you get bored playing the same strategy over and over again, invent another one! With Ptolemies, have you tried: Mercenary rush Spamming colonies around enemy base to annoy them Slinger rush Pikeman rush Camel spam Bolt shooter rush Siege towers Champion cav raid All elephant army Catapult + ram flood Naval maps ? Every civ has fun strategies already invented and waiting to be discovered. By the way, your strategy of booming fast then pushing with all mercs is very effective if your enemy doesn't know what you are doing (I lost 2 matches against you this way). But the third match we played, you tried the exact same thing again and you lost to me. The reason is, I predicted what you will do so I chose Spartans, outboomed you and got a fortress in your way. Then I baited your army into the range of my fort then I had hoplites to handle your pikes and teleported Skiritai into your crowd of ranged units. There used to be a lot of unique units in A23 but they were deleted for balancing purposes and historical inaccuracy. Also there are untrainable units in the Atlas editor that you can try (e.g. Roman gladiators). I would really like the Spartan and Athenian Stoas to return, as well as Cardakes Mercenary, even if then bend history a bit.

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.

Another great Sunday 4v4 Those darn towers!!!! Replay Download below SG.73_4v4 Towers of Doom.zip

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.

Did you use the suffix thing? This shouldn't be the case of you use the whole file as is.

If you play the Iberian faction, their horse javelin unit with flaming javelin enabled work wonders against siege units and buildings. 20 of those in a group can take care of 3 to 4 battering rams in seconds. I also do away with siege units completely when playing this faction and just use them for razing buildings. They are much faster and more flexible than battering rams, and can defend themselves effectively and not requiring escorts. Best of all if they are in real danger you can always stick them in the safely of a temple. Have two rotating groups of flaming javelinist doing their work and with the temple itself covered by arrows from garrisoned civic centres and fortress (20 units max each) pretty much sums up my late-game gameplay. You can fill the civic centre and fortress with cheap skirmisher units and it will shoot the same arrow as more expensive ones, they can be put to work when the complex is not under attack, save the metals just for the fire javelinist and replace lost units here and there. I strike here and there with the horse units, taking down a couple of buildings and retreat, drawing in the enemy units to be whittled down by my base defense, then switch to my other group to strike out again while the first group heals. If the enemy comes with siege units take those out first while they are still on their way then withdraw back to the temple. Set the horse units on defensive mode so they only attack what you tell them to and don't stick around absorbing unnecessary damage and losses. Good and effective game play boils down to a plan consisting of a simple number of steps that you just repeat over and over again. Building up and surviving until you can put the plan to work is the key. Preferably getting everything in place before their escorted siege units arrive. (If you are playing another faction champion sword cavalry units in groups of at least 20 is still your best counter against siege units. Try to save and reuse champion units as they are too valuable and expensive to be used up in one battle. Infantry champion units are too slow and will be overwhelmed while they try to destroy siege units. Lump your units with ctrl+number keys to better control them in the mess of men during battle and set attack mode to defensive so they don't act out on their own. Bolt crossbows will work against battering rams and catapults but they are a pain to pack/unpack and hard to defend against other enemy units.)

Eldi quit without resign when i was winning My Username in lobby RogerDeFlor Opponent Username. Eldimetadata.jsoncommands.txt THANKS!

Yes, there might be some more strategical decisions; Territory Expansion should become a real strategical thing - not everything is everywhere and doesnt de facto matter -> it misses deep of the game and that will affect long term fun

Hello everyone, We're happy to release the first testing bundle of 0 A.D. Alpha 26 (name to come). Keep in mind, this is not a 'Release Candidate' yet, and so some bugs are to be expected. We provide this in the hope of finding and squashing them efficiently. If you choose to test, please keep that in mind. Downloads - Current bundles are for SVN revision r26108 (See below for updated bundles) Linux data and build macOS Windows Snap build is available at latest/edge Things to note: Translations are not complete & may be buggy -> Play in English for now. Mind your mods -> they might introduce issues or Out Of Sync. Save your A25 config file somewhere, ideally. Changes: https://trac.wildfiregames.com/wiki/Alpha26 Points of attention: Acceleration Currently known issues: AI is slower to attack https://code.wildfiregames.com/D4391 Maurya palace triggers errors https://code.wildfiregames.com/D4392 Gui scale popup might close quickly https://code.wildfiregames.com/D4318 What to do if I have an error or notice something weird? Post your commands.txt (replay) and the interestinglog.html file from your folder. You can also reply to this thread. What to do if the game crashes Update your crashlog.dmp and crashlog.txt see https://trac.wildfiregames.com/wiki/GameDataPaths What to do if I have an Out Of Sync? You should go in your logs folder, find the replay (commands.txt at least), the mainlog/interestinglog and find the OOS dump folder. Zip all these files and upload them here. Ideally, you should coordinate with the OOS players so that they upload their own OOS dump, so we can compare them. Things you may want to test (non-exhaustive) Launch a random game Launch a skirmish. Connect to the lobby Play on the lobby with someone Launch Atlas and try things out there Open Unit tests demo (To see if there any breakage in displaying entity's) (It's in scenarios) Enable feedback and see if it works (Main menu) Example video Connect to and use mod.io ( Try to download and install the linux libertine font) Test replaying new games Test Screenshots (F2) Test Big Screenshots (Maj+F2) Test hotkeys Test Saving and loading a game. Test Quickload/Quicksave And of course playing games.

I think @psypherium made a good point about that in his video by saying inclusion wouldn't matter if we didn't have any assets for the hans or any of the other civs. We are not considering the yayoi Japan for inclusion because there are barely any assets, Lordgood never released the buildings. Han, Xiongnu, Zapotecs, Scythians have their own assets which make them eligible. The Kushites got in the game that way. In other words we are stripping potential fun away by not including a civilization that's probably more complete than a few of the 13 civs when they got in the game.

slowly slowly I'm updating the mod to include some new features, assets and all the good stuff. If you want to try it out, you can find it here: https://github.com/stereotipo/millenniumad Current changes had been : - A full building set for the Umayyad civilization (was lacking) - An update of some Byzantine buildings, to make them more historically accurate and improved textures (thanks to @Andronikos Medina for his historical supervision, as scholar of Byzantinism) - A new civ, the Rus (currently on hold) with new planed features and mechanics Today, as a personal exercise I also made an alternative splash screen, featuring the Norse and I'm planning to make a few more! Once completed, I hope that this mod can have the chance to promote 0ad and Wildfire Games through early medieval history!

Working on this mod, so far I managed to make something similar to what @Lion.Kanzenwas explaining. I introduced a new civ (Rus) and a new building with special functions based on my initial idea/concept at the beginning here: Stan gave some suggestions in this thread on how to develop the concept from the templates available: So here you go! A new 3d model that can be built in neutral territory and, as you can see from the pictures, act as a market (and also as a dropsite!). It's all playable here : https://github.com/stereotipo/millenniumad If you're interested I can keep you updated on future progress! I didn't exactly know how the Council of Modders operated, but now I think it will be good to share more of new material here in the forum, so it can benefit also of the supervision and feedback of more experienced people! I just hope I'll not bother too much

Other features that can be considered. Military organization with the insignia of officers who would help organize the battlefield and formations. Fire attacks against enemy structures. In addition to protecting battle uniforms, they had strong ritual and psychological value.

I intend to expose here a sequence of realistic technologies for the Forge (or armory) Pre-Classic Zapotec (and for Mesoamericans in general). Initially, I intend to replace a standard 0ad technology with a name and technology suitable for a preclassical Mesoamerican civilization. Then we can discuss unique technologies and in the future some Zapoteco names for them. Mesoamerican forge (Zapotec armory) tecnologics soldier_attack_melee_01 -- Secondary weapon// Chert knife. soldier_attack_melee_02 -- Improves obsidian blades. soldier_attack_melee_03 -- Improves green obsidian blades. soldier_attack_ranged_01 -- atlatl. soldier_attack_ranged_02 -- Chert arrowhead. soldier_attack_ranged_03 -- obsidian arrowhead. soldier_resistance_hack_01 -- padded armor. soldier_resistance_hack_02 -- armor padded with salt. soldier_resistance_hack_03 -- wood reinforced helmets. soldier_resistance_pierce_01 -- reinforced shields. soldier_resistance_pierce_02 -- leather reinforced shields. soldier_resistance_pierce_03 -- wood reinforced shields. archer_attack_spread -- atlatl training.

Well I objected at the time https://code.wildfiregames.com/D2494

I like the visions for the civs, to give them all some unique mechanics. I am particularly interested in this in the shorter term however: I like this idea, and I feel these upgrades should be more expensive than regular blacksmith upgrades especially the one for elite rank (assuming its the same as "veteran" rank). Perhaps the "elite" upgrade would be more expensive, and add a 10 metal cost to the unit.

the times of Jesus and the second temple is one of my hobbies to investigate and read.

My mod is ready for alpha 25.