[Trigger] Debuff not being removed at end of spell

[KILLCIDE]

Background on spell: Point-target spell that adds a HoT to friendly units, and places a curse on enemy units. The curse lasts forever as long the enemy unit stays within the AoE. Once the spell is over or if the enemy unit walks out of range, the debuff gets removed.

The spell was working completely fine the other day, but as I started to tinker with the effects, the debuff doesn't get removed anymore at the end of the spell.

If (All Conditions are True) then do (Then Actions) else do (Else Actions) If - Conditions VL_Counter[VL_CurrentIndex] Greater than or equal to VL_Duration[VL_AbilityLevel[VL_CurrentIndex]] Then - Actions Unit Group - Pick every unit in VL_EnemyGroup[VL_CurrentIndex] and do (Actions) Loop - Actions Set VL_EnemyUnit = (Picked unit) Unit - Remove VL_Debuff buff from VL_EnemyUnit

Here are the full set of triggers. I have set up debug messages hoping that it was a problem with the unit group, but this is what I get (I have 12 enemy units set up around me):

• Spell Start + Loop
  • Number of units in VL_EnemyGroup: 12
• Spell Ends
  • REMOVED DEBUFF FROM: grunt (this message appears 12 times)
  • Number of units in VL_EnemyGroup: 0

EDIT: I forgot to clarify that only SOME of the units dont get their debuffs removed. In the example above, 4 of the 12 units didn't get it removed.

EDIT2: So it looks like the only solution I have been able to find was changing the periodic timer to 0.01 seconds instead of 0.03. Is there any other solution other than this?

 

[DEE-BOO]

Try switching it around. Try anything

• Custom script: set udg_VL_EnemyGroup[udg_VL_CurrentIndex] = null
• Set VL_EnemyGroup[VL_CurrentIndex] = VL_EnemyGroup[VL_MaxIndex]

Btw, you have very nice coding, makes me want to touch up my Zephyr entry :L

 

[KILLCIDE]

Try switching it around. Try anything

• Custom script: set udg_VL_EnemyGroup[udg_VL_CurrentIndex] = null
• Set VL_EnemyGroup[VL_CurrentIndex] = VL_EnemyGroup[VL_MaxIndex]

That wouldn't be the problem because the debuff removal happens way before that :/

Btw, you have very nice coding, makes me want to touch up my Zephyr entry :L

Oh wow thanks lol. I always thought my triggers were a hot mess. I really liked your spell in the Zephyr contest! Not only did it fit the theme extremely well, but it looked cool.

 

[DEE-BOO]

That wouldn't be the problem because the debuff removal happens way before that :/

I had an issue with creating groups with custom script and I tested removing the de-indexing and it worked afterwards.

Oh wow thanks lol. I always thought my triggers were a hot mess. I really liked your spell in the Zephyr contest! Not only did it fit the theme extremely well, but it looked cool.

Thanks, I'm glad you liked it

 

[KILLCIDE]

Turns out it was this causing the issue:

Custom script: call RemoveLocation (udg_VL_EnemyUnitLoc)

 

[DEE-BOO]

I have no idea. But I know that groups are weird. Instead of nulling the group at the de-index part, just Empty it, I think it's called clear group.
And instead of this

• Custom script: if udg_VL_EnemyGroup[udg_VL_MaxIndex] == null then
• Custom script: set udg_VL_EnemyGroup[udg_VL_MaxIndex] = CreateGroup()
• Custom script: endif

Just create a empty group regardless.

• Set VL_EnemyGroup[VL_MaxIndex] to Random 0 Units in No Region

Or in the de-indexing part, after nulling the group, pick all unit's within range of VL_TempAoE[VL_CurrentIndex] and remove, the buff if they have it, since you nulled the group they won't gain the buff again but if they still have the buff and are still need it, then your other trigger will fix that,

• Conditions (VL_PickedUnit has buff VL_Buff) Equal to False Then - Actions
• Unit - Create 1 VL_Dummy for VL_Player[VL_CurrentIndex] at VL_PickedUnitLoc facing Default building facing degrees
• Set VL_DummyHeal = (Last created unit)
• Unit - Add a 1.00 second Generic expiration timer to VL_DummyHeal
• Unit - Add VL_AbilityHeal to VL_DummyHeal
• Unit - Set level of VL_AbilityHeal for VL_DummyHeal to VL_AbilityLevel[VL_CurrentIndex]
• Unit - Order VL_DummyHeal to Night Elf Druid Of The Claw - Rejuvenation VL_PickedUnit

 

[KILLCIDE]

Or in the de-indexing part, after nulling the group, pick all unit's within range of VL_TempAoE[VL_CurrentIndex] and remove, the buff if they have it, since you nulled the group they won't gain the buff again but if they still have the buff and are still need it, then your other trigger will fix that,

• Conditions (VL_PickedUnit has buff VL_Buff) Equal to False Then - Actions
• Unit - Create 1 VL_Dummy for VL_Player[VL_CurrentIndex] at VL_PickedUnitLoc facing Default building facing degrees
• Set VL_DummyHeal = (Last created unit)
• Unit - Add a 1.00 second Generic expiration timer to VL_DummyHeal
• Unit - Add VL_AbilityHeal to VL_DummyHeal
• Unit - Set level of VL_AbilityHeal for VL_DummyHeal to VL_AbilityLevel[VL_CurrentIndex]
• Unit - Order VL_DummyHeal to Night Elf Druid Of The Claw - Rejuvenation VL_PickedUnit

