Nescio

Sounds great! 0 A.D. has very limited biodiversity, so more animals are always most welcome! There are lists with animals we'd like to have at https://wildfiregames.com/forum/index.php?/topic/23840-gaia-animals/ and https://wildfiregames.com/forum/index.php?/topic/22944-fauna-requests/ but other animals can be accepted too. However, you have to be willing to release your contributions under the CC-BY-SA-3.0 license.

A clear majority seems to favour D2875 over D2806. The number of votes hasn't changed in nearly a week. For the record, I've just updated D2875, which remains principally the same, but now the same icon size is used in various panels (e.g. selection groups). This is how it looks like on minimum resolution (1024×768):

Thanks, that's good to know. So the number of objects to draw has a much larger impact than the number of lines to draw per object? Even if the total number of lines would be less under more objects?

How much worse? I understand placing e.g 42 stakes one by one is less efficient than placing one set of 42 as a whole, however, once placed, it's still the same number of lines, right? I'm not saying it must be implement, but I do believe it's worth exploring.

Maybe something that could be tried out in https://wildfiregames.com/forum/index.php?/topic/28064-request-longer-palisades/ ?

Actually I don't have a programming background, I have a background in classics, an entirely different kind of texts. I can't read or write Python either.

There are simply too many other things I want to do, learning Blender is nowhere near the top of my list. Leaving art files to people who show they understand graphical software is good enough for me. Besides, I'm very much a text-based person, I like being able to read what I'm doing, and write what I want to be done (that's why svg is great, it's basically xml).

This is something that bothered me too more than once. However, I disagree with redoing art as a workaround, it could (should?) be solved in the code. If I understand correctly, fields follow all curves of the terrain, whereas other structures are rigid objects and take the terrain height at the centre point of the structure footprint to off-set their position. In my opinion wall segments should be treated as a special case: they should not take the height at the centre of the wall segment itself, but the average of the height of the centre of the wall tower they start at and that of the wall tower they go to.

To be clear, this is just the Fortress random map. I didn't build anything myself. I merely wanted to show that realistic walls could look great in game, but then it turned out the script placed them in the opposite direction, which still looks good, though not as intended. Anyway, it turns out it could easily be solved by inserting <WallPiece> <Orientation>2</Orientation> </WallPiece> or 0, or 4, or any other multiple of 2, into the `byza_wall_long.xml` template: Which makes me wonder why specifically 1 (i.e. π rad = 180°) is chosen as the default value. (@s0600204?)

Thanks! Take your time, doing it properly is more important than doing it quickly. For the siege wall tower (and the outpost) what is to be done is clear and simple: just raise the top platform (or roof). The Greek (athen, mace, spart) and Seleucid wall towers it's more work but still quite straightforward. For the Mauryas it's more complicated. That said, I don't really now how Blender works, and my graphical skills are rather limited, so my request is obviously easier said than done. I made a simple graphic to illustrate how I think a default wall tower design ought to be, perhaps it helps: Fainter colours: surrounding wall segments. Blue: wall base, solid to parapet level. No doors, windows, or arrow slits here. The height should be the same as the height of the short, medium, long wall segments, which varies per civ. The width must be between 6 and 12, i.e. at least half of and at most the full short wall segment length (12). The depth must be at least 1 more than the depth of short, medium, long wall segments. Most wall towers are square, thus depth would be the same as width, i.e. between 6 and 12. However, non-square wall towers are perfectly fine too, e.g. a 6×12 footprint works, as do circular, octagonal, and other polygonal footprints. Green: solid corner columns supporting the platform on top. Yellow: tower chamber, hollow. Since units in 0 A.D. have a height of about 4, this room should have a height of 5. Historically this was where light artillery was deployed, not on the top platform, for multiple reasons. Firstly, they need a stable ground below them. Secondly, the strings were made from human hair (usually from female slaves and captives, but in emergencies also from citizen-born women; horse hair was an inferior substitute) and exposure to sun and rain had a negative impact. Thirdly, unlike archers, artillery can't fire at an angle below 0° (horizontal); placing them at a higher position means they have a higher maximum range but also a much higher minimum range; in siege warfare this is simply not worth the trade-off; the purpose is to prevent people from reaching the walls, increasing the safe zone in front is not helpful. Magenta: windows, two on each side, or three if the wall tower is wider than usual (e.g. cart). They're long and narrow to allow shooting both at an upwards angle for increased range, and horizontally for increased accuracy. Given that the footprint radius of infantry is 1.5, the distance from the centre of a window to the centre of the next should be 3. Red: parapet and battlements. The above is more information than you really need, I'm just explaining the reasoning behind the drawing I made, also for future reference. For the mace and sele wall towers the current footprints etc. are fine, they just need their roof replaced with a platform on top.

It turns out that the Byzantines in Millennium A.D. have four sets of wall segments, default two-sided high walls, realistic one-sided high walls, extra two-sided low walls, and realistic one-sided low walls. After making the realistic walls the default, I discovered the wall placement map script works the other way around:

@m7600, if you have the time and motivation, maybe you could try your hand at this?

