Set temp_point

[Krakenn99]

temp_point... one of the most used variable
I was wondering if I use temp_point for every spell will I have bugs and errors?

 

[Chaosy]

As temp_point is usually used and removed instantly after usage, so no it should not cause issues if they spells are done properly.

Though it is preferred to use unique variable names. When creating a spell or a system we usually name our GUI variable like this:

XX_variableName

Where X is a short version of the spell/system name. So if you create a spell called Poison Blades you name it PB_variableName

 

[NeosDany]

You can use TempPoint in every spell you want but bare in mind deleting it after each use, or at least clean it before using it again, for example in a spell set TempPoint then do the action and at the end call RemoveLocation (udg_TempPoint).
In fact you can create loops of TempPoint in the same trigger but remember to add the line that cleans it correctly.

 

[Chaosy]

Not that simple.

If one spell use:

• For each (Integer A) from 1 to 36, do (Actions)
  • Loop - Actions
    • Set tempPoint = someLoc offset by start towards interger A * 10 degrees)

and in a second spell use:

• Actions
  • Set tempPoint = ((Center of (Playable map area))

They might very well conflict. It depends on usage.

 

[defskull]

That is why the name is "TEMP_point" whereas it means TEMPORARY to be used.
The sake of using this keyword for a variable is that it should only be used only for that trigger and should be cleared right after it has been fully used by other scripts (in the same trigger) and doesn't necessarily to be put at the end of the trigger script.

Also, you need to understand by using this approach, you should understand and comply that the variable use is instant, meaning no other trigger may interact with it OR in a pro-longed period of time.

Good Example:
1. Set Point A
2. Create Dummy at Point A
3. Remove Point A

Bad Example:
1. Set Point A
2. Create Dummy at Point A
3. Iterate for 5 seconds OR until Caster is dead
4. Move Dummy to Point A
5. Remove Point A

For this example, you see that there is a "time-gap" for the conditions to occur ?
This means that you should not use TEMP variable as approach, use another unique variable for that trigger because simply, it's not instantly used and removed.

Also, there is no such thing as "happening at the same time" in Warcraft III I believe.
Meaning that, if two triggers having the same Actions but only differ in Events - both happening at the same time, and the Actions used variable that are shared between those triggers, even if you do the Event and pull it at the "same time", the variable will never collide (provided that those two triggers consist of instant Actions, no pro-longed, no interactions with other triggers).

 

[Krakenn99]

Thanks a lot all, so as long as the trigger is instant and I clear the leak it's ok

 

[Ceday]

That is not always true, if a trigger causes a second trigger to run(???) and both triggers use same variable there might be problems.

Trigger 1
Set temp_point = somepoint
Unit - Create a unit at temp_point // after this line code jumps to trigger 2
Remove temp_point // when trigger 2 finishes, we come back here

Trigger 2
----Events----
A unit enters playable map area
----Actions----
Set temp_point = position of triggering unit
Special effect - create something on temp_point
Remove temp_point

 

[Squiggy]

But only if you forget to reassign the variable in trigger 1 which you shouldn't do in the first place.

 

[Ceday]

Reassigning variable won't save you, because every time you create a point its a completely different object.

----Events----
A unit starts the effect of an ability
----Actions----
Set temp_point = Position of triggering unit
Set temp_point = Position of triggering unit
Remove temp_point

You leak a point here.

 

[IcemanBo]

For some info you can read in here http://www.hiveworkshop.com/forums/trigger-gui-editor-tutorials-279/memory-leaks-263410/#C4.

 

[defskull]

That is not always true, if a trigger causes a second trigger to run(???) and both triggers use same variable there might be problems.

Trigger 1
Set temp_point = somepoint
Unit - Create a unit at temp_point // after this line code jumps to trigger 2
Remove temp_point // when trigger 2 finishes, we come back here

Trigger 2
----Events----
A unit enters playable map area
----Actions----
Set temp_point = position of triggering unit
Special effect - create something on temp_point
Remove temp_point

What are you talking about ?

Consider triggers below:

• Trigger 1
  • Events
    • Player - Player 1 (Red) skips a cinematic sequence
  • Conditions
  • Actions
    • Set TempLoc = (Center of (Playable map area))
    • Unit - Create 1 Footman for Player 1 (Red) at TempLoc facing Default building facing degrees
    • Game - Display to (All players) the text: Trigger 1
    • Custom script: call RemoveLocation(udg_TempLoc)

• Trigger 2
  • Events
    • Unit - A unit enters (Playable map area)
  • Conditions
  • Actions
    • Game - Display to (All players) the text: Trigger 2
    • Set TempLoc = (Position of (Triggering unit))
    • Custom script: call RemoveLocation(udg_TempLoc)

If you execute those above triggers, the game message would show in these orders:
Trigger 1 -> Trigger 2

What you stated was, Trigger 1 -> Trigger 2 -> Trigger 1, it's wrong.

Also,

Also, you need to understand by using this approach, you should understand and comply that the variable use is instant, meaning no other trigger may interact with it OR in a pro-longed period of time.

NOTE:
The only time it follows Trigger 1 -> Trigger 2 -> Trigger 1 is when you manipulate the Event Game - Value Of Real Variable - which is not the case for the situations discussed in this thread.

• Trigger 1
  • Events
    • Player - Player 1 (Red) skips a cinematic sequence
  • Conditions
  • Actions
    • Set TempLoc = (Center of (Playable map area))
    • Unit - Create 1 Footman for Player 1 (Red) at TempLoc facing Default building facing degrees
    • Set G = 1.00
    • Game - Display to (All players) the text: Trigger 1
    • Custom script: call RemoveLocation(udg_TempLoc)

• Trigger 2
  • Events
    • Game - G becomes Equal to 1.00
  • Conditions
  • Actions
    • Game - Display to (All players) the text: Trigger 2
    • Set TempLoc = (Position of (Triggering unit))
    • Custom script: call RemoveLocation(udg_TempLoc)
    • Set G = 0.00

 

[Ceday]

You might be right about that specific case because unit enters region event has a delay, still my point is valid for even something like this.

Trigger 1
Create unit
Kill unit
Message:1


Trigger 2
--Events--
A unit dies
--Actions--
Message: 2

2 gets displayed first.



Also I wasn't replying to your post, I didn't even see it.It was a warning about his post above me so no need rage.

 

[defskull]

Rage ? Haha, you funny, come, I give you rep!
Cheers~

 

[Bribe]

Unit Indexers have a filterfunc run within the existing execution sequence by assigning the response directly to the event. This is impossible in GUI so there isn't such a risk, however if you use GUI Unit Indexer you will not want to use those common variables within those triggers.

Order events and perhaps spells with 0 cast time/Amov removed from dummy units will run within the execution sequence, so you want to avoid common variables within those just to make sure.

Damage Events also run within the execution sequence and thus it is not recommended to use those variables from a damage event response or trigger that has an undestroyed variable of that kind before using UnitDamageTarget or Point.

I can't think of other events at this time which may make errors in GUI, but let me say this potential variable overlap is a burden pure JASS or GUIJASS users do not have to suffer thanks to access to locals.

As a safeguard, you can use global variable shadowing with locals, but you have to null local agents and some other handle types as well (such as lightning).

• Shadow
  • Events
  • Conditions
  • Actions
    • Custom script: local location udg_TempPoint
    • Set TempPoint = (Position of Your Mom)
    • Do something
    • Custom script: call RemoveLocation(udg_TempPoint)
    • Custom script: set udg_TempPoint = null