For each integer do.....

[Recnelis Eht]

I made spells that use this function. When for example I use Spell A, the whole trigger works. But when I use Spell B while Spell A is not yet done with the For each integer function, it skips Spell A and proceeds with Spell B. And when I make an AoE spell, the for each integer function only works on one unit instead of all. As you can see I am noob and doesn't know a single sheeesh about programming and coding. The question is how can I make it so that all the For each integer function on all spells will work all the time regardless if the triggers are triggered simultaneously? If not, what alternatives can be sought?

 

[Chaosium]

By default you can use integer A and B which are just examples that Blizz provided, but there's nothing preventing you creating your own integer variable (e.g. SpellInteger1), then you can use "for each integer from X to SpellInteger1), create another one for your second ability, etc

Otherwise if you use A for your first spell and also A for your second spell, they will overlap

 

[Uncle]

I made spells that use this function. When for example I use Spell A, the whole trigger works. But when I use Spell B while Spell A is not yet done with the For each integer function, it skips Spell A and proceeds with Spell B. And when I make an AoE spell, the for each integer function only works on one unit instead of all. As you can see I am noob and doesn't know a single sheeesh about programming and coding. The question is how can I make it so that all the For each integer function on all spells will work all the time regardless if the triggers are triggered simultaneously? If not, what alternatives can be sought?

Those are global variables, key word being GLOBAL. This means that they're accessible and shared between all of your triggers, with any changes to their value immediately applying to those other triggers as well.

If you want your variables to be used exclusively in one trigger then:
1) Use local variables (custom script required).
2) Use unique global variables that you've created specifically for a particular trigger or group of triggers.

The #2 solution can still cause problems if your trigger(s) use Waits, assuming that they can run again while a previous instance is active. In that case you can avoid using Waits entirely and rely on something like Dynamic Indexing or Unit Indexing along with Periodic Intervals / Times. Links in my signature.