there already was a mod that tried similar by placing "virtual markers" on the ground at locations where radars should be built, but sometimes it was difficult to handle (setting up the origin, etc) and most of all you only saw those markers when you already were at or near that location.

with this mod, it's easy to see in which direction to go and then build the radar !!!

btw: by using a mod setting of 3 for the range (near area scan of 7x7 chunks) players will always have full coverage of the factory (as you already said), but it's also very easy to increase that to up to 14 to sooner or rather later (after 440 minutes) have completely charted all chunks in the far range of 29x29 chunks around each radar. placing only four (protected, depending on biter settings) radars in the four diagonal directions and then let them do their work to uncover up to 29 chunks in each direction around your factory (area of 3364 chunks, almost 2x2 km² or 1.35 miles²) while you concentrate on working in the factory is very easy with this mod :-)

even with some effort, i could only find two small details to nitpick :-) very nice work !!!

-1- although the explanation on the info tab was excellent, it was a bit confusing how to adjust the offset for the origin since in the third picture you say "step 2. take the current values", pointing to the values at the cursor. but those values are always positive and sometimes have to be inverted before taking "the opposite". it would be much easier to point users to your info window (at the top left of the same picture) which already tells the correct values eg "Radar ...+2, ...-2" without any need to adjust/invert the values and then take the opposite for entering them in the mod options.

-2- usually I'm running around with a blueprint to put down protected radar stations (with walls, lasers, solar+accu for their own power supply, etc, and of course with a radar :-) but it probably is too complicated to check a blueprint held in the cursor for radars, and most of all this is rarely needed and switching between a radar and the blueprint is not complicated at all ...

I'm already eagerly waiting for my research of the "Scanning Radar" to finish which allows a far range of several hundred chunks (for insane energy costs), but with the help of this mod it should be possible to place several (maybe 9) of them in a grid (maybe every 15 or 20 chunks) for better scan times and full coverage at much lower energy costs.

I am glad you like this mod and found this helpful. And I really appreciate your experience in-depth.

-1- Thanks for pointing out how to make the steps clearer! The picture/screenshot is updated accordingly.

-2- Scanning the blueprint is complicated, though possible. But if the blueprint contains multiple radars, then it would be even more complicated (or impossible) to determine which radar in blueprint should be used. So I guess it's better to just skip this feature... In your case, I think it's easier for you to hold radar in hand and find the sweet spot first, then turn on grid to see which chunk it is in, then switch to blueprint where radar would be placed inside that chunk.

Always nice to know more radar mods. May I ask which one you are using?

-2- yes, it would be too complicated, and switching between blueprint and radar is easy enough.

about all those different radar mods: in the course of time, i have used many radar mods and each had some nice features and some disadvantages.
most useful and logical at first sight are radars that increase their range by research. but the better radars now would overlap and require placing all radars again ... too much work for me.
another mod has three different radars with different properties for near and far range, etc, but I am too lazy to think how to use it best, and different radars on the same map also cause problems with different grid placement.
and then there probably is some space radar, but i have no idea how that works, and it would be unusable for a large part of the game until i can send rockets.

my solution: at first use a few vanilla radars, and also use vanilla radars later for full coverage of the factory and outposts. when "Scanning Radar" is researched, i use that one for exploration since it can be individually configured with signals. that radar is like a rotating beam using polar coordinates, with settable angle1 to angle2, range from radius1 to radius2 (thus it's even possible to scan a small but very long path, eg 200 chunks to the east, but only in an angle of +-5 degrees), selectable scan speed, and since it is configured with signals, it even can be automatically adjusted, eg extending range to scan in a spiral over time, or reducing scan speed when i get power problems ...
but beware of using several hundred GW to scan a full circle of radius 120 chunks in a very short time, and then be stuck with 5 FPS/UPS because of the amount of revealed map :-) LOL

Right, I also love the Scanning Radar a lot, give a more realistic (and military) sense. Although the vanilla type radars made it easier to manage the base in game-play sense.

fun fact :
when i had scanned a rather large circle of radius 120 and started sending artillery on automatic mode (having cheated artillery range to maybe level 50+ which would normally cost several trillions of science :-), i noticed that the vanilla game does NOT send artillery to all the nests from nearest to farthest using real distance (polar coordinates), but it destroys nests from nearest to farthest using some kind of manhatten distance, resulting in first a square being targeted (similar to how vanilla radar works), and then in the end extending that to the full scanned circle (probably still targetting in a square but skipping the tiles outside the circle)

