@Toffer90, the current format confuses TB as he argues the statement <Or>Ａ,Ｂ,Ｃ<And>Ｄ,Ｅ</And></Or> could be easily misinterpreted as （ Ａ Or Ｂ Or Ｃ
And （ Ｄ And Ｅ ） ）. I came up with this linear format that can be interpreted sequentially. The nested statement becomes
（ Ａ Or
Ｂ Or
Ｃ Or
（ Ｄ And
Ｅ ）.
Each line is one tag entity. Open parenthesis is indicated with a keyword newlogicgroup, or whatever, and close parenthesis with endlogicgroup. The outermost parenthesis is automatically closed if there is no more tag to consume.
When Not is introduced in the statement, it only negates the option on the line it belongs to, and won't apply to other members of a parenthesis:
（ Not(Ａ) Or
Ｂ Or
Ｃ Or
（ Ｄ And
Not(Ｅ) ）.
And we need to be careful with it.
If we want to negate the （ Ｄ And Ｅ ） group, we would write the equivalent (and disband/merge the group when appropriate):
（ Ａ Or
Ｂ Or
Ｃ Or
Not(Ｄ) Or
Not(Ｅ) ）.
Wow, does this example mean "Grant the free building if an African unit preexists on the tile we're about to settle on this turn"? Anyway, how about this:
<NewCityFree PromotionType=PROMOTION_CULTURE_AFRICAN RelationType=RELATION_SAME_PLOT />
Do we see a second potential interpretation about this line?
The GameObject will resolve to the GameObjectUnit, inferred from the PromotionType we've declared. This is a feature I'd like to add too. It may not be able to resolve the GameObject type in some cases, where we'll need to specify.
The example in the doc, making a building available to any city connected to our capital, can be shortened to this:
<ConstructCondition BuildingType=BUILDING_PALACE RelationType=RELATION_TRADE />
It infers from the RELATION_TRADE that it's going to query the City GameObjects.
Edit: I haven't read through the documentation on the expression system, and didn't know about the <IntegrateOr> tag. Thought it was a new invention and took your question differently.
Edit: Reordered the open parenthesis keyword before the identifier.
The DOM does not enforce strict order of attributes, but it's helpful if we follow the order we would interpret it.
<Tag
newlogicgroup not InfoType=ID iNum=N
next=AndOr endlogicgroup />
If "[new/end]logicgroup" is too long, what's an appropriate keyword shorthand we would agree upon? Please suggest a more specific keyword for "next" as well.
Edit: In an afterthought, we might just use RELATION_SAME_PLOT for a building prerequisite that has to exist in the city. We can add new enums such as RELATION_SAME_CONTINENT, RELATION_SAME_PLANET, etc. But short keywords like inThisCity, onContinent, onPlanet, etc, will be better.
- <PrereqBuilding BuildingType=BUILDING_MONUMENT iNum=2 byPlayer inThisCity /> (2 by the current player, and needed in city, like in vanilla Civ. Do NOT use RELATION_SAME_PLOT because it confuses a lot.)
- <PrereqBuilding BuildingType=BUILDING_MONUMENT iNum=4 byTeam inThisCity />
- <PrereqBuilding BuildingType=BUILDING_MONUMENT iNum=6 byAllPlayers scalesWithMapSize onPlanet inThisCity />
-
Code:
<PrereqBuilding newlogicgroup BuildingType=BUILDING_CASTLE inThisCity next=Or>
<PrereqBuilding newlogicgroup iNum=2 byPlayer onContinent next=Or />
<PrereqBuilding iNum=6 byAllPlayers scalesWithMapSize endlogicgroup />
</PrereqBuilding>
<PrereqBuilding newlogicgroup BuildingType=BUILDING_CATHEDRAL iNum=2 byPlayer next=And />
<PrereqBuilding iNum=1 byPlayer onContinent endlogicgroup />
In the last example, if we omit BuildingType, it means ditto, but we don't necessarily nest the ditto lines. When we nest these tags, it implies a middle layer of logic group: ( Parent And ( Children's group ) ). When we don't nest ditto lines, we need to explicitly create a logic group. This example can be translated as: We're entitled to build this Wonder if we have a castle here and either one in somewhere else on the continent, or a total of six by all players including us if we are on a Standard-sized map; we could also just build a cathedral on this continent and another anywhere and still be entitled the blueprint. How cool is that.
