Categories and/or tags

[redrum]

@alkexr Thanks for the input and posting your code. Yeah, its possible to implement both and even so you could use a combination like you point out. I think I'm gonna start with categories and see how that goes and then consider adding the ability to 'tag' to add to or create a category.

I think the next question is what's the best/easiest way to define them. I don't think I'm going to do any validation at the category level and just treat them as essentially a list of strings which get validated later on when they actually set into the values. Any thoughts on whether its easier to have each item as its own element vs just a colon delimited list? I'd also think if going with each item as its own element then using its base type is easier than a generic 'element'.

Also, do you think category is the best thing to call it? Couple alternatives I thought of is "list" or "variable" or "map".

Option #1

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

Option #2

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

Option #3

    <category name="anyMech.Infantry">
        <unit name="germanMech.Infantry"/>
        <unit name="italianMech.Infantry"/>
        <unit name="japaneseMech.Infantry"/>
    </category>
    <category name="axisPlayers">
      <player name="Italians"/>
      <player name="Germans"/>
      <player name="Japanese"/>
    </category>

[alkexr]

@redrum I would call it a variable if there is a potential future plan to add / remove elements using triggers. Map would be a confusing term. List or category are both fine. But category feels wrong with #2.

#2 is only good if you have to write hundreds of these and length is a concern. I think that typically this part of xml editing is going to be negligible in terms of time spent typing, while clarity at a glance is probably more important here than anywhere.

[redrum]

@alkexr I like variable as well just wasn't sure if its too technical for most map makers.

Ok I'll go with something like option #1 or #3 then.

Do you think variables are useful in anything besides attachments?

[alkexr]

@redrum said in Categories and/or tags:

Do you think variables are useful in anything besides attachments?

Foreach loops could be used for turn sequences or production frontiers, maybe even unit placement (like placing an invisible factory on every territory - though defining ownership is a problem) or map options (like "Player1 is AI"). But staying within the realm of reason, these are the only possibilities I can think of. (Of course there are always some mapmakers who stray out of said realm sometimes ) Without foreach loops, they can only be used as colon delimited lists, which only happen in attachments at the moment.

[redrum]

Alright. So got some initial code working around tackling defining variables. Here in a example of TWW:

  <variableList>
    <variable name="AntiTankTargets">
      <element name="germanMech.Infantry"/>
      <element name="germanTank"/>
      <element name="germanHeavyTank"/>
      <element name="germanHeavyTank-damaged"/>
      <element name="russianMech.Infantry"/>
      <element name="russianTank"/>
      <element name="russianHeavyTank"/>
      <element name="russianHeavyTank-damaged"/>
      <element name="americanMech.Infantry"/>
      <element name="americanTank"/>
      <element name="americanHeavyTank"/>
      <element name="americanHeavyTank-damaged"/>
      <element name="italianMech.Infantry"/>
      <element name="italianTank"/>
      <element name="italianHeavyTank"/>
      <element name="italianHeavyTank-damaged"/>
      <element name="japaneseMech.Infantry"/>
      <element name="japaneseTank"/>
      <element name="japaneseHeavyTank"/>
      <element name="japaneseHeavyTank-damaged"/>
      <element name="britishMech.Infantry"/>
      <element name="britishTank"/>
      <element name="britishHeavyTank"/>
      <element name="britishHeavyTank-damaged"/>
      <element name="chineseMech.Infantry"/>
      <element name="chineseTank"/>
      <element name="spanishTank"/>
      <element name="brazilianTank"/>
      <element name="turkishTank"/>
      <element name="swedishTank"/>
    </variable>
  </variableList>

    <attachment name="unitAttachment" attachTo="germanAntiTankGun" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="attack" value="1"/>
      <option name="defense" value="1"/>
      <option name="isAAforCombatOnly" value="true"/>
      <option name="typeAA" value="AntiTankGun"/>
      <option name="targetsAA" value="$AntiTankTargets$"/>
      <option name="maxAAattacks" value="1"/>
      <option name="maxRoundsAA" value="-1"/>	  
      <option name="transportCost" value="2"/>
      <option name="mayOverStackAA" value="true"/>
      <option name="movement" value="1"/>
      <option name="attackAA" value="2"/>
      <option name="isLandTransportable" value="true"/>
      <option name="requiresUnits" value="germanFactory"/>
      <option name="canBeGivenByTerritoryTo" value="Germany"/>
      <option name="damageableAA" value="true"/>
      <option name="canInvadeOnlyFrom" value="none"/>
    </attachment>

[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>