I've solved problems with AIs crashing (it was a gameframe issue- apparently AIs cannot deal, if the swap-outs occur during frame 0) ... I have random logic, replacing all of the Features on a map with Units... I've solved making the icons not draw on the minimap, they're stealth, they're reasonably fast, etc.
Now I "just" need to develop some logic that will allow for the creation of cities and other special features by game designers, either specific to their game in particular, or for Spring games in general (like, say, a city-generation algorithm that can be used with a "city" map type, giving us awesome city-fighting in Spring, with animated building collapses and other stuff, among other goals here).
I can see that I can get the locations of the Commanders on Frame 1 easily... so, I can exclude them, if I can figure out the whole issues of grids (more in a second). Looks like I can very easily use rectangular selection areas to deal with grabbing the new "features" and deleting them, to make room for things like cities, randomized forests based on some sort of algorithm, etc. All of this looks good.
Only problem is, I need an algorithm that will create and store a grid, so that I'm not just randomly destroying / creating over however many iterations I want this part of the logic to run, but am doing stuff that makes sense. To do this, I need to take the MapX / MapY, and store grid areas that have been already put to use, other than randomly, so that from then on, the script won't attempt to use them.
If you're not sure what I'm talking about, here's an example. This grid is totally blank, except for the player locations, ABCD:
XXXXXAXXXXXX
XXXXXXXXXXXB
CXXXXXXXXXXX
XXXXXXXXDXXX
We want to exclude those 4 locations from the first iteration, which builds a 2X2 box in our world, using building-set F. Ideally, we'd end up with something like this:
FFXXXAXXXXXX
FFXXXXXXXXXB
CXXXXXXXXXXX
XXXXXXXXDXXX
On the next iteration, we need to solve for available grid locations to place a 3X3 box, using building-set H. We cannot over-write ABCD or F, so we should see something like this:
FFXXXAXXHHHX
FFXXXXXXHHHB
CXXXXXXXHHHX
XXXXXXXXDXXX
On the next iteration, a 4X4 box is chosen at random. This has no solution on our map. It should not get placed at all, and the software should re-iterate, and mark down that 4X4 or larger is not possible, so that we don't waste CPU cycles trying to find a solution again.
See what I want? Pretty simplistic, really. But I really don't have a clue about how to go about solving this one- the data-storage requirements to store a 2D grid and use it to solve against are way beyond my meagre skills, and we already know that my ability to work with arrays is, well, terrible- I still don't really get it

It's the last major hurdle, folks, any ideas on how to solve this would be very, very useful- doing this randomly aside from start-positions is possible already, but I'd strongly prefer an iterative approach that solves this stuff more elegantly.
While I'm waiting for some responses, I'm going to start testing the part of this that will put in "unintelligent actors"- i.e., random collections of Units, both Neutral and non-Neutral, that will be assigned random patrol paths and wander around in groups- I've already done basic tests, as part of getting PURE's latest technical stuff done, and it's really pretty easy to do- we can have random Krogoths spawn every 20 minutes, for example, attacking all players
