fatherbushido

@wowgetoffyourcellphone if that's the emiter source issue, it will be solved in D921 (what I ref as B1): sound will be emit at a position. But the attack sound will still be in the attacker template, so I guess it's enough and what I ref as B2 is not needed.

@Pureon@wowgetoffyourcellphone Your input is needed for the @Mate-86's work on D921. Actually it's simple to have both. Currently, we have a A) sound emited for hit units grabbed from the attacker (attack_impact). We could have B1) a projectile impact sound (always emited, even when ground is hitten) (attack_impact) grabbed from attacker B2) and a sound emited for hit (damaged) units grabbed from the target. (We could reuse for them the previous attack_impact sounds?) (name suggestion? armor_impact?) We first think to only have B1) but adding B2) is trivial (just will need some templates editing then).

Ok, I will sleep then.

sorry, you guys know.

It seems you like that new forum stuff.

You can still download it.

I was serious when talking of a17

@Nescio I read the pdf and go through the different folders. It's a well thought work.

I will try to clean it

I have those errors when selecting some special textures in atlas (yellow, blue,...) ERROR: Failed to decode texture "art/textures/terrain/types/yellow.png" libpng error: IDAT: chunk data is too large tex_png.cpp(294): Function call failed: return value was -1 (Function failed (no details available)) Function call failed: return value was -1 (Function failed (no details available)) Location: tex_png.cpp:294 (decode) Call stack: (0x562613557e6e) ./binaries/system/pyrogenesis(+0x5dce6e) [0x562613557e6e] (0x5626134f9251) ./binaries/system/pyrogenesis(+0x57e251) [0x5626134f9251] (0x5626134fb0fc) ./binaries/system/pyrogenesis(+0x5800fc) [0x5626134fb0fc] (0x56261355168f) ./binaries/system/pyrogenesis(+0x5d668f) [0x56261355168f] (0x56261354e1b7) ./binaries/system/pyrogenesis(+0x5d31b7) [0x56261354e1b7] (0x562613342d71) ./binaries/system/pyrogenesis(+0x3c7d71) [0x562613342d71] (0x5626132e8fe5) ./binaries/system/pyrogenesis(+0x36dfe5) [0x5626132e8fe5] (0x56261340d43d) ./binaries/system/pyrogenesis(+0x49243d) [0x56261340d43d] (0x7f0a53eac494) /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f0a53eac494] (0x7f0a53bf0abf) /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f0a53bf0abf] errno = 0 (No error reported here) OS error = ?

What about a17?

Well, next time, give the mins to look at. (edit: ) Well so 42 boltshooters (!) don't let people come near them. What do you want to conclude from that?

I meant 0 H/P/C non splash damage.

They should have 0 damage.

Hi @Baptman67, you have to create an account on transifex (it's where the translation is handled): https://www.transifex.com/wildfire-games/0ad/ edit: by the way, as you are french, I might recommend you that nice article in french about the last alpha http://linuxfr.org/news/sortie-de-0-ad-alpha-22-venustas

It seems there is some fallback to athen in maps/random/rmgen/wall_builder.js You might look at adding your civ to the abobe block in the previous file. var wallScaleByType = { "athen": 1.5, "brit": 1.5, "cart": 1.8, "gaul": 1.5, "iber": 1.5, "mace": 1.5, "maur": 1.5, "pers": 1.5, "ptol": 1.5, "rome": 1.5, "sele": 1.5, "spart": 1.5, "rome_siege": 1.5 };

Editing templates is the easy part and could be done in alpha 776543 or in any mod. Providing the feature and the previous code background was the hard part.

25. It seems doable by putting those techs as requirements and using pairs or things like that for them.

23. It's the full damage * (1 - x^2 / r^2) where r is the splash radius and x the distance. The distance factor is 'continuous' (((quotes for representation of numbers))). 23 bis. I would say it's both. Let's imagine the point we aim. Landing point will be randomly distributed around that point following a bivariate gaussian law (something like the picture above). The bigger the spread is, the less concentrated it is (39.3% of the hits are in disk of the spread radius, 86.5% of the hits are in a disk of 2 * spread radius, 98.9% of the hits are in a disk of 3 * spread radius). For convenience, think that this circle is placed at 100m (and then use proportionality). (Thanks to @quantumstate for having done all those things).

@Nescio About 19. Rank are not hardcoded anywhere execpting in the xml schema (I checked the AI too). Just some random trigger maps perhaps use explicitly elite templates. That won't work. You need to change the following schema in Identity.js (here only three choice are allowed). (If you do such a thing, I would recommend you to not use the _b convention for naming the initial rank.)

@Nescio: If you just want to modify the gain multiplier of a trader, you just have to modify Trader/TraderMultiplier see: Trader.prototype.Schema = "<a:help>Lets the unit generate resouces while moving between markets (or docks in case of water trading).</a:help>" + "<a:example>" + "<GainMultiplier>0.75</GainMultiplier>" + "</a:example>" + "<element name='GainMultiplier' a:help='Trader gain for a 100m distance'>" + "<ref name='positiveDecimal'/>" + "</element>"; Currently the trader gain is basically gainMultiplier * (distanceBetweenMarkets)^2. If you want to modify that, you just have to modify L43 of simulation/helpers/TraderGain.js (or more if you want a more complex system). For circular splash damage, the damage is dealt to all units in the radius with a quadratic fall off with the distance. For linear splash damage, it's the same but the shape is a rectangle 'starting' at the impact of length radius and of width 2 * radius / 5. (With also a quadratic falloff). When the target location is predicted an error is added. That is a 2d gaussian error and the spread is the standard deviation of that gaussian (if the target is at 100 m). To be more explicit, as explained in the schema doc: "a disk at 100 meters from the attacker with this radius (2x this radius, 3x this radius) is expected to include the landing points of 39.3% (86.5%, 98.9%) of the rounds."

(Take care that it affects repeat time and not prepare time)

I can't agree with a so closed view of the developement of the game.

Right ;-) (if I am not wrong. Note for myself: write tests). Let's assume you'll use stackable auras and that you don't use the mauryan tech. 100 * 1.1 * 1.1 + 10 + 10 (Here the affected entity is the Player itself. We compute all multiplications of all auras which affect it then additions.) ;-) Oh that (I thought you wanted auras and tech to modify rank). You can do it but you need to change the schema in Identity component to use numbers, but there will be many things to change. (I don't recommend to do it in an hacky way, but that's an idea to explore). By default, auras are not stackable. You can do it by adding stackable: "true" in the aura template. (Take care of potential perfomance issue perhaps)

Thx for the ref. @vladislavbelov: some warnings seem not related to that, do they? edit: those ones remain and