Custom Script Fix

[Faith]

• FS Run
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Feared Strike
  • Actions
    • Set FS_TempLoc00 = (Position of (Target unit of ability being cast))
    • Set FS_TempUnit00 = (Target unit of ability being cast)
    • Wait 0.40 seconds
    • Unit - Cause (Triggering unit) to damage FS_TempUnit00, dealing ((Real((Level of (Ability being cast) for (Triggering unit)))) x 50.00) damage of attack type Spells and damage type Normal
    • Unit - Pause FS_TempUnit00
    • Unit - Move (Triggering unit) instantly to FS_TempLoc00
    • Animation - Play (Triggering unit)'s attack animation
    • Wait 0.25 seconds
    • Unit - Unpause FS_TempUnit00
    • Custom script: call RemoveUnit(udg_FS_TempUnit00)
    • Custom script: call RemoveLocation(udg_FS_TempLoc00)

That's my trigger. I have a problem with this part:

• Custom script: call RemoveUnit(udg_FS_TempUnit00)

It seems it removes the unit, instead of just reseting the variable. How can I reset the WITHOUT removing the unit?

Or rather, do I even need to reset the variable?

~Go easy on me, this is the first ability I've ever made, and my first time using custom scripts.

+REP will be given to whoever helps me.

 

[Axarion]

It's not really needed to reset the variable but you could use:

• Custom script: set udg_FS_TempUnit00 = null

 

[Faith]

Alright, if it's not needed, I won't bother. Thanks anyway.

 

[defskull]

Off-topic
You should NEVER use Wait action as this can cause errors and bugs
Why do you want to remove the unit ?
You want to clean the leaks or something ?
If you are, you should just use this:

• Unit - Add a "value" second Generic expiration timer to (Your soon-to-die unit)

This action is from Unit - Add Expiration Timer
By adding this action, the trigger will automatically clean the leak
It doesn't need any custom script to clean it off

 

[Faith]

I don't want to remove the unit. The whole point of this thread was to find out how to remove the leak, if there was one. However, Axarion explained that this is not necessary.

~Instead of wait, what should I do?

 

[defskull]

Replace wait using Timer
Although Timer must be cleaned using:

• Clean
  • Actions
    • Custom script: call DestroyTimer(udg_"variable")

 

[GhostThruster]

I'm back at helping!

Anyways, there is no leak. Waits can be used in instant-use actions, but not periodic triggers. Your trigger is suitable to use waits. If you don't want to use waits, you can use Timers and periodic triggers.

 

[Faith]

Timers take longer to make than wait actions.. soo... THANKS FOR CLEARING THAT UP.

 

[defskull]

Longer time, really ?
Does 0.0016s bugs you.. ?

 

[Faith]

Yes.

 

[GhostThruster]

No, but spending an extra five minutes just setting up a timer for one trigger does. Waits should only not be used for periodic, repeating triggers, like knockback spells.

 

[defskull]

I heard Wait can cause the trigger to be non-MUI ???

 

[PurplePoot]

Timers take less than a minute to set up and are better in pretty much every way than waits are. There are very few situations which justify using waits.

That said, I think the OP of this thread is an excellent example of why you shouldn't just teach people to blindly call some function at the end of every trigger to "clean up leaks" somehow.

--

Alright, here's a crash course on leaks.

Object leaks (for example, the location in this trigger): Warcraft III has no garbage collection, so unused objects have to be explicitly gotten rid of. In the case of your trigger, you are creating a Location object and thus need to get rid of it (via RemoveLocation) to prevent leaks. However, in the case of the unit, getting rid of the unit is undesirable since the unit is interacting with the game (and units will be automatically cleaned up when they die/decay regardless).

Reference leaks (for example, setting a variable to null): If you don't dereference every reference to an object after it is destroyed, then the index will never free. This only really matters if you cause enough of these to run out of references, which will almost never happen, or if you are using GetHandleId() and hashtables. In the case of local variables, this means you will have to null object-related variables (assuming the object will be destroyed at some point in the game, which excludes things such as players/heroes/etc that generally persist) since they can never be assigned after the function exits, but in the case of global variables reassigning them will dereference the old reference and thus cause the index to eventually be freed regardless.

