Nescio

Suggestions for new team bonuses (and also technologies) are certainly welcome! Current things that don't make much sense can be deprecated. As for the resource dropsite idea, I doubt the AI can handle it, since Petra uses the Storehouse class, rather than the DropsiteMetal etc. classes.

True, but the proposed six will catch a lot more than the current four.

Thank you, that's better! @scythetwirler appears quite inactive and could be removed from O11 too. One more thing, while I tend to put [gameplay] in the patch title, there is no guarantee others do exactly the same, so the https://code.wildfiregames.com/H13 won't capture e.g. GAMEPLAY: or [balance]. False positives (e.g. D368) are less annoying than false negatives (e.g. D2737), therefore maybe change the H13 conditions to any patch of which the tag or title includes: balanc Balanc BALANC gameplay Gameplay GAMEPLAY i.e. no brackets or colons, and no -e or -ing.

While I'm not opposed to the existence of code owners groups, the people currently included in O11 (@badosu, @borg-, @Feldfeld, @scythetwirler, @Stockfish, @ValihrAnt) are not interested in every patch, only in the subset that affect gameplay balance. Basically split the group in two: “simulation data and templates” (current repository paths) “gameplay balancing” (current people) and add a global herald rule to set the gameplay balancing group as a reviewer to any patch that includes [gameplay] in its title.

The end-users are players, and for them file names etc. are completely irrelevant. However, for future additions, modifying the game, and making maps it helps if file names are reflective of what they are. This is already the case for e.g. pyramids: gaia/ruins/pyramid_great.xml gaia/ruins/pyramid_minor.xml structures/kush_pyramid_large.xml structures/kush_pyramid_small.xml The folder paths make it clear the former two have a different function than the latter two. Likewise, it would make sense to have fruit and wood trees in separate gaia subfolders, to make it less likely map makers mistakingly pick one functionally different from what they intend. And if at some point there are e.g. different geese, then birds/goose.xml gaia/fauna/goose.xml would make it clear which one flies around and does nothing, and which one can be killed to supply food like other fauna.

To be clear, birds inherit from template_bird.xml (which already exist), not from template_gaia.xml (they never did), and they don't have <Health>, <Identity>, or <ResourceSupply> nodes, and can't be killed or selected in game; birds just fly around and are completely different and independent from other entities. Right now there is only one, the erroneously named gaia/fauna_hawk.xml (it's actually a buzzard). The chicken, peacock, etc. inherit from template_unit_fauna.xml and should thus be grouped alongside the other animals, as is already the case.

Yes, that too, but the purpose is also to have clear and unambiguous folder names, e.g. currently most structures are under structures/, but some others are under campaigns/, other/, and skirmish/. It is a straightforward change, yes, but it also involves by far the largest number of files and affects the most mods. Right now that's not possible, is it? And if there is a code change to make it possible, how would it work in game? Can both resources be gathered simultaneously? Then how do workers know which one they ought to gather? Or can one be gathered only after the other is exhausted? If so, then it could already be done with <SpawnEntityOnDeath>, and that would mean they're two separate entities, one fruit and one wood tree, right? In my opinion the most consistent option would be: birds/ ↔ template_bird.xml gaia/ ↔ template_gaia.xml rubble/ ↔ template_rubble.xml structures/ ↔ template_structure.xml territory_pulls/ ↔ template_territory_pull.xml triggers/ ↔ template_trigger_point.xml units/ ↔ template_unit.xml

That's the least controversial?

Yes, it does, actually walls can host even more infantry. You might like @Freagarach's world population setting (D2426/rP23873). Keep in mind Delenda Est modifies the development version (A24) and 0abc the latest stable (A23). I haven't actually worked on my mod in months, mostly because of the increased activity on phabricator for the next 0 A.D. version. I don't know what DoM is, but modifying 0 A.D. is really easy, the templates are simply xml. You just have to be aware files inherit values from their parent(s), see the second line in the templates (<Entity parent="*">), e.g. template_unit.xml template_unit_cavalry.xml template_unit_cavalry_ranged.xml template_unit_cavalry_ranged_javelineer.xml units/athen_cavalry_javelineer_b.xml units/athen_cavalry_javelineer_a.xml units/athen_cavalry_javelineer_e.xml

Yes, you'll probably have to modify the Upgrade.js file, perhaps others too. It's much simpler to give the templates you want to upgrade to each other the same footprint.

Actually length refers to the extent in the dominant dimension. What matters in 0 A.D. is the footprint, i.e. the radius if the footprint is circular, otherwise the width (left to right) and depth (front to back); the height (bottom to top) is unimportant. Entities (templates) can have footprints that are smaller or larger than their actors (art). Moreover, wall segments do overlap, that's how wall sets work. Entities that upgrade to each other should have the same footprints, to prevent overlap with other entities. An example: suppose you allow upgrading temples to wonders. Now someone builds a tower directly adjacent to a temple and subsequently upgrades the temple to a wonder. Because the wonder's footprint is much larger (both width and depth) than the temple's, the tower's footprint ends up inside the wonder's. As a consequence the tower can't be garrisoned or repaired by its owner, nor attack or captured by enemies, because it can't be reached, since the wonder overlaps and surrounds the tower on all sides.

See e.g. https://code.wildfiregames.com/D2760 and https://code.wildfiregames.com/D2783 To be able to properly upgrade structures, it's important both have practically the same footprint (and obstruction size and wall length). Upgrading village phase towers to town phase towers works, as does upgrading long wall segments to gates. Upgrading siege walls to stone city walls, or vice versa, would work too, since they're equally long. However, upgrading palisades to walls won't work, since palisades are much shorter. Hence https://wildfiregames.com/forum/index.php?/topic/28064-request-longer-palisades/ (Unfinished; longer palisade segments alone is not enough, larger palisade towers are needed too; for wallsets to work it's important that the corners (i.e. wall towers) have a diameter of at least 50% of the short segment length.)

Part of the problem is that the “O11: Templates (Balancing)” group is automatically added to any patch that includes a file from the simulation/data/ or simulation/templates/. Ideally only those that are explicitly labelled [gameplay] would be. Just a few examples that don't affect gameplay balance at all but have the O11 group added nonetheless: https://code.wildfiregames.com/D2948 https://code.wildfiregames.com/D2720 https://code.wildfiregames.com/D2688 There are dozens more.

D2806 was uploaded two months ago (June 8), D2875 a month later (July 12), and this poll has been around for a few weeks (July 18), so maybe it's an appropiate time for the team to make a decision? It's a visible change, but necessary for future additions, and helpful for mods.

Two articles discussing those ancient Indian stirrups: Lawrence S. Leshnik “Some Early Indian Horse-Bits and Other Bridle Equipment” American Journal of Archaeology 75.2 (April 1971) 141–150 https://doi.org/10.2307/504032 Nazer Aziz Anjum “Horse Sculpture in India” Proceedings of the Indian History Congress 72.2 (2011) 1247–1253 https://www.jstor.org/stable/44145736 There are probably more, but those are the first two I could find. It's available on Amazon (and probably elsewhere): https://www.amazon.com/Horse-How-Has-Shaped-Civilizations/dp/1933346132 There is a serious review available at https://muse.jhu.edu/article/238355 and various other reviews (e.g. at https://www.goodreads.com/book/show/1566029.Horse ) indicate it's more of a narrative written for the general public rather than a sound and critical study.

Yes, I'm aware of that. However, the Ashokan rock edicts were carved in stone (obviously); are they just text or do they have some images too? For comparison, the Achaemenid imperial rock inscriptions (e.g. Darius' tomb, Behistun inscription), by which Ashoka's were likely inspired, have some great and important examples of Persian iconography. I wouldn't be surprised if it existed even before the Mauryas then, but disappeared without a trace. (Rope isn't very durable.) Some of the horsemen in your opening posts visibly have swords. Are the toe ropes used only by melee cavalry, or also by horse archers etc.? I guess there are simply too few depictions to say anything with certainty about that? Anyway, it's a nice detail, though in the end it's up to artists (e.g. @Alexandermb) to decide whether they want to model and animate it.

It seems you may be on to something! Those slightly postdate the Mauryas, but that does not mean they did not exist earlier. Did you find any depictions of cavalry under the Mauryas? Do those have toe ropes too?

Thank you for sharing those images! Where are they from and when are they dated?

The civ code; the full name doesn't work for the simulation folder. So basically: {civ}_*.xml → {civ}/*.xml See e.g. https://github.com/0abc/0abc-a23/tree/master/simulation/templates/units/athen The great advantage is that you would end up with a few dozen folders with a few dozen files each, rather than one folder with over a thousand files. This would make things much more manageable in the long term, and also more accommodating for future additions. While it involves many files, the moves are simple and straightforward. Most of the file corrections can be done by script (sed).

Thank you! I've been saying this for years. First a bit of context: three years ago @fatherbushido wrote a ticket ( https://trac.wildfiregames.com/ticket/4770 ) for cleaning up the other/ folder and asked me to work on it. @elexis also participated in that discussion and committed most of the patches: D989 / rP21093 (special ruins in gaia to gaia/ruins/) + rP21094 (ruins from other/ to gaia/ruins/ ) + rP21095 (treasures from other/ to gaia/treasure/). D1002 / rP20403 (civ structures from other/ to structures/). D1007 / rP20473 (plane from other/ to units/). I also wrote patches for creating subfolders for fauna and flora (D1009) and geology (D1010), but those failed to generate interest and are now outdated and need to be redone from scratch. All that was in 2017. More recently, in 2019, some further clean-up was done: D1798 / rP22266 (territory_pull from other/ to special/). D1881 / rP22797 (wallset_palisade from other/ to structures/). D2083 / rP22657 (new template_territory_pull.xml and corresponding territory_pulls/ folder). D2234 / rP22982 (palisades from other/ to structures/) + rP22983 (a few forgotten map fixes). What's currently left under other/ are some gaia structures. In my opinion there ought to be a correspondence between `template_*` files and folders, i.e. everything that inherits from `template_unit.xml` belongs under units/, every file inheriting from `template_structure.xml` going to structures/, and gaia/ containing only the files that inherit from `template_gaia.xml`, as is already the case for e.g. rubble and territory pulls. Effectively this would mean the following: Flying birds inherit from `template_bird.xml`, not from `template_gaia.xml`, therefore should be moved to a new birds/ folder: https://code.wildfiregames.com/D2254 campaigns/ contains three structures and three units; that folder can be deprecated and those files moved to structures/ and units/ respectively: https://code.wildfiregames.com/D2925 other/ can be deprecated and its files moved to structures/. skirmish/ can be deprecated too: skirmish/structures/*.xml → structures/skirmish/*.xml skirmish/units/*.xml → units/skirmish/*.xml finally, animals inherit from `template_unit.xml`, not from `template_gaia.xml`, and thus ought to be moved to units/animals/. @Freagarach, if you're up to it, I suppose I could write a few more patches. While I proposed introducing fauna/, flora/, and geology/ folders in the past (see above), I've changed my mind. Flora and geology are descriptive terms based on visual appearance (i.e. art). What matters for simulation is not how things look like, but what is their function in game. In my opinion the `template_gaia_fauna*` and `template_gaia_geology*` files ought to be split in fruit, tree, rock, and ore, i.e. one file per resource subtype, as is already the case for fish, ruins, and treasure. Once that's done corresponding subfolders can be introduced under gaia/. And no, the gaia/ folder is certainly not redundant! (Just poorly named: resources would probably be more appropiate, though that isn't perfect either.)

Making random maps the default is my preferred solution: https://code.wildfiregames.com/D2926

As am I. I'm simply having difficulty imaging how it could work. Also, “cartwheel-shaped engine” is not the same as “engine with a wheel”. In that case the wheel should be located on the axis on the end, which is wound to get torsion on the sling-arm of the onager, right? But why would one use a wheel for that? A stick is much simpler and more effective; it would also remove the need for putting the machine on legs, grounding it firmly on the ground is much more stable. Exactly! Perhaps it didn't have any wheel. I suggested earlier it might have been horizontal, because a composite bow when fully drawn is more or less circular, so if it were a bow-based machine, it may have resembled a cartwheel when viewed from above. It's not perfect, but it's the only way I could make some sense of it. The pào or mangonel. That one doesn't resemble a cartwheel, nor does it have one, and if had existed in India BC, it wouldn't have disappeared, but spread from there, which didn't happen, therefore the Sarvatobhadra must have had a fundamentally different design. Again, I'm sincerely trying to figure out how it might have worked. More suggestions are welcome. Also from other people! Being unburdened by any knowledge of ancient engines could actually be an advantage.

Yes, the left selection panel needed to display five columns for formations and stances, therefore there is no reason limit barter resources to four when there is space reserved for five, hence why a fifth resource is supported. I didn't touch the top panel, though (that's beyond the purpose of the patch). The distance between the individual icons remains the same. I have a 3840×2160 screen and play with gui.scale = "2", because otherwise texts are hard to read, but even with gui.scale = "1" I have no difficulty distinguishing icons. That said, I'm biased, of course.

