Cpeophoros's Mods

[cpeosphoros]

ATTENTION I don't plan to update those mods any time soon. They are realesed under MIT's license, so any one who wants to may take then over..

Thread to keep track of my published and planned mods.

Published:
-Mods
Busy Bots 0.14.4
Concreteer 0.14.4
Tree Cutter 0.14.3
Bot Recaller 0.14.1

-Tools
Milliseconds Time Profiler for Mods

Planned:
- configuration and reporting GUI for Busy bots
- landfill laying worker mod for Busy bots
- building upgrader worker mod for Busy bots
- module outfitter worker mod for Busy bots

Suggestions, Bug Reports, etc, are very welcome, either in this thread or by PM.

ATTENTION Busy Bots 0.14.4 breaks internal API compatibility. If you upgrade to it, you should also upgrade any worker module you are using to their latest version.

[katalex]

Busy bots 14.2 - spam continues.

[cpeosphoros]

Busy bots 14.2 - spam continues.

Which message? The same "Init - No Workers"?

[katalex]

Sorry, may be I don't understand principle of operation of your mod?

[cpeosphoros]

Sorry, may be I don't understand principle of operation of your mod?

That message is expected to happen once the first time you load a save with Busy Bots, and also once each time you update it.

That is the process of registering roboports and making sure it's not registering Factorissimo's buildings (the bunch of "small-factory"s in your print) or other type of "fake" roboports.

As per your print, you are getting that message each second, not once per mod update, so we have a bug. I'll let you know when I upgrade a fix.

[cpeosphoros]

Busy bots 14.2 - spam continues.

Solved. Please upgrade Busy Bots to 0.14.3 and any worker module to 0.14.2.

[Anson]

Busy bots 14.2 - spam continues.

Solved. Please upgrade Busy Bots to 0.14.3 and any worker module to 0.14.2.

running Busy bots 14.3 and worker modules 14.2 - spam continues.

and without Concreteer it even crashed

when i installed your three mods for the first time yesterday, i used the most current versions 14.3, 14.2 and 14.2.
my testworld where i added those mods already was paved with concrete all around a roboport. result: first a notification that "Busy Bots added roboporty xxx", followed by spamming me with coordinates every 2 seconds "Warning! Concreteering concrete for xxx at -40,-55" (next lines -40,-54, -39,-55, -39,-54, -41,-56, ....), apparently one message per tile, and sound for each one.

then i removed the roboport and built a new one in the wilderness. first i got messages about "Low count of concrete" several times. then it finally started paving the area, but always 2 seconds of normal gameplay, then 10 seconds frozen, 2 seconds normal, 10 seconds frozen. and after a while, the messages about low concrete were back (i don't want to be notified that i can't produce 800+ concrete every 2 seconds, or including lag every 12 seconds).
finally the whole area was paved, thus robots didn't work, but i still got the messages about "low concrete" until i had 1000 concrete filled in a storage chest. at that time, the messages "Warning! concreteering concrete" came back and continue, together with the huge lag.
unplayable like that.

then i restarted the map after disabling concreteer, had no roboports, and walked around. every two seconds the game froze for a fraction of a second. very ugly.

and as last test, i went to the wilderness again and placed a roboport. as result all trees in the area are marked for removal, and the game crashed with

• Notice:
• Error while running event on_tick (ID 0)
• Unknown interface: Concreteer
• stack traceback :
• __CpeBusyBots__/control.lua:84: in function 'work'
• __CpeBusyBots__/control.lua:209: in function 'checkTick'
• __CpeBusyBots__/control.lua:214: in function <__CpeBusyBots__/control.lua:214>

the idea behind the mods is nice, but they probably need quite some more work to work at all, and to work without insanely lagging the game.

I probably will go back to removing trees with the deconstruction planner, and paving an area by using blueprints to mark maybe 32x32 tiles (1 chunk) or 64x64 tiles (2x2 chunks) at a time. doing it with blueprints also will allow me to do more detailed work (eg following outlines of my walls, etc) instead of having huge square areas (including areas outside of my walls) concreeted.

edit: just tested again with 100 bots, and the lag is still noticable, but quite small and tolarable. the above problems seem to be caused by having 1k bots ... but "concreteering" is probably most useful on megabases, and which megabase has less than 1k or even 10k bots ?

[torne]

