[STATWATCHER][/STATWATCHER]

wolpakwolpak Posts: 473
edited June 2016 in GUTS Community Help
Just wanted to open up discussion on [STATWATCHER]. This underutilized tag is very powerful and helps us actually put logic into our skills.

Here is what I can tell is happening:
STAT REQ
Secondary Stat: I am not sure what this is for
Secondary Target Type: This is what you are looking at on your target
Secondary Value: The value what you are comparing the stat to
Stat: The stat you are looking at
Target Type: The initial target
Value: The value of the initial target
Watch Type: The type of comparison

So, basically you are comparing some state to a stat. If it accepts, then it moves forward, if it rejects then it doesn't. What will actually happen? Well, this is what I can tell.

[STATWATCHER] controls whatever TAG it is inside of. It should be the last thing in the TAG and the TAG runs if [STATWATCHER]'s criteria is met.

I have it work on [SKILL], [LEVEL], [EVENT_*] and [AFFIX] tags.

If you put it on [SKILL], then the skill cannot be called unless the [STATWATCHER]'s criteria is met. Same thing on level (though, much less valuable since it appears you can't have two [LEVEL1] tags.

I have found the most value on [EVENT_*] tags. You can have two [EVENT_START]s and have the statwatcher control which one gets called. Very nice and easy for toggles and other functionality. Same thing works with AFFIXES if you don't want to have multiple EVENT Tags.

If anyone has any more info, or something I have wrong, feel free to post and I'll fix it.

Comments

  • You pretty much explained the basics of it. A Statwatcher is more or less just a fairly limited IF statement. If its conditions evaluate as True, the object it is embedded in (the skill, the event, etc) is enabled. If not, it is disabled.

    Widespread use and open discussion (at least among contributors on these boards) of Stat Watchers at the Event level is relatively recent. Some people may have been using them that way but it was mostly publically undocumented. Very few of the existing TL2 skills embed Stat Watchers at the Event or Affix level. Several skills that do exist can be found in the code but were never published in the game, eg the "leyline buffs" originally planned for Embermages. Runic seems to have had seconds thoughts about many of the skills set up with Statwatchers, maybe for the reasons we've encountered here. I certainly experience my fair share of weirdness from them.

    It also appears to be possible to set up Statwatchers at the Affix level but this is even more rare and I have had spotty results from it, maybe due to my own limited understanding of the structure. The skill Share the Wealth appears to have a Statwatcher at the Affix level to avoid adding the buff effect if the Outlander has 0% charge and thus nothing to contribute to teammates.
    theolbanner.png
  • HaetteHaette Posts: 119
    edited September 2013
    wolpak wrote:
    Secondary Stat: I am not sure what this is for

    If you're using a Value for your Secondary Target Type, you don't need anything in that spot. However, if your secondary target is a unit like the caster or a spell target, you use this field to select a stat to check on that target. You could, say, compare your own HP to an enemy target's HP, and apply an affix only if the target's health is less than your health.
    [EVENT_UNITHIT]
    			<BOOL>STATSHIDDEN:1
    			[AFFIXES]
    				<STRING>TARGET:ENEMY
    				<STRING>AFFIX:EXECUTION_DAMAGE_1
    				[STATWATCHER]
    					<STRING>STAT:HP
    					<STRING>SECOND_STAT:HP
    					<STRING>PRIMARY_TARGET_TYPE:SELF
    					<STRING>SECONDARY_TARGET_TYPE:ENEMY
    					<STRING>WATCH_TYPE:GREATER THAN
    				[/STATWATCHER]
    			[/AFFIXES]
    		[/EVENT_UNITHIT]
    
  • There is also a weird gotcha that may belong in this thread. Statwatchers within a skill called as a child skill within an EXECUTE SKILL event are somewhat unreliable. Recently someone suggested a fix for an EXECUTE SKILL proc I had set for the Theol class by changing the "is silenceable" flag (I forget the name of it) to 1. I have no idea why that fixed it, but prior to that, the proc skill would always fire the first time and then never again until the player logged out and back in.

    I have another skill in the Theol class called "Star Smite" which is supposed to buff the damage of channeled spells. It does this via an EXECUTE SKILL call in the event_start of each channeled skill. Until this weekend there was a longstanding bug with this that caused the power to always fire the first time a player activates a channeled skill, whether they have ranks or not even though the stat is zero. I fixed it by moving the Statwatcher from the Skill level to the Event level. I have no idea why this works except that possibly too many EXECUTE SKILL objects can possibly interfere with each other's stats.
    theolbanner.png
  • HaetteHaette Posts: 119
    I have a bunch of skills that use statwatchers in various places and with different types of stats, I can post them with some explanation in a bit. At the very least, it'd probably be handy to have a basic reference that shows the differences between affix and event statwatchers.
  • Yeah, I naturally went for the most dangerous statwtcher before I saw this thread...checking the player HP % and casting a shield spell when it drops below a certain percent.
    Dying isn't the best way to discover the statwatcher is problematic.
    I just moved the statwatcher into the EVENT_START and flipped the "IS SILENCEABLE" bit and now to test it. Thanks for the tips.

    Oh, here's the code for the skill executed, if anyone is interested:
    [LEVEL1]
    		<FLOAT>RANDOMRANGE:0
    		[EVENT_START]
    			[AFFIXES]
    				<INTEGER>AFFIXLEVEL:1
    				<STRING>TARGET:SELF
    				<STRING>AFFIX:RAILMAN_AEGIS_PROC_HP_01
    			[/AFFIXES]
    			[STATWATCHER]
                <STRING>STAT:HP %
    				<STRING>PRIMARY_TARGET_TYPE:SELF
    				<STRING>SECONDARY_TARGET_TYPE:VALUE
    				<STRING>WATCH_TYPE:LESS THAN OR EQUAL TO
    				<FLOAT>SECONDARY_VALUE:22
    			[/STATWATCHER]
    		[/EVENT_START]
    	[/LEVEL1]
    
    HP % is a predefined INT (took awhile to figure it wasn't a float, another tip from these forums), and the affix that casts this from the passive is just a 100% chance to cast.

    Any tips to improve this so it's more reliable are appreciated. :D
  • ChthonChthon Posts: 1,855
    If you put two statwatchers in the same code block, do you get consistent behavior? If so, is it AND or OR?
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • wolpakwolpak Posts: 473
    Chthon wrote:
    If you put two statwatchers in the same code block, do you get consistent behavior? If so, is it AND or OR?

    Yes and it is an and. I have 3 stat watchers in some blocks and they always work.

    In addition, combined with execute skill, they can make a while loop.
  • Kva3imodaKva3imoda Posts: 984 ✭✭
    Can I use this feature for affix? For example, if I have a some value of Vitality then I get a Resistance bonus?
    4ByzPdz.png 88pn2UZ.pngtrCrfep.png
  • wolpakwolpak Posts: 473
    In an affix? I am not sure. In a skill to keep and affix from triggering, them yes. The only won lines I have seen is with effects. Somehow, stat tracker is like bunnies in Australia when I put it within an effect.
  • wolpakwolpak Posts: 473
    Btw, make sure you do this.

    http://docs.runicgames.com/wiki/Creating_UI

    Ignore the button and only put the window up. The text in the window should be the stats that statwatcher is watching so you can watch the stats that are being watched by stat watcher.
  • JeppeJeppe Posts: 2
    So looks like disabling the skill usage with the Statwatcher doesn't automatically swap the icon to the inactive icon (greyed out usually). Anyone know to work around this? I suppose I need to apply the same statwatching mechanics somewhere in the UI logic.
Sign In or Register to comment.