You should understand a little about how triggers work.
Fist of all, you could change the event to a generic unit event, making it work for all players in one event instead of adding it for each player separately.
Once that event fires, this trigger will run.
And if the ability being cast is equal to the paradrop, then the actions will run.
(So far so good.)
Code runs for all clients (all players), so the units are created without problems.
The action "Player Group - Pick every player in (All players) and do (Actions)" is something different.
It loops the code (running it multiple times with (ussually) slightly different input), and changing the (Picked Player) to a player from the player group you chose (in this case "(All players)") so it runs for each of those players.
There is a way to run things "locally" (as in, your computer will run this code, but mine wont).
In that case, lets say, you create a special effect.
Then this special effect is not visible for me because afaik, it is never created.
This is in almost every case a result of GetLocalPlayer() which is unavailable in GUI though so you shouldnt worry too much about it.
In any case, you are not allowed to create certain stuff in a local block (a block of code that possibly doesnt run for all clients), such as units as it creates 2 different states of the game. (Imagine another unit aggro'ing the newly created unit and running towards it... where is that unit running to on my screen?)
In the case of units, but mostly anything (except floating texts and maybe a few more), the game will run out of sync and disconnect the players that have a different game state as the host.
But back to your code.
In theory, your code is fine.
Just place everything outside the loop and remove the loop.
There are two problems with it though.
1, leaks.
Imagine creating objects and putting it in your bag.
What happens if you keep creating objects, but dont remove those objects from your bag?
Simple, your bag becomes heavy and hard to carry with you.
That is the same with this. You create objects (in this case locations that contain data of a point in a 2d world... yes 2d), but you dont remove them.
So every time this ability is cast, you put some locations in your bag, but never remove them.
After a while, your computer will start to run slower and slower and slower until it is unbearable to continue playing.
(Ofcourse, this ability has to be cast over a thousand times, but imagine if all your abilities were like this.)
You can search some stuff about cleaning leaks, but they are not included in GUI, so you require some custom scripts.
2, inaccuracy issues of wait.
Waits are pretty bad as they are inaccurate up to 0.2s in single player and about 2 to 10 seconds in multiplayer (or even higher depending on connection speed).
They are also a pain with variables, as mentioned before that casting unit cannot be (safely) used after a wait.
If you plan on making your map multiplayer, then you should try to change it to a timer.
SPAWNUNIT Paradrop
Events
Unit - A unit owned by Player 1 (Red) Begins casting an ability
Conditions
(Ability being cast) Equal to (==) Paradrop (Neutral Hostile)
Actions
Player Group - Pick every player in (All players) and do (Actions)
Wait 0.75 seconds
