Variables

Part of Mythic Mobs Integration.

Mythic Dungeons has two variable scopes, and both live and die with the running instance.

The names above are the ones shown in the in game element pickers. There is no third, global scope: the only thing that outlives an instance is a persistent player variable, described further down.

Reading a variable

Inside a dungeon Message Sender, Title Sender or Boss Bar function, wrap the name in square brackets:

You have collected [gems] gems.

That reads the instance scope. There is no message syntax for player variables; read those with the Player Variable Comparison condition.

Inside a Mythic skill, use the placeholder instead:

- message{m="Kills: <dungeon.var.kill_count>"} @trigger

That also reads the instance scope. Outside a dungeon the placeholder returns the literal text [Couldn't find dungeon instance]. See Placeholders for the rest of the <dungeon.*> family.

Variable names are colour stripped when you type them into the editor, so a name entered as &agems is stored as gems. Write names plain wherever you reference them.

Comparing a variable

The Variable Comparison, Player Variable Comparison and Placeholder Check conditions each take a single comparison string:

[kill_count] >= 5
[boss_phase] = enraged
[gems] > [gems_needed]

Supported operators are = (or ==), >, >=, < and <=. There is no != and writing one does not raise an error: the ! is read as part of the left-hand side, so the comparison simply never passes. With =, both sides are compared as numbers when both parse as numbers, and as plain text otherwise; every other operator needs both sides to be numeric or it fails. A comparison with no operator at all never passes and logs a warning once. Surrounding single or double quotes around the whole comparison are stripped before it is read.

All three are skipped as misconfigured if the comparison string is left blank, and Player Variable Comparison never passes on a trigger that fired without a player (it warns the first time that happens).

Unset variables

A player variable that was never written reads as 0.

An instance variable that was never written reads as 0 only when Mythic Mobs is not installed. With Mythic Mobs installed the instance store is a Mythic variable registry, and an unset name reads as the literal text UNDEFINED. Either write your variables to a starting value on the Dungeon Start trigger, or give the read a default with [name|default], for example [kill_count|0] >= 5.

The [name|default] form only works while Mythic Mobs is installed. Without it, [name|default] never matches a stored value and always yields 0.

Edit modes

The Dungeon Variable and Player Variable functions each have three modes:

ADD and SUBTRACT only accept a number, and the editor rejects anything else at input time. Adding to or subtracting from a variable that was never set treats it as 0.

The Dungeon Variable function applies its change one tick after it fires. A condition checked on the same tick still sees the old value. The Player Variable function applies immediately.

Auto-typing rules (v2.0.1)

When Mythic Mobs is installed, a new instance variable created from Mythic Dungeons is auto-typed:

Once a variable exists, its type sticks. SET re-parses the new value into the existing type, and if the value does not parse, the change is refused and the previous value is kept (a warning is logged). ADD and SUBTRACT do arithmetic in the stored type; on a Boolean they are refused with a warning, and on a String the result is written back as a String in decimal form, so a String "5" incremented by 1 becomes "6.0". A brand new variable created by ADD or SUBTRACT becomes an Integer when the result is a whole number that fits in an integer, and a Double otherwise.

Without Mythic Mobs the instance store is a plain text map: nothing is typed, and whole numbers are printed without a decimal part.

Persistent player variables

The Player Variable function has a Persist Across Runs toggle, off by default. With it on, every write is also saved to the player's data file and restored the next time that player enters a dungeon, surviving restarts.

The persistent store is not separated per dungeon. A persistent variable saved in one dungeon is restored into every dungeon that player enters afterwards. Prefix your names (mydungeon_progress) to avoid collisions.

Lifetime

Instance variables and non-persistent player variables are discarded when the instance is unloaded. A player's variables are also discarded the moment they leave the instance.

Setting a variable from a Mythic skill

Skills:
  SetMyCounter:
    Skills:
    - setdungeonvariable{key=kill_count;value=0;type=INT}

See setdungeonvariable for its full attribute list. Two things worth repeating here: type accepts only STRING, INT, DOUBLE and UNDEFINED, so type=INTEGER is not valid even though that is the name Mythic Mobs uses elsewhere; and leaving type out auto-detects INT, then DOUBLE, then STRING (no boolean detection on this path).

Reading a variable from a Mythic condition

Use Mythic Mobs' comparevalues condition, which accepts placeholders, an operator (==, !=, >, <, >=, <=) and an optional type:

Conditions:
- comparevalues{value1=<dungeon.var.kill_count>;operator=>=;value2=5;type=INTEGER}

For string variables, stringequals also works:

Conditions:
- stringequals{value1=<dungeon.var.boss_phase>;value2=enraged}

Setting from Mythic Dungeons, reading from Mythic Mobs

The placeholder always hands Mythic Mobs a string, but the stored type decides how that string is printed: an Integer prints as 3, a Double as 3.0. That is why setdungeonvariable{...;type=INT} and the auto-typing rules matter when you compare with stringequals, and why comparevalues with type=INTEGER is the safest numeric comparison.