[Unsolved] Behaviors increasing other behaviors stack

[plumsy460]

Is it possible to make behaviors stack other behaviors?

For instance: I have a unit with 10 stacks of "BEHAVIOR 1" and I cast an ability (let's call that ability "BUFF") which applies a behavior that increases the stack of "BEHAVIOR 1" by 5, so I now have 15 stacks of "BEHAVIOR 1" on the unit.
I tried changing the "BUFF" behavior modification in "Modification^- Attribute Changes^- Attribute^" in addition to the section below called "-Points^".
Sadly it didn't seem to have any effect.

I'm very well aware that this is easily done in the trigger editor -which was actually my initial approach. There are a few problems though.

When the behavior runs out I'm using a trigger saying "Behavior change Destroy" and simply remove the equal amount of "BEHAVIOR 1" that the ability "BUFF" applied.
HOWEVER: If I want multiple units to be able to cast this ability at different scales and durations, the trigger will have trouble keeping up with the difference in amount to be removed.

So if there is not a way to make behaviors in the data editor increase another behavior's stack amount... Is there a way to make a trigger identify a specific behavior? I'm not talking about behavior types but actual individual behaviors. So once the effect is applied the trigger will remember that particular behavior and know exactly what amount of "BEHAVIOR 1" to remove from the stack of unit when "BUFF" expires/is destroyed.

EDIT: The reason why I would like flexible "BUFF" is because I wanna leave my map open for features such as spell steal, reset cooldown and such.

 

[Dr Super Good]

When applying the buff you can try using a set effect to also apply the other buff in the appropriate quantity. When each stack of the buff expires you then run an effect to remove stacks of the other buff.

What is this for? It sounds possibly more complicated than it needs to be.

 

[plumsy460]

That'll work! I never thought of the idea of a site effect.
Thank you as always!

You are probably right that I'm making it more complicated for myself than I need to. My idea is that I wanna make everything go "hand in hand" so it's easier to modify with features like Transfer, Steal, Copy, Extend, Refresh, Remove, Shorten and what not on behaviors and abilities.

In this case I was making a temporary attribute buff for my dialog system which is likely to be changed in the feature anyway (the one that works with Buff Stacks as attributes). But since this ability increases attributes equal to the hero level of the caster, nothing is constant and Effect values change in scale throughout the game. I need a way for an attribute buff to keep track of it's initial value. I've already done this partly with catalog triggers, but for some reason the effect keeps setting the entirety of the attribute set to 0 when it expires, at least when it has a duration. If I make it permanent and use Remove Behavior the hand-in-hand link breaks because that effect is first applied later, and the hero level can have changed by that time, in that case the hero permanently loses attributes because the Remove Behavior count will be higher than the initial created count.
In that case I'm back to square one where I need the trigger and the catalog function to remember it's partner's initial count.

 

[Dr Super Good]

This is all why you should really avoid using attributes in the first place. They are only there for nostalgic reasons as physically they can be simulated without attributes at all (Heroes of the Storm style).

Triggers might be the best idea in this case. When a hero gains a level you remove all the buff and then re-apply all the buff. Do not worry about efficiency as long as your event is specific enough since triggers with events that do not fire have as good as no resource overhead.

Some people have had success with iterative effects that iterate instantly to increment or decrement behaviours. They use either validators or requirements that compare two quantities until they match. Personally I do not trust this approach as I can imagine it being inefficient or error prone, or even just not customizable enough.

 

[plumsy460]

Makes a lot of sense to me now that you mention it's an "incomplete" feature/mechanic they put in just for nostalgic reasons. In my case, which demands a rather extremely flexible system I think you're right that triggers are the way to go. Fortunately the sc2 trigger editor can do a lot more than wc3 and it is possible with the optional specifications for events and conditions.
I have actually made a trigger that works perfectly... At least for now.

Roughly explained, it assigns the target to a unit group along with a number where the integer value is stored for the trigger to identify the amount it is supposed to remove when the buff "decreases". The unit group can only hold 1 unit, so if you cast the buff twice on a unit, the unit will basicly go into 2 unit groups with 2 seperate numbers -so they dont interfere with each other.

Anyway, I consider my problem solved. There's still room for improvement with a more elegant trigger, but as long as it works, I can fix that later.

Thanks as always for your insight Dr. Super Good!