Re-using/Multi-using Variables

[Jaina Proudless]

Hello, I am still not very good with my triggers and one question I wanted to clear up is: to what extent can I re-use or multi-use my variables?

For example, I have a lot of position variables because I need to fix position leaks. However, can I simply use a single variable for all of them? Or perhaps for all of them that do not use a timer?

What other variables are safe to recycle this way? If I have multiple systems using the same variables (and clearing it immediately afterwards) can it cause issues?

At the moment my variable list is simply bloated!

 

[Tasyen]

Actions can evoke other events (therefore triggers), if that happens you need another pair of variables to avoid colisions (leaks).
Kinda safe would be to use unique variables for each eventtype.
Cause triggers with same events will execute in a queue. 1. Trigger finished then 2.Trigger runs then 3.Trigger ... They won't colide, if they do not execute their own event

Still problematic in such a view would be, if an event starts the same event again.

Example: main spell starts sub spell.
Example2: Unit dies -> deal aoe Damage -> other unit dies. The unit death can execute again aoe damage which will execute before the 1. trigger finished leaking its location if you use the same location variable.​

 

[Serenity09]

if you need the variable to keep its state, in a way that you can control the dependencies for freely, make a new variable. if you don't need the variable to keep its state between function calls, and don't need the variable to depend on anything besides its type, then re-using a global is fine (and a frequent approach). really, the optimization is more for you than the computer at this point, but it is still a small one, and may help network code depending on its caching system... (i have no clue don't quote me on this)

essentially what you're saying is you want to rename all these variables to something generic and just share that. this isn't necessarily a bad approach, you see it frequently in the BJ global variables for last unit, enum unit, etc. It's more that this approach has limitations that might be problematic for your needs -- by making the variable re-usable you lose a lot of your ability for it to depend on other functionality, again because it needs to be re-usable. That's frequently fine, but sometimes makes for an inconvenient/limiting tool and you'd be better off creating a new global that you can freely control dependencies/relationships with

example:
you have a point global. within a single context, this point is created, accessed, and destroyed. this point does not depend on your code, it just needed to be a point type, and so its fine to make generic

on the other hand:
you have a point global. this point represents where a hero died and will come back to life in code that executes a few min later. you depend on this point keeping its state and also that the point will represent where the hero died. you don't want to make that generic

 

[WaterKnight]

In the first programming lesson, you learn that global variables are bad. In Warcraft III, you have an event-driven system, can nest calls and during Waits, it's basically concurrency. If you don't do elementary stuff, it quickly gets out of hand, you reduce the flexibility of your code and the ability to statically analyze it. I would only use global variables if they truly describe global game states that don't make sense to manifold.