Hopefully that was somewhat understandable. The first part (object leaks) is far more important for GUI.

 

[Faith]

GUI = Graphical User Interface, yes, no?

MUI = ???

Thanks PurplePoot. You cleared up EVERYTHING.

 

[defskull]

MUI = Multi Unit-Instanceable
Meaning multiplayer units can cast the spel at the same time, without having bugs or errors
Usually, Wait action can cause the trigger to be non-MUI as Wait action should ONLY be use under certain circumstance like the trigger is meant for Single-player map

Another 1 is MPI = Multi Player-Instanceable
It allows the trigger to be used by multiple Player at a time

 

[Faith]

Ahh, I get it. Alright.. you guys win. I'll make a timer...

Must I create a variable for the timer as well?

EDIT: Don't answer that. I was being stupid.

 

[defskull]

You can create variable for Timer, but you must destroy it later by using Custom script: call DestroyTimer(udg_variable) !

However, you can also just create the timer without the use of variable:

• Countdown Timer - Start (Last started timer) as a One-shot timer that will expire in 30.00 seconds

By using this method, you don't need the custom script and it's leakless

 

[Faith]

Too late.

• FS Run
• Events
• Unit - A unit Starts the effect of an ability
• Conditions
• (Ability being cast) Equal to Feared Strike
• Actions
• Set FS_TempLoc00 = (Position of (Target unit of ability being cast))
• Set FS_TempUnit00 = (Target unit of ability being cast)
• Countdown Timer - Start FS_WaitTimer00 as a One-shot timer that will expire in 0.40 seconds

That was the first trigger..
..Here is the second.

• FS RunNext
  • Events
    • Time - FS_WaitTimer00 expires
  • Conditions
  • Actions
    • Unit - Cause (Triggering unit) to damage FS_TempUnit00, dealing ((Real((Level of (Ability being cast) for (Triggering unit)))) x 50.00) damage of attack type Spells and damage type Normal
    • Unit - Pause FS_TempUnit00
    • Unit - Move (Triggering unit) instantly to FS_TempLoc00
    • Special Effect - Create a special effect at FS_TempLoc00 using Abilities\Spells\Undead\AnimateDead\AnimateDeadTarget.mdl
    • Special Effect - Destroy (Last created special effect)
    • Animation - Play (Triggering unit)'s attack animation
    • Countdown Timer - Start FS_WaitTimer01 as a One-shot timer that will expire in 0.25 seconds

Here is the final trigger.

• FS RunFinal
  • Events
    • Time - FS_WaitTimer01 expires
  • Conditions
  • Actions
    • Unit - Unpause FS_TempUnit00
    • Custom script: call RemoveLocation(udg_FS_TempLoc00)

It doesn't look as cool and complicated, 'cuz it's in 3 smaller, seperate triggers... but... I suppose if it works correctly...

 

[PurplePoot]

This isn't actually much better since it still is carrying global values for a finite amount of time (although it is more accurate timing-wise).

 

[Faith]

I forgot to add in the custom script to remove the timer. Deos that help it any?

Here it is.

• FS RunFinal
  • Events
    • Time - FS_WaitTimer01 expires
  • Conditions
  • Actions
    • Unit - Unpause FS_TempUnit00
    • Custom script: call RemoveLocation(udg_FS_TempLoc00)
    • Custom script: call DestroyTimer(udg_FS_WaitTimer00)
    • Custom script: call DestroyTimer(udg_FS_WaitTimer01)

 

[PurplePoot]

No, don't destroy the timers, since you will want to use them more than once.

The issue is that you are trying to carry a value in a global variable over time, so if the trigger executes a second time while the first instance is still executing the values will be overwritten and thus the old values will be forgotten.

 

[defskull]

Please use checking Conditions, like this:

• Checking
  • Events
    • Time - Every 0.03 seconds of game time
  • Conditions
  • Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • (Integer((Remaining time for (*Your Timer*)))) Equal to 0
      • Then - Actions
        • *Here is your action*
      • Else - Actions

Relate this trigger with your initial trigger using Turn On Trigger action

@PurplePoot
No wonder I've had some bugs with my Timer, I've destroyed them and the old values are forgotten~
But, if the timer is not cleaned, it leaks, what about it ?
Leak is bad you know...
But like I said, if you didn't set your Timer as Variable, you would not need to destroy it as it doesn't naturally leaks

 

[PurplePoot]

No, their initial solution was better.

 

[Faith]

Ugh... This is taking more than 0.0016 seconds.. Will it really matter all that much if I just use Wait actions?

I'm not trying to be lazy here... but.. I don't really need to wait... it just made it look more complex. Special Effect-wise.

 

[defskull]

It depends =)
If you're using this trigger for Multi-player, it is NOT wise to use Wait action
A long time-consuming and steady project/work will produce the best result, think ;D

 

[Faith]

Very well. I just want it to look cool.

 

[defskull]

You're saying that using Wait seems, cool ?

 

[Faith]

I'm talking about the ability/effects. Not the triggering.

 

[GhostThruster]

Here is some info about waits:

• Good use of wait
  • Events
    • Unit - A unit Acquires an item
  • Conditions
  • Actions
    • Wait 10.00 seconds
    • Unit - Kill (Triggering unit)

• Bad use of wait
  • Events
    • Unit - A unit Acquires an item
  • Conditions
  • Actions
    • Set p = (Position of (Triggering unit))
    • Wait 5.00 seconds
    • Unit Group - Pick every unit in (Units in (Playable map area)) and do (Actions)
      • Loop - Actions
        • For each (Integer A) from 1 to 10, do (Actions)
          • Loop - Actions
            • Wait 5.00 seconds
            • For each (Integer A) from 1 to 10, do (Actions)
              • Loop - Actions
                • Wait 5.00 seconds
                • Unit - Kill u
                • Custom script: call RemoveLocation(udg_p)

About timers: if you want MUI timers, you'll need to use Hashtables(arrays don't work as you can't detect the expired timer), as your above trigger won't be MUI. In this case, you might as well use waits.

So, to clarify things: use the bloody waits in that trigger!

@Post 22 by defskull: if you're gonna do that thing, you might as well make a periodic trigger.

Arkon Kaos, if you want, I can give you a demo map of all 3 different types of 'waits'.

 

[D4RK_G4ND4LF]

Here is some info about waits:

• Good use of wait
  • Events
    • Unit - A unit Acquires an item
  • Conditions
  • Actions
    • Wait 10.00 seconds
    • Unit - Kill (Triggering unit)

use gametime wait since normal wait might disconnect players because of the inaccuracy of waits (and lags might fuck it up further)
the gametime wait waits until all players synced their stuff

arrays don't work as you can't detect the expired timer

for int i from to....
GetExpiredTimer() == timer

@topic
I'd use a periodic time event for that or use no wait at all
doubt that any player will care if it takes a few parts of a second to cast that spell or not
also you could avoid "pause unit" this way and you won't have to struggle with any other spells using "pause unit"
(e.g. you cast your spell, then an enemy casts a spell on you which pauses your hero for 10 seconds and makes him invulnerable for that duration but your spell unpauses your hero after 0.25 sec and you got an invulnerable hero for 9.75 seconds which would be lame)

 

[GhostThruster]

for int i from to....
GetExpiredTimer() == timer

Well, technically that is JASS.

 

[D4RK_G4ND4LF]

Well, technically that is JASS.

• call RemoveLocation(udg_p)

Well, technically that is JASS.

 

[defskull]

GUI uses a semi-JASS trigger
Well, maybe not semi, but just ONE
That is:

• Custom script: call (WRITE YOUR OWN FUNCTION HERE)

 

[GhostThruster]

I meant that you couldn't detect an expired timer in conventional GUI script. Happy?
But whatever, you're more experienced than me in triggering.