This sounds really promising, I'll certainly try it out later! Looking at https://github.com/eserlxl/Arch-AI/tree/master/simulation/ai/arch-dev , it seems you basically took Petra's files and improved them to create your own version, i.e. yours does not need Petra to work, correct? Have you considered making your AI compatible with the svn development version (A24)? One minor thing, 0 A.D. is released under the GPLv2 licence, which means anything can be reused and rereleased under the same or later licence. However, the reverse is strictly speaking not true: GPLv3 files can't be used by 0 A.D. You released your files under GPLv3, which is perfectly fine, but it means they can't be legally incorporated into the public mod.

Yes, the first two are. Anyway, I was not criticizing, merely pointing out that not every chariot is a war chariot. (Also, the “huge battle axe” is actually a halberd, i.e. a two-handed pole arm. In Sun Tzu's world (5th C BC), chariots had three men: a charioteer (driver), noble (archer), and servant (with a gē (dagger-axe pole arm), in case enemies got to close); although weapons had evolved under the Han, the continuity is striking nonetheless.)

Most of the images you showed are actually travel chariots, not war chariots. I should probably have made that distinction in my previous post. Chariot warfare largely disappeared by the 1st C BC (1st C AD in Great Britain), except in India, but travel chariots continued to be used for centuries in Europe. In Qin and Han China, numerous types of non-war chariots existed, and under the Han the two-beam-one-horse chariot was invented (as opposed to the traditional single-beam-two-or-four-horses), which continued to be used in China for the next two millennia in several shapes and forms. It's especially a pity because in my opinion the Kushites have the only good-looking chariot in 0 A.D., but it's reserved for a hero. It shouldn't be too difficult to make the clothes and colours less fancy and replace the warrior with the existing champion archer?

You mean historically? Spoked-wheel war chariots spread throughout most of Eurasia during the Bronze Age (second millennium) and dominated the battlefields, and though declining in importance after the introduction of cavalry in the Iron Age (first millennium), they continued to be used in 0 A.D.'s timeframe. In China specifically chariot dominance peaked during the Spring and Autumn period (c. 771–481 or 403 BC; cf. Sun Tzu's The Art of War). During the Warring States period (c. 481 or 403–221 BC), massed infantry equipped with crossbows became a dominant army feature. Under the Qin (221–206 BC) and Early or Western Han (206 BC – AD 9) war chariots were gradually superseded by cavalry, though they continued to exist and be used on the battlefield, both chariot archers and chariot crossbowmen, as attested by numerous depictions, archaeological remains, and textual evidence. Under the Later or Eastern Han (AD 25–220) the situation was different, but that's outside 0 A.D.'s timeframe anyway. (I'd also like to see a Kushite chariot archer, as well as the addition of both bigae and quadrigae for Carthage, which are well attested, used on Sicily until the 3rd C BC, and probably longer by various Libyan tribes in North Africa. I believe I've requested them more than once elsewhere on these forums, but I agree it's a low priority.)

The perfect solution, of course, would be to redesign and reanimate the Han chariot, using the much newer assets from the public mod. However, I believe only @Alexandermb is experienced enough to do that properly. Ideally we need two Chinese war chariots, for champions a biga (two-horsed light chariot): And for heroes a quadriga (four-horsed heavy chariot):

No need to apologize, I just replied to both your pull requests on github only this morning. If just renaming would be sufficient, then I assumed we might as well delete the file. I tried that and it doesn't work. Currently with the Han China mod the Han chariot works, but those from the public mod don't; deleting the Han skeleton causes those from the public mod to work again, but then the Han chariot has errors: ERROR: art/meshes/structural/han_chariot.dae: Assertion not satisfied (line 393): failed requirement "recognised skeleton structure" ERROR: Could not load mesh 'art/meshes/structural/han_chariot.dae' ERROR: CObjectEntry::BuildVariation(): Model art/meshes/structural/han_chariot.dae failed to load I assumed this means you're missing files. However, after seeing your latest post I tried your suggestion (renaming it) and you're right, it does solve the errors, both from the public chariots and the Han chariot. So somehow the file is used, but without specifying its file name. Which again proves I don't really understand how the art folder works. Anyway, I've now merged your pull request. You can delete your github branch, if you like.

https://github.com/0ADMods/han_china/pull/22 Type the at sign followed by the github username (e.g. @StanleySweet, @Nescio0) in the pull request conversation.

Thanks! I believe it's incomplete, though. You don't have to post here on the forums whenever you make or update a pull request on https://github.com/0ADMods , you can just ping Stan (@StanleySweet) over there; for the Han China mod you can also ping me (@Nescio0). It's best to keep the discussion in a single place, i.e. in the pull request conversation.

Is 16×16 really a high resolution texture? Those pngs were created ten (!) years ago, but nowadays some people have 3840×2160 screens, therefore scaling them up is not inappropiate, hence the mod.

Actually I don't think that's true. I did the following: scale up some images: art/textures/ui/global/border/line_corner_*: 4×4 → 16×16 line_horiz.png: 256×4 → 4096×16 line_vert.png: 4×256 → 16×4096 ../session/minimap_circle_modern.png: 256×256 → 1024×1024 bundled the png images as a mod (should work with any 0 A.D. version): gui_borders.zip tried it out with gui.scale = {1, 1.5, 2, 3, 4 (not recommended)}: Downsizing looks fine. Please try it out and see for yourself.

Does it? It looks fine on my end. With the mod:

If it's just image stretching then it could be solved by simply scaling up those images. Here you go: borders.zip

That's caused by how the gui code handles images. (Don't ask me how it works.)