Sure, that would be great. 
Hereās a copy of how I handle converting hit locations to array indexes in the turn based tile toolkit pasted on rancoudās awesome blueprint sharing site:
http://blueprintue.com/view/loP5iFCm/
Edit: By the way, you might be able to simplify it a bit since your requirements are different. Iāve made it so that the tile meshes can be of arbitrary size and donāt even have to be perfect squares/uniform hexagons. Thin and wide hexagons and rectangles work fine too with this solution.
Thanks! It isnāt quite working just yet. I had to reverse a few things since I use flat topped and you use pointy topped. A lot of the times it will pull a neighbor tile instead of the tile I actually clicked. Unfortunately I will have to troubleshoot both the snapping and the reverse projectionā¦ -_-
Donāt mention it 
Just troubleshoot each one individually and use a lot of print statements while you debug and it shouldnāt be too hard. The solution I gave you is the most efficient I could think of for converting from vector to index, being just some simple math and a simple get from array.
Had the X and Y values crossed. With that fixed, I am seeing another problem. Testing traces on an area within 5 hexes of the camera works well. Further out though and a gap starts to form between where the trace actually seems to hit, and the index that it pulls. Compare the red trace markers to the nearest mountains(circled):
Under the suspicion that the sphere and projection might be slightly mismatched, I enlarge the sphere by .1% and see this:
Then by .2% and this:
Those mountains arenāt smaller. They just seem to be sitting in a trough in the projection.
Upon closer inspection of the collision sphere mesh, it is obviously to blame. Matches the above image pretty well It has 960 triangles and 745 verticesā¦ I am going to need something quite a bit more robust than this.
I was beginning to think it was a flaw in the projection math and that was really going to suck! Luckily it is just my collision mesh.
Working on getting collision to work with my 50K triangle sphere. 
Anyone know how to get proper collision to generate on a sphere using the editor? I am not sure the editor is up to the task. You can see the holes in the sphere using auto convex collision with the max hulls/verts I could put into it:
I was trying to add collision to my sphere in blender but that program is so un-intuitive it makes me want to break my computer.
Finally got a proper collision sphere in game and the response is way better. Thanks to J. J. Franzen for the mesh. I am glad that the sphere was the root of the problem and not the math. May need an even more uniform sphere in the future, but the accuracy on my standard test map size is 95-98% so I am content with it as it is.
I am pretty busy with work the next 3 weeks, but I will be taking time off work afterwards to work on the generator. Hopefully I can still make progress in the few hours I do have.
Happy to help. Although it is frustrating that the importer seems to ignore a collision mesh with more then 500 triangles. Anyone know if thereās a hard polygon limit to individual UCX_ meshes? I did try turning off the One Hull per option in the importer as I found suggested around the googles but to no effect. I know its not the naming because a poly sphere with 15x15 divisions imports fine, but the same sphere with 16x16 divisions does not. Very weirdā¦
J^2
Thanks. Please chime in on my feedback thread with any details that might help shed light on what is actually going on: In Editor Collision Creation And Collision Mesh Feedback - Feedback for Unreal Engine team - Unreal Engine Forums
Contemplating whether I could practically apply polar wrap if at all.
Noting that the rectangular map shape all but eliminates any possibility of a normal looking polar region due to the circumference of the arctic circle equaling that of the equator; what do you guys think of the polar alignment?
Try and focus on the tiles outlined in red as if you were staring at a flat map of Earth. Going directly north from North America puts you in the middle of Eurasia. North from the Atlantic puts you in Eurasia/Pacific. Basically anyway.
The indexes seem to line up in a way that is mechanically sound. You could say this form of map projection has some serious distortion at the poles, but is an otherwise practical method for polar wrapping. I am asking your guyās opinion because I may be missing some key alignment-related loophole that could break gameplay such as āIf you go north from tile X to tile Y you teleport across the mapā.
In conjunction with this, I think I may seriously try to work the map in such a way that as the player moves around the map, the map moves around the player. This way I could have just 1 of each tile on the map instead of 3 versions for the world wrap. So if the map is 10 tiles tall, then if you are above index 5, then 6 through 9 will be above you, and 0 through 4 below. If you are above index 9, then 0 through 4 above, and 5 through 8 below. If you move up 1 tile, then all tiles on the very bottom move above you, and vice versa. The oddest part might be when you come over the pole from North America and see Eurasia flipped upside down. You could play the entire map flipped upside down just by staying on that side of the globe in that orientation. It would all flip back to normal if you just went south far enough(before eventually flipping again).
When I first implemented wrap I kind of wrote this method off as not being practical, and I didnāt really understand it so I went with the easiest option for my brain at the time. I now think I can make it happen, if very carefully. A few problems such as it will break my river splines completely, but the projection already does that. I may end up using normal meshes for rivers since it will probably take an engine upgrade to get them to work with the sphere projection.
I have a feeling that I will be adding an option for players to either use sphere map mode, or simply use normal flat map mode. The entire logic of the game will be happening on the flat map anyway, so that should be pretty simple(knock on wood ).
I might be understanding this wrong, but when standing on one of the poles you should be able to move to any tile surrounding the pole in the same amount of steps. With your new solution you will only be able to move to the tile that is directly opposite of the tile you start from, or am I missing something? This would create strange situations where for instance Canada could reach northeastern Russia through the poles, but not northern Norway. But really, nations having trade routes, sending troops or even scouts through icy poles would be pretty silly in a world like ours, so you could just block them off like iv Civ.
However, if you want to simulate alien worlds with ice-free poles you would have to think of something. If I have understood you correctly or not I would in any case urge you to start adding some very basic gameplay soon. To create pawns moving across the world might get you to see benefits of certain approaches that you would not have otherwise, and might even force you to scrap solutions which seemed ideal without pawns. That would suck having to fix later. Just my 2 cents
The map will interlock at the wrap so normal movement will apply. You can see the wrap a few posts up.
For most of the game, on a map with standard Earth-like climate, the extreme cold will stop or kill any units that wander into it. By the time you get to the industrial age and are able to actually traverse the poles in a meaningful manner, the shape and exact mechanics of the polar region will be an oddity that I think will be worth the ability to send subs, nukes, planes, and even (eventually) land units over, as well as interactions such as fighting over oil and other pristine resources.
The biggest problem is that the map is a rectangle. Apart from blacking out half the tiles near each of the poles and coming up with all sorts of weird algorithms for the newā¦ whatever shaped world, there basically isnāt a viable solution to tile a sphere with only hexagons. And I donāt intend on using any pentagons.
The options as I see them are:
- A rectangular map with no polar wrap as you see in most such games.
- A map with multiple tile shapes that would be hell to program for.
- A map that basically wraps in an intuitively odd way, with a polar region that looks pretty weird once you do finally get to the point where you can lay eyes on all of it.
I am heavily leaning towards #3 just to have a polar wrap in a genre that hasnāt seen such a thing.
This isnāt even for alien worlds, but even our own. We are already at the point where the north pole is navigable by ships in the summer. It wonāt be long before the whole north pole is open ocean as a normal occurrence. I intend to have options for runaway global warming events that could change the entire strategic picture. The same for global ice ages(giant meteor, supervolcano, mass nuclear war, etc).
Anyway, the map generator is so wide open that you can easily have a generation that does not have icy poles. The lack of polar wrap makes even less sense in an earth that is too hot to have ice caps.
And yeah, I really want to start working on pathfinding soon, but I need to work out a few other things first including fleshing out a new system for wrapping and re-factoring the rest of the generator. I am not at all worried about polar wrap causing any major problems. It will be easy to turn off if I change my mind.
If youāre confident then Iām confident Working on my own blueprint Iāve had a few time where I had to rework parts of the system when adding new features, but thatās pretty much unavoidable anyway.
Yeah it can be, but everything builds on itself. And sometimes you just have to prove what doesnāt work before you get to what does.
Will you be making the system such that you could choose between the flat map and the spherical projection? I do appreciate the visual impact of the projection, but depending on the game design, I may not want the game world presented that wayā¦
J^2
Yeah I will most likely have an option to switch back and forth between the two.
Just doing some more visualization tests between the indexed map and a polar view of earth:
These are quick approximations, so obviously my 8 bit landmasses could be adjusted and moved about a bit.
So the most obvious difference between an actual sphere like the earth and a polar wrapped cylinder is the stretching that happens around the poles. This is pretty common when map makers translate the spherical earth onto a flat piece of paper.
This actually looks a lot better than I thought it would. It doesnāt line up perfectly around the poles, but honestly I think the big features are close enough that it should work out.
One thing I noticed in game though, is that you can just barely see any given point(say Alaska) on 2 sides of the globe when you are hovering over the pole. I feel like I am working in 4-5 dimensions and it hurts my brainā¦ Almost as if in the real Earth you are over Alaska, then you go to the North Pole, then you go directly South to Siberia, and then due east back to Alaska. But in game this shows up as simply North-East and halfway around the globe.
Anyway, by slightly reducing the size of the sphere projection you wonāt be able to actually see this directly in game(IE see 2 of the same city on the map at the same time). If the player scrolls in a certain way and finds them self back at the city they just left much faster than intuition would allow, then this is the polar wrap/stretching at work.
Am I crazy, or should this basically work?
Just poking in to say hi! Itās been fun reading all 3 threads for your generator. Very cool stuff. Iāve been lurking for awhile, but finally joined up and starting to post a bit.
Canāt wait to see what the future holds.
Thanks! Canāt wait to start making some progress again. Work has been stomping me flat the past few weeks. 
I didnāt read all the replies, but the type of conversions you want are polar coordinates <-> cartesian coordinates.
Check out the Wikipedia for it: Polar coordinate system - Wikipedia
The important bit:
The Z coordinate/height stays the same/is whatever height above the ground was prior to projection.
As an aside, projecting a plane onto a sphere will never turn out really right. Youāll always suffer some distortion. The naive projection has quite a lot at the poles.
What you really want, is a Dymaxion Projection. Use an unwrapped icosahedron as a source map, or use a cube and tessellate that into one, then into a sphere. You can use the typical polar coordinate conversion (use the 6 faces of the cube to get the X/Y coords).
Iāve done a lot of research into planetary rendering, as Iām interested in eventually making something like Outerra, where itās capable of gameplay on the scale from a ground level avatar to flying out to space. A dymaxion projection canāt be beat.