Not really satisfied with this solution, since we now try to fix translations ourselfs for some specifc cases (n=1, n=2, n>2). That does no allow the full generality:

(03:29:46 PM) elexis: v1 something v2 somethingelse ..., v(n-1) somethingelsetoo v(n)

Also as the Gnu getText documentation says The consequence of this is that application writers should not try to solve the problem in their code.

so you suggest to add variable to keep track if gpu skinning was disabled or to write custom getter for gpuskinning and disable it silently?

Successful build - Chance fights ever on the side of the prudent.

fix check

Successful build - Chance fights ever on the side of the prudent.

disable gpuskinning if glsl is disabled

Successful build - Chance fights ever on the side of the prudent.

fix test

Issue with parabolic query:

don't forget to revert the config2 change

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Successful build - Chance fights ever on the side of the prudent.

Don't apply patches on patches bb, or at least work on 1 thing at the same time...

Ideally there would be one rubble and one foundation per building but it's just too much work

Reuse the cmpPosition's turnRate, let formations really turn. Fixes jittering

Successful build - Chance fights ever on the side of the prudent.

Don't include useless headers instead

Successful build - Chance fights ever on the side of the prudent.

Remove newlines

Fix build when passing --without-audio

Line 63 is indeed different in the three 3x3 foundations.
And found them in Atlas:

actually use sort 2n -> n*logn
fix some comments

Scaffoldings not the ground thing. Need to set the variant in actor viewer

IIRC scaffolds are different for the wall foundations.

Are they? The actors looked the same in Atlas.

IIRC scaffolds are different for the wall foundations.

Successful build - Chance fights ever on the side of the prudent.

Fix dumb race condition

One could take look into performQuery function in parabolic range branch and see this checks looks like redundant
https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/simulation2/components/CCmpRangeManager.cpp$1210

No sickle

In D2995#132340, @Nescio wrote:

Different context == different translation

Good to know! I assume that also applies to no context? By the way, could you also add context to the <GenericName> of those templates, to allow consistency with <AttackName>?

no context != some context, also usually strings without context ought to be translated with a translate call, not a translateWithContext call. And those are pulled from a different part of the dictionary (the without context part).
In theory we can add context in a similar way for any template node (including GenericName). The GenericName translation code flow is however slightly different than we have for AttackName, so it isn't completely straightforward. In any case this should be the subject of another revision.

Successful build - Chance fights ever on the side of the prudent.

Different context == different translation

Good to know! I assume that also applies to no context? By the way, could you also add context to the <GenericName> of those templates, to allow consistency with <AttackName>?

You are right, also founda new type: kush_champ_amum has a Sickle. Also some heroes. 9 Singles on 51 swords now
EDIT: somehow feel Sickle is the wrong word, but can't find the correct one...

It's a khopesh, which is not a sickle-sword (i.e. pointing forward and sharp on the inside of the curve), but an axe-sword (i.e. pointing backwards and sharp on the outside of the curve). It's probably better to stick with ‘single-edged sword’, though.

outdated

