s0600204

Bonuses are currently applied thusly: [base] * [proportional bonus] + [absolute bonus] Both +20% and +15% are proportional bonuses, so (at the point where a unit enters the overlap in the radius' of both auras, and assuming no other auras in effect) they are multiplied together to get a total +38% bonus, which is then cached. The caching allows the final calculation to be as above - which is relatively quick to calculate - rather than having to iterate through every aura active on the map, determine if they're in range, whether they should apply, etc... all several times a second. When a unit moves out of the radius of one of the auras, the cached proportional bonus is divided by the proportional bonus of the aura no longer in effect, and the result replaces the old cached value. Absolute bonuses work similarly, except they are added to (and subtracted from) one another, with the result cached: only recalculated when a unit passes in or out of another applicable aura. You might use an absolute bonus to add a given bonus regardless of the base stat (e.g. +5 resource carry capacity).

@abc1: If both auras affect whatever units you're controlling, then yes the effects will combine. @sphyrth: you're asking if 0AD is doing: [base attack] +20% +15% (equivalent to: [base attack] * 1.2 * 1.15) or [base attack] +(20 + 15)% (equivalent to: [base attack] * 1.35) I believe it's the former, which in this theoretical scenario where both auras are in effect, amounts to +38% to unit attack. @Feldfeld: Whether or not an Ally's aura affects you depends on how the aura in question has been defined. It is also possible for an Enemy's aura to affect you if defined to do so. As an example: the Ptolemaic hero Cleopatra has an aura that increases the heath of allied Heroes, and a second aura that lowers the health of enemy Heroes.

As requested, all posts off-topic (and those flaming and/or trolling) have been split elsewhere. Those with value in them may be restored in/as a different thread, later. However, to everyone who posted before the split, regardless of who they be: Be. Nice. It is acceptable to disagree with someone else. It is not acceptable to insult, to demean, or be overly aggressive in your posts. I hope that is clear to everyone. No exceptions. Oh, and please keep on-topic in future, thanks!

(Split posts out of original thread as it was off-topic there.)

For what it's worth, the warnings above for AtlasObjectXML.cpp concerning the implicit fallthroughs should no longer occur as the code has been rewritten to no longer need the break-less switch...case statements at all. @eecsninja, thank you for your patch. It is unfortunate that it wasn't included (due to it being superseded by work being undertaken pursuing another objective), but we appreciate the effort .

(./source/ps/VideoMode.cpp, line 247) Error appears self inflicted - this is the same code block as it appears in our code repository: u16 ramp[256]; SDL_CalculateGammaRamp(g_Gamma, ramp); if (SDL_SetWindowGammaRamp(m_Window, ramp, ramp, ramp) < 0) LOGWARNING("SDL_SetWindowGammaRamp failed"); Looking at the history of the file, the line in question has never read SDL_CalculateRamp. Thus, this error appears to be caused by local modification by user. Neither SDL_CalculateGammaRamp nor SDL_CalculateRamp appear anywhere else in the source files.

Your old friend is busy. Please have patience. In the meantime, you can test the proposed fix here: https://code.wildfiregames.com/D1919. If it works, then we can include it. Edit: At 10:57 UTC today, the patch was committed. Your problem should now be fixed. Don't forget to update your local copy.

The change is now live in our code repository. To use, simply add the appropriate argument: ./update-workspaces.sh --prefer-local-libs Then run make as usual. You will also need a file in /etc/ld.so.d.conf with the contents /usr/local/lib so that the runtime linker can locate the local libraries. (If you're compiling and using local libs on a regular basis, there may already be such a file present.) The build instructions on the wiki have also been updated.

Considering how we currently use fonts, it does seem odd that the source files are bundled with the game. I guess they're only there because they're in the "binaries" folder, and that folder is bundled almost in its entirety. As a loose idea as to how many distributions have the fonts available in their package repositories (stats courtesy of Repology): LinuxLibertine : 66 packages (across 20 "families") DejaVu : 145 packages (across 33 "families") FreeFont : 122 packages (across 26 "families") TeX Gyre : 37 packages (across two package names across 5 "families") And for the eastern Asian languages: Hanazono : 48 packages (across 10 "families") Japanese Kanji Source-Han-Sans : 92 packages (across 13 "families") Pan-CJK characters (Repology groups distributions by "family", e.g. Ubuntu, Debian, SteamOS, LinuxMint are one "family". If you're running LinuxMint, then as LinuxMint is derived from Ubuntu, then the repositories for the appropriate version of Ubuntu are mostly compatible with your LinuxMint system. It's not a perfect categorisation, but as a rough guide it works.) Alternatively, here's something I threw together to more easily compare some of the commonly used distributions. CentOS, Fedora, OpenSUSE, OpenMandriva, and Slackware are the ones that are noticeably problematic. Yes, Windows and OSX would most likely still need the fonts bundled with the game. The way I see it, we have three possibilities: We change nothing, but tell the packagers to exclude the "binaries/tools/fontbuilder" when packaging the "0ad-data" package for their repositories. We remove the font files entirely, make the files' respective packages a build-time-only dependency, and write instructions on where to download the files for systems that don't have a package repository or do but lack the specific packages. (The caveat is that we don't use them at build-time either...) We relocate the font files somewhere else within our repository, such as into a subdirectory under "libraries/source/". I think I personally favour a combination of the second and third: move the files and then, when we get in-game rendering working we add package dependencies and use the new location as a fallback (whether that be as the source of a 0ad-fonts package, auto-bundling of the fonts by build-osx-bundle.sh, and/or some other solution). I think the fonts we use are reasonably stable (LinuxLibertine and FreeFont haven't had any releases since 2012, and DejaVu since 2016. TeX Gyre is the most recently updated at 2018, but the release before that appears to have been 2016). I would imagine that if the typeface anatomy of fonts change too much between versions, then the font's creators would possibly get complaints from their user-base. Also, some of the fonts we use claim to be a like-for-like replacement (Gyre Pagella for Palatino), or to have the same appearance as - but a wider character range than - another font family (DejaVu for Vera), and so in theory shouldn't deviate too much from their "inspiration". I get what you mean though: having two users with what should be the same font but - due to changes between versions - are visually different could disrupt our established visual style (such as it is), or make for an inconsistent experience between users. It is true that many games get bundled with their own fonts, even on Linux systems (eg. SuperTux, SuperTuxKart).That might be down to simplicity: they have to bundle the fonts for Windows and OSX systems, so it's easiest to just do the same for Linux as well. Huh, this turned into a longer post than I anticipated. Apologies, and congratulations if you got this far without glazing over.

Well I guess the majority of projects today uses cmake and ExternalProject_Add() After a bit of research (and playing around a little with both build systems), it appears that projects that use CMake don't have to handle this because CMake handles it for them. Comparing how premake and CMake specify which libraries should be included: premake tells the linker to include a certain library but leaves it up to the linker to locate it. CMake, on the other hand, locates the library itself and, should the library not be in /usr/lib, adds the non-standard path via -rpath (an approach that might get them in trouble with certain OSes) so that both the compile-time linker (ld) and the run-time linker (ld.so) can find it. Anyhow. Taking your suggestion of adding an option to our build system: https://code.wildfiregames.com/D1747

@Angen sure. You can find slightly more up-to-date code here; and some more information/musings here, which includes links to where the civselect screen was first proposed and a ticket (that arguably went off-topic) that also uses the code.

Ach, my apologies, I mean ./build/premake/extern_libs5.lua. (Was getting late and tired.) The simplest change that should work is: --- a/build/premake/extern_libs5.lua +++ b/build/premake/extern_libs5.lua @@ -197,6 +197,8 @@ extern_lib_defs = { link_settings = function() if os.istarget("windows") or os.istarget("macosx") then add_default_lib_paths("boost") + else + syslibdirs { "/usr/local/lib" } end add_default_links({ -- The following are not strictly link dependencies on all systems, but You might have a point. I'm not familiar enough with other software projects to know how they handle this in their respective build systems. If you wish to look into it and create a patch for review (more general than the diff above), better minds than I can - and no doubt will - pass comment on it. (See here for how we accept patches.) I'm afraid real life commitments (eg. work) are going to take my focus for the next couple of days, so good luck.

The "View online" and "Decline" strings are in the "Mod Selector" resource on Transifex. "Publications" and "Terms" were translated after the RC was created.

Why should it? That path is already included for search by default. The problem is that it is searched after /usr/lib64, /usr/local/lib64 in that order (plus a couple of distro-specific paths). That's fine for the vast majority of users and systems, it's just problematic in this case. What's really annoying is that the gcc search path (for include headers) goes (by default*) /usr/local/include, /usr/include (eg. locally-generated then repo-provided); whilst the compile-time linker searches for libraries in the other direction (repo-provided then locally-generated). (Then you have the run-time linker which doesn't search /usr/local/lib{64} at all. Which does make a sort-of sense, I guess.) You could modify ./premake/external_libraries5.lua to append that to the start of the search path (so the linker searches there first - unlike gcc, ld claims not to mind paths appearing more than once); but unless you've told b2 to name the 1.68 libs with the -mt suffix, you'll also have to tell ./premake/external_libraries5.lua to stop preferring files with the suffix -mt over files without. * - 0 A.D. messes this up, hence revision.

Relevant revision: https://code.wildfiregames.com/D1695 The above, once accepted & committed, will fix the Credits screen. If there are any other translation-gaps you've come across, please make them known.

The translations are being pulled from Transifex, but the translate() calls in the JS code appear to not be used correctly. And yes, good catch @thekolian1996!

Do you happen to have another version of boost installed on your system? Perhaps version 1.53? Edit: Yeah, that appears to be it. I'm guessing at some point you've installed the boost-devel package from the CentOS repos. Unless you need this for compiling something else, I recommend you remove it. (If you do need it for compiling something else, then will that something compile with Boost 1.68, and if not - well, that's when things get interesting...)

Hi @skaiware, I'm having difficulty replicating your issue with my VM. I wonder if you could run a few things and report back the results? What is the output when the following command is run? ld --verbose | grep SEARCH_DIR | tr -s '; ' '\n; Could you provide the file pyrogenesis.make (from the folder ./build/workspaces/gcc/)? Are you trying to compile A23 or the current svn head?

Not to worry, this is to be expected. Due to work on resolving various multiplayer issues, there is a possibility that the A23 original-release and the A23 re-release is not fully 100% compatible. Thus, a new lobby instance has been created for the A23 re-release, which is what you're seeing... which has no players in it because we haven't released the re-release yet. Once we do, everyone who updates to the re-release will migrate over. An internal soundcard is one that is internal or built-in to the computer. An external soundcard is one that is connected externally to your computer via a USB, Firewire, Thunderbolt or Lightning (very, very frightening me! Galileo!... sorry) cable. If your headphones or speakers plug directly into your computer, you have an internal soundcard. If your headphones or speakers plug in to a box separate from your computer but connected by a data cable, then you might have an external soundcard. (If connected via an audio cable, then the box is more likely to be an amplifier of some description.)

(The crash with no soundcard present or available was #4786 / r19877, fixed as of r21097 (by Itms, not me)) I don't recall doing anything else regards to audio problems. Sorry. (Imarok has D1481, but that hides the messages if --nosound is passed.) As to @Servo, I think we'd need to know more. Built-in soundcard or external? Version of OpenAL being used? What programs do you have running in the background (anything that might interfere, cause the system to reset the audio connection, or take up a lot of memory)? What happens if you have some music playing in a media player (Quicktime, VLC, or other) in the background - do the errors still occur, does the music cut-out when 0AD loses audio, or something else? If we can find another program that plays ogg files through OpenAL, then we could see if that also suffers from the same problem.

Try using the arrows at the side to move 0ad above Hyrule Conquest. (Mods are loaded in the order shown, top-to-bottom. You appear to be loading them out-of-order.)

Indeed. When not zipped, the folder structure should be: ./binaries/data/mods/public/ |- art/ |- audio/ |- globalscripts/ |- [...] '- mod.json Whilst when zipped, it should be: ./binaries/data/mods/public/ '- public.zip |- art/ |- audio/ |- globalscripts/ |- [...] '- mod.json

When you extracted the zip file, how did the folder structure look? [...]/mods/public/public/[art|maps|...] or [...]/mods/public/[art|maps|...] Similarly, what is the structure of the new zip file - is there a mod.json in the root level of the new zipped file? And how exactly did you re-zip it?

Huh. On my VM, I was able to successfully compile the game with the provided gcc 4.8.5. And I did not have a package by the name of devtoolset-7-gcc (or similar) installed at all. But if you're telling me that it is required for someone using a physical machine, then so be it.

With due respect, according to the list of packages on the CentOS 7 primary mirror, gcc 4.8.5 has been available since April 25th.