Categories and/or tags

[redrum]

And an example of nested variables:

    <variable name="russianAntiAirTargets">
      <element name="russianFighter"/>
      <element name="russianTacticalBomber"/>
    </variable>
    <variable name="americanAntiAirTargets">
      <element name="americanFighter"/>
      <element name="americanTacticalBomber"/>
    </variable>
    <variable name="AntiAirTargets">
      <element name="russianAntiAirTargets"/>
      <element name="americanAntiAirTargets"/>
    </variable>

[Frostion]

This sounds great. I really think the “Solution #1: Categories” or similar would be a great feature, so that we don’t have to list all units. Awesome if triggers could change these codes!

I think the most intuitive way to give a unit anti-air targets would be the example:

<option name="targetsAA" value="anyMech.Infantry:anyTank:anyHeavyTank"/>

And then the lists being like

<category name="anyTank" type="unit">
        <element name="germanTank"/>
        <element name="italianTank"/>
        <element name="japaneseTank"/>
</category>

I think understanding the code would be could be even more intuitive for mapmakers if it was not </category> but instead </unitCategory> .

Maybe the above (unit)category code could also have a ”players” setting with a list of affected players or unaffected players, so that like some enemy units can evade this specific aa attack. Default could be ALL if not used. But this could open up for players having the same units with the same name, lige “Fighter” and “Bomber”. So like if a player develops “stealth” then his fighters/bombers can become immune from some attacks after the player is removed by trigger from the code. If a player develops “flares” then missiles can’t hit or reactive armor that disrupts RPG units’ if they have an AA attack. You get my meaning

I must admit that I don’t really understand the talk about “tags” either. Also, I don’t understand how “variables” can or should be understood in this context. To me it seems like language out of a mathematical equation.

[Cernel]

https://en.wikipedia.org/wiki/Variable_(mathematics)
a variable is a symbol, commonly a single letter, that represents a number, called the value of the variable, which is either arbitrary, not fully specified, or unknown.

Mutatis mutandis, something defined as "variable" inside the xml makes me think of something that is strictly numerical and it is not fixedly defined by the xml itself (that is or may be stored somewhere else). For example, something that the user may customize (for example, called from a potentially editable property).

[redrum]

@Frostion For now I'm leaning towards calling them 'variables' instead of 'categories'. 'unitCategory' wouldn't really work since you can have a list of player, territories, etc as well not just units. The easiest way to think about it is this is essentially a find/replace that's useful when you end up having the same list of 'elements' copy and pasted multiple times.

@Cernel This is the definition that would be more accurate: https://en.wikipedia.org/wiki/Variable_(computer_science)
In computer programming, a variable or scalar is a storage location (identified by a memory address) paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of data referred to as a value. The variable name is the usual way to reference the stored value, in addition to referring to the variable itself, depending on the context. This separation of name and content allows the name to be used independently of the exact data it represents.

Essentially, they are key/value pairs where you define a variable 'name' and that represents the list of elements (units, players, territories, etc). Where ever you use that variable, it is replaced with the list of elements.

[Cernel]

@redrum That thing I'd rather name it a set.

https://en.wikipedia.org/wiki/Set_(mathematics)

[redrum]

@Cernel Actually if anything it would be a "list" not a "set" since you could in theory have duplicates of the same element assigned to the same one.

[Cernel]

@redrum List is too generic; the xml is a bunch of lists. If not "set", then "group".

What would be a user case for having something like:

<category name="anyMech.Infantry">
    <element name="germanMech.Infantry"/>
    <element name="italianMech.Infantry"/>        
    <element name="italianMech.Infantry"/>        
    <element name="japaneseMech.Infantry"/>
</category>

If none, then better that the program doesn't accept duplicates.

[redrum]

@Cernel I'm adding the foreach ability along with this so you could do something like this for an attachment where you have 2 "lists" of the same length that are looped through to create in this case 4 attachments:

<attachment foreach="anyMech.Infantry:anyMechPlayers"