Nice find.
I did not investigate myself. But I did realize the artillery fire do sweeping like a polar angle scan for a thin layer of radius, like peeling onion but from inside to outside. (Though this is a "low" artillery range lv behaviour.)
I would analyze this in the programming sense. Perhaps the developers have a quick scan first based on the location of chunks, chunk by chunk, which looks to be square-like scanning (like based on Manhattan distance). Then look into the chunk for any available targets. If found, then calculate the "real" distance (mathematically called Euclidean distance) to see if it is in range and mark it for fire. If not found or all out of range, then that chunk will be marked as "cleared" temporarily, and continue with another chunk.
This is needed when there are lots of entities in such large area (artillery range lv 50+ :D ), since storing Euclidean distance of EACH entities would be very memory-consuming, so such calculations have to be done as late as possible. (Each Euclidean distance calculation consists of two multiplication and a square-root operation, which is quite costly in CPU power.) In comparison, chunk Manhattan distance is much easier to handle. I guess in-game code have something like double for loop or while loop, where only addition/subtraction is needed (which is very fast). So for such very large area, double for loop is used in place of costly Euclidean distances.
This is also a good reason why developers set artillery wagons can fire only when stationary. Because the position should be fixed to start such chunk-by-chunk scanning and to make the stored Euclidean distances meaningful. Any movement will break the scan and rendered the data useless, having to restart whole scanning process.

yes, just the same as vanilla radar.
and after placing new artillery, it seems to take forever until it starts shooting, but that's due to starting the scan again at near distance and taking a while to get to the "non-cleared" area again.

this is also the reason why i probably will set up radar and artillery in pairs with only "low" to medium radius (maybe 8 to max 20 chunks), barely exploiting the huge max range of the Scanning Radar for killing biters. and thus we are back at this mod which immensely will help finding the proper grid locations for those pairs. Without this mod, it would be quite difficult to find the exact chunks which have a distance of 10, 15 or 20 chunks to each other.

ps1: calculations can be improved a bit, eg comparing x² + y² with r² instead of comparing sqrt(x² + y²) with r (doing a third multiplication instead of the root) but no matter how much it is improved it will still be a lot more work than simple addition for manhatten distance. less pretty but more effective might be to approximate the circles with a square (manhatten), some kind of hex-shapes (6 circles fit nicely around one center circle when trying to cover an entire area), or maybe 8 edges with easy ratios like 2:1, 1:2, -2:1, 2:-1, etc.
but after all, radars are good enough as they are, and for huge areas, ION cannons can be used instead of artillery :-) the main limiting factor for really huge areas will be the huge amount of storage for so many chunks and the related low FPS/UPS ...

ps2: if you are really bored and want a little challenge, you could add a new mod option whether to calculate the chunk positions of the radars in a square grid (best for use with vanilla radars or most other radar mods) or in a hex grid (might be interesting for use with radar mods that scan in circles like the Scanning Radar). but that probably would be more fun "by itself" (to see what is possible, or how to do it) rather than being really needed.