Found a bug in Busy Bots: it assumes roboports all have unique backer names, and if it finds a duplicate while processing the initial list of roboports it will stop processing the list entirely and not register any other pre-existing roboports.

The game doesn't seem to prevent duplicate names from being assigned; my pre-existing save has a pair which have been assigned the same backer name by chance. I guess you'll have to use some other identifier to keep track of them?

[cpeosphoros]

Busy bots 14.2 - spam continues.

Solved. Please upgrade Busy Bots to 0.14.3 and any worker module to 0.14.2.

running Busy bots 14.3 and worker modules 14.2 - spam continues.

and without Concreteer it even crashed

when i installed your three mods for the first time yesterday, i used the most current versions 14.3, 14.2 and 14.2.
my testworld where i added those mods already was paved with concrete all around a roboport. result: first a notification that "Busy Bots added roboporty xxx", followed by spamming me with coordinates every 2 seconds "Warning! Concreteering concrete for xxx at -40,-55" (next lines -40,-54, -39,-55, -39,-54, -41,-56, ....), apparently one message per tile, and sound for each one.

then i removed the roboport and built a new one in the wilderness. first i got messages about "Low count of concrete" several times. then it finally started paving the area, but always 2 seconds of normal gameplay, then 10 seconds frozen, 2 seconds normal, 10 seconds frozen. and after a while, the messages about low concrete were back (i don't want to be notified that i can't produce 800+ concrete every 2 seconds, or including lag every 12 seconds).
finally the whole area was paved, thus robots didn't work, but i still got the messages about "low concrete" until i had 1000 concrete filled in a storage chest. at that time, the messages "Warning! concreteering concrete" came back and continue, together with the huge lag.
unplayable like that.

then i restarted the map after disabling concreteer, had no roboports, and walked around. every two seconds the game froze for a fraction of a second. very ugly.

and as last test, i went to the wilderness again and placed a roboport. as result all trees in the area are marked for removal, and the game crashed with

• Notice:
• Error while running event on_tick (ID 0)
• Unknown interface: Concreteer
• stack traceback :
• __CpeBusyBots__/control.lua:84: in function 'work'
• __CpeBusyBots__/control.lua:209: in function 'checkTick'
• __CpeBusyBots__/control.lua:214: in function <__CpeBusyBots__/control.lua:214>

the idea behind the mods is nice, but they probably need quite some more work to work at all, and to work without insanely lagging the game.

I probably will go back to removing trees with the deconstruction planner, and paving an area by using blueprints to mark maybe 32x32 tiles (1 chunk) or 64x64 tiles (2x2 chunks) at a time. doing it with blueprints also will allow me to do more detailed work (eg following outlines of my walls, etc) instead of having huge square areas (including areas outside of my walls) concreeted.

edit: just tested again with 100 bots, and the lag is still noticable, but quite small and tolarable. the above problems seem to be caused by having 1k bots ... but "concreteering" is probably most useful on megabases, and which megabase has less than 1k or even 10k bots ?

Sorry for the delayed answer, was in new year's holidays.

I'm working hard on the lag issue.

