I really fail to see how you want to find a typo in a name automically.

There's automatically and then there's "easily". We could detect close-names (such as capitalized/uncapitalized versions of the same string) quite easily with a script, and likewise typos aren't too complicated. Simply outputting all "known" status effect node-names would make it obvious if there are duplicates, and that's not extremely difficult to do.

This patch has maximal gameplay impact and minimal fixed compared to D2837, D2913 and D3021

In D3021#132508, @Freagarach wrote:

Also chasing is beyond broken

I actually find it a tad easier to hunt now, since the hunt does not speed away ^^

Have you tried attacking an infantry unit which is walking away with melee cav?

In D2808#132511, @wraitii wrote:

I somewhat disagree with @bb -> we have people looking at our templates quite closely,

Currently maybe, but we can't know if that is sustainable.

and we're supposed to test things,

I really fail to see how you want to find a typo in a name automically. It is more that plausible that the codes defer by 1 character and such and not all templates need to define everything.

and it's really just not that hard to make sure there are no typos.

It actually is, since the codes can be almost identical (1 character difference is enough, say a Cap vs lower case), so getting it from the template will be hard. And ingame one would need to look extremely closely too see if the resistance is applied (see the hero garrison aura not being applied for a long time, before we found out).

Forcing template writers to make JSON files isn't an improvement to me.

We already do for Auras and technologies.

In D2808#132510, @Freagarach wrote:

That is also the case for damage types, right?

That is also the case for damage types, right?
If you would require SE to have JSONs the templates could be simplified as well (no need for the translatable names in there I guess?).

Also chasing is beyond broken

I actually find it a tad easier to hunt now, since the hunt does not speed away ^^

What gives me a bit of a stomachache is the fact the codes of the statuseffects can be completely arbitrary, but still need to match for resistances to apply. 1 typo in the resistance and the resistance will silently not work. Imho all statusEffects should have an json and give a big fat error otherwise.

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.

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.

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 build 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!!.

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 doubles now

Fixed by rP24071

More compile errors:

/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