causative

@chrstgtr If you're talking from a historical point of view, the point of a wall is that it takes siege equipment (such as a ladder or siege tower or giant earthen ramp) to capture, or siege equipment to destroy (rams, which only work if the wall is not too thick, or for thicker walls, digging under the wall to collapse it.) Soldiers without siege equipment couldn't capture walls unless the walls were unmanned. Walls were really darn good in the ancient world so that often the most practical way to assault a walled city was to starve them out.

Please no. Give me a regular website with links and menus that makes it easy to navigate, not some animated slide show.

Oh yeah, "Edit 2018-09-09: This content may be outdated. We hope to make a new website soon, which will be easier to maintain."

Personally the website looks fine to me. What makes it "outdated" or why do you say it is slow? But I support your desire to contribute and it is a shame if you have good ideas and a willingness to implement them, but are blocked from helping.

Wоuld аlѕо аllоw ѕрооfіng реорlе'ѕ nісknаmеѕ wіth сhаrасtеrѕ thаt lооk the same as Lаtіn сhаrасtеrѕ but аrеn't the same. The preceding sentence is full of such characters but you'd never know from looking.

You want to maximize your rate of production for a given upfront cost. The upfront cost is the cost that you have to pay in order to build the barracks, plus the cost that you have to pay in order to "get production started," which is the total cost of the batch. Both of these can be considered fixed, sunk costs. Even though the batch cost is from one perspective recurring, it should be treated as a fixed cost plus a continuous per-second recurring cost. For example, if you want to 10-batch, then you need 300 wood for the barracks if it's Mauryas (plus, actually, about 100 more opportunity cost for the time building the barracks, depending on number of builders and walk time), and you also need 500 wood and 500 food to get your 10 batch started. As long as you keep producing 10-batches, that 500 wood and 500 food is always tied up in the barracks. You also need to continuously harvest a recurring cost of 938 total resources per minute so that you will have enough when it's time for the next batch of 10, but this recurring cost is in addition to the upfront batch cost. The production rate per minute for an N-batch is 60 * N / (10 * ceil(N**0.8)). The batch cost is 100 * N. The barracks cost (including build time) is maybe 400 equivalent. So the efficiency is 60 * N / (10 * ceil(N**0.8)) / (400 + N * 100). This reaches a maximum for N=1. N startup cost efficiency 1 0.012 2 0.011 3 0.010 4 0.0097 5 0.0090 For non-Mauryas the barracks cost will be different - lower, if you don't count the stone cost for the first three barracks, which only favors a batch size of 1 even more.

Not specific build orders, but some general rules of thumb I've been puzzling out. You need 3.5 farms (food income of 500 per minute) to support 5-batch women production from the CC You need 2 farms (food income of 300 per minute) to support constant production of men from a barracks in batches of 1. If you have four barracks and the CC all producing men in 1-batches, that means ten farms. 1-batching from a barracks in theory is the most efficient batch size for a big boom to 200 pop. In practice sometimes larger batches will be necessary to use up excess food. But batches should be kept as close to 1 as possible. With no barracks you need 1 house builder if you can keep him going all the time. 1 barracks, 2 house builders. 2 barracks, 3 house builders. 3 barracks, 5 house builders. 4 barracks, 6 house builders. In theory - walk time may mean you need one more than this. Or if not all your house builders work on the same house at once you can use fewer. Roughly the process is: first spend any excess wood on farms to support your current barracks number plus 1, keeping wood as close to 0 as possible. Then wait until you have enough wood for another barracks without interrupting production, and make it. Repeat. (Process is more complicated if your barracks also costs stone.) If you have extra food from berries or hunting or Ptolemy teambonus, the same applies that you want 300 food income for every barracks (or CC producing men) plus 500 food income if you're batch producing women. There's little purpose in gathering more food than that, and the rest should go on wood and make barracks whenever there is excess wood. Food income from such sources can be measured with my show resource income mod. The "1-batching is the most efficient batch size" may be the most controversial part of this. Here's my reasoning. What you want is to get the maximum production rate for the minimum upfront investment. If you have a large batch size, the batch should be counted as part of the upfront investment. So the efficiency is (production rate of men) / (300 + size of batch * 100). It turns out this is minimized for 1-batches.

No, sorry, that would need to be a completely different program.

