only a small hint: the scanning radar mod now uses tiles instead of chunks to specify the radius, although it (of course) only reveals entire chunks. i don't know whether it is worth it to change anything in this mod to reflect this and it would probably be confusing to specify one radar in tiles and another in chunks in this mod, but people should be aware that measurements might be done in different units and a factor of 32 might be needed when setting up both mods to match each other.

ps: lower cap for minimal power usage in that other mod is 10MW which allows to have radars with radius up to 18 chunks at a speed of 5 (or 40 chunks at speed 1 for a very slow scan, or probably still 13 at a max speed of 10 for almost permanent coverage of everything). on one hand this makes this alignment helper not needed in many cases when the base has a diameter below 26 or 36 chunks, and on the other hand it makes it even more valuable IF looking for the best position 26, 36 or even 80 chunks away (800+, 1100+, or even 2500+ tiles away :-) in some 60 degree angle from the origin, where an entire outpost for that much energy production needs to be built ...

For input / calculation purposes, it would be sane to keep everything in chunks, since the game works this way.
Chunk coordinates calculations HAVE to be done in units of chunks and in integers.
(I may actually consider dropping the support for Scanning Radar, if things get too complicated. I will not even bother with a floating point version of chunk coordinates calculations.)

At best, I may revise the texts and consider adding some extra words to emphasis every values are in chunks.

yes, texts should be consistent ...
the current popup for "Radar reveal radius" correctly says "In units of Chunks, 3 for vanilla radar.", but then continues "Use value of signal R for mod 'Scanning Radar'." which became incorrect after that change. it now should read "Use (value/32) of signal R ..." or even "Use (value/32) of signal R which is given in tiles ..."

ps: speaking of different ranges and factors, i just remember that i recently started counting chunks differently when i played a vanilla map without this mod. instead of "0 1 2 3 3 2 1 0" (with "0" indicating the chunks where radars need to be placed to get full coverage), i am now counting "0 1 2 3 2 1 0", effectively using only 2.5 range for vanilla radars. the reason is simple: i partially started building my factory with blueprints and ghosts in the map view. that requires to place a new radar in the last visible chunk "3" of the old radar, making radar ranges overlap, and both "3" now indicate the same chunk. it's no problem when I walk around and place radars only in the "0" chunks, or when I'm already in map view and simply place radars in the last visible chunk (that would be all "0" and "3" chunks), but to make it match later (one radar in each SIXTH instead of seventh chunk, to have only one auxiliary radar between two "0" chunks) i needed to count differently, so that it would become easier and faster in map view to add new radars or to replace a destroyed one. otherwise it needs two auxiliary radars until i can reach the next planned "0" chunk (total of 3 radars instead of 2) and thus takes 50% longer to rebuild until i can see the critical part of the factory where biters have destroyed or still are destroying something.

i tried setting the range mod option to "2.5" and the decimal point can be entered for that integer, but the value is not accepted :-( it would be nice to be able either entering half chunks as radius, or having a flag to indicate whether to use "best fit for exact complete coverage" or "overlapping borders by 1 chunk"

May need to wait some time for updating text, I currently have no time on modding yet.

Chunk coordinates calculation is an integer operation. If you inspect my code, you will know what I mean.
Decimal value has no meaning use, because it has to be truncated before calculations anyway.

PS1: Now from a (game) mathematical point of view. For such quasi-hexagonal formation, two neighbouring radar sites would be on the same horizontal line (thus East-West line, the same y but with "full-width" distance in x). The other four neighbouring radar sites would have "half-width" distance in x.
Thus the tiling is optimal only for integral values of radar radius (in chunks). Any decimal values will be sub-optimal results.
The game reveal a whole chunk at a time. You may not like this fact, but this is how the game works. Scanning Radar cannot shift the revealing chunk to arbitrary positions.

PS2: Even if anyone do not care about the sub-optimal placement stated in PS1...
Okay, there may be a possible way to have a floating point version of chunk coordinates calculations. But I will NOT do that, as what I stated in my last reply.
It will require additional lots of complexity to the code, even if it is possible. And it definitely prone to logical error (leading to more overlapping / holes) and is even harder to debug.
And I do not see any real benefit to trade for this additional complexity, especially when player can set their radar range freely? When range of 128 (4 chunks) or 160 (5 chunks) both works, why even bother with intermediate range like 129,133,159?
I do not really see how the (game) mathematics can be overcome, as pointed out in PS1.

Just released 0.17.3, which updated the description string.

thanks for the updated string.
i completely agree that the original intention of this thread (R/32) is [solved] now.

the following is only intended as clarification to an idea that may or may not be useful :-)

the problem with "half chunks" is difficult to describe and it is NOT related to the scanning radar or really wanting to have half chunks as distance, but to have an even distance between radars instead of an odd distance: when specifying eg radar range 3, there will be 3 scanned chunks on either side of the radar, thus radars will be 7 chunks away from each other, with 2x3=6 chunks between them.
this is the optimal position to place radars with NO overlap, and thus the original intention of having this mod.

