System BuffStruct

[13lade619]

using Hashtables:

when saving a BuffStruct to [ BuffId x UnitHandle ]..
something would go wrong when you stack the same buffs on a single unit.

-

but how about attaching a Queue (FIFO) of buffs to a unit?.
i dont know how to implement it but it's an idea...

Spoiler

struct fifo_node 
{
  struct fifo_node *next;
  value_type value;
};
 
class fifo
{
  fifo_node *front;
  fifo_node *back;
  fifo_node *dequeue(void)
  {
    fifo_node *tmp = front;
    front = front->next;
    return tmp;
  }
  queue(value)
  {
    fifo_node *tempNode = new fifo_node;
    tempNode->value = value;
    back->next = tempNode;
    back = tempNode;
  }
};

 

[Jesus4Lyf]

That is my current plan. But does it actually make sense? What if you want to see how many stacks there are of a buff on a unit? What if you want to remove the latest stack, not the first? :nuts:

 

[13lade619]

What if you want to see how many stacks there are of a buff on a unit?

..manually having a counter you can +/- and attaching using PUI/AIDS would be my (primitive) solution if i were to code a spell that does that.

What if you want to remove the latest stack, not the first?

http://en.wikipedia.org/wiki/Double-ended_queue

idk if it's possible through JASS though..

again, i'm just tossing in some ideas i dont know how to implement .

 

[Jesus4Lyf]

I've implemented everything you're talking about many times, and there's resources here on TH which do it for you.

The problem is, do I return a list of buff instances or only the buff instance from the start or end?

 

[13lade619]

..reporting in some lag: not preloading.

well, discovered this was the source of my lag, ability ids are not preloaded.

i had to create my own method inside buffstruct to preload the ids... and it reduced my lag.

<hmm.. BuffStruct not preloading + Status not preloading = lagspike!.>

 

[Zwiebelchen]

I got some questions about your system, before upgrading my map to this new system - I read through the posts but I am not 100% sure if everything was answered yet:


1) How can I create stacking buffs with this? Is it enough to just create local buffstructs and just apply them to the unit multiple times? I think it is, but I want to go sure.

function bla takes unit target returns nothing
     local BuffA a = BuffA.create(target)
endfunction

2) How can I write a simple dispel ability that removes 2 buffs from a unit? I want it so that if Buff A is 3 times stacked, it only removes 2 stacks and removes no other buff in this case.

3) The textmacros seem not to create the required object data. Is it save to just create the buffs/abilities on your own? How can I tell which AbilID and BuffID they need?

thanks in advance.

 

[13lade619]

Buff effects CAN stack.. but buggy.... but the 'buff' gets removed when the first one is destroyed.. though the effects will remain as long as theyre triggered

3) The textmacros seem not to create the required object data. Is it save to just create the buffs/abilities on your own? How can I tell which AbilID and BuffID they need?

sometimes it takes 2 save/restarts to create object data.

 

[Zwiebelchen]

Buff effects CAN stack.. but buggy.... but the 'buff' gets removed when the first one is destroyed.. though the effects will remain as long as theyre triggered

So basicly, there is no 'clean' stacking possible without creating workarounds?
Not sure if I understood you right:
Lets say I apply 3 buffstructs of the same bufftype to a unit. Only one buff icon appears, but internally, the 3 buffs are active. If I now destroy one of those buffstructs, the bufficon disappears although the other two buffs are internally still active? If so, then J4L has to do something about it. The buff icon should only be removed when the last buff of the same type gets destroyed.

sometimes it takes 2 save/restarts to create object data.

Thanks ... after saving twice and then reloading, it works magically.

 

[13lade619]

Lets say I apply 3 buffstructs of the same bufftype to a unit. Only one buff icon appears, but internally, the 3 buffs are active. If I now destroy one of those buffstructs, the bufficon disappears although the other two buffs are internally still active?

precisely. because the first onRemove removes the 'buff'. but the triggered effects created by the 3 onApply's are still active.

 

[Zwiebelchen]

precisely. because the first onRemove removes the 'buff'. but the triggered effects created by the 3 onApply's are still active.

So how can I workaround this most efficiently? By counting the number of buffs on my own and only applying one buff to the unit instead of multiple ones? This totally renders the system useless, as you can easily create non-stacking buffs on your own without the need of complicated systems.

J4L really has to fix that problem. I mean ... it's not that hard after all. Just count the number of buffs of each type per unit and only remove the ability and buff if it was the last one. I would do it on my own, but I do not know how the non-removing of the tornado ability in the destroy/setUnit method affects other parts of the system.

As far as I can see, the .isOn() method retrieves the ability level for the unit. This also needs to be changed in order for it to work.

 

[Jesus4Lyf]

It's high on my to-do list in terms of WC3 mapping, I just haven't spent time mapping in a little while.

I'll endeavor to take a look at it soon. I'm aware of the issue and have a resolution or two in mind...

 

[13lade619]

i can think of an easy fix for now..

a bufftype counter computed on the onApply method.
then conditionally removing the ability..

example:

onApply :

if buffcounter == 0, AddAbilId
else buffcounter +1

onRemove :

buffcounter -1
if buffcounter == 0, RemoveAbilId
else nothing.

so the current .isOn will still work.

allows buff Counting and 'Stacking'.
though this does not solve the retrieval issues.

 

[Zwiebelchen]

though this does not solve the retrieval issues.

Dont know what you mean by that? Can you explain please?


EDIT: Also, can you please upgrade the BuffStruct functionality, so that it allows entering a buff art? I can do that manually by just adding the art to the buff ability, but it would be better if I could do that directly with the system.

 

[13lade619]

you can create effect members of the struct and attach them to the unit at onApply, then destroy/null accordingly.

Dont know what you mean by that? Can you explain please?

it's what J4L is gonna 'fix' soon i hope.

currently, you cannot retrieve a specific instance of buff from a unit just yet.
the only thing you can do, i believe, is

check if Buff.isOn(unit) then call Buff.destroy().

 

[Zwiebelchen]

check if Buff.isOn(unit) then call Buff.destroy().

Buff.destroy() only removes the right buff instance, as far as I know, so it should work fine. The problem is only, that is takes the ability away when it is removed.

 

[13lade619]

say you have 2 buffs on,

then you call .destroy().

you do not know which of the 2 got destroyed...

 

[Zwiebelchen]

you do not know which of the 2 got destroyed...

Errr ... what? Are you sure? I think structs are perfectly identified.
I mean, when you call MyBuffInstance.destroy(), then theres no way any other instance than this one can get removed.

 

[Jesus4Lyf]

Zwiebelchen is correct. When you destroy an instance, that instance is destroyed.

I am in the process of fixing when the ability is removed (which is, of course, cosmetic - stacking and stuff already works fine for this system).

 

[Zwiebelchen]

I am in the process of fixing when the ability is removed (which is, of course, cosmetic - stacking and stuff already works fine for this system).

It's not cosmetic. The .isOn method checks for the buff ability and thus is also bugged.

 

[Grundy]

I never really understood why .isOn was there in the first place. I can't think of any situation I would ever use it. If I ever did need to find out if a unit had the buff I think I would rather just have a function in the buff struct that returns the unit the buff is applied to instead of a function that takes a unit as a parameter and returns a boolean. And even that would be so situational I'd probably just write that function in whatever buff struct I needed it in instead of a part of the system that's included in every buffstruct.

Is there a reason why .isOn checks if the unit has the ability instead of comparing it to the unit that the buff was applied to?