https://github.com/bparkis/0adbuildoptimizer It's a simplified 0ad simulator where you tell it a build order and it instantly tells you when you're going to run out of pop or resources, or have an excess of resources. See the README. It will be a lot more useful to you if you happen to know Python. I think the best explanation of how it works would be an example of what a build order looks like with this. # set up the map. addForest(10, 0, 5000) means there is a forest at coordinate (10, 0) - which is 10 seconds of walk time away from the CC - with 5000 wood available. # 5000 is around the amount of wood you would chop before you would need a second storehouse. addForest(10, 0, 5000) addForest(11, 0, 5000) addForest(12, 0, 5000) addForest(13, 0, 5000) addForest(14, 0, 5000) addForest(15, 0, 5000) addBerries(-5, 0, 1000) addChicken(0, 0, 400) setCiv("Mauryas") setSummaryPeriod(1) # show a summary every 1 second debugEnd() # always throw an exception when we finish, to allow pdb debugging of the detailed state. e.g. with python3 -m pdb boom.py builds/maurya1.txt # This will report the first time when wood went over 300 # and stayed that way until the end. Useful for deciding when we are # able to build stuff without interfering with any other production. reportSurplus(0, 300, 0, 0) # men chop with elephant dropsite, women make berries farmstead, horse on chickens, elephant makes a house at wood chop(selectWorkers("male")) build(selectWorkers("female"), "farmstead", pos=(-5, 0)) walk(selectWorkers("elephant"), (10,0)) # walk ele to forest chicken(selectWorkers("horse")) berries(selectWorkers("female"), queued=True) # The elephant's house is queued meaning it will happen after the # elephant walks to the wood. A non-queued order will just # replace any existing orders. build(selectWorkers("elephant"), "house", queued=True, pos=(10,0)) # train 4 initial women at the CC train(cc, "female", 4) # train batches at the CC that are "maximum batches," as much as food and pop allows, up to a batch of 5 # Do this "repeating," i.e. repeatedly make batches until the order is canceled # also queue it behind the previous train command train(cc, "female", 5, queued=True, repeating=True, maxBatching=True) # Set a schedule for what the women will do after being produced. # Women produced from the CC will go to berries between population 11 and 12. # between population 13 and 27, they will chop wood. # between population 28 and 41, they will build farms and start farming # between population 42 and 46, they will be idle (we'll give them orders then) # after population 47 they will chop wood. setWaypointSchedule(cc, [(11, ((-5, 0), "berries")), (13, ((10, 0), "chop")), (28, (None, "farm")), (42, (None, "idle")), (47, (None, "chop"))]) # wait until 28 seconds into the game, because now the farmstead is done and we can research the berry upgrade time 00:28 research(selectBuilding("farmstead"), "up_gather") # At 0:44 the elephant has made his first house # and at 0:46 we have just enough wood to start a second time 00:46 build(selectWorkers("elephant"), "house") # at 1:17 the elephant is done with the second house. There's not # enough room for the elephant to make more than two houses while # still being a wood dropsite and leaving enough space for the # elephant to get out, so we'll take a man off of woodcutting. The # man will make unlimited houses as a repeating order. (All of these # houses will be at 10, 1) time 01:17 build(selectWorkers("male", num=1), "house", pos=(10, 1), repeating=True) # also queue up an order for berries women to go onto farms farm(selectWorkers("female", "berries"), queued=True) # at 3:23 we have 500 spare wood. We'll transfer 5 women off of wood # and onto farms, in preparation for the first barracks. time 03:23 farm(selectWorkers("female", "chop", num=5)) time 03:28 # These are two women just produced from the CC build(selectWorkers("female", "idle"), "barracks", (3, 3)) time 03:49 # four more women just produced from the CC to help build houses and the barracks build(selectWorkers("female", "idle", num=1), "house", (10, 1), repeating=True) build(selectWorkers("female", "idle"), "barracks", (3, 3)) time 03:53 research(selectBuilding("farmstead"), "up_farm1") time 04:35 # barracks is done # we need another house builder. She can help the male housebuilder at (10, 1) farm(selectWorkers("female", "idle", num=5)) chop(selectWorkers("female", "idle")) train(selectBuilding("barracks"), "male", 1, repeating=True) setWaypoint(selectBuilding("barracks"), (10, 0), "chop") time 05:47 # enough wood for another barracks build(selectWorkers("female", "chop", num=5), "barracks", (3, 4)) farm(previousWorkerSelection(), queued=True) time 06:05 build(selectWorkers("female", "chop", num=5), "barracks", (4, 4)) farm(previousWorkerSelection(), queued=True) time 06:38 # barracks done # selectBuilding will get us the idle barracks preferentially setWaypoint(selectBuilding("barracks"), (10, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) time 06:56 setWaypoint(selectBuilding("barracks"), (10, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) time 06:36 # We've made 67 women. That's probably enough. Switching to men from the cc. train(cc, "male", 1, repeating=True) time 07:09 # forest dead, move on. build(selectWorkers("male female", "chop"), "storehouse", pos=(11, 0), queued=True) chop(selectWorkers("male female", "chop"), pos=(11, 0), queued=True) chop(selectWorkers("male", "walk"), pos=(11, 0), queued=True) setWaypoint(selectBuilding("barracks", index=1), (11, 0), "chop") setWaypoint(selectBuilding("barracks", index=2), (11, 0), "chop") setWaypoint(selectBuilding("barracks", index=3), (11, 0), "chop") setWaypoint(cc, (11, 0), "chop") time 07:27 build(selectWorkers("female", "chop", num=1), "house", (10, 1), repeating=True) time 08:00 build(selectWorkers("female", "chop", num=5), "barracks", (5, 5)) farm(previousWorkerSelection(), queued=True) build(selectWorkers("male", "chop", num=5), "storehouse", (12, 0)) chop(previousWorkerSelection(), pos=(12,0), queued=True) time 08:31 build(selectWorkers("female", "chop", num=5), "barracks", (5, 5)) farm(previousWorkerSelection(), queued=True) build(selectWorkers("male", "chop", num=1), "house", (10, 1), repeating=True) research(selectBuilding("storehouse"), "up_chop1") time 08:51 setWaypoint(selectBuilding("barracks"), (12, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) time 09:02 build(selectWorkers("female", "chop", num=5), "barracks", (5, 5)) farm(previousWorkerSelection(), queued=True) time 09:17 build(selectWorkers("female", "chop", num=5), "barracks", (6, 6)) farm(previousWorkerSelection(), queued=True) build(selectWorkers("female", "chop", num=1), "house", (10, 1), repeating=True) farm(selectWorkers("female", "chop", num=5)) time 09:36 chop(selectWorkers("male female", "chop"), pos=(12, 0), queued=True) chop(selectWorkers("male", "walk"), pos=(12, 0), queued=True) setWaypoint(selectBuilding("barracks", index=1), (12, 0), "chop") setWaypoint(selectBuilding("barracks", index=2), (12, 0), "chop") setWaypoint(selectBuilding("barracks", index=3), (12, 0), "chop") setWaypoint(cc, (12, 0), "chop") time 09:40 build(selectWorkers("female", "chop", num=5), "barracks", (7, 7)) farm(previousWorkerSelection(), queued=True) setWaypoint(selectBuilding("barracks"), (13, 0), "chop") build(selectWorkers("male", "chop", num=1), "storehouse", pos=(13,0)) chop(previousWorkerSelection(), queued=True) train(selectBuilding("barracks"), "male", 1, repeating=True) time 09:46 setWaypoint(selectBuilding("barracks"), (13, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) time 09:54 build(selectWorkers("female", "chop", num=5), "barracks", (8, 8)) farm(previousWorkerSelection(), queued=True) setWaypoint(selectBuilding("barracks"), (13, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) time 10:10 build(selectWorkers("female", "chop", num=5), "barracks", (9, 9)) farm(previousWorkerSelection(), queued=True) setWaypoint(selectBuilding("barracks"), (13, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) build(selectWorkers("male", "chop", num=3), "house", (10, 2), repeating=True) time 10:15 build(selectWorkers("female", "chop", num=5), "barracks", (9, 9)) farm(previousWorkerSelection(), queued=True) time 10:31 setWaypoint(selectBuilding("barracks"), (13, 0), "chop") train(selectBuilding("barracks"), "male", 1, repeating=True) build(selectWorkers("female", "chop", num=5), "barracks", (10, 10)) farm(previousWorkerSelection(), queued=True) time 12:00

