1.
It goes like this:
You order unit to cast some ability
Unit turns to target and gets close to target
Unit Begins Casting an ability Event - no mana is drained by the spell, spell's cooldown did not start yet.
Wait time equal to that unit's Art - Cast Point field
Unit Starts the effect of an ability - mana is drained, spell's cooldown stars
The difference is that the one fires later than the oter, but the more important thing is that with the "Start the effect..." mana is drained and cooldown started - so you cannot abuse this by cancelling the spell and then firing it immediately again.
So it is actually meant more for checking stuff - for example if you want your spell to target undead only, you can use the Begins casting an ability event to check if the target is indeed undead and if no, you stop the caster from casting the spell.
2.
The custom script "tells" the game that the next created unit group should be destroyed.
It will thus take care of memory leak, but you need to use the custom script before
each unit group you want to destroy with this custom script.
4.
It most likely wouldn't cause crash, what I tried to point out though was that the way you have your spell set up, you may damage completely different units than what you targeted with your spell.
From personal experience, when you create some stuff, immediately test it if it works. Don't create 20 things (long scripts) and then test them together, or that you create some stuff and don't test it at all and then you go for example sleep - you will forget that trigger/spell and it may cause crashes due to bad coding but you'll have hard time pinpointing where the problem is since you didn't even test the spell before and you may forget about it at all or you have suddenly way too much code to test.
8.
No two triggers ever fire simultaneously - they fire in sequence one after another - the difference in time they fire can even be just a 0.00001 second difference, but it is difference nonetheless.
If you have trigger, which does not use any waits, no temporal variable inside such trigger will get overwritten by the same temporal variable in other trigger. That won't happen.
For example your second trigger in your previous post has no wait in there. If you use temporal variable in there, they won't get overwritten by any other trigger.
The only exception is the action:
-
Trigger - Fire Your_Trigger (Checking/Ignoring Conditions)
A trigger with this action in it will fire action commands in sequence one after another, then, when it gets to this command, it fires the trigger specified in the command and after that trigger finishes, it returns back to the first trigger and finish that one.
10.
That's not timer.
You need to create variable of type
timer
Then you fire the timer by using
-
Countdown Timer - Start Your_Timer as a One-Shot/Repeating timer...
and in another trigger create an event
-
Time - Your_Timer expires
Timers are exact, they are not prolonged by player's ping, etc.
You have to split your trigger into two - one that fires when spell is cast and the rest is after the "wait" - this will be in the second trigger which is fire when your timer expires.
You can even use the same timer multiple times, etc.
It may seem complicated at first, but it is far better solution.
my friend who is a programmer told me too many arrays use a ton of memory wc3 does not have since its an old game, otherwise i would go crazy with arrays. one time i did and my triggers would not load at all ingame, the way i fixed it was by just deleting the arrays i didnt use/need. here is some of an email he sent me: [anyway.. try not use too many arrays, that is hero[1000] is a rather large array. wc3 is old and doesn't have a very large amount of accessible memory. if you NEED to use an array, try making it smaller, like hero[20].... i don't know if this will work, but i remember that this was always a problem with wc3.]
The problem with arrays is that they're not like in C/C++ or other programming languages, where you specify the amount of slots the array has.
WCIII's variable is either non-array (has 1 slot) or is an array (has 8192 slots starting from 0 to 8191) that's a lot of unused slots.
There's also another thing. When you create array (by checking the "array" box in variable editor), there's an "Array size" field. The best is to leave number 1 there. It has no influence on how many slots the variable will have, but on how many are initialized. If you put high value everywhere, the map initialization may "overload" (for the lack of a better word) and won't initialize properly.
That's all the problem I know about.
loop also doesn't give as much freedom as the method i currently use, which lets me create each item individually without choosing from the arrays i will have to...
Depends what you want to do. But it is always better to think of how to optimize your trigger and make it easier to read.
It's all about set up. However if you don't feel Ok with using loops, etc., it's your choice.
are you sure the triggers fire from the highest to the lowest if they have the same events?
Actually I myself have never checked it. I go by what people here over the years wrote.
If it weren't that way, then I imagine it will be from the oldest trigger to the newest.
im not sure where to find info on the damage detection system, i have searched for it, but it looks like i need to be a programmer to learn it and i know nothing about programming or jass.
You don't really have to understand how it works. You just have to find a GUI dds, not jass/vjass DDS.
Every DDS should have notes on how to import and make it work and an example trigger using the DDS. It's all about knowing which variable to use for event and which use to refer to source of damage and target of damage, etc.
one thing that really bothers me is i cant target destructibles with skills th...
Yeah, i believe you'll have to use an ability which targets trees by default. For example huntress' scout ability (or how's its name).
