Factorio Forums

Mod-Info-Header

• Name: Scanning Radar
• Version: 0.2.8
• Factorio-Version: 0.16.x
• Description: A radar that actually scans in a sweeping arc. Massive power requirements.
• License: MIT
• Release: 2018-05-13
• Download-Url: Download
• Website: viewtopic.php?f=93&t=58659
• Category: Defense

A radar that actually scans in a sweeping arc. Massive power requirements that scale with area scanned and speed.

Default settings to scan about the same area as the vanilla radar.
Connect signals to modify the behavior.
The initial scan can be slow quite slow as the game generates map data.
Scanning too much map area can bloat your game. See my other mod DeleteEmptyChunks if you need to slim it back down.
375,000 chunks takes about 9GB of memory which is 3/4 of a full scan with a radius of 400 chunks

Known issue: not blueprint compatible... yet

Remote monitoring of an outpost

Very nifty, but a number of comments:

For reasons of UPS, I'd probably prefer the more CPU-efficient algorithm; then again, trig functions are I think single-cycle on modern processors, but branch instructions can take significant numbers of cycles to resolve, so I'm uncertain which would actually be more efficient.

I've noticed that the current algorithm seems to have a certain amount of jitter; over multiple rotations it seems to only sometimes chart certain chunks that are on the edge of the scan radius.

It also seems to skip charting chunks at (I suspect) around 0 degrees; specifically, to the right of the radar, but only sometimes.

I attempted to move the radar, but when mined, it does not return the original object.

If the circular algorithm is really the major performance draw (is it?) you could always try memoizing the result. Table lookup are very fast and that would also avoid the mentioned problems with inconsistent scanning of sectors on the outer edge.

PS: Thanks for clockwise mode btw :P

mrudat wrote:Very nifty, but a number of comments:

For reasons of UPS, I'd probably prefer the more CPU-efficient algorithm; then again, trig functions are I think single-cycle on modern processors, but branch instructions can take significant numbers of cycles to resolve, so I'm uncertain which would actually be more efficient.

I've noticed that the current algorithm seems to have a certain amount of jitter; over multiple rotations it seems to only sometimes chart certain chunks that are on the edge of the scan radius.

It also seems to skip charting chunks at (I suspect) around 0 degrees; specifically, to the right of the radar, but only sometimes.

I attempted to move the radar, but when mined, it does not return the original object.

There are many reasons I switched to a trig based calculation method. The most flippant one being the advances in modern CPUs. The Bresenham's circle rasterization algorithm is an optimization for integer math which draws a complete circle. But I had to be able to step the outside and scan between that and the center. This would leave a radially symmetrical pattern of holes within the plot. This required adding a fudge factor to get a complete fill. This is when I discovered the LUA does not actually have an integer type, everything is floating point calculations anyway. Accounting for that and allowing for more flexible rotation speed, dynamic direction, oscillating between two angle, etc. I chose to simplify the algorithm.

The jitter you are seeing on the outside edge is because the outside edge is a calculation of a radius from the center. Because of fractional stepping to get a complete fill, sometimes the next point will be on the inside corner of a chunk on one pass and an outside corner of an adjacent chunk on the next. The smallest unit to scan is a full chunk and I had planned to leave this as is rather than require a fixed stepping or storing a lot more state data.

Skipping chunks around zero degrees is something that I am afraid that I completely missed. The map that most of the testing was done has a railroad line extending east past 13500 with some existing vanilla radar coverage. I will take a look at that when I get home from a business trip at the end of the week.

Hand mining the radar should work correctly and always has for me in testing. Deconstruction with bots and adding to blueprints is not yet implemented and is where the next planned effort was to be directed.

eradicator wrote:If the circular algorithm is really the major performance draw (is it?) you could always try memoizing the result. Table lookup are very fast and that would also avoid the mentioned problems with inconsistent scanning of sectors on the outer edge.

PS: Thanks for clockwise mode btw

Most of the time is actually either from the game engine generating or refreshing the map data in the LuaForce.chart method. commenting out that line gets the in script time down to under 0.1 and usually less than 0.05

And you're quite welcome. I hadn't done any programming in nearly a decade and getting into modding this game has given me a chance to dust off an old skill set and work at picking up the language.

I can't seem to get this to work on version 0.16.41. With these settings, or any other of many combinations I tried, I get no scanning. The power usage does increase significantly with radius. Any idea what I'm doing wrong?

Adamo wrote:I can't seem to get this to work on version 0.16.41. With these settings, or any other of many combinations I tried, I get no scanning. The power usage does increase significantly with radius. Any idea what I'm doing wrong?

The radar will operate with default settings until a circuit network connection is made. When connected, it disables scanning until an enable condition to the radar is satisfied. Click on the radar itself to set its enable condition. I usually set it to 'S' > 0.

Scanning with limits will scan from wherever it is until it reaches the outside limit then either oscillate or wrap around depending on settings.

Make sure you have enough power for it to run. With the settings you have in the screenshot, the radar will require about 128MW.
Side note: When scanning a small area, use a lower speed to minimize power usage while maintaining full visibility. In your screenshot the speed could be set to 4, reducing power usage to about 53MW.

Version 0.2.8 has just been uploaded with various bugfixes. Please retest with this version.

mrudat wrote:skip charting chunks at (I suspect) around 0 degrees

This has been corrected in version 0.2.8

Hi, I'm having a problem with this mod
can you help me?

tank you

Apolyon wrote:having a problem

Ya, I had fixed this in the source repository a couple weeks ago but had not yet uploaded a new release.
I'll try to do so this evening

I put a PR up on your Github to update this for 0.17.

0.17.21 BUG - does not work in a world with limited height, please fix

burninghey wrote: ↑

Wed Mar 27, 2019 9:57 am

0.17.21 BUG - does not work in a world with limited height, please fix

Bugfix committed to source, release coming shortly

Bug: in Factorio 0.17.36, scanning radar is drawn with a glitch. On certain zoom levels only, the radar dish gets stuck pointing south (down). Doesn't happen to vanilla radars. The upper radar is vanilla, the lower one is (glitching) scanning.

scanning radar is drawn with a glitch

Yup, has always been this way. Because of the way one has to abuse entities to create your own in Factorio there can be some difficult to mitigate issues. The reason the happens is because multiple entities are stacked to produce the combined features of an animated radar and still have a mouse-over icon for the modified entity to which one can attach signals. Works most of the time.