Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: tags #25

Closed
wants to merge 15 commits into from
Closed

Conversation

KatrinaHoffert
Copy link

This implements tags, which is a way to classify units. Upgrades and boosts can be applied to "classes" of units via these tags. These tags work over the entire techtree, so if you have an attack boost that affects units with the "warrior" tag, it will work regardless of which faction those units belong to (provided that they are a target of the boost -- ally, foe, faction, etc).

Use cases:

See the forum discussion

Syntax:

Assigning tags:

Tags are assigned with the <tags> element, which is a child of <parameters> in the unit XML. Units can have any number of tags. Tags are merely strings. Note that tags are case sensitive. The <tags> element is optional and may be empty.

Tags should be restricted to letters, numbers, and underscores. As with units, underscores will be converted to spaces and the first letter of each word capitalized.

Example:

<parameters>
    <!-- ... -->
    <tags>
        <tag value="warrior" />
        <tag value="burnable" />
    </tags>
    <!-- ... -->
</parameters>

Applying upgrades to tagged units:

Tags can be added to the upgrade XML's existing <effects> element. They can be mixed with existing <unit> elements. The upgrade will thus be applied to all units in the player's faction which have that tag.

Example:

<upgrade>
    <!-- ... -->
    <effects>
        <unit name="roundtent"/>
        <tag name="test" />
        <unit name="archer"/>
        <tag name="warrior" />
    </effects>
    <!-- ... -->
</upgrade>

Applying attack boosts to tagged units:

Tags can also be added to the target of attack boosts. The syntax is similar to that of upgrades. The target value (foe, ally, all, etc) will be obeyed.

Example:

<skill>
    <!-- ... -->
    <attack-boost>
        <allow-multiple-boosts value="false" />
        <radius value="5" />
        <target value="all" include-self="false">
            <unit-type name="archer" />
            <tag name="warrior" />
        </target>
        <!-- ... -->
    </attack-boost>
    <!-- ... -->
</skill>

Translating tags

In game, tags are displayed in the "affected unit list". The list is sorted alphabetically, with all units listed before the tags. See attached images. To differentiate tags from units in the list, all tags are preceded with the value of TagDesc (a key in the language file). Note that this key needs to be defined. For convenience, I created a pull request in megaglest-data that has the required change.

I currently have this defined as:

TagDesc=Tag:

As well, the actual tags are translatable in the same manner as unit names. This requires adding keys to the appropriate techtree language file. The format of the keys are TagName_<actual tag name>. Thus, if we have a tag warrior, we can translate it like:

TagName_warrior=Guerrier

Other

  • I have tested that saving and loading games correctly apply attack boosts/upgrades to tagged units
  • Also tested that the target of attack boosts (foe, ally, etc) is correctly used (particularly since its code was refactored to remove duplication)
  • Tags are not matched against anything. This makes it easy to create tags on the fly, but provides no protection against typos. I do not think this is a problem.

Screenshots

screen0
screen1

Mike Hoffert added 15 commits August 2, 2014 15:41
Not yet available for attack boosts.
Ensures uniqueness of units. Only applies to attack boosts (regular
upgrades are next). Requires changing how the set is accessed, since
set has different methods than vector.
This prevents duplicate units (easy to do if you have multiple,
overlapping tags). This also cleans up the code (the previous
method of checking for duplicates was a bit messy).
Also fixed bad null pointer bug that was freezing the game when you
hover over the upgrade button.
Note that only the application of tags is complete. Display and
load/save still to come.
Note: not yet translated.

Also fixed awful crash that occured due to how isAffected was
implemented. Fix is rather unusual, but works.
Issue was returning by value was creating a copy of a set instead
of returning a reference (which was what I expected).
I think I goofed this commit and part of the change is in the prior
commit, which probably won't build because of this.
IMPORTANT: Requires adding the following to the English lang file:

    TagDesc=Tag:
Use the techtree translation key: `TagName_<actual name of tag>`.
Eg, `TagName_warrior` for units that have `<tag name="warrior" />`.
As with the rest of techtrees, the game setting "Allow translated
techtrees" must be enabled (otherwise reasonable defaults are shown).

Also, the TagDesc is now translated for upgrades, too. This makes
everything related to tags translatable.
@@ -98,7 +99,8 @@ class AttackBoost {
bool allowMultipleBoosts;
int radius;
AttackBoostTargetType targetType;
vector<const UnitType *> boostUnitList;
std::set<const UnitType *> boostUnitList;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sets are used to simplify handling duplicates. Sets will ignore duplicates. This was a bigger deal back when the implementation was to simply dump all units with a matching tag into the boostUnitList. Although now it's useful to find the intercept of the set of upgrade/attack-boost tags and unit tags, which makes checking if a unit is affected much simpler (if slightly less efficient).

titiger added a commit that referenced this pull request Sep 29, 2014
Tags feature ( manually merged ) from Omegas pullrequest 25
#25
see forum discussion:
https://forum.megaglest.org/index.php?topic=9543.0
@titiger
Copy link
Member

titiger commented Sep 29, 2014

manually merged

@titiger titiger closed this Sep 29, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants