Nescio

No, I don't think many people are happy with how exactly rams are in 0 A.D. Stating the problem is easy, and there is no shortage of ideas to address it either. However, the difficulty is getting consensus one particular proposal is better than the alternatives. For what's worth, my prefered solution would be to introduce a four damage type (thrust), such that: macemen inflict only crush damage swordsmen inflict only hack damage spearmen inflict only thrust damage archers inflict only pierce damage In combination with negative resistance levels (D2975) that would also allow for removing the hard-coded bonus attacks of spearmen vs cavalry. Actually rams were capturable in the past, but that made them rather useless, and was thus undone (18037) in A21. There is also a proposal to make other siege engines uncapturable too: (D2493).

0ad/binaries/system/pyrogenesis

Yes, exactly! The object size numbers are left, top, right, bottom. The percentages and relative numbers are necessary because not everyone has the same resolution.

Yes, the size and location are defined in XML and can be easily edited (see gui/session/session.xml line 75). However, being able to resize or move the minimap around in game is more complicated, as is “switching between different thematical maps”.

Uncommon does not mean it never happens. I for one like to group all my unit-producing structures together, and sometimes I select both units and structures simultaneously. A very good point! It's intentional, yes: resources can't move, form formations, build structures, train units, research technologies, etc., therefore they don't have the right and left selection panels. In contrast, (many) units can, therefore they have those panels, even though they're occassionally empty. This is not trivial. Most of the GUI is defined in XML or JavaScript, however, the minimap is partially generated by th C++ source code, complicating things. I believe the general idea behind 0 A.D.'s current session GUI design is not to swamp players with too many numbers. Whether an unit is an archer or javelineer is more important information than whether e.g. their attack damage is 6.9 or 7.1. That shouldn't be too difficult to implement. You could have a look at the gatherer counts patch (D3155/rP24357). I don't know if someone is already working on an idle worker counter( @Freagarach?). A lot more is done than what's advertised on the forums. I recommend playing the svn development version from time to time.

You don't need to install any version of SpiderMonkey, the 0 A.D. repository includes the required version by default. The --with-system-mozjs is optional, just omit it. Looking at your first post, I understand you want to install the latest stable, but patch it to work with your AMD Ryzen processor. A23b was released two years ago, so you don't want the latest svn development version. What I would recommend you to do is: get the full A23b version from https://github.com/0ad/0ad/tree/eb2fc5c53d0c55de308be6dc5bb7f952cfbc210d patch the relevant files to work with your CPU follow the build instructions from two years ago: https://trac.wildfiregames.com/wiki/BuildInstructions?version=337

So I did a make clean and a clean-workspaces.sh, then ran update-workspaces --with-system-mozjs and make, which ended with: ==== Building pyrogenesis (release) ==== Creating obj/pyrogenesis_Release main.cpp Linking pyrogenesis /usr/bin/ld: ../../../binaries/system/libscriptinterface.a(ScriptInterface.o): in function `JSStructuredCloneData::~JSStructuredCloneData()': /usr/include/mozjs-78/js/StructuredClone.h:459: undefined reference to `js::SharedArrayRawBufferRefs::~SharedArrayRawBufferRefs()' /usr/bin/ld: /usr/include/mozjs-78/js/StructuredClone.h:459: undefined reference to `js::SharedArrayRawBufferRefs::~SharedArrayRawBufferRefs()' collect2: error: ld returned 1 exit status make[1]: *** [pyrogenesis.make:81: ../../../binaries/system/pyrogenesis] Error 1 make: *** [Makefile:71: pyrogenesis] Error 2 When trying to run binaries/system/test or pyrogenesis the response is “No such file or directory”. Then I did a clean again, applied D3127, and ran update-workspaces --with-system-mozjs again, which quickly stopped, ending with: string_sha1.c string_startswith.c term_textColor.c zip_extract.c Linking Premake5 make: Leaving directory '/home/b/Projects/0ad/build/premake/premake5/build/gmake2.unix' Premake args: --with-system-mozjs --atlas Error: /home/b/Projects/0ad/build/premake/pkgconfig/pkgconfig.lua:89: attempt to call a nil value (global 'aftersysincludedirs') ERROR: Premake failed

@wraitii, could you specify what dependencies are needed for SpiderMonkey and what the requirements are for the rest of the game? https://trac.wildfiregames.com/wiki/BuildInstructions lists a --with-system-mozjs option. I have the relevant package installed (mozjs78-devel-78.6.0-1.fc33.x86_64) and tried compiling 0 A.D. with it, but it failed, unfortunately. Being able to use the distribution's shared package would save disk space and compilation time.

Today it's a year ago that I started this thread. Dozens of gameplay balance patches have been reviewed and committed since then. Many thanks to all who participated! However, there are still dozens of open gameplay patches and more will be added. For a full list, see https://code.wildfiregames.com/search/query/4pPnEvE_Ol0A/ or the opening post.