The "Warning! Concreteering concrete" can be toggled off by adding "concrete" to the whitelist on config.lua (And I should have documented it on the mod's page). I'm tweaking how warnings work, so they will not pester the player aaall the time.

The "Unknown interface: Concreteer" crash is entirely my naive assumption that people would not remove worker mods after adding them. Next version will care for that.

Thanks a lot for the detailed report.

[cpeosphoros]

Found a bug in Busy Bots: it assumes roboports all have unique backer names, and if it finds a duplicate while processing the initial list of roboports it will stop processing the list entirely and not register any other pre-existing roboports.

The game doesn't seem to prevent duplicate names from being assigned; my pre-existing save has a pair which have been assigned the same backer name by chance. I guess you'll have to use some other identifier to keep track of them?

I'm very sad with that. Yes, I assumed backer names were a unique identifier. I will get a way to work around it next version, thank you.

[Nexela]

Most entities (at least the ones that matter) all have a unit_number which is unique.

[Anson]

Sorry for the delayed answer, was in new year's holidays.

welcome back and a happy (and healthful and peaceful) new year!

I'm working hard on the lag issue.

when people have the time to pave large bases, they also should have a little time to wait until the work is done. thus *I* would gladly accept when the whole process would be a little slower in exchange for no more lag, eg by spreading the work to more ticks, and capping the number of tiles per tick to some fixed (non-lagging) number (maybe easily to be changed in the config, in case someone wants 1000++ tiles per second while drinking a cup of coffee per tick (at <1 ups) :-).

The "Warning! Concreteering concrete" can be toggled off by adding "concrete" to the whitelist on config.lua

i have a lot of mods and update them all always before starting factorio. thus i prefer default settings that are useful and that enable me to simply update mods and not have to check everytime where i might have to adjust parameters after an update (and search for mod location, unzip mods, edit config, etc). too bad that mods can't have their own config files that are saved and loaded between game sessions, updates, or even between maps.

... would not remove worker mods after adding them.

thanks for the future fix.
after paving the largest part of my factory, i probably don't want it to automatically pave more (or remove trees, etc) if i add some roboports, maybe temporarily at an outpost, or to connect several separate logistic networks (one for each outpost) with each other by a line of roboports. that would cause unnecessary lag, remove half the forests on the map, etc. I also would hate this to happen if i need to check something and therefore temporarily add a roboport covering a huge area in a remote location (creative mode has ports with logistics 200x200 and construction 400x400 :-)

just had an idea for an alternative: what about a specialized roboport/machine that has (almost) no range, but a slot where i can put concrete or wood, and the amount of items in that stack determines the range where it marks trees and tiles for work that is done by bots from a "real" roboport somewhere ?


after i am done with most of my paving now, i wanted to remove lots of bots and put them in storage so that they don't fill and block roboports. but when i pulled them from roboports with bot recaller and then moved them to a storage chest, i got the usual problem that i have in factorio (loop between requester and provider/storage) :

related question for another thread - factorio for dummies

how can i put back some items in a storage system to be used by specific assemblers/roboports/etc ? example: an assembler makes belts, feeds them to a provider chest, and other assemblers take belts from there to make underground belts etc. when i replace yellow belts with red or blue belts, i want to trash the removed yellow belts to that chest too. but how? obviously it can't be any kind of provider chest to receive items directly. using a requester next to that provider creates a loop with the provider. using a storage chest works only as long as there are belts left in the storage chest and as long as the system doesn't decide to put other junk in it. a storage chest with filter slots would be nice, but doesn't exist.

another problem with this requester functionality is that the bot recaller requests hundreds of bots which are not only pulled from roboports, but also freshly produced. this is most noticable when there are only few or none left in the network and in roboports.
would it be possible to restrict your bot recaller to only get bots from roboports and not request them otherwise ?
(there is another mod that exchanges bots for upgraded bots, but that mod can't "extract only" bots from the system, and afaik it has no delay so that it feels more cheaty to teleport all immediately. otoh, it is more like an active provider and thus sends the old robots to storage where they can be accessed more easily)

[cpeosphoros]

Sorry for the delayed answer, was in new year's holidays.

welcome back and a happy (and healthful and peaceful) new year!

You too.

I'm working hard on the lag issue.

when people have the time to pave large bases, they also should have a little time to wait until the work is done. thus *I* would gladly accept when the whole process would be a little slower in exchange for no more lag, eg by spreading the work to more ticks, and capping the number of tiles per tick to some fixed (non-lagging) number (maybe easily to be changed in the config, in case someone wants 1000++ tiles per second while drinking a cup of coffee per tick (at <1 ups) .

That's almost exactly the solution I've come up with. I have also done heavy refactoring for caching variables between loops, so table look-up would not hit performance. Those are some characteristics of Factorio's Lua interpreter which are a bit different from vanilla Lua, so some adaptations must be made to account for performance.

I'm testing it in a bobs/angel megabase. So far, with ~60 roboports and ~600 construction bots, no lag at all (I had 3 to 5 seconds lag each cycle, with those same numbers, before the refactoring). I've found, though, that having all those bots in the air puts a huuuge drain on my electrical network, so I'm working up - non mod related, - the electricity, so I'll go up to, like, 5k bots and see iif there is still no lag.

The "Warning! Concreteering concrete" can be toggled off by adding "concrete" to the whitelist on config.lua

i have a lot of mods and update them all always before starting factorio. thus i prefer default settings that are useful and that enable me to simply update mods and not have to check everytime where i might have to adjust parameters after an update (and search for mod location, unzip mods, edit config, etc).

I hear you there. I'll pack future versions with plain old "concrete" as the whitelisted version, and I've also come up with a more moderated low count warning (something like each 30 cycles, which by the default 2 seconds cycles, would amount to a minute between warnings). All those numbers will also all be configurable.

too bad that mods can't have their own config files that are saved and loaded between game sessions, updates, or even between maps.

Yes, I miss that too. Maybe they will have that bettered in some future version. It's still Alpha, early release, etc, after all.

... would not remove worker mods after adding them.

thanks for the future fix.

It'll be in the next version up.

after paving the largest part of my factory, i probably don't want it to automatically pave more (or remove trees, etc) if i add some roboports, maybe temporarily at an outpost, or to connect several separate logistic networks (one for each outpost) with each other by a line of roboports. that would cause unnecessary lag, remove half the forests on the map, etc. I also would hate this to happen if i need to check something and therefore temporarily add a roboport covering a huge area in a remote location (creative mode has ports with logistics 200x200 and construction 400x400

I'm working on a configuration GUI that will allow you to toggle mods on/off, wholesale or per roboport. GUIs are not trivial to program in Lua, and this GUI in specific is not simple, so, big work. And it also got backlogged by the performance issues in the main mods.

just had an idea for an alternative: what about a specialized roboport/machine that has (almost) no range, but a slot where i can put concrete or wood, and the amount of items in that stack determines the range where it marks trees and tiles for work that is done by bots from a "real" roboport somewhere ?

I like the general idea, but I think it would be better on the GUI, also, instead of coming up with yet another entity in the game. What do you think?

I'm working on something with looks quite similar to Advanced Logistic System's gui.

after i am done with most of my paving now, i wanted to remove lots of bots and put them in storage so that they don't fill and block roboports. but when i pulled them from roboports with bot recaller and then moved them to a storage chest, i got the usual problem that i have in factorio (loop between requester and provider/storage) :

related question for another thread - factorio for dummies

how can i put back some items in a storage system to be used by specific assemblers/roboports/etc ? example: an assembler makes belts, feeds them to a provider chest, and other assemblers take belts from there to make underground belts etc. when i replace yellow belts with red or blue belts, i want to trash the removed yellow belts to that chest too. but how? obviously it can't be any kind of provider chest to receive items directly. using a requester next to that provider creates a loop with the provider. using a storage chest works only as long as there are belts left in the storage chest and as long as the system doesn't decide to put other junk in it. a storage chest with filter slots would be nice, but doesn't exist.

another problem with this requester functionality is that the bot recaller requests hundreds of bots which are not only pulled from roboports, but also freshly produced. this is most noticable when there are only few or none left in the network and in roboports.

I've come up with some contraptions that alleviate that loop problem, using hard limits (the red "X" button on chests), circuit network and intermediate non-logistic chests. Quite works most of the time, but you have to give it some attention every dozen minutes, to see if has not get clogged, etc. Not ideal, but helps.

Simplest setup

Have a requester (or a bot recaller) with only a couple stacks allowed, feeding by inserter a non-logistic chest, also with only a couple stacks, which also feeds by inserter a passive provider/storage chest. The last inserter is connected to the logistic network and set only to work on a specified condition.

If you tweak the numbers right, it'll break the darned loop.

I have a more detailed system here: viewtopic.php?f=33&t=37998#p232967

would it be possible to restrict your bot recaller to only get bots from roboports and not request them otherwise ?

I'd have to have a look at it. As it stands now, it's just a simple hack of a vanilla requester, so all the vanilla behavior stands up too. I'll put it on the todo list, but not with a very high priority, probably after the GUI.

(there is another mod that exchanges bots for upgraded bots, but that mod can't "extract only" bots from the system, and afaik it has no delay so that it feels more cheaty to teleport all immediately. otoh, it is more like an active provider and thus sends the old robots to storage where they can be accessed more easily)

Yes, that's Lord Peppe's mod, which gave me inspiration to come up with my bot recaller.

Anyway, thanks again for the detailed suggestions. They are a huge help.

[cpeosphoros]

Most entities (at least the ones that matter) all have a unit_number which is unique.

Nice to know, thank you, it's not clear from the documentation.

But I need a human readable Id, so it will work with the GUI. What I've done was add a simple counter-generated unique number to all backer names, so if they are duplicated you result with something like "Mandela #0010" and "Mandela #0027" and not have name collision.

I don't use the names themselves to access the roboports. For that I keep an internal reference to then. But I started using the names as table indexes for inter-mod interface calls, as the roboport (or any table entity, actually) references get mangled up when passed through the interface pipes.

The result is, as it stands now, this:

Code: Select all

worker = {name = roboport.backer_name .. getUniqueNumber(), roboport = roboport, ...}

And downstream I use worker.name as table indexes everywhere.

[Anson]

I'll pack future versions with plain old "concrete" as the whitelisted version

only "concrete" literally? or also "stone" and (eg via wildcard matching when you check or setup the whitelist) all other floor names that have "concrete" in them (to include all those colored concrete, etc)

I'm working on a configuration GUI that will allow you to toggle mods on/off, wholesale or per roboport.

just had an idea for an alternative: what about a specialized roboport/machine that has (almost) no range, but a slot where i can put concrete or wood, and the amount of items in that stack determines the range where it marks trees and tiles for work that is done by bots from a "real" roboport somewhere ?

I like the general idea, but I think it would be better on the GUI, also, instead of coming up with yet another entity in the game.
What do you think?

i thought it might be easier to add another item instead of programming a complicated gui :-)

but when i can enable and disable everything for each single roboport, it should have a similar effect: to cover the whole base, i could use some modded roboports for large areas (with all your functionality disabled), and setup a few normal or even other modded smaller roboport that have the desired functions enabled.

I've come up with some contraptions that alleviate that loop problem, ...
Quite works most of the time, but you have to give it some attention every dozen minutes, to see if has not get clogged, etc. Not ideal, but helps.

I'll have a look at what you did, but I'm looking for a solution that works all the time. i don't like having to run a few kilometers every few minutes (or even only once per hour) to some outpost just to check whether chests are misbehaving.

my solution

my solution is the following setup :

• assembler
• -> inserter (activated if storage chest < theshold1)
  (threshold1 is the number of items that i want to have available)
• -> storage chest
• -> one or more inserters (activated if storage chest > theshold2)
  (threshold2 is an estimate for a small remainder of items that keep the storage chest reserved for that type of item)
• -> next assemblers

factorio itself will take care of using this chest first to store more items of the same type, and using other storage chests first for other types when they have those other types already, or when they are empty, but it still needs some attention in case more than threshold2 items are used quickly (emptying the storage chest, thus the system potentially filling it with other items), or in case that all other storage chests in the network are partially filled (and thus the system starts adding more types to this chest). it also doesn't work (in this simple and easy layout) when i need that item type at different locations in the factory so that i can't simply have one or more inserters grabbing that item type directly from that single storage chest.

the best solution would be to have storage chests with filter slots that reserve which items are allowed in that chest, maybe even a special filter selection for "everything that is already in the chest" (with the option to never empty the last item of any type and/or the last item of any stack) ... thinking of the logistic pipes mod in minecraft :-)

would it be possible to restrict your bot recaller to only get bots from roboports and not request them otherwise ?

I'd have to have a look at it. As it stands now, it's just a simple hack of a vanilla requester, so all the vanilla behavior stands up too.

not high on the priority list: ok, but here is an idea. maybe it's simple enough to do ...

the functionality to pull bots from roboports is not from vanilla :-)
maybe that added functionality could be kept, ignoring the amount of bots that is set in the filter. then i could set the filter of the requester chest to 0 bots of some type and thus none would be requested by the vanilla functionality, and it still could pull bots from roboports with your added functionality (as long as there is space in the chest, keeping the functionality of limiting the capacity with the red X so that not all bots are always completely removed from the network when you can't handle them fast enough with your factory, eg upgrading them in some assembler, etc)

[cpeosphoros]

I'll pack future versions with plain old "concrete" as the whitelisted version

only "concrete" literally? or also "stone" and (eg via wildcard matching when you check or setup the whitelist) all other floor names that have "concrete" in them (to include all those colored concrete, etc)

The packed config.lua now reads

Code: Select all

-- if you are using a mod which provides colored concrete, you can use some of the commented out options

-- tiles on this list will not be overriden by concreteer
preserveTiles = {["concrete"]}
--preserveTiles = {["concrete-white"]=true, ["concrete-magenta"]=true}

-- concreteer will emit a warn if trying to pave tiles with anything not on this list
whiteList = {["concrete"]=true}
--whiteList = {["concrete-white"]=true}

-- if a tile under a roboport has no concrete, concreteer will use this to pave
defaultConcrete = "concrete"
--defaultConcrete = "concrete-white"

No wildcards at the moment, I'll add that to the to-do list, but also not with very high priority. The pattern checker will, at the moment, look only for tiles with "concrete" in their name. But, if they don't find a concrete tile below the roboport, it will fall back to whatever is listed under "defaultConcrete" in config.lua, which can be any paveable tile, like "stone", or even "wood".

Also, under "preserveTiles", you can list any kind of ground, like "grass" or "grass-dry", for an example.

I'm working on a configuration GUI that will allow you to toggle mods on/off, wholesale or per roboport.

just had an idea for an alternative: what about a specialized roboport/machine that has (almost) no range, but a slot where i can put concrete or wood, and the amount of items in that stack determines the range where it marks trees and tiles for work that is done by bots from a "real" roboport somewhere ?

I like the general idea, but I think it would be better on the GUI, also, instead of coming up with yet another entity in the game.
What do you think?

i thought it might be easier to add another item instead of programming a complicated gui

I'll give it some thought.

the functionality to pull bots from roboports is not from vanilla

Sure it is not. That's exaclty what my small hack does.

maybe that added functionality could be kept, ignoring the amount of bots that is set in the filter. then i could set the filter of the requester chest to 0 bots of some type and thus none would be requested by the vanilla functionality, and it still could pull bots from roboports with your added functionality (as long as there is space in the chest, keeping the functionality of limiting the capacity with the red X so that not all bots are always completely removed from the network when you can't handle them fast enough with your factory, eg upgrading them in some assembler, etc)

Again, I'll give it some thought, but my priority now is still fine tuning performance, and adding some of the planned extra worker mods.

[Anson]

Code: Select all

-- tiles on this list will not be overriden by concreteer
preserveTiles = {["concrete"]}
--preserveTiles = {["concrete-white"]=true, ["concrete-magenta"]=true}

only
preserveTiles = {["concrete"]}
and not
preserveTiles = {["concrete"]=true}
?

if they don't find a concrete tile below the roboport, it will fall back to whatever is listed under "defaultConcrete" in config.lua, which can be any paveable tile, like "stone", or even "wood".
...
Also, under "preserveTiles", you can list any kind of ground, like "grass" or "grass-dry", for an example.
...
I'm working on a configuration GUI that will allow you to toggle mods on/off, wholesale or per roboport.

it would be nice if those tiles in the pattern without legal pavement would be skipped.
this would require users to first put some pattern under a roboport and some people might think that it doesn't work since nothing happens, but at the same time avoid work to automatically start for every roboport. by putting pavement only under some roboports, it would be easy to select where to get a paved factory and where to keep the original floor ... with no need for a gui at all :-)

Again, I'll give it some thought, but my priority now is still fine tuning performance, and adding some of the planned extra worker mods.

thinking about lots of configuration details, i came to this personal result:
the mod is very nice, but also a lot of work ... for you to program (if you want to be prepared for all kinds of special events, layouts, floors, etc, and probably will miss one or two special cases anyway) as well as for me to setup (if i use several mods to get additional floor types, like all the colored concrete, asphalt, asphalt and other concrete with line markings, danger markings, etc, and lots more like from "more floors", etc).
thus it probably will be best for me and my factory to keep doing it semi-manually, eg by using a large blueprint with the desired pattern, and the ability to stamp blueprints with roads on my factory without need to edit the config to avoid that the mod accidentally overwrites all those carefully placed roads etc (which will become really difficult if i have asphalt roads on one map, concrete on another, and then there is an update and i have to adjust everything again)

good luck with this mod and your other (planned) workers ...
I'll keep watching how it develops anyway :-)

[DRY411S]

Feedback on Bot Recaller.

First, thanks for this.

It recalls bots that are already in other logistics chests. It would be better if it only recalled idle bots from roboports.

[Optera]

It's impossible to use stone-brick.
Under roboports it's ignored as pattern
Setting the item name "stone-brick" as default results in an error when it tries to find "stone-brick" tiles.
Setting the tile name "stone-path" results in an error when it tries to find "stone-brick" items.

[admo]

I've been seeing the pictured issue in my bases. It doesn't reproduce consistently and most areas are paved correctly. I'm looking for some tips to better narrow this down to a better reproduction.

The way this stuff is getting put down is from a large blueprint that puts down one of the rail grids you can see in the mini map. The blueprint has the roboports in it as well. I'll typically just run in a direction of an ore field placing these grids. Much latter when I return to see the finished construction this pattern is left behind. The mods of busy bots did correctlyl remove all the trees though.