1) The grid should be based on the size of the green system circle. I was going to suggest 110% of that size i.e. two systems placed one grid-point apart would have a gap of 10% the diameter. Most people would probably space systems 2 grid-points apart to allow for the infographic outer circles. Given the 20 and 140 numbers mentioned above, I'm guessing a system circle is 50 diameter with a 20 buffer giving a default 'used' grid size of 70 and a default placement of systems two grid-points apart. This is a little bigger than my off-the-top-of-my-head 110% but perfectly acceptable to me. Note though that it is impossible to place a system midway/halfway between two default placed systems as 20 does not divide 70.The finer grid spacing allows for more creativity in arranging the map:I agree db48x, but, it seems highly unlikely anyone would want systems to overlap, so a grid smaller than the diameter of a green system circle is unlikely to be necessary. A person likely might want to place a system midway between and above/below two others suggesting a grid half the size, but the reality of the space necessary to display the information the player will likely want suggests using the even grid-points for major placements and the odd grid-points for half-way. Indeed, Hex-grids like the one you have created in the screen shot you have attached can be approximated using a really simple algorithm: even columns (-2, 0, 2) use even rows (-2, 0, 2) and odd columns (-3, -1, 1, 3) use odd rows (-3, -1, 1, 3)
2+3) Geo-survey status and grav-survey status are shown in completely different ways, and grav-survey info is shown multiple times. Currently a partially surveyed system shows a percentage number (that never goes away) for the geo-survey status, a red circle if the grav-survey is incomplete, an additional orange circle if jump points have been found and remain unexplored and an orange dot with the number of unexplored jump points. I suggest showing the geo- and grav- status as a counter-clockwise decreasing coloured arc proportional to what is remaining to be done. Zero system bodies geo-surveyed show a complete (red?) circle. 42% geo-survey complete, show an arc from 12 to 7 (210°). Similar for grav-survey status: zero done complete (orange?) circle, 17 of 30 points surveyed a 156° arc. The orange dot with number for unexplored jump points.
5) Ctrl-click on a system on the galaxy map to go to the system map for that system. Ctrl-click on the galaxy map icon to go to the galaxy map with the current system highlighted (rather than Sol).
The finer grid spacing allows for more creativity in arranging the map:I agree db48x, but, it seems highly unlikely anyone would want systems to overlap, so a grid smaller than the diameter of a green system circle is unlikely to be necessary. A person likely might want to place a system midway between and above/below two others suggesting a grid half the size, but the reality of the space necessary to display the information the player will likely want suggests using the even grid-points for major placements and the odd grid-points for half-way. Indeed, Hex-grids like the one you have created in the screen shot you have attached can be approximated using a really simple algorithm: even columns (-2, 0, 2) use even rows (-2, 0, 2) and odd columns (-3, -1, 1, 3) use odd rows (-3, -1, 1, 3)
I find the galactic map rather frustrating to use, and the impression I've gotten here is that I'm not the only one. I think there are a couple ways the galactic map could be improved, some of which I think would be fairly easy to implement:The finer grid spacing allows for more creativity in arranging the map:
- Wider grid spacing. Currently I find it very easy to accidentally misalign different parts of the map because the gaps between the points on the grid are very small. Put another way, there
Agreed. No matter how far apart the grid spacing is, the ideal way to do it is to have the map update live, as you drag things around. This requires a decent frame rate, and that requires a somewhat different mindset to achieve. Instead of dragging a system and then clicking a button to snap everything into place, the drag and drop system should update the map continuously, with the system already snapped into place. This gives the user a feedback mechanism that allows them to naturally adjust the system into the place they want it to be in one motion.
- Better grid snapping. To be honest I can't quite figure out what algorithm is being used to snap systems to the grid: sometimes it seems to be rounding to the nearest grid point, other
times it seems to be rounding down, moving the system in the direction of the starting
I think this only helps you by going to the fleet in the system map, I don't think it does anything with the galactic map.I have a other maps suggestion. I come to realize this with my biggest empire yet finding a system can be hard. I know were are my colonies but if something happen to one of my exploration ship I probably don't know were the system is and I have to look at all the map.
It would be nice to have a research tool in the galactic maps, it could center the maps on the system you are looking for.
Not to say this isn't a good idea, but if you need to find a specific ship you can select it (or its fleet) in the Fleet Organization window with the checkbox to center the tactical map on the selected fleet enabled.
I have a other maps suggestion. I come to realize this with my biggest empire yet finding a system can be hard. I know were are my colonies but if something happen to one of my exploration ship I probably don't know were the system is and I have to look at all the map.
It would be nice to have a research tool in the galactic maps, it could center the maps on the system you are looking for.
Supported 100%.
- Implement zooming. This one is pretty clear I think -- maps grow beyond what can fit on one screen very quickly, and it would be much easier to make sense of the map if we could zoom out.
an option to use the largest colony in the system as the starting point, rather than the primary star.It should actually default to that even if orbital mechanics make it a dynamic distance rather than a fixed one.
I would love it if the calculation of distance between systems was improved in two ways:I would like these as well, and also an option to use the largest colony in the system as the starting point, rather than the primary star.
1) Take into account Lagrange points.
2) In cases where multiple routes are possible, display the distance of the shortest possible route, not the distance of the route with the fewest hops.
