Cache radar "near" visibility, instead of scan

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

Post Reply
Lennartos
Inserter
Inserter
Posts: 24
Joined: Mon Jun 27, 2016 10:13 pm
Contact:

Cache radar "near" visibility, instead of scan

Post by Lennartos »

TL;DR
Remove the performance hit for radar "near" visibility.

What ?
Right now radars repeatedly "scan" nearby chunks, which has a notable performance impact once your area of visibility grows, especially since radars can overlap a lot if you dont manually place them.
So instead of the nearby scan routine, just mark each chunk as visible permanently as soon as a radar has been placed within its range and has power with a reference on each chunk to what radars cover this chunk.
If a radar has been destroyed the entry is removed and the chunk will dissapear unless there are other radars in that list.
If a radar lacks power, it doesnt reveal anything or you can scan its sectors with a cooldown similar to now, and once power has been restored mark it as permanent again.
Why ?
It removes the performance impact of having the map revealed.
This would also be very beneficial for allowing research that increases radar ranges (right now those cost a lot of performance ) or simply ignore the penality of overlapping radars (or entities with radar properties) without having to worry about the performance impact.

Koub
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by Koub »

Lennartos wrote:
Sat Aug 01, 2020 12:21 am
which has a notable performance impact
Lennartos wrote:
Sat Aug 01, 2020 12:21 am
(right now those cost a lot of performance )
You have a source for that ?
Koub - Please consider English is not my native language.

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by posila »

Koub wrote:
Sat Aug 01, 2020 5:27 am
You have a source for that ?
It is true (at least for 0.18/1.0 and all previous versions).

In addition to that, there is also rather large cost of redrawing the map pixels, which happens only on revealed chunks when something changes on them (entity that is supposed to draw on map is created/destroyed/moves) ... this doesn't happen often on factory chunks (as things that move inside the factory are not drawn on map normally), but happens a lot outside of factory as biters wander.

Lennartos
Inserter
Inserter
Posts: 24
Joined: Mon Jun 27, 2016 10:13 pm
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by Lennartos »

Koub wrote:
Sat Aug 01, 2020 5:27 am
You have a source for that ?
Its not the biggest drain compared to entity update if your base is small, but its definitely noticeable especially once you want to light up the entire safe zone to make the Blueprint from map system work.
If you start to get in the neighborhood of 1000 standard radars you will see that the radars start to eat into your UPS, and you definetly will start to notice the up to 12ms spikes on the tick when scan is done, if you install a mod that increases ranges then radar can easely eat up a few ms of your update time... since all the old radars will overlap a lot, slowing the game down without giving you any more visibility for the UPS cost.

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by mrvn »

Lennartos wrote:
Sat Aug 01, 2020 9:51 pm
Koub wrote:
Sat Aug 01, 2020 5:27 am
You have a source for that ?
Its not the biggest drain compared to entity update if your base is small, but its definitely noticeable especially once you want to light up the entire safe zone to make the Blueprint from map system work.
If you start to get in the neighborhood of 1000 standard radars you will see that the radars start to eat into your UPS, and you definetly will start to notice the up to 12ms spikes on the tick when scan is done, if you install a mod that increases ranges then radar can easely eat up a few ms of your update time... since all the old radars will overlap a lot, slowing the game down without giving you any more visibility for the UPS cost.
But is that the "near" visibility or the scan?

I would think it's because even a radar deep inside your base will check all the chunks in it's scan range to see which one has not been scanned the longest and then it notices that they are all "near" visible to some other radar.

Posila: Could you maybe tell us bit more details about what a radar inside the base does? Is there some optimization so it knows which chunks are permanently visible? Or does it have to check every scan cycle?

Lennartos
Inserter
Inserter
Posts: 24
Joined: Mon Jun 27, 2016 10:13 pm
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by Lennartos »

The spikes are caused by the scan, but it seems the "near visibility" is very similar to the scan, just fired more often and for every chunk within range.
As far as i know you can control the near scan chunk repeat frequency by changing the "energy_per_nearby_scan"

*edit:
from the wiki
"The amount of energy the radar has to consume for nearby scan to be performed. Performance warning: nearby scan causes recharting of many chunks, which is expensive operation. If you want to make a radar that updates map more in real time, you should keep its range low. If you are making radar with high range, you should set this value such that nearby scan is performed once a second or so. For example if you set energy_usage to 100kW, setting energy_per_nearby_scan to 100kJ will cause nearby scan happen once per second. This value doesn't have any effect on sector scanning."

So even here there is a performance warning

Rseding91
Factorio Staff
Factorio Staff
Posts: 13171
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by Rseding91 »

Sorry but this doesn't work; the radar may not have enough energy to do the scan at full speed; so just saying "the chunks always stay revealed" doesn't work.

At a fundamental level; what you want to do will always be costly - keeping all of some huge area revealed will always have some cost. The cost to scan the nearby chunks is already O(N): where N is the number of chunks the radar keeps revealed.
If you want to get ahold of me I'm almost always on Discord.

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by mrvn »

Rseding91 wrote:
Sat Aug 08, 2020 4:33 pm
Sorry but this doesn't work; the radar may not have enough energy to do the scan at full speed; so just saying "the chunks always stay revealed" doesn't work.

At a fundamental level; what you want to do will always be costly - keeping all of some huge area revealed will always have some cost. The cost to scan the nearby chunks is already O(N): where N is the number of chunks the radar keeps revealed.
Normal would be that the radar has power. So this could work like beacons. When the radar gets power it tags all the near chunks. When it looses power it removes the tag.

Yes, that will be costly when power changes. But that isn't normal. And does it cost any more than the scan now? It would be O(N) but only on change.

Lennartos
Inserter
Inserter
Posts: 24
Joined: Mon Jun 27, 2016 10:13 pm
Contact:

Re: Cache radar "near" visibility, instead of scan

Post by Lennartos »

mrvn wrote:
Sat Aug 08, 2020 8:13 pm
Rseding91 wrote:
Sat Aug 08, 2020 4:33 pm
Sorry but this doesn't work; the radar may not have enough energy to do the scan at full speed; so just saying "the chunks always stay revealed" doesn't work.

At a fundamental level; what you want to do will always be costly - keeping all of some huge area revealed will always have some cost. The cost to scan the nearby chunks is already O(N): where N is the number of chunks the radar keeps revealed.
Normal would be that the radar has power. So this could work like beacons. When the radar gets power it tags all the near chunks. When it looses power it removes the tag.

Yes, that will be costly when power changes. But that isn't normal. And does it cost any more than the scan now? It would be O(N) but only on change.
Thats pretty much in tune as what i was thinking.
Since there is a delay before the FOW returns, then the current system can be recreated in a multitude of similar ways, there is no issue at all from a technical perspective.
The only question here is when/how often to reset the FOW timer for the sector.

Now as for the power issue the question is what we want to model really:
Since we have no use for a scan timer we might want to remodel the timer into a % of power we had over the estimated scan time (or 1 sec as the recommended scan rate in the wiki) , then add a small hysteresis (10%) on that so we dont react to small variations.
If power is 90-100% then set the flags if missing and thats it.
in case we have < 100% power we could:
1) ignore the tag system altogether and just reset the FOW like now - meaning a small expense in performance to ilterate over current tags and remove if any.. and big gain in case power is up.
2) pick out n-random secors where the tag should be removed, based on power level and the scan range... which would mean it would look a lot more like the far scan, just in reverse... reduction in chunk ilterations in both powered and unpowered, but has a bit more math for unpowered so might end up neutral there.
3) reduce scan range based on power level - scaled to its range - this one would be the largest in terms of hysteresis steps and thus tags would be quite constant so there could be big reduction in both math and chunk ilterations.

KISS: There are many buildings that stop working if there isn't enough power to power them 100%, making radar one of them doesn't really sounds like a big issue.

As an absolute worst case solution:
Allow us to place bleuprints in FOW territory, maybe even remove the hidden terrain so only enemy is hidden.
viewtopic.php?f=6&t=87390

Post Reply

Return to “Ideas and Suggestions”