System BuffStruct

[Zwiebelchen]

I don't think Jesus should add more functionality to the system, as it would overload it.
At a certain point in programming, adding more features to a program causes the program to be less flexible instead of adding flexibility. Not to mention the efficiency loss of every additional check that has to be done. I don't want buffs to be automaticly cleared when a unit dies. If you feel like you need it, then just create a simple onDeath trigger and remove all buffs from the unit by enuming at the moment of dying.
I think the system is perfectly fine when he finally fixes the issue with multiple buffs on the same unit.

 

[13lade619]

hey,

There's this serious 'Double Remove' bug happening on my map.
Zack1996 says that he's getting some negative bonuses sometimes when using my spells with Buffstruct+Status.

idk maybe it's my coding but i strongly sense it's buffstruct...

 

[Jesus4Lyf]

I don't think Jesus should add more functionality to the system, as it would overload it.

Right.

I think the system is perfectly fine when he finally fixes the issue with multiple buffs on the same unit.

Which will be solved with BuffType[unit] when I get around to it.

hey,

There's this serious 'Double Remove' bug happening on my map.
Zack1996 says that he's getting some negative bonuses sometimes when using my spells with Buffstruct+Status.

idk maybe it's my coding but i strongly sense it's buffstruct...

Check that you're not double-freeing, or re-calculating the amount after the values it is based on has changed. I strongly doubt a buff struct issue. Post the code for the 'bugged' buffs if you want it reviewed. :thup:

Make sure that each buff can only be destroyed once - turning debug mode on will reveal if they are being double-freed.

 

[13lade619]

Make sure that each buff can only be destroyed once - turning debug mode on will reveal if they are being double-freed.

i think most of the bugs were gone with the update.

i'm sure it wasnt double-freeing it didnt display any AIDS errors (i'm on debug).

it ran the onRemove method twice and i checked that sometimes the values i initiated on onApply were null.

 

[Viikuna]

System should be modular, you know. So its easy to add additional libraries, which add additional features.

( And dont start again about "big systems that do everything" -stuff. It is supposed to be a big system which does everything, but that doesnt mean that it cant be modular too )

Anyways. Id like to see BuffClasses too. Having only Positive and Negative just aint enough. We need N number of classes for all kind of ultimate and elemental buffs.

 

[Furby]

I don't want buffs to be automaticly cleared when a unit dies.

It would not do any change in system, and buff wouldn't be automaticly destroyed unless you'd add line like this to buff declaration.

[ljass]//! runtextmacro SetBuffDeathDestroy("true")[/ljass]

or just

[ljass]set thistype.BUFF_DEATH_DESTROY=true[/ljass]

otherwise the buff would react absolutely same as the one made by current system.

 

[Viikuna]

Thats the wrong way.

You simply have a buff clearing trigger like this:

event: -unit dies

actions: -wait for 0 sec, so other death actions can run and you can still use buffs in those triggers
-remove all buffs.

( Unless you have some priority even stuff, when you just make sure that this even is run after other death events )


Its not system codes job to auto remove buffs. ( Although it should come with some simple remove script like this. )

 

[Darthfett]

Thats the wrong way.

You simply have a buff clearing trigger like this:

event: -unit dies

actions: -wait for 0 sec, so other death actions can run and you can still use buffs in those triggers
-remove all buffs.

( Unless you have some priority even stuff, when you just make sure that this even is run after other death events )


Its not system codes job to auto remove buffs. ( Although it should come with some simple remove script like this. )

It should be the system's job to automatically run destroy methods when buffs are removed. It's up to you to code the onRemove method, which may remove an effect only under certain conditions.

You should not have to manually destroy buffs when a unit dies, because those buffs ARE removed. If he revives, he won't have those buffs. Buffstruct is here to make those icons you see under a unit's status actually mean something, not to do your spells' triggering for you.

Viikuna, if you have to manually destroy buffs, you would also first have to check if the unit has buffs of every type. If you simply tell it to destroy the unit's buffs and the unit has none, you may come across problems.

 

[Zwiebelchen]

It should be the system's job to automatically run destroy methods when buffs are removed. It's up to you to code the onRemove method, which may remove an effect only under certain conditions.

No it is not. Just because a buff is removed, you do not necesarily want it to also be destroyed (depends on your spells wether you want that or not ... things like reflection and stuff are always great).

You should not have to manually destroy buffs when a unit dies, because those buffs ARE removed. If he revives, he won't have those buffs.

He will have those buffs even after revival, because those buffs are simply auras. Dead units do not lose their abilities just because they are dead.