@radopenev, did it work at some point in the past? If you're experiencing errors you didn't encounter before, you should try doing a clean: cd build/workspaces/gcc/ make clean cd ../ sh clean-workspaces.sh cd ../../ and update (svn up or git pull), then build the game again. Could you check which version of fmt you have installed?

@nifa, first of all, are you using the latest stable (A23) or the svn development version (A24)? The stable is fine if you just want to play the game or want to experiment with modifying it, but if you want your changes included into the default distribution, then you should work from the development version. See https://trac.wildfiregames.com/wiki/BuildInstructions for how to get it running, if you've not done so already. Most of the interface is written in JavaScript (*.js) and located under binaries/data/mods/public/gui/ Here are three small patches I wrote: https://code.wildfiregames.com/D2247 https://code.wildfiregames.com/D2984 https://code.wildfiregames.com/D2985 They're rather minor but can help you to familiarize yourself with the relevant files.

@gameboy, feel free to help translating 0 A.D. at https://www.transifex.com/wildfire-games/0ad/ Currently simplified Chinese (PRC) is at 92.8% and traditional Chinese (ROC) at 80.7% Doesn't it actually run twice a week, on Monday mornings too?

Indeed, having a match option would be great. We already have a “disable spies” toggle, but ideally I'd like to see: espionage never with technology [default] always share territory roots with allies: never with technology always [default] share vision with allies: never with technology [default] always share dropsites with allies: never with technology [default] always share resources with allies: never [default] with technology always For the last one, I suppose population should be excluded.

Well, I don't have objections to including a generic `template_obstruction.xml` in the public mod, provided it does not include more lines than strictly necessary. Have a look at the trigger points.

@hyperion, you're right, commits such as 15713 or 19095 ought to be avoided. On the other hand, committing every single modification separately is undesirable too. Where to draw the line is always a bit arbitrary. D2493, D2494, D2495 affect the same entities; I did it in three because each of those can make sense on its own (or not) and can be implemented indepently. D2494 removes splash attacks and raises default damage of artillery, but having one patch removing splash attacks and another raising default damage is not really an improvement, these changes make much more sense together than they do separately. Likewise, the <PreferredClasses> changes are because of the damage changes. You have a point that the summary does not really explain why the patch is as it is. I'll rewrite the summary to be more argumentative rather than descriptive. One problem is that the actual splash damage inflicted depends not just on the splash radius, but also on the distance from the centre of the entity hit; because structures (and warships) tend to have long footprints (longer than the splash radius), they don't take any splash damage in practice. Also, the AI does not seem able to take splash damage into account. Another issue is that ancient missiles were not exploding shells; splash damage is anachronistic. To be clear, I'm certainly not arguing to remove the mechanic. I'm actually in favour of having a cheat unit that has a splash attack (perhaps a mortar; or some Greek fire, or the dragon?). Anyway, this discussion is getting quite specific. Could we please continue it over there on phabricator ( https://code.wildfiregames.com/D2494 ), where the actual review is supposed to take place?

Thank you for your feedback! See the opening post or https://code.wildfiregames.com/search/query/4pPnEvE_Ol0A/ for a full list of open gameplay patches. All changes are related. While I like splash damage in theory, in practice it's rather flawed. The aim of the patch is to have artillery attacks that are easier to understand and balance. This deserves an explanation. First of all, I like diversity . I fully agree civilizations are currently rather similar and ought to be diversified. However, differentiation for the sake of differentiation is not always desirable. If something makes sense, it can be kept, but if something doesn't make sense, it ought to be removed. The aim of these, and other, patches is not to make civs more similar, it is to work towards a clean and consistent situation. Proposals for further differentiation (e.g. new civ bonuses) are certainly welcome!

For your information, it has been committed: https://code.wildfiregames.com/rP24393 (finally!)

Yes, they look weathered, those Han fortifications are over two thousand years old; the fact they survived at all is mostly thanks to the desert climate and low population density of Gansu. As stated earlier, rammed-earth walls were (and are) typically left unfinished; their exact colour depends on the material used (the local subsoil), but yes, it tends to be a sandy shade. The Han imperial capital was at Chang'an; no Han fortifications are still standing there, the city was razed and rebuilt a couple of times in its history; it's now part of Xi'an, the capital of Shaanxi, and one of the larger multi-million cities in China. What has survived there is a section of a Ming-dynasty city wall: Ignore the bricks, but look at the colour of the interior.

Yes, rammed earth is known by a variety of terms, taipa is the Portuguese name, hāngtǔ the Chinese. Paul A. Jaquin, Charles E. Augarde, Christopher M. Gerrard “Chronological Description of the Spatial Development of Rammed Earth Techniques” International Journal of Architectural Heritage 2.4 (2008) 377–400 https://doi.org/10.1080/15583050801958826 is an overview describing usage around the world. Note that there are two independent traditions, one originating in Northern China and another in the Near East; apparently the Phoenicians and Carthaginians introduced the technique to the Western Mediterranean. An important difference is that the Phoenicians already used wooden formwork, which allowed for narrower and straighter walls, whereas in China formwork was known but “a ‘true’ rammed earth technique was first developed” only after the Han dynasty. [EDIT] Apparently @Genava55 found the same article while I was writing this. Basically, ancient Chinese city walls belong to type 2.

No. Plaster interferes with its ability to “breathe”. It's important to emphasize rammed earth is a fundamentally different technique than mudbrick or adobe. Rammed earth was used for thick defensive walls and for erecting platforms upon which other structures could be built. In contrast, for ordinary Chinese structures the primary building material is wood; they had simple, non-load bearing walls that could be plastered, yes. *Han. As you know, I like consistency, and I think all wallsets should use the same wall lenghts. (I'm therefore also in favour of slightly resizing ptol and sele walls.) However, wall thickness isn't fixed, nor is height, it varies from civ to civ in 0 A.D.. The walls of the Mauryas especially stand out, theirs are much taller, thanks to their roofs, but less than half as thick as Roman walls. Both the Servian and the Aurelian walls of Rome were less than 4 m thick; the thickest walls of Constantinople were up to 6 m thick. In ancient China city walls of up to 40 m thick have been found, so having Chinese walls in game that are only two to three times as thick doesn't seem excessive. The colour is fine, but the pattern is not. Moreover, those cracks will get repetitive. Rammed earth was erected in horizontal layers; it would be nice if the texture could convey that. To better show what I mean, here are some pictures of the Great Wall at the Jiayu pass in Gansu, from the Ming dynasty, mind: [EDIT] For remains from the Han dynasty, see:

Sure, I know all that. Didn't someone write “a language is a dialect with an army and navy”? Differences between American and British English are much smaller, than, say, between Cockney and Scouse. If Arabic written in Egypt is indeed different from the standard form, then yes, having an Egyptian Arabic translation is fine. But there is no point in keeping a 0% translated language variety if no such thing exists.

Why would wall thickness be “an issue for certain maps”, though? And if it is, why is that a problem? Maps use actors and simulation entities, but they don't dictate them. Not all maps have to use walls, just like ships aren't used on non-water maps. Why? Romans can't upgrade palisades into siege walls, or siege walls into city walls. They're three separate sets. No, rammed earth is not the same as mud. I posted some photographs earlier, and the wikipedia page has more images.

It's not about the amount of work, but whether it is meaningful. So if written Spanish in Argentine or Chile is really different from written Spanish in Spain, then yes, continue maintaining them, and add variants for Bolivia, Peru, etc. as well. But if in practice all such translations would be the same, then what's the point of having them? Again, common speech is irrelevant in this case, what matters for translations of 0 A.D. is the written language. The first part is easy: As for the second part, looking at https://github.com/0ad/0ad/tree/eb2fc5c53d0c55de308be6dc5bb7f952cfbc210d/binaries/data/mods/public/l10n , it seems ar_EG, ar_SA, kn, ku, si, and sw were already present in A23, which was released over two years ago. (And fr_CA was added at least four years ago, and is now only at 2.2%.) That said, I think it's fine to keep e.g. Mongolian, Swahili, Urdu, despite them being at 0% and currently having no translators, because they do have written forms clearly different from other available languages. However, I very much doubt that's true for ru_UA or zh_SG. The difference is that the vernacular is the spoken language, not written, whereas Danish, Swedish, and Norwegian all have written forms; and translations of 0 A.D. are very much written text, not spoken audio. To emphasize, I'm not at all opposed to having varieties of a language; I'm merely questioning whether some (written) translations would actually be any different from each other.

While such walls would be larger than the currently existing walls, their footprints are still smaller than those of civic centres, or wonders. Moreover, walls are not built in every match; the AI never does, and on small maps an early rush can already win the game. Besides, I'm proposing giving the Han three sets of walls, making them stand out from other civs and giving players a choice; the largest walls would mean a significant investment in time. By the way, I'd love to see a proper Gallic wall in game! Sorry, I still fail to see what's wrong. But if you understand what the problem is and how it can be fixed, could you make a pull request to https://github.com/0ADMods/han_china ?

To be clear, I'm not saying there are no differences: no doubt native speakers can easily hear where someone is from, and people from different parts of the world may have trouble understanding each other. However, are the differences limited to the vernacular, or do they extend into the written language as well? (I don't know, I don't live in Quebec.) For the purposes of localization, the vernacular is irrelevant, only the written language matters. So the question is, would a translation of 0 A.D. into Canadian French look actually any different from one into standard French?