hx and gx should be nulled after you have removed their objects in case those are local variables.
CreateNUnitsAtLoc can be replaced by
native CreateUnit takes player id, integer unitid, real x, real y, real face returns unit
You actually do not even need a location and there is...
A trigger condition cannot use waits. But independent from that, it's just some sort of organization to interconnect dynamic codes and for semantics. The worst thing, you can do, would be to replace TriggerAddAction by TriggerAddCondition directly inlined. Because that's not what it stands for...
On inwarcraft.de, in the past month, we have collected some suggestions that would improve wc3 mapmaking. The requirements were that backwards compatibility should be maintained and that it should not stray too far away of the existing engine. The results were posted in blizzards suggestion...
By comparing it to -1 as suggested here?
You can if you preallocate this -1 to where it belongs to. I guess you are referring to the default values of Wc3, game caches, hash tables and integer arrays returning 0 at unassigned keys.
Suitable index allocation method depends on the situation...
You can have up to 100 texttags, their ids ranging from 99-0 (counting downwards). When you destroy a text tag/it's life span ends, its id is available again, being thrown at the top of the stack. This means, you will first get the latest released ids back. If all 100 texttag slots are used up...
Functions without parameters cost nearly nothing. Else it has to declare the locals and assign them the incoming values. But it's nuts to make this priority. There are other interests mapmakers strive for like progress, modularity, not write the same things twice, build greater structures. Would...
I do not know if it is faster and it also depends on your exact situation but these are possibilities. Maybe SetState/GetState is faster than this.life=/SetState/this.life after all. Well, decreasing the frequency would of course help greatly. Regeneration is mostly a slow process in gameplay...
Not sure why you need the evaluation and return false.
Instead of
call SetUnitState(<unit>, UNIT_STATE_LIFE, <value>)
you can use
native SetWidgetLife takes widget whichWidget, real newLife returns nothing
to save on parameter.
Rather than reading out the same value 3 times from struct, you may...
Why do you need own hashtables for each unit? They already reserve their space by integrating them in the keys. Also you can only have 255 hashtables, so this part alone allows no more than 127 registered units.
Never use "Unit - Damage Area". As you have noticed, you cannot properly filter the targets there and it may even create a problem for mac users as this function is not safe. Pick the units in a group (there is a "range around location" pick type) and you can add a condition function. Then use...
No, not generally. This means if the global gameplay is more self-sustaining like in GTA or Diablo, that's a plus. But it becomes quickly boring or the desultoriness seems like a huge waste of time. Since it has no ending, people will leave asynchronously and those that are really interested and...