@Sodalite It is a good idea, but have you seen the Random map, "Fortress"? You start with a walled city with some buildings already made and a bunch of resources. Similar to what you are saying, I think, if not exactly the same.

Ah, this thread! My boom breaks the rules of that challenge because I make more than 50 women by the time I hit 100 pop (75 women). Also I'm Mauryas rather than Spartans. However, I don't take any hunt, which the challenge does allow. I reach 100 units on the map (in fact 102) by 7:25, which would put me in fourth place if I weren't breaking the rules.

Capturing and enslaving civilians is also a war crime.

@Player of 0AD Skipping the berry upgrade, maybe. If I do that I need to have 8 women on berries to match the rate of 6. It's 100 resources for the berry upgrade and 100 resources for the two women, so it's going to be a close call whether it's worth it or not. Getting the wood upgrade earlier, yes, I just forgot about it until I was halfway done designing the build order, and I didn't feel like starting over. I'll do this on my next run. +25% chop rate at a cost of 300 wood and a little build time (100 for storehouse + 200 for tech). It costs a similar amount to five women and their house, so the optimal point should be around when 25% of the choppers is 5, which is when there are 20 choppers. That happens around 4:30 at 59 pop. I suppose there's some merit in using the trees around the cc earlier, to reduce walk time. That might save a few seconds. Walk time to the main forest is ten seconds, so using the near trees might speed up the run by five seconds or so, considering that it only affects half of the workers and only early on. There won't be any compounding effects over time because to delay the workers by ten seconds is certainly no worse than to just wait ten seconds doing nothing at the start (all those workers would then be ten seconds late anyway). So I estimate it would just save a fixed five seconds over the whole course of the run.

