It's very much
NOT messed up and is quite succinct compared to how it would be to trigger the buff, periodically tick damage, properly overwite instances, and detect projectile impact correctly. The reason I wrote what I wrote above is because it avoids a ton of the minutiae that is required to make triggered spells feel like native spells. If I thought it was better to code the whole effect I would have done it, but after enough years I've come to understand that there are inherent benefits to using native abilites whenever possible.
Most of that trigger is configuration to give you specific control over how the ability functions. If you'd chosen to
read my trigger instead of
immediately balk at it you would understand what is happening and how to apply it; Literally everything is setting variables for data except the dummy spawning and four lines used (twice) that set skill damage and duration.
Frankly, in my opinion AdaptiveTrigger is doing you a disservice by just throwing a map at you with no explanation or information. You've been on this site for 17 years, Dinodin; you should be capable of seeing a trigger and recreating it yourself with ease. That's a vital skill I'm certain you have exercised before. By understanding what I showed you can do with the field natives, you will understand how to dynamically change
any base wc3 skill at-runtime to do exactly what you want whenever you want it. I won't rage any more and I'm not trying to disparage Adaptive's time and effort spent making that map for you; it just doesn't
really help *any*one in the long term.
@AdaptiveTrigger You've combined the main two possible methods (change AB with field natives and dummy-cast them vs. fully trigger the whole skill) without really the benefits of either and are doing something very not-recommended by setting the base damage of AB to 1000000000 in the OE. You've apparently done that to make it easy to detect damage dealt by the AB ability's ticks specifically, but such a method only works for one thing at a time in a map. What if this same unit had a second skill whose damage you also needed to detect? What do you do then, since you can't pick a "big but not
that big" number in between somewhere since the damage taken is modified by armor and any runed bracers abilities the map might be using.
In such a situation, the correct process is to dummy-cast the skill/effect whose damage you want to detect so that the main unit doesn't actually do any of the damage. Then in damage detection triggers you look specifically for the damage source being a dummy unit with a nonzero level of the relevant ability it would have cast. This does require your dummies to stick around throughout the cast duration but that shouldn't be an issue if they're properly designed since they can't be interacted with or seen (and we have expiration timers for automatic removal).
There's also another issue with your code: since you save the data about the cast in a hashtable that uses the caster's handle id as one key, and then load that same data for every active instance (when you loop through the groups), each unit will always take the same
exact tick damage. If I cast the skill at level 1 with no items, then refresh the cooldown and pick up a bunch of agility items or level up the skill higher and cast it a second time simultaneously... the damage dealt to the units that were
already hit and currently are ticking
will change to match the second cast. Does it matter much? No. But it's an interaction that could be exploited, especially if the map has any time-limited agility buffs to account for. It's also not accurate to say that this skill simply doesn't snapshot stats on cast (like mine does), since that implies its damage will constantly be updated to match any changes to your agility or base damage, which isn't something your code actually
does constantly (only when the skill is cast)
There's also a fair amount of of hardcoded stuff like
250.0 + ( 0.5 * agility * abilitylevel ) which I generally don't agree with since it's not easy for someone to understand how to change that if they want, say, the agilty scaling to be more complex. I'm not here to nitpick that.