<variable name="anyMech.Infantry">
    <element name="germanMech.Infantry"/>
    <element name="italianMech.Infantry"/>        
    <element name="italianMech.Infantry"/>        
    <element name="japaneseMech.Infantry"/>
</variable>

<variable name="anyMechPlayers">
    <element name="Germany"/>
    <element name="Italy"/>        
    <element name="ItalianMinors"/>        
    <element name="Japan"/>
</variable>

[Cernel]

@redrum Will "foreach" work for triggers (for example, allowing a trigger to fire once for each of some units in a territory?). If so, will this make "each" deprecate?

Back on the matter in case duplicates are not redundant (meaning "germanMech.Infantry+italianMech.Infantry+italianMech.Infantry+japaneseMech.Infantry" is not the same as "germanMech.Infantry+italianMech.Infantry+japaneseMech.Infantry"), it can be called "sequence".

https://en.wikipedia.org/wiki/Sequence

The only matter, at this point, is that in sequences the order is usually supposed to have significance.

I don't recall if there is a term for something repetitions sensitive but not positions sensitive (set isn't for both and sequence is for both).

[Cernel]

@Cernel said in Categories and/or tags:

I don't recall if there is a term for something repetitions sensitive but not positions sensitive

Apparently, it's called "multiset".

https://en.wikipedia.org/wiki/Multiset

[Frostion]

I really hope that the term is at least a word known to ordinary people and not technobabble gibberish

[Cernel]

@Frostion said in Categories and/or tags:

I really hope that the term is at least a word known to ordinary people and not technobabble gibberish

Knuth himself attributes the first study of multisets to the Indian mathematician Bhāskarāchārya, who described permutations of multisets around 1150. Knuth also lists other names that were proposed or used for this concept, including list, bunch, bag, heap, sample, weighted set, collection, and suite.

I just advice against list, as pretty much all the xml is a bunch of lists, so that may be confusing if you are talking about some lists.

[redrum]

@Cernel It will be available for any type of attachment. It will in ways complement "each" by allowing map makers have essentially a attachment "template" which then uses a "variable" to generate multiple attachments (should help minimize copy/paste). One of the most obvious uses of this is having separate units for each player like TWW does where you will define "infantry" and use "foreach" with a variable containing say the list of players which the engine will then generate a separate unit attachment for each player.

@Frostion I think I'm going to just stick with variable as that avoids trying to decide between all the different types of lists, sets, sequences, etc. Essentially its similar to in algebra or basic programming, you can define a variable with a symbol/name which then represents some value (list of elements). Wherever you use that variable, it then replaces it with the list of elements.

[Cernel]

@Cernel Also, a "weighted set" would be a little more polished, if you can just call the element once and define a number of entries for it, rather than having to list it multiple times.

[redrum]

And now the second portion of this change which is foreach. This allows defining essentially an attachment "template" which using variables then generates multiple attachments. This can be very useful for repetitive unit attachments, conditions, triggers, etc as it will make the XML much shorter and easier to manage/update. The following shows an example of how this can be used to define multiple similar unit attachments for TWW:

Define 3 variables which vary across the unit attachments
*Notice that you can have an empty element (under Players in this case) which means that any attachment option will be skipped

  <variableList>
    <variable name="Infantry">
      <element name="germanInfantry"/>
      <element name="russianInfantry"/>
    </variable>
    <variable name="Players">
      <element name="Germany"/>
      <element name=""/>
    </variable>
    <variable name="Barracks">
      <element name="germanBarracks"/>
      <element name="russianBarracks"/>
    </variable>
  </variableList>

Define unit attachment "template" using "foreach" and specifying the 3 variables (Infantry:Players:Barracks)
*The foreach makes it so it iterates through the variables' elements and replaces any @X@ that is specified in the templates which in this case the Infantry variable is used to specify what unit to attachTo by using @Infantry@

    <attachment foreach="$Infantry$:$Players$:$Barracks$" name="unitAttachment" attachTo="@Infantry@" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="movement" value="1"/>
      <option name="attack" value="2"/>
      <option name="defense" value="3"/>
      <option name="transportCost" value="2"/>
      <option name="isLandTransportable" value="true"/>
      <option name="canBeGivenByTerritoryTo" value="@Players@"/>
      <option name="requiresUnits" value="@Barracks@"/>
      <option name="canInvadeOnlyFrom" value="none"/>
    </attachment>