Roman siege walls say they can be built in own, neutral, or enemy territory. If you build them in neutral territory they will convert to Gaia within 25 seconds. This may be okay but it does mean you don't control the gates. If you build them in enemy territory they will convert to the enemy within 25 seconds. The enemy can then just delete them. You can't capture them back and you can't garrison them to stop them from converting. What's the point?

There should also be an a27 section by now.

Yes, and where is the a26 section?

There's no appropriate place on the replays forum to post a26 replays so I'll put it here. As a hobby, instead of actually playing 0ad, I've been trying to theoretically optimize build order for the fastest boom. I developed a program that roughly simulates a single player 0ad economy and executes a pre-set build order. Using that program, and a good deal of trial and error, I developed a Maurya build order to get to 220 population quickly. Now, I have tried playing out that build order in single player 0ad, with lots of pauses and 0.1x speed to match it as accurately as possible. The attached replay is an age 1 boom with Mauryas, with only the starting berry patch and no hunt except chickens. I get to 200 population by 11:00, and 220 units (not just population, but actually trained units) by 11:44. 141 archers, 75 women, 3 spearmen, 1 elephant. More women would have meant a faster boom, but I limited them because, after all, the point of a boom is to get a big army. This seems pretty fast for a first try, and I made a lot of mistakes and compromises along the way so booming a lot faster should be possible. You can see around 100 pop where I slip from strictly following the planned build order, keeping food and wood bank really low, to sort of winging it and getting too much wood and not enough food. Also, clearly if I made use of extra berry patches and hunting it could be faster; the only reason I didn't do this was to keep it simple. Of course, really what we want to optimize is a boom to age III with blacksmith upgrades and a hero, but that's a bit more complicated. commands.txt metadata.json

The goats could climb the outside of the towers.

You just need to have a lot of your own units guarding several rams. Then the swordsmen will die before they can kill all the rams.

Why not take some advice from history about the role of skirmishers and ranged units vs the role of spearmen? Historically, Hellenistic city-states would go into battle with a large force of hoplites in phalanx, which would meet in melee with the enemy phalanx of hoplites. There would also be thousands of less-equipped skirmishers and infantry around with slings and throwing weapons. The role of the skirmishers would be to harass the enemy skirmishers, protect the flanks, and generally be an irritation before the hoplite vs hoplite battle begins. Once the hoplites start fighting, the skirmishers have little to do, because they can't shoot at the hoplites once they meet, or they would hit the backs of their own hoplites. Also, hoplite shields and armor were really good protection against missile weapons aimed at the front. So, hoplites can tank a lot of ranged fire especially when shot from the front, and friendly fire was an important consideration in who the slingers and javelineers could hit. The norm of 0ad where the skirmishers fire right into the melee and miraculously only hit enemy units is unrealistic and ahistorical. And from a gameplay perspective it devalues hoplites. Once the melee starts, the shooting should stop. Perhaps there could be a friendly-fire rule where slingers, skirmishers, and archers will do friendly fire damage, and won't automatically target an enemy if a friend is adjacent to it, unless the enemy is a higher value target.