I am busy with developing some new mods recently, like tank auto-cutting woods on driving, alien artifact loot, and post-rocket weaponry like tanks MK3 stuff, so actually enough challenges for myself. ;-)
But I will put your request of hex grid option on list, and update the mod when I see fit.
In principle it is not difficult. Say the scanning radar covers a circle. For all the circles to cover all chunks completely, it is the most efficient to have 3 circles together with their radii forming an equilateral triangle (thus complete tiling looks like a hex grid).
Let me use the wiki entry picture for illustration (https://en.wikipedia.org/wiki/Equilateral_triangle, second picture).
The 3 centres (A, B, C) from the centroid is exactly the scanning radius (assume 10 chunks here). The optimal placement radius is half of a side of triangle r_p = a/2 = b/2 = c/2. So we have cos 30° = r_p / 10. Thus r_p = 8.66.
So it is equivalent to putting 8 or 9 into the options menu radius, and need to offset in alternate rows/columns since it's a hex grid. Whether I should round down (8) or round up (9) or round at non-0.5 decimal, I have to do some real testings. But 8 will be a sure-safe full coverage in this case.

slightly different approach, but almost same result :

using the same second picture from that wiki page, let's assume having a radar at A with radius b=c (and =a). if you place the next radars at B and C, they would overlap by more than 100%, and if you double the distance the radars would no longer overlap at all. but as easily can be seen from the construction of a hexagon, the two circles that are located at A and at a point to the top right of B and C (at a distance of twice the height: 2 x h = sqrt(3) x a , and in the direction of h(a) ) will intersect at B and C. the same applies to each of the six points around A (rotated around A by 60 degrees). thus with a scanning radius of eg 10 the distance between radars should be sqrt(3) x 10 = 17.32

with A at 0,0 the coordinates of those "nearest six radars" would be ±1.5a,±h and 0,±2h (or ±h,±1.5a and ±2h,0). with the example radius of 10, the coordinates would be ±15,±8.66 and 0,±17.32 (or ±8.66,±15 and ±17.32,0).
to construct all those locations, the spacing in one dimension has to be 3a (30 in the example) and the radar in the next row/column has to have an offset of 1.5a (example 15) in the same dimension and h (example 8.66) in the other dimension (above and below that row of radars, or left and right of that column of radars)

end of theory :-) end of using float :-( needing to round integer now :-(

changing (rounding) this distance causes the circles to no longer intersect in those 6 points, and making the distance larger would cause the circles to not even completely overlap any longer. maybe this can not be seen for many small radii, but sooner or later for larger radii there would be unscanned gaps. thus all rounding has to be "down", in the example from 8.66 to 8 (and also from 17.32=2x8.66 to 2x8=16), and thus coordinates of the radars are
m x 3a , n x h (example m x 30 , n x 8) for even rows and
1.5 + m x 3a , n x h (example 15 + m x 30 , n x 8) for odd rows
or x and y switched when taking the other dimension as main direction. in theory there could be even more "main directions" besides horizontal and vertical (total of 6 directions every 30 degrees) but having parameters for all of them would be a bit excessive :-)

as a result, scanning circles will fit perfectly in one dimension and only optimally in the other dimension (overlapping a bit too much).

Nice, we should have the same result (8.66, or double as 17.32), since we are both using equilateral triangle. Otherwise, one of us must have been wrong.
The reason of using radius (8.66) instead of distance (17.32): is about how radar interacts with chunks in Factorio (up to version 0.16.51), because the coverage area must be symmetric. There would be less confusion to consider only one radar (use radius) to do the following calculations, like using the coverage area as "clone brush" and "paste" them as other radars. Details as follows:
Considering A at {0,0} as the starting radar, other radar sites along x-axis are {±(2r+1),0}, {±2(2r+1),0}..., {±n(2r+1),0}, where n is an integer. I set d=2r+1 as the chunk distance. r must to be an integer for how Factorio works with chunks, so d must be an odd number. (Like vanilla radar has chunk radius r=3, d=7, giving {±7,0}, {±14,0}, etc.) Similar to what you said about "rounding down" 17.32 to 16 in the last step, considering the radius only right from the beginning makes the description less confusing.

Of course I know it is safer to do overlapping. But the reason of whether I should round down (8) or round up (9) or round at non-0.5 decimal, is because I haven't looked into how the code in Scanning radar mod is working exactly. If it does an "aggressive" round-up (or called ceiling) then I MAY be safe to use 9 as chunk radius in my code. But 8 is a "sure-safe", considering maybe some future radar mods doing similar thing but using different code.

I guess most (if not all) users who dare to come to this mod have OCD. ;-) Grid axis using any angle other than horizontal or vertical are "heretic", so they (we) won't accept it anyway.
PS: OK, you can be not an OCD-player and want those weird angles. But on the programming side, it makes the code more complicated, and I cannot guarantee they still give full radar coverage. So I will skip that.

