I did it!! Hey, I have a rather exciting story to tell about how I solved this problem. Well, maybe it's not that exciting and I'm just nerdy. Anyway, the problem is just how does one break a pangaea continent with a minimal number of meteors programmatically? Basically you want to detect where the thinnest choke points are and throw a meteor at them, hoping to divide the big continent into two.
In PW1 I found chokepoints by drawing a circle around a point, and checked each square in the circles progression for water on opposite points on the circle and also land on opposite points. Then I sorted all the choke points I found by distance to the geographic center of the continent, pick the one closest to the center and put my meteor there. This method worked ok, but there were many meteors that were thrown unnecessarily at the exterior limbs of continents. The center of a continent was not always close to the place where the meteors needed to go. In worst case scenarios much of the land was destroyed before a satisfactory division of continents appeared. In PW1 all this happend after climate generation so the large oceans created by the meteors had no effect on the climate. Fortunately, I was able to tune certain variables so that the meteor scheme worked pretty well almost all the time. The continent shapes in PW1 just happened to avoid worst case behavior mostly by luck.
When I tried to apply this scheme to PW2, I ran into some problems. First of all, I really wanted any oceans created to effect the climate properly, and that meant that I had to throw the meteors before I generated the climate. That meant that I had to work with the heightmap on a different size than the final map, so I could not use 'coast' tiles to test if I had really broken the pangaea or not. Further complicating the situation was the new toroidal option. It is much harder to break up a pangaea that can connect in every direction. I initially just turned the meteor code off when using toroidal, because it failed more times than it worked.
When you look at a pangaea map, the human eye can instantly see where the meteors need to go, so why couldn't I make it happen programatically? It was driving me nuts. So last week I googled and wikepediad and googled again, and I found an interesting article about something called
'betweeness centrality'. After looking further I found an efficient algorithm, invented by Ulrik Brandes, for determining betweeness centrality over a network. But hold on, finding betweeness centrality involves calculating all shortest paths from each continent square to every other continent square. Obviously that's way too much processing overhead, and it was because I tried it anyway just to see what the results would be like. I let the computer run all night and it still wasn't finished, so I never even got to see if I was on to something.
All was not lost though! I decided to drastically cut the processing time by approximating the continent shape at a much lower resolution, and with four connected neighbors instead of eight. So instead of evaluating the paths to every continent square, I was evaluating every 5th one in the x and y directions. So instead of my network looking like this:
Code:
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
It looked like this:
Code:
X...X...
........
........
X...X...
........
Each 'X' is a neighbor of the nearest X.
This reduced the proccessing time enough to be faster than the old way, and it works
perfectly without fail. I still have some minor polishing but hopefully the new version will be released tonight. It even works on toroidal!
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
it even changes the climate slightly near the pole, so that the central section of the map is colder ( snow ) , and it gets progressively hotter as you move to the left/right ( snow -> tundra ) . it looks really realistic, aside from the fact that there's only one pole instead of two of course 