Oh thats the healing block, I'm talking about the debuff block right under it xD


UGH what is wrong with this trigger. Its all of a sudden working >.> I didn't do SHIT to it. The location thing wasn't the issue >.> A fix I found was changing the periodic timer to 0.01 seconds instead of 0.03, but I don't want to do that ._. hoping someone can help me find an alternative solution.

 

[DEE-BOO]

I mean, instead of specifically removing the buffs from the group that is about to be de-indexed, just remove the Blind Buff from everyone at VL_TargetLoc[VL_CurrentIndex] within the VL_TempAoE[VL_CurrentIndex].
Here is aura spell that I made for someone before. http://www.hiveworkshop.com/forums/...48393d1441753579-help-please-powerfuel-v1.w3x
EDIT: I didn't see that you edited the comment above xD, I guess you solved it?

 

[KILLCIDE]

I mean, instead of specifically removing the buffs from the group that is about to be de-indexed, just remove the Blind Buff from everyone at VL_TargetLoc[VL_CurrentIndex] within the VL_TempAoE[VL_CurrentIndex].
Here is aura spell that I made for someone before. http://www.hiveworkshop.com/forums/...48393d1441753579-help-please-powerfuel-v1.w3x
EDIT: I didn't see that you edited the comment above xD, I guess you solved it?

That sounds like a good idea will try that out in a bit.

EDIT: Only works when theres one instance running :*(

 

[DEE-BOO]

If you can give me the spell in a test map, I can try to fiddle around with it.
EDIT: Thanks, I'll check it out soon. My mum wants to play poker with me and my brother, she just got into it lol.

 

[KILLCIDE]

If you can give me the spell in a test map, I can try to fiddle around with it.

Here you go!

EDIT: Ignore how the dummies are visibile. I was testing something and forgot to change their model path xD

 

[Bribe]

Add a Game - text message action at the top of your loop trigger, converting integer CurrentIndex to string. If it runs once during the loop, the instance was overwritten. If it runs twice, add a second text message at the bottom of the loop indicating the word "endloop". If the messages display as you'd expect, it may be a good idea to create a second loop trigger from memory (not copying your current one) to see if you can accidentally get rid of the bug (that's what I did in DamageEngine).

 

[KILLCIDE]

Add a Game - text message action at the top of your loop trigger, converting integer CurrentIndex to string. If it runs once during the loop, the instance was overwritten. If it runs twice, add a second text message at the bottom of the loop indicating the word "endloop". If the messages display as you'd expect, it may be a good idea to create a second loop trigger from memory (not copying your current one) to see if you can accidentally get rid of the bug (that's what I did in DamageEngine).

The messages display like normal. The messages continue to spam the instance number until it ends.

• One instance
  • 1
• Four instances
  • 1
  • 2
  • 3
  • 4
• When an instance ends
  • 1
  • 2
  • 3
  • 4
  • endloop
  • 1
  • 2
  • 3

 

[Bribe]

Aside from the rewrite suggestion, you can try analyzing the data within the loop to see if it is distinguishable between resources. For example, printing a message with unit names. It's difficult to find a bug when everything looks right.

 

[KILLCIDE]

Aside from the rewrite suggestion, you can try analyzing the data within the loop to see if it is distinguishable between resources. For example, printing a message with unit names. It's difficult to find a bug when everything looks right.

Yah I've been playing around with debug messages but I put the post up for additional help.

 

[Dr Super Good]

I believe the problem is that the buff is not immediately applied. After the order returns for giving the buff the unit does not have the buff. Some amount of time can pass before the unit gets the buff during which time multiple instances can claim ownership of the unit. Equally well the instance might expire before the unit receives the buff. The result is improper removal of the buff either by multiple instances (owned by multiple instances) or no instances (buffed as expired).

 

[Flux]

I believe the problem is that the buff is not immediately applied. After the order returns for giving the buff the unit does not have the buff. Some amount of time can pass before the unit gets the buff during which time multiple instances can claim ownership of the unit. Equally well the instance might expire before the unit receives the buff. The result is improper removal of the buff either by multiple instances (owned by multiple instances) or no instances (buffed as expired).

You may be on to something here DSG,
So KILLCIDE if that is the case, you can use

• Custom script: if UnitRemoveAbility(udg_VL_EnemyUnit, udg_VL_Debuff) then
• Unit Group - Remove VL_EnemyUnit from VL_EnemyGroup[VL_CurrentIndex]
• Custom script: endif

such that you will only remove the enemy from the group if the buff is really removed.

 

[KILLCIDE]

I believe the problem is that the buff is not immediately applied. After the order returns for giving the buff the unit does not have the buff. Some amount of time can pass before the unit gets the buff during which time multiple instances can claim ownership of the unit. Equally well the instance might expire before the unit receives the buff. The result is improper removal of the buff either by multiple instances (owned by multiple instances) or no instances (buffed as expired).

You may be on to something here DSG,
So KILLCIDE if that is the case, you can use

• Custom script: if UnitRemoveAbility(udg_VL_EnemyUnit, udg_VL_Debuff) then
• Unit Group - Remove VL_EnemyUnit from VL_EnemyGroup[VL_CurrentIndex]
• Custom script: endif

such that you will only remove the enemy from the group if the buff is really removed.

I think that did it guys thank you. I will test it for a few days to make sure it doesn't bug out.