It's striking indeed. However, that one evidently evolved from the mangonel (“traction trebuchet”) that reached Europe only in the Early Middle Ages. Its design is much simpler to construct or use than any torsion engine, and far more powerful. If something like that already existed in 5th C BC India, then why did it disappear without consequence? Sūkarikā is a bag filled with cotton or wool to protect against stones hurled at the fortifications. This implies stones were shot more or less forward, as is the case with Greco-Roman engines, but not with mangonels and trebuchets, which hurl stones upwards and can also land behind enemy walls. Sarvatobhadra is a cartwheel-shaped device that, when spun, hurls stones. Yānaka is a rod one Daṇḍa long mounted on wheels and meant to be hurled at oncoming soldiers. Śataghni is a large pillar studded with sharp nails with a cartwheel at one end and intended to be hurled down at the enemies. The cartwheel suggests these devices belong to the same family. Jāmadagnya is a device for shooting arrows. This suggests a composite bow-based weapon (like the Mediterranean torsion engines), as does 2.18.2–3: He should, moreover, move them around and expose them to sun and wind frequently, and store differently those that may be damaged by heat, moisture, or insects. I'm trying to visualize what you mean, but I fear I simply don't understand. Could you perhaps make a drawing? Yes, but the author does not imply it predates the torsion engines we know have existed. Thanks for the article, by the way, I've read it entirely. I knew Marsden's work, so I'm not unfamiliar with the article's subject, but the French suggestion that the arms in the palintone might have swung inwards rather than outwards is new to me, and certainly worth further reading. I also really liked footnote 126, which contains the word “javelineers”, indicating I was right when proposing https://code.wildfiregames.com/D2591

Actually I meant Vegetius' epitome De Re Militari, which was written at the end of the 4th C AD, but was clearly based on several older treatises, given that many things he describes are depicted on Trajan's column. You're right, I should have written “attested” or “used”, not “invented”. It's not exactly clear when one-arm engines were first designed. However, I believe the composite bow → gastraphetes → oxybeles → ballistra → scorpio → onager → springald evolution is fairly well accepted? Like the London Eye? Indeed it is. What speaks in favour is that Greeks are known to have lived under and influenced the Mauryas. One example, the oldest of Aśoka's edicts (e.g. Kandahar rock inscription) were actually written in Greek and Aramaic. The pillars with Prakrit inscriptions were erected somewhat later in his reign. They did. During the Warring States period (5th C BC to 221 BC) siege warfare really took off and a variety of machines were invented, including oversized crossbows, ladders, siege towers, and, possibly the pào mangonel (“traction trebuchet”). It's also clear all those did not exist during the preceding Spring and Autumn period (8th C BC to 5th C BC), when warfare was very different. That Chinese war machines emerged in the same time as those in the Mediterranean is a coincidence; we know from remains their designs were very different and part of two independent traditions. In contrast, the Mauryas were very much part of the Hellenistic world.