Here, I've changed it from random coords to trigonometry(meaning no collision detection needed) 
I really liked this method of creating the asteroid field without having to check for overlaps. You had quite a few things in there that were new to me, like using periods and semicolons, your array setup, and even putting commands on separate lines (I never knew I could do that!). So it took me a while just to figure out what was going on with those little things. But- there was something about the end result that I didn't like.
Before I get into that, let me expand a bit further on what I wanted in this map and some of the problems I’ve encountered.
A randomized map for two AI opponents would be very simple to create, but I want the map to be expandable to accommodate any number of AI factions. In order to maintain perfect symmetry for the purpose of maximizing fairness, a circle-based battlefield becomes necessary for three or more opponents. This method gives each faction the same starting point relative to asteroid availability. Once the starting factions exceed three, however, placement of starting asteroids relative to stronger/weaker opponents creates an unavoidable bias. This cannot be avoided in a 2-dimensional arena, but this problem is minimized by utilizing a circle-based starting grid.
How to design the map?
I figured the easiest way (for my level of math and programming skill) was to divide a circle by the number of opponents, fill out one portion with an asteroid field, and then copy it repeatedly. This would give each faction the most even playing field possible. (I can think of a better way to do this but just don’t know how).
Consider the arena layouts below:



As you can see, the more opponents, the narrower the space becomes for each opponent to “own”. This creates several problems.
If asteroids spawn too close to the center, they will overlap.

If asteroids spawn too close to the edge of “their” boundaries at the same distance from the center, they will overlap.

What about asteroids of different sizes? The AI opponents may or may not care about the radius of an asteroid since the size is not always indicative of an asteroid’s strength, but for aesthetic purposes I wanted to have various diameters on the map. This creates another variable to consider. Assuming a large asteroid spawns close to the map center or an edge, care must be taken that it does not overlap another faction’s identical asteroid. So, the largest potential asteroid size must be taken into account during the map-seeding process.

As this picture shows, the larger the asteroid, the farther from the map center it can be allowed to spawn.
I also want the number of asteroids to be adjustable. This requires the overall size of the map to be automatically adjusted so that the asteroids do not become too dense or too spread out.
Another design problem entailed connections between side-by-side factions. Ideally, side-by-side sections are connected at several points, not just at the center. It would be extremely simple to create a wheel-spoke-like map where all the asteroids are lined up in a row, meeting at the center. This would not be aesthetically pleasing in my opinion.
So back to your Trigonometry version, Aino. Despite fiddling with the code, I could not wrangle the asteroids sufficiently to create a more dense and random-looking asteroid field. Plus, as I added more asteroids, the field became larger in diameter, but continued in it’s snake-like form. If I could figure out how to control it better, it may turn out to be my only solution, since it does not require an overlap-check.
Could you try storing the desired send distances to an array in LevelSetup?
EG you could create an array called SendDistanceStored[n] where n refers to the ID of each asteroid.
Then, at the beginning of LevelLogic(), set all the send distances a second time like this: GetAsteroid(n).SendDistance = SendDistanceStored[n]
That should correct the send distance problems. :>
I’m not sure how I could do that. How would I know what send-distances are necessary before the map is randomly-seeded? I’ve been desperately looking at collapsoul’s Web map for some clues or guidance in creating a "preview" map but his techniques are WAAAAY over my head. Waaaaaaaaaaaay waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay over!
You call MapCreation() from inside itself. This has the potential to create an infinite loop, resulting in a Stack Overflow.
If you instead test the following:
if overlap == true and counter < 50 then
Where counter is initialised with the value 0 prior to calling the function, and then if overlap is equal to true then it increments the counter by one, and then calls the function again.
This means that the code will get a maximum of 50 attempts to do what it wants to do. If it hasn't managed after 50 attempts, it will abandon the attempt and proceed instead of overflowing.
Yes, I was aware of that problem, but your solution seems unsatisfactory in that abandoning the attempt is not an option. By utilizing another method of repeating only the offending asteroid’s placement rather than the entire map, I was able to achieve a successful seeding in very few extra iterations. Unfortunately, that method later proved unworkable in the real world of asteroid creation (vs. Sprites), and ultimately doomed this entire project, I fear. (see the attached map)
So I experimented a bit in trying to tweak the asteroid field creation to accommodate the above-mentioned criteria. If interested, you can view one interim experiment in the first map attached below.
I eventually got close enough to my desired intention that I tried to actually seed a map with actual asteroids. This was where I found out that my methods to this point were not going to work, and am now, I think, forced to put this project into the trash-heap of failed attempts (a growing pile!).
Perhaps I’ll finish this with a much more modest goal of a symmetrical, adjustable, 2-AI arena- something I’m sure I can complete. Or, I could just add a generated code printout for pasting into another map. Let me know if you think it would be worth it.
Attached second is my last non-functional map without attempting to create an actual asteroid field. Use it for visual entertainment purposes only. Just left-click to rotate to a new random layout. Some of the shapes get interesting! (Note- both maps are left-clickable) (Oops- attached wrong map before. Download the new one)