[1.1.35] Massively scaled building mini-views cause huge performance hit.

[Kingdud]

Technically a modded problem, but given that I'm (more or less) only using the scale property on an existing factorio entity, this problem is actually inherent to Factorio itself. Whether you choose to fix it or not *shrug*, but I want you to be aware at least.

I have a number of mods that aim to make late-game megabasing possible (> 10k SPM) without UPS hits. All of them show this behavior, but I limited this bug report to one of the simplest mods (Smelter UPSGrade) purely to rule out as many variables as possible. At a fundamental level, all I'm doing is deep-copying the existing electric-furnance prototype, setting the scale property and collision/drawing/bounding boxes to (much, ~3000) higher values, and going from there. If the mod setting is not saved when you load the attached savegame, startup->smelter ratio = 600 to really see a great example of this problem (lower values will cause it, like 250, but to a much lesser degree). Control.lua and all on-tick/event based actions are NOT used by this mod. It's purely a data.raw modification @ startup mod.

The problem seems to be in the live-previews that appear on both the mouse-over (just below the minimap) and crafting screens (IE: when you click on the building and it opens up a window). In both cases, performance tanks. I suspect what is happening is that Factorio is rendering the entire building at its hilariously massive size rather than scaling the building down to something sane first, then rendering it second. Such a step isn't needed in vanilla, but it is helpful for my mods, at least.

First, let's prove that it's not a multi-mod conflict. Screenshot pair 1 shows all the mods I normally play with and the FPS drop from 60 to 32 just by moving my mouse over the building, causing the minimap preview to display.

no-issue.png (3.4 MiB) Viewed 3685 times

And now, when I move my mouse over, the problem.

issue.png (3.25 MiB) Viewed 3685 times

Now, let's disable all but one mod (Smelter UPSGrade) and see what happens. Before:

onemod-noissue.png (3.3 MiB) Viewed 3685 times

and now when I mouse over:

onemod-issue.png (3.21 MiB) Viewed 3685 times

(I did wait the required time for the whole-map rechart to finish after disabling so many mods).

Here is a test map (it has just the one building, no power, and an infinity chest for you). The problem will occur whether the building is active or idle, whether the building is powered or not. I think it's 100% a render scale issue in the below-minimap and entity-interaction screens.

[Rseding91]

Thanks for the report. I looked at it and the performance hit comes from trying to render what electric poles are powering that entity. The way that logic works is: take the bounding box of the entity + the max distance any electric pole can reach and then do an entity-search in that area to see if any electric poles are found. Because the entity is *huge* it means it ends up doing a *huge* search every frame to see what poles might overlap the entity.

I don't know if we want to try to find a smarter way to do that logic or if we just say "that's just how it is with huge entities". There are other things that do similar searches (for example inserter interaction previews).

My thoughts are: *huge* entities shouldn't be a thing. All of the game logic is built around entities around a maximum of 5x5 and any bigger and it starts causing issues. We so far haven't artificially limited entity sizes but we might do that one day.

[Kingdud]

lol. As far as causes go that's pretty funny. For what it's worth, the reason for the buildings being so massive is:

1. Optional (all the mods have a setting to constrain building size)
2. So that you can have a megabase which takes up the same space (and thus face all the problems) as a 'real' (vanilla) megabase would.

Is there anything else I can do on my end to fix performance? And why would it search for electric interactions only on mouse-over/interaction?

[eradicator]

We so far haven't artificially limited entity sizes but we might do that one day.

Um...please,...no?! Even vanilla has the - by your definition - "huge" rocket silo. Because entity sizes add variation to both visuals and gameplay. If you don't actively want to support them - fine, everyone understands. But please don't ruin the creativity of a great many mods by imposing more artificial limitations.

[Rseding91]

Is there anything else I can do on my end to fix performance? And why would it search for electric interactions only on mouse-over/interaction?

To render what electric poles are powering the entity.

[Rseding91]

We so far haven't artificially limited entity sizes but we might do that one day.

Um...please,...no?! Even vanilla has the - by your definition - "huge" rocket silo. Because entity sizes add variation to both visuals and gameplay. If you don't actively want to support them - fine, everyone understands. But please don't ruin the creativity of a great many mods by imposing more artificial limitations.

The ideal way to do any "large" entity is to do multiple smaller entities. That way any logic which interacts with "things around it" doesn't have to try to account for searching potentially several chunks when in 99%+ of the cases it will never find an entity in that area interacting with it.

[Kingdud]

Ohhh, so when you say 'render' you mean that yellow box around the corners of the entity + the yellow outline around the power poles! Ok. That makes sense. Would making these entities void powered resolve that problem? Every other solution I have in mind requires scripting to make it work (like dropping 1-width electric grid interfaces inside the entity) to soak up power that way. Eh...I'm not a fan of this solution. :/ If I could just build a cache of where the power pole was I could say "look here, and only if it's gone, do the full rescan". You're probably not going to change where this thing is powered from very often, given its size.

[atomizer]

I'm not a modder, but it seems clear to me that there are two totally different things you want from it - (1) actually doing the entity's work and (2) restricting building in an area. Is it really that hard to do these separately and link them to each other?

[ptx0]

The ideal way to do any "large" entity is to do multiple smaller entities. That way any logic which interacts with "things around it" doesn't have to try to account for searching potentially several chunks when in 99%+ of the cases it will never find an entity in that area interacting with it.

what if we could just set the electric search area to be that of a smaller entity and offset it?

[Kingdud]

what if we could just set the electric search area to be that of a smaller entity and offset it?

That really wouldn't work. In order to do that you'd need to basically...imagine a smelter with a yellow box in one corner and if you didn't provide power to *that one specific corner* the building wouldn't work. That's lame considering every other building works if power touches it anywhere. And not every building type can be rotated. The base-game determines what building prototypes can be rotated at all, so you may not be able to move where that power spot is. You could cheat and make a 1x<length> entity that ran along the perimeter of the building (4 of them, 1 for each side) but then you have to check 4 different entities X # of buildings every tick to determine if you should operate the building or not. That's a crap solution performance wise.

I'm not a modder, but it seems clear to me that there are two totally different things you want from it - (1) actually doing the entity's work and (2) restricting building in an area. Is it really that hard to do these separately and link them to each other?

In order to get items in/out of the entity, you have to have the entity be on the 'edge' of the bounding box. Er...ok, imagine you have a 3x3 smelter (that's how big a normal smelter is). If you shrank the smelter down to be 1x1, but then added a secondary item on top of it (entities can be stacked on top of each other). The problem is you wouldn't be able to insert any ore into the smelter, because the inserter only has a 1-unit reach, and if that doesn't overlap with the 1x1 smelter inside, then it won't ...*idea; see a bit below*

On entity stacking: The mod: https://mods.factorio.com/mod/FurnaceMiningDrill just has a script that drops the furnace down on top of the electric drill prototype when you place said drill. This is not something you can do normally, but mods can do it. That's how some of Dell's other mods, and turret-shields/teleporter mods all work is with entity stacking.

*idea* Something that might work is to make the entity small, have a larger, non-powered entity stacked on top to act as the exclusion zone (might need to reverse this, but whatever) and then also drop power poles invisibly inside the exclusion zone. So, basically, cheat, and route the power to the small entity inside without letting the player know or worry about the fact that is what you are doing. That...could actually work. It's a PITA to code, but it could work. At the rate I feel like developing my mods, it may be a year before I sit down and code something to do that. :/ But it's an interesting idea.

The downside to this approach is that the mouse-over data and animations will be all wrong. You won't see the power consumption or building status on mouseover. You'd see the info for the 'exclusion zone' entity instead. And, no, you can't keep the two in sync.

[eradicator]

The ideal way to do any "large" entity is to do multiple smaller entities.

Last time I checked you seemed strongly opposed to mods using compound entites - let alone adding official support for them to the engine. So, I'm not sure if you're just making a very crude joke?

But let's see if @OP's mod could just use a small entity that still acts like a large one...
___
Energy: Can reasonable be assumed to be recieved on the edges of a building. But there is no api to forcefully connect an entiy to a network that it is not overlapping with.

Option 1: Cover the edges with hidden accumulators, and connected with hidden power poles. Conclusion: Adds a bunch of entities and one power network per entity.

Option 2: Listen to every construction/removal of power poles, try to figure out if they should power the small entity in the middle of the "virtual entity"'s bounding box, then build a single invisible power pole per outside network at the entity's position and connect that to the outside pole with an invisible wire. Doesn't add extra networks but is a huge bunch of messy scripting that would likely be incompatible with a bunch of mods that do power-pole shennigans themselfs. And hacking around the 5-connection-limit of power poles is a swamp I wouldn't want to be in myself. Conclusion: Too complicated.
___
Inventory: In/Output from inserters can happen on any one tile of the area covered by the virtual entity. Inserting into assemblers has lots of special logic (sleeping, input overload, output blocking, etcpp) so the assembler<->inserter connection must be kept. Theoretically this might be possibly by detecting inserter placement and changing dropoff/pickup target. Practically there are no events for inserter vector changes, and no reliable events for inserter rotation or even construction (i.e. mods with hidden inserters like miniloader). And custom vectors mean that relevant inserters could be anywhere on the entire surface. Conclusion: Impossible without adding lots of restrictions and mod incompatibilities.
___
Misc: As @OP mentioned above this is also going to mess up the tooltip and require extra scripting just to allow the player to even open the entity. And then you either have a bogus selection box highlight or you add yet another entity just for that. And finally the whole mess also has to work with blueprints, item request proxies, settings copy/paste and preferrably mods that teleport entities (i.e. picker extended).


Given that the entire point of @OP's mod is to have fewer entites to save UPS, and given that the mod already works except for and edge case with low FPS, I'm not sure what point you're trying to make.

To me the "ideal" solution is to give modders better tools to work with engine limitations instead of imposing more limitations and recommending horrible hacks. In this case a prototype flag to not render the entity preview seems sufficient to solve both the tooltip and the gui opened FPS problems.

[eradicator]

In the meantime... if you're willing to sacrifice the mouse-over tooltip you could put a fake entity above the real one (to steal the selection box) and manage gui opening in script. It's an ugly half-assed hotfix, but at least you can walk around those entites with being scared of accidentially "touching" them?

[Kingdud]

To me the "ideal" solution is to give modders better tools to work with engine limitations instead of imposing more limitations and recommending horrible hacks. In this case a prototype flag to not render the entity preview seems sufficient to solve both the tooltip and the gui opened FPS problems.

I like this idea. As to your idea for putting a transparent blocking entity over the top...maybe. I was going to stack a custom radar inside the building too and if I'm already dropping a radar inside that's sized to reveal the entire building, it's no thing to also make that same radar block interaction. I've never scripted a window interaction before, so that would be new. I can't say fun, but new, yes.

[Klonan]

For now, we are probably not going to look into fixing this