when placing radars in map view (in contrast to walking there and placing them manually), they can't be placed directly at the optimal location (in the middle of some "fog of war"), but at least one "auxiliary" radar needs to be placed between two other radars (and can later be removed after the intended radar finally was placed) and all such "auxiliary" radars need to be placed suboptimally on the third chunk (the last visible chunk in map view). thus the first new aux radar behind an old radar (or in some gap after biters have destroyed a radar in an existing grid) is on the 3rd chunk, and the second new aux radar is on the 6th chunk from the old radar instead of the 7th. now there are three alternatives:
- placing TWO aux radars in the 3rd and 6th chunk and the "final" new radar on the 7th. pros: this the optimal position and matches the recommendations given by this mod. cons: 50% more work, and 50% additional time needed, especially annoying after biters have destroyed the radar and something else (or are still destroying it)
- placing radars every 6th tile instead of every 7th. pros: only needs one aux radar in case of repairs or later expansions in map view, thus saves on work and time. cons: not the optimal position, causing 1 chunk of overlap, and not being able to use this mod for suggested positions while first placing radars manually once, for a basic grid layout. this relates to my suggestion in my last post to have a mod setting for "1 tile overlap".
- same as above, trying to solve it by specifying 2.5 instead of specifying an overlap, to get recommendations for radars with 2x2.5=5 chunks between them instead of 2x2=4 or 2x3=6 chunks. this was NOT intended to get recommendations for half chunks, but only to allow for odd numbers of chunks between radars since radar distances are specified by giving their range and doubling it (doubling integers always results in getting even numbers), and not by specifying the distance to the next radar (which might be confusing, even more so when now changing this existing way to do it).

of course, directly specifying "i want 1 chunk overlap" is much cleaner than doing tricks with non-integers, but would have required an additional mod option and thus i first tried whether some "quick&dirty" solution of specifying "half chunks" might work with the current version.
but you programmed it too well, allowing only integers :-) :-(

Alright, I re-read you text and finally figured out your "0 1 2 3 3 2 1 0" statement, which I misunderstood you that you were NOT(?) talking about scanning radar and its quasi-hexagonal grid...

But then I have a big question about the usage of this mod:
This mod is about optimal placement, so suggesting the sites of {0, 7, 14, ...} that players will walk/run their to place.
Your usage is about withing fog of war (for map view and/or bot placement?), so you actually need {0, 3, 6, 9, 12, ...}.
You also need the positions of aux radars, right? If your aux radars are not placed correctly (3), your final radars would not be placed correctly (6) neither.

If my above description is correct, then you actually need {0, 3, 6, 9, 12, ...}. Something like radius = 2.5 would not give correct results neither. "1 chunk overlap" is not the right word neither.
Saying like "rim/border placement", "fog of war placement", "overlap placement", or "chain placement" could be more clear and closer to such situation.
What you need now (as working trick) is to input "radius = 1" to generate positions {0, 3, 6, 9, 12, ...}.
(But yes, this is just a trick setting. For example, no tricks can get positions {0, 4, 8, 12, 16, ...} for a modded square radar of radius 4. Still needs coding as a new feature.)
But now I have to confirm if this is what you want first.

yes to the first point, from one radar to the next i count 01233210, or you could also say that a radar reveals the chunks "-3 -2 -1 0 +1 +2 +3", and partial yes to your next point too, but i don't consider this mod to be a helper only for optimal placement (without overlap) which was its original intention. i hope to someday also be able using this mod also to build radars (or maybe even other things like roboports) in a grid. optimal placement is always a grid, but a useful grid not necessarily needs to be optimal placement :-)

i don't need additional indicators for aux radars in some 3x3 grid while i manually place down the main radars in the larger 6x6 grid. i only want to place the main radars in a grid that i later can easily expand on (or get to those locations fast with a single aux radar) when using map view. in map view it will also be easy to find the borders of the fog of war, and to scroll/drag exactly horizontally or vertically and to count chunks. this mod is most useful when i walk around, clean up some spots with biters, and then go back to "walk the grid" and look for the next main location more than a screenful away. for this functionality, nothing has to change, except for the radar distances (only even, or also odd). the aux radars will be removed later anyway and thus they can even be placed on the "wrong" chunks as long as it is the last visible chunk in map view. and even if i would need the locations for aux radars, i simply could look for horizontal or vertical alignment at the distance 3 (at the most, maybe with a new doubleheaded arrow "↔", "↕"), but simply looking out for any arrow with a 3 in any direction would be good enough if needed at all.

about the naming: since it is more about specifying (even and odd) total distances and the size of the grid instead of specifying a "range with overlap", the option might be named anything. but since it is not at all about the immediate placement of aux radars, having the word "placement" in that option might be confusing. the option itself is only whether to specify optimal even sized gaps between radars or one chunk shorter odd gaps, with a possible application to be used for those aux radars later.

I have just uploaded 0.17.4, which has two extra options for both mentioned grid types:
- Square (Intersecting) {0, 6, 12, ...}
- Square (Double intersecting) {0, 3, 6, 9, 12, ...}

The original grid type is now called "Square (Optimal)"; the special grid type for Scanning Radar is called "Quasi-hexagonal (Scanning Radar)".