This then generates the equivalent of having 2 unit attachments
*Notice that canBeGivenByTerritoryTo is only included for germanInfantry not russianInfantry because its left empty in the Players variable

        <attachment name="unitAttachment" attachTo="germanInfantry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
            <option name="movement" value="1"/>
            <option name="attack" value="2"/>
            <option name="defense" value="3"/>
            <option name="transportCost" value="2"/>
            <option name="isLandTransportable" value="true"/>
            <option name="canBeGivenByTerritoryTo" value="Germany"/>
            <option name="requiresUnits" value="germanBarracks"/>
            <option name="canInvadeOnlyFrom" value="none"/>
        </attachment>
        <attachment name="unitAttachment" attachTo="russianInfantry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
            <option name="movement" value="1"/>
            <option name="attack" value="2"/>
            <option name="defense" value="3"/>
            <option name="transportCost" value="2"/>
            <option name="isLandTransportable" value="true"/>
            <option name="requiresUnits" value="russianBarracks"/>
            <option name="canInvadeOnlyFrom" value="none"/>
        </attachment>

[Cernel]

@redrum said in Categories and/or tags:

*Notice that you can have an empty element (under Players in this case) which means that any attachment option will be skipped

I don't understand.

[redrum]

@Cernel So here is the variable definition with an empty second element:

    <variable name="Players">
      <element name="Germany"/>
      <element name=""/>
    </variable>

This is then used in the template further down in this line:

<option name="canBeGivenByTerritoryTo" value="$Players$"/>

And ends up generating the germanInfantry attachment with this:

<option name="canBeGivenByTerritoryTo" value="Germany"/>

And the russianInfantry attachment skips that option.

[redrum]

Here is another foreach example to generate multiple similar triggers:

Variables

  <variableList>
    <variable name="Players">
      <element name="Germany"/>
      <element name="Brazil"/>
    </variable>
    <variable name="Phases">
      <element name="germanyBattle"/>
      <element name="brazilBattle"/>
    </variable>
  </variableList>

Trigger Template

    <attachment foreach="$Players$:$Phases$" name="triggerAttachmentLiberationUsaBy@Players@" attachTo="@Players@" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachmentWashingtonlost:conditionAttachmentChicagolost"/>
      <option name="when" value="after:@Phases@"/>
      <option name="players" value="Usa"/>
      <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentLiberationUsa"/>
      <option name="playerProperty" value="switch" count="true"/>
    </attachment>

Generated Triggers

    <attachment name="triggerAttachmentLiberationUsaByGermany" attachTo="Germany" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachmentWashingtonlost:conditionAttachmentChicagolost"/>
      <option name="when" value="after:germanyBattle"/>
      <option name="players" value="Usa"/>
      <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentLiberationUsa"/>
      <option name="playerProperty" value="switch" count="true"/>
    </attachment>
    <attachment name="triggerAttachmentLiberationUsaByBrazil" attachTo="Brazil" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachmentWashingtonlost:conditionAttachmentChicagolost"/>
      <option name="when" value="after:brazilBattle"/>
      <option name="players" value="Usa"/>
      <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentLiberationUsa"/>
      <option name="playerProperty" value="switch" count="true"/>
    </attachment>

[Frostion]

I hope that the basic features of this feature request will be implemented in a way that will not require the mapmaker to understand or use these new and more advanced possibilities. I don't understand anything you presented in your last couple of posts @redrum.

[redrum]

@Frostion These are optional advanced XML features and don't at all need to be used (and have no impact on existing maps). They are really just providing a way to have a "find and replace" type XML feature and an "attachment template to generate multiple similar attachments". They are provided to map makers to minimize copy and paste if they want. These can be very useful to maps like TWW which have lots of repetitive XML around unit attachments, conditions, and triggers that are hard to make updates to.