Build is green

Updating workspaces...
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (307 tests)...................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (307 tests)...................................................................................................................................................................................................................................................................................................................OK!
Checking XML files...

http://jenkins-master:8080/job/phabricator/2151/ for more details.

Executing section Default...
Executing section Source...
Executing section JS...
Executing section XML GUI...

http://jenkins-master:8080/job/phabricator_lint/619/ for more details.

Indeed that hunk should be left out, since @fatherbusido noticed the code is broken in that case (and that should go in a seperate diff).

thx for the review!

In other parts of those files (e.g. “requirements” the convention seems to be to alternate [brackets] and {braces}, therefore I'm wondering why it's brackets within brackets for affects, e.g. "affects": [ ["Infantry", "Advanced"] ],
And does this change also affects the “affects” within “modifications”?

By the way, what is now the OR operator? Simply a space, without a comma?

In D977#38358, @Nescio wrote:

In other parts of those files (e.g. “requirements” the convention seems to be to alternate [brackets] and {braces}, therefore I'm wondering why it's brackets within brackets for affects, e.g. "affects": [ ["Infantry", "Advanced"] ],

• indicates an array, [[],[]] is an array of arrays. requirements needs objects, that for some of the possibilities take arrays of requirements (so again objects).

And does this change also affects the “affects” within “modifications”?

Same thing applies to that, all of those end up in the same function (MatchStringList, see the commit/diff referenced in the description).

By the way, what is now the OR operator? Simply a space, without a comma?

Same as the old one. ("A B" or [["A"], ["B"]])

What is changed (or going to change here) is a confusing syntax that might be read as OR, but is actually AND due to how the above mentioned function works. Basically requirements need to be specified in disjunctive normal form. Then only thing that is slightly confusing is that some places support only strings, so those are split into arrays of arrays, and others support arrays, so use them since that does not require splitting. The confusing syntax is mixing the two, and allows syntax that would mean something different without [] and just makes the whole thing harder to grasp.

according to some post by fatherbushido the modification support is broken. For the documentation of the classes strings see the MatchesClassList function in templates.js (its like two elements in the first scope is OR so "foo bar"==["foo", "bar"], in the second AND, so "foo+bar"==[["foo", "bar"]])

Thank you for your reply; now I'm confused, unfortunately.
How to write down OR and AND right now (before these changes), and what will they be (after these changes)?

OR can be written like "foo+bar" or [["foo"],["bar"]] or ["foo", "bar"]. (all those are equivalent)
AND can be written like "foo bar" or ["foo+bar"] or [["foo", "bar"]]. (all those are equivalent)

Also notice that this patch doesn't change the execution (ignoring that one template with comments), it only removes some misleading cases of ["foo bar"] with in the current code that is equal to "foo bar", but that is not obvious so should be avoided/removed.

Thank you for the clarification. So all those instances work right now (before these changes) and will remain unchanged (afterwards)?

In D977#38383, @bb wrote:

OR can be written like "foo+bar" or [["foo"],["bar"]] or ["foo", "bar"]. (all those are equivalent)

"foo+bar" is foo AND bar. The other two are correct.

AND can be written like "foo bar" or ["foo+bar"] or [["foo", "bar"]]. (all those are equivalent)

"foo bar" is foo OR bar. The other two are correct.

Also notice that this patch doesn't change the execution (ignoring that one template with comments), it only removes some misleading cases of ["foo bar"] with in the current code that is equal to "foo bar", but that is not obvious so should be avoided/removed.

Except in the current code ["foo bar"] is equivalent to "foo+bar", which means we have with the same meaning as + in one case, but not in any of the others.

Guess this just shows how confusing this is.

To help with figuring out how this works (or should): The outer "layer" (be that items in the first level array, or parts of strings separated by ) is combined with OR, the inner layer with AND.