Elephants are currently not that great, so it would be bad to let spear units counter them.

Oh, bonus damage / counters were removed from the game? Sad.

From different civs. So e.g. Mauryas Swordsman have the same stats as Romans Swordsman. But they can still be different. E.g. Romans Swordsman are P1, Mauryas Swordsman are P2, and Mauryas deal +20% in P3 thanks to their final melee damage upgrade. edit: Also flavor. Instead of going to the approach like AoE2 where the many units look identical across Civs in 0AD many units have a Civ-specific look.

That was fast, @Tapothei! Thanks for putting in the effort to learn how to create a PR. You could get a source-code editor like Visual Studio Code to make things easier for you. Also, when creating a PR that solves an issue, you normally want to include this in the PR message like this: "Fixes #8781" I'll try to explain the basic Git workflow as simply as possible. I'm still learning myself, so there may be a few details I’m overlooking. The usual workflow is to fork the repository, clone your fork locally, and create a branch for your changes ( You don't want to work directly on the website for practical reasons). You commit your work and push the branch to your fork. Each contributor works on their own fork. Once the changes are ready, you open a pull request from your branch to the upstream repository, where the maintainers can review it. Also, right now your changes are on the main branch of your repository. `Check this: Normally main should not be used for development. Instead, it is kept in sync with upstream (the official 0 A.D. repository), and new changes are developed in separate branches. Pull requests are then opened from those branches.  This is an example of a PR from another contributor, notice his PR comes from another branch, called "lazy-actual-size": This way your main branch always stays clean and can be used to create new branches. Otherwise, if main contains previous work that wasn’t merged, those changes could end up included again in future pull requests. An if you later want to work on something else and sync your main branch with upstream, you may run into problems because git will detect local changes that don’t match upstream. By creating separate branches from main, you isolate each set of changes. This makes it easier to keep main clean, revisit your work later, and work on multiple things in parallel. I also noticed that your PR contains many separate commits. Like this: In these cases, it is usually recommended to squash (git command) them into a single commit. This makes it easier for maintainers to review the changes and keep a clean history of the proposed modifications. I know this might seem completely confusing right now. But if you plan to keep contributing, learning it will make things much easier in the long run.It can take months and plenty of frustration to get comfortable with the basics of git. So if you decide to learn it, be patient with yourself. It gets a little easier every day. Well, I don’t want to overwhelm you any further. You’ve already made it this far, and that’s worth recognizing. Thank you!  

NO. KEEP MY ELEPHANTS AWAY FROM THIS! ELEPHANTS ARE NOT CAVALRY