Well, it's just where the gatherer counts would be, only the numbers are bigger. Here's a screenshot of a replay. You can see that 1337rtslegend here has a food income over 1000/min from farms and berries and a wood income of only around 500/min. Indeed, fast forwarding the replay a minute, he ends up with 900 food he can't spend. So that's an example of how it could be useful to compare food income to wood income to anticipate a problem ahead of time. The second picture is myself in a similar situation, with too many on berries giving an income over 1000, and less than half that income of wood. Sure enough, a minute later I have way too much food.

This mod shows current income per minute for each resource (food, wood, stone, metal) in the top bar, replacing the gatherer counts. Includes gathered resources, trickle income, and trade income. I've attached the mod to this post as a .zip. I also put it on mod.io, but that's pending approval. Why do you want to see current income per minute? Well, suppose you're doing some unusual builds with hunting or fishing. The food income will directly show you how your build compares to a more typical farming build. It can help you anticipate when you're going to have too much food or too much wood soon. A good rule of thumb in some parts of the game is to keep wood income around 30% higher than food income, so you can build houses/farms/storehouses as well as citizens. You can also use this mod to see directly how researching different technologies or building closer storehouses affects net gather rates. Or to decide how many barracks you need, to produce soldiers at the same rate as your income. This mod is compatible with either standard a26 or the Community Mod. However, if you want to use it with the Community Mod you'll need to make sure this mod appears below the Community Mod in your mod list - otherwise the Community Mod will clobber some files needed for this. A smooth and responsive estimate of income is obtained by taking a rate for every income source - every citizen chopping a tree or picking berries, every fishing boat and trader. The rate is the amount of income from each gatherer divided by the time it took for the gatherer to get that much income. You might wonder, why bother with that, why not just take a rolling average of total resources harvested? The answer is that if the average is taken over too long a period - say, 30 seconds - then it won't be very responsive to short-term changes in income. If the time average is too short - say, 10 seconds - then it won't be smooth, swinging wildly up and down because of random differences in when each worker returns to the dropsite. By instead summing up rates from each income source, we get the best of both worlds. Each gatherer's average rate is nearly constant over time, providing smoothness, and we can responsively detect when a gatherer starts or stops gathering. The time for the income estimate to respond to a gatherer starting or stopping is roughly the length of one gathering cycle. showresourceincome.zip

Well, couldn't you have all the files in gitlab, but have a script that only copies over the changed files when it's time to put out a new verified patch version? Something like (bash, rsync): # make a directory to put just the community mod files that # are different from a26 mkdir ~/cm_minimal/ # If ~/cm/ contains the (non-zipped) community mod, # and ~/0ad/a26 contains a source distribution of 0ad alpha 26, # this command will gather all the files from the community mod # that are different from a26 or not present in a26, and put # the filenames in files.txt, while excluding cached.xmb files rsync -ric --dry-run ~/cm/ ~/0ad/a26/binaries/data/mods/public/ | cut -d " " -f 2 | grep -v "cached.xmb" > files.txt # this command will read the files from the previous step # and copy them into cm_minimal rsync -a --files-from=files.txt ~/cm/ ~/cm_minimal/

I don't use BuildingAI.js in my mod. Why not just remove any files from the community mod that the mod doesn't touch? The community mod includes all 4610 files under the simulation directory but only touches about 260 of them.

Right now the community mod includes all the simulation/components/*.js files, but it doesn't actually change any of them. This makes it incompatible with other mods that might change those .js files. Can those .js files be removed from the community mod? I am writing a mod to estimate instantaneous player income, which has to touch a few of those files. My mod needs to touch those files to collect data to show on the GUI, but it doesn't cause any desyncs with vanilla 0ad and is compatible with vanilla 0ad, so it would also be compatible with the community mod if the community mod didn't include those .js files.