Viikuna, if you have to manually destroy buffs, you would also first have to check if the unit has buffs of every type. If you simply tell it to destroy the unit's buffs and the unit has none, you may come across problems.

No, as you can use the EnumBuffs func the system has. That's what it is there for.
And btw; you can't just "destroy" the buffs blindly. It wouldn't work, as you would have to know the struct ID of that buff instance. Struct destruction is not static.

 

[Furby]

It should be the system's job to automatically run destroy methods when buffs are removed. It's up to you to code the onRemove method, which may remove an effect only under certain conditions.

You should not have to manually destroy buffs when a unit dies, because those buffs ARE removed. If he revives, he won't have those buffs. Buffstruct is here to make those icons you see under a unit's status actually mean something, not to do your spells' triggering for you.

Viikuna, if you have to manually destroy buffs, you would also first have to check if the unit has buffs of every type. If you simply tell it to destroy the unit's buffs and the unit has none, you may come across problems.

Viikuna didn't mean death triggers/functions of this system. But death triggers/functions in your map, for example spell which deals damage to nearby unit depending how many buff unit has.

And Viikuna you've got there point. :thup:

I haven't think about this. +rep
(can't, mehehe)

 

[Darthfett]

Viikuna didn't mean death triggers/functions of this system. But death triggers/functions in your map, for example spell which deals damage to nearby unit depending how many buff unit has.

I'm talking about the BuffStructs you create via textmacros. Of course it shouldn't touch your spell structs that simply create BuffStructs inside it. I don't think Viikuna was talking about outside structs, but the actual BuffStructs you create via textmacro.

No it is not. Just because a buff is removed, you do not necesarily want it to also be destroyed (depends on your spells wether you want that or not ... things like reflection and stuff are always great).

This is essentially a buff wrapping struct. It should function in a way identical to a buff: onApply when a unit has a buff applied to it. onRemove when a unit loses a buff. Units lose ALL their buffs when they die.

He will have those buffs even after revival, because those buffs are simply auras. Dead units do not lose their abilities just because they are dead.

An aura that still works on nearby units after the unit is dead should be done via a unit attachment system, such as AIDS. The actual effect of the aura can be done with BuffStruct.

The unit does NOT 'still have' these buffs after revival, because when they unit dies he loses these buffs. They are reapplied when the unit revives.

No, as you can use the EnumBuffs func the system has. That's what it is there for.
And btw; you can't just "destroy" the buffs blindly. It wouldn't work, as you would have to know the struct ID of that buff instance. Struct destruction is not static.

Exactly my point: you can't just 'destroy the bluffs blindly', as it can cause problems. My idea was simply to destroy any and all buffs, without knowing or caring what buffs the unit had. However, I didn't realize Jesus4Lyf had implemented the EnumBuffs method.

 

[Furby]

An aura that still works on nearby units after the unit is dead should be done via a unit attachment system, such as AIDS. The actual effect of the aura can be done with BuffStruct.

The unit does NOT 'still have' these buffs after revival, because when they unit dies he loses these buffs. They are reapplied when the unit revives.

He's saying that these "dummy" buffs are created via aura.. [ljass]'Aasl'[/ljass]

 

[Viikuna]

I was talking about how buff systems should work in general.

You dont always wanna destroy every buff of unit, whenit dies, so its no systems job.

If you do wanna do it you can trigger a trigger like in the post I made before.
If you wanna do something else, you can do a trigger for that too.

You can even edit that stuff later, without having to touch the system code.

( Moar modularity )

 

[13lade619]

Removing before timedDestroy

I need something like this:

A buff that will last up to XX seconds.
but, if the buffed unit deals damage (onDamageDealt) the buff will be destroyed.

problem is, if i call .destroy() inside the methods, the .onDestroy will also run when the timer stops and will run on a null struct.

so what i'm asking for is a way to stop the timer and to 'properly' remove the buff manually.

 

[Furby]

I need the same. I agree with 13lade619. You should add such a feature.

Also, prolonging buff durations. :thup:

 

[Jesus4Lyf]

When I finally add the SpellStruct timer/trigger features, this should get taken care of... <_<

 

[Furby]

Hopefully it will be before 27th of July.

 

[Chaos_Knight]

Hopefully it will be before 27th of July.

lol? Why?

 

[Weep]

lol? Why?

StarCraft 2 release.

 

[Zwiebelchen]

StarCraft 2 release.

Doesn't really matter anymore, as Starcraft II is one of the greatest disappointments of the mapping scene that was ever created.

Code limit and extremely limited bank system is just plain FAIL and destroys everything that made the SC2 engine superior to WC3. :nuts: