[modded] Massive RAM spike on placing stone path

[Illiander42]

Mods installed that are possibly relevant: Dectorio, RampantAI (with the option that increases RAM usage turned on), full AngelBobMadclownSpaceEX, AAI Vehicles, Coverup, Clean Concrete.

Game running happily, if a little RAM-hungry. Then I go to place a stone path under my bus, so I can walk faster, and suddenly the game freezes. I pull up my process monitor on my other screen, and see that factorio's RAM usage is slowly and steadily increasing. It was at 16GB, plus probably about 4GB of the swap partition when I killed it.

Mods Folder: https://drive.google.com/open?id=1g2ATC ... 2Z5-YM2WCL

---

Edit: OS = Gentoo Linux

[Loewchen]

Is this reproducible?

[Illiander42]

Two for two so far, plus a previous crash that was probably (but not certainly) this plus running out of RAM.

Just load the save and try placing some stone path.

Any other info that would help?

[Illiander42]

And here's a minimal save that has the same problem.

Stone Brick in inventory.

[Jap2.0]

I can confirm (Win7, 16.51). I'm going to try to narrow down the mods to see what's causing it.

[Illiander42]

Just tried blueprints, and getting nanobots to place the tile.

Blueprints go down fine.

Activating nanobots in range of a stone path blueprint gives the following trace:

Error while running event Nanobots::on_tick (ID 0)
Error while running event Coverup::on_player_built_tile (ID 45)
__Coverup__/control.lua:5: bad argument #2 to '__index' (string expected, got nil)
stack traceback:
__Nanobots__/control.lua:415: in function '?'
__Nanobots__/scripts/hash_queue.lua:80: in function 'execute'
__Nanobots__/control.lua:609: in function 'handler'
__Nanobots__/stdlib/event/event.lua:348: in function <__Nanobots__/stdlib/event/event.lua:293>

[Jap2.0]

Confirmed with a lesser set of mods; I'll continue checking this and then we can look at the mod.

[Rseding91]

The freezing is coming from code in LandfilPainting making bad assumptions about next_direction on tiles.

There may also be other mods conflicting causing this specific issue.

Specifically: LandfillPainting expects that for any given tile; tile.next_direction.next_direction.... eventually leads back to "tile" and in your collection of mods it doesn't.

I don't know if it doesn't because it was made that way or because of a mod conflict.

[Illiander42]

Specifically: LandfillPainting expects that for any given tile; tile.next_direction.next_direction.... eventually leads back to "tile" and in your collection of mods it doesn't.

Is that meant to be true, and another mod broke it, or does it just happen to be true a lot?

[Rseding91]

Specifically: LandfillPainting expects that for any given tile; tile.next_direction.next_direction.... eventually leads back to "tile" and in your collection of mods it doesn't.

Is that meant to be true, and another mod broke it, or does it just happen to be true a lot?

That I don't know. I just know the assumption is wrong because it's not enforced anywhere.

[Jap2.0]

It works fine with only landfill painting.
Adding dectorio gives the following error:

Error while running event LandfillPainting::on_player_built_tile (ID 45)
__LandfillPainting__/control.lua:13:attempt to index field 'next_direction' (a nil value)

It proceeds to go to the menu. I've contacted the mod author to see what he can do about it. I'll also look at what is causing the freeze and various other things.

[Jap2.0]

Okay, I believe I may have stumbled across two separate issues (presumably mod errors/compatibility issues, although I don't know if memory leaks and crashes are something mods are supposed to be able to do). With only Landfill Painting (and most mods), everything works fine. With Bot Landfill, you get the memory leak and crash. With Dectorio, you get an error and crash to menu. Saves to reproduce both of those (for mod authors or whoever wants to look at those) are attached.

Tl;dr: don't use Dectorio or Bot Landfill and you'll be fine.

[Trainwreck]

LandfillPainting 0.2.3 uses the factorio supplied items_to_place_this table instead of trying to built it's own copy. This should be more a more robust way of handling it.