This patch should move actor-related nodes (footprint, obstruction, rubble, foundation actor) from the generic template_structure_* to the specific structures/* templates. Everything else ought to be split off.

• remove unnecessary campaign_city_* <Attack> lines

Could be the --macosx-version-min=10.9 flag cc @Itms

Mac-OS bundle is failing since this commit, see jenkins logs
../../../source/lib/sysdep/os/osx/osx_atlas.mm:49:2: error: type arguments cannot be applied to non-parameterized class 'NSDictionary'

Successful build - Chance fights ever on the side of the prudent.

In D2995#132196, @Nescio wrote:

Below the translation field, there is a "more info" box displayed. The third item says "Context", the context string added here will be displayed there.

If I understand correctly, strings are translated on transifex, not occurrences, i.e. if a particular string is translated, all occurrences that are exactly the same have the same translation, which is typically fine for full sentences or longer texts. Although context is displayed on transifex, it's essentially meta-data, and since it does not alter the string, I fear both "Sword" (with double-edged context) and "Sword" (with single-edged context) will have the same translation. That said, I don't know the inner workings of transifex and I didn't test for this particular case

A very valid question, but transifex is slightly smarter:

1. It translates strings per module (see the grouping of strings in transifex). This ofcourse does not help in this case, since all strings will be in Sim. Templates.
2. Transifex cares about the context. Strings with different context will appear as different items in the list (e.g look at the "Range:" string in Misc. GUI, one without context, one with "aura" context). Also as you can see in the code the context is passed to the translate call (translateWithContext(context, string) and that will choose the translation of the tuple (context, string) so context should help us in this case!!. Different context == different translation

And then it is replaced by the correct term, when wanted. If I counted correctly there are 20 different sword wielding units, of which 4 use a single-edged one. I believe avoiding duplication legitimizes settting the double-edged variant in the parent.

Did you check champions too? Those usually don't have swordsman in their file name. Anyway, if single-edged blades are indeed a small minority, I agree it's better to set Sword in the generic template parent and a different string in the relevant children. Perhaps ‘Saber’? It's a bit anachronistic, but probably clearer than e.g. ‘Backsword’.

You are right, also founda new type: kush_champ_amum has a Sickle. Also some heroes. 9 Singles on 51 swords now
EDIT: somehow feel Sickle is the wrong word, but can't find the correct one...

Fixed by rP24071

More compile errors (why didn't the bots find this?):

/usr/bin/ld: ../../../binaries/system/liblowlevel.a(snd.o): in function `snd_detect()':
/home/Bouke/0ad/SVNcom/0ad/build/workspaces/gcc/../../../source/lib/snd.cpp:48: undefined reference to `alcIsExtensionPresent'
/usr/bin/ld: /home/Bouke/0ad/SVNcom/0ad/build/workspaces/gcc/../../../source/lib/snd.cpp:65: undefined reference to `alGetString'
/usr/bin/ld: /home/Bouke/0ad/SVNcom/0ad/build/workspaces/gcc/../../../source/lib/snd.cpp:50: undefined reference to `alcIsExtensionPresent'
/usr/bin/ld: /home/Bouke/0ad/SVNcom/0ad/build/workspaces/gcc/../../../source/lib/snd.cpp:53: undefined reference to `alcGetString'
/usr/bin/ld: /home/Bouke/0ad/SVNcom/0ad/build/workspaces/gcc/../../../source/lib/snd.cpp:51: undefined reference to `alcGetString'
collect2: error: ld returned 1 exit status
make[1]: *** [pyrogenesis.make:81: ../../../binaries/system/pyrogenesis] Error 1
make: *** [Makefile:71: pyrogenesis] Error 2

Those look like the openAL functions used in snd_detect(). Looks like this patch is not only correct, but also necessairy by the looks of these errors. To solve the errors probably snd.h function shouldn't be compiled.

Ahh okay, thanks, needs @s0600204 then...

What would be the use case of this class?

https://code.wildfiregames.com/D2720#115075

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Remove useless change

Merge snd block, update message, fix compilation, (Config 2 change is just for the CI)

One obstruction for adding this considering the maintainability.

updating workspace --without-audio gives

../../../source/soundmanager/scripting/SoundGroup.cpp: In member function ‘void CSoundGroup::SetDefaultValues()’:
../../../source/soundmanager/scripting/SoundGroup.cpp:75:2: error: ‘m_Seed’ was not declared in this scope
   75 |  m_Seed = 0;
      |  ^~~~~~

Very good points :) What about just using the vision range?
Gather a tree there, is the tree gone, _look_ for another tree.

On the caching: since we already listen to the modifactionUpdate messages adding the cache does not lower much performance. It gains very little performance in execution. But lowers the performance of (de)serialisation and makes the OOS logs unnecessarily larger.

Observers can now see the "proper" trading ratios, albeit they lag a bit behind in MP.

comments

Proper fixing indeed out of scope especially since more functions/buttons are probably affected.

• updated because of D3016

• forgot other/ structures (not the first time)

Also gives all siege wall segments the same cost-to-health ratio.

This is intimately linked with this patch. Currently wall towers are disproportionally more expensive than other wall segments because they have an <Attack>. If that's removed, then their cost ought to be proportional.

And clean up <BuildingAI> to define it only in structure templates with an <Attack>.

Done in D3016.

Structures: Same as BuildingAI in another patch, the sound is only necessary when a structure can attack, right?

Right. Done in D3016.

That can take a while before it is reviewed, sadly.

That's understandable, I reallize D2953 is quite a large patch (as is D3000). I do hope it'll make it into A24, though, since the current template_unit_fauna_* situation is rather messy.