Just released 0.16.3 to support such circular coverage area of scanning radars.
The grids are close to, but not exactly, regular hexagonal. Therefore, I call it quasi-regular hexagonal grid instead.
The actual implementation is more complicated than more I expected or written as above. It is because I have to handle the rounding of numbers.
The chunk pattern is equivalent to an addition 0.5 in radius (e.g., signal "R" = 10 or 10 chunks gives 10.5 inside calculations. Then I can use the formula to determine the "centroid" approximate position, but need further empirical comparison to determine the "optimal centroid", to give least overlapping. The optimal centroid is usually neither the floor nor ceiling nor rounding from formula, therefore not from a single analytic formula. The optimal centroid is then used to determine the dimensions of the hexagonal grid.
For the hexagonal grid, I am using the so-called "offset coordinates" system, the "odd-r" horizontal layout. There are some online resources so I am not typing here. However, it is not "regular hexagon" as it is a bit asymmetric due to the chunk considerations. Therefore I have some a bit complicated formula and case-by-case calculations, if you look into my code.
Anyway, it gives the "optimal" placement in the sense of least overlapping yet full coverage.

tested and it works pretty nicely. THANK YOU!

the reason of whether I should round down (8) or round up (9) or round at non-0.5 decimal, is because I haven't looked into how the code in Scanning radar mod is working exactly

as far as i have seen, the method to calculate the inner and outer borders was already changed once, and afaik, it uses trigonometric functions now. from testing i have seen that (depending on radius and speed which in turn determines the delta-angle for each scan-beam) currently two consecutives rotations of that radar don't scan the same sectors at those borders. thus you are right to "better be safe than sorry" and round values to guarantee full coverage with some overlapping.

Thanks for sharing your experience.
I have only tested some radius, but not the whole range. (Maximum range is 500 chunks from what I read from code, right?) It seems impossible for me to test everything. (It would be very time-consuming, and yes, I am lazy to do that...)

for the effect of "scanning radar" not always scanning the same chunks at the border, i used F=10, N=5 and S=5.
that combination seems to not end up at exactly 360 degrees per rotation and thus on the next rotation all chunks have become darker already and some stay dark (are not scanned) while others which were black (not scanned on the first rotation) light up.

btw: for testing the overlap at max range, you would need to travel 800 or 1000 chunks, around 25-30 kilometers, which (with a fast train, ignoring the time to lay down tracks) would take maybe 10 minutes :-) and with so many chunks revealed, it would even take longer with the resulting low UPS :-)

Hmm, I used F=10, S=5 to explore uncharted border but did not see any missed chunks. (Or do you mean they are not always scanning some rim chunks? Yes, I knew that. But they will eventually be scanned after some passes, so still count as full coverage.)
BTW, it is difficult to observe whether it's full coverage with S=5 or lower, so I did full speed S=10 for testing to confirm full coverage.

Oh, wow! I won't do such kind of extensive tests. I would rather spend my time to develop new mods. Better leave this in the hands of "hardcore" builders, and let them tell me their experimental results. :D

do you mean they are not always scanning some rim chunks?

yes, and although those chunks are scanned sooner or later, I don't call this "full coverage" since on slow/medium speed with large radius it can take quite a while (at least two or more rotations) to update those chunks. thus i prefer guaranteed overlap in favor of minimal overlap ... "better safe than sorry"

about the long travel tests: i once played on a map with a large lake and started building a rail track around it. but the lake was bigger than expected and when i finished the route i had travel times of 10+ minutes around it at max speed :-) i even needed to transport some fuel to a refueling station halfway around the lake to refuel other trains there. LOL
thus i don't do such tests on purpose, but am aware of the effort it would take, do it only "in theory" (by doing calculations or extrapolating previous experiences), and the hint in the above post was rather meant as "testing would be insane, almost nobody needs that, thus just have a guaranteed overlap to be on the safe side and forget it" :-)

Well, if having to go after this... By definition, "full coverage" should mean the whole area (no holes) can be view at any time (100% up time) from satellite view, like the GPS system. So scanning radars having slow speed do not have "real" full coverage anyway, even if more overlap.
Scanning radar, when not using very high speed, do not offer 100% up time to chunks, as it is the inherit property. (That's why it's called "scanning" radar, right?)
If players want real full coverage, they should use classic radars, or have scanning radars tuned up high speed or have multiple.

Or if you insist a different definition as "at least scanned once per scan cycle for each chunk", I think the easiest way is to set value of "Radar reveal radius" 1 chunk less on your side. By this way, I don't have to make two settings: one for slow mode and another for fast mode.

different definition as "at least scanned once per scan cycle for each chunk", I think the easiest way is to set value of "Radar reveal radius" 1 chunk less on your side.

yes, that was my definition since i like to have everything deterministic and not have random effects like needing 2 or maybe even more rotations to scan the whole scan area.
and your suggestion to set a slightly different scan radius is so simple that i just didn't think of it and was only thinking of how to improve calculations :-) :-( ... see "egg of Columbus" :-)
btw: if such hints ("may need 2+ rotations to scan the entire border" on the other mod, or "set radius to R-1 to guarantee full coverage on each rotation" on your mod) are included in the description or mod settings, I'm ready to buy any such (or even bigger) things as intended features instead of problems :-)