Cpeophoros's Mods

Topics and discussion about specific mods
User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Cpeophoros's Mods

Post by cpeosphoros » Mon Dec 26, 2016 6:49 pm

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.
Last edited by cpeosphoros on Fri Jul 14, 2017 8:17 pm, edited 6 times in total.

katalex
Inserter
Inserter
Posts: 49
Joined: Mon Nov 10, 2014 7:44 pm
Contact:

Re: Ceophoros's Mods

Post by katalex » Tue Dec 27, 2016 5:41 pm

Busy bots 14.2 - spam continues.

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Ceophoros's Mods

Post by cpeosphoros » Tue Dec 27, 2016 6:26 pm

katalex wrote:Busy bots 14.2 - spam continues.
Which message? The same "Init - No Workers"?

katalex
Inserter
Inserter
Posts: 49
Joined: Mon Nov 10, 2014 7:44 pm
Contact:

Re: Ceophoros's Mods

Post by katalex » Tue Dec 27, 2016 7:17 pm

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

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Ceophoros's Mods

Post by cpeosphoros » Tue Dec 27, 2016 8:15 pm

katalex wrote:Image
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.

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Ceophoros's Mods

Post by cpeosphoros » Tue Dec 27, 2016 9:09 pm

katalex wrote:Busy bots 14.2 - spam continues.
Solved. Please upgrade Busy Bots to 0.14.3 and any worker module to 0.14.2.

Anson
Fast Inserter
Fast Inserter
Posts: 235
Joined: Sun May 22, 2016 4:41 pm
Contact:

Re: Ceophoros's Mods

Post by Anson » Wed Dec 28, 2016 2:01 pm

cpeosphoros wrote:
katalex wrote: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
Filter Inserter
Filter Inserter
Posts: 272
Joined: Sun Jan 01, 2017 11:54 am
Contact:

Re: Cpeophoros's Mods

Post by torne » Sun Jan 01, 2017 11:57 am

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?

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Ceophoros's Mods

Post by cpeosphoros » Tue Jan 03, 2017 10:50 pm

Anson wrote:
cpeosphoros wrote:
katalex wrote: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.

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Cpeophoros's Mods

Post by cpeosphoros » Tue Jan 03, 2017 10:52 pm

torne wrote: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
Smart Inserter
Smart Inserter
Posts: 1814
Joined: Wed May 25, 2016 11:09 am
Contact:

Re: Cpeophoros's Mods

Post by Nexela » Wed Jan 04, 2017 12:52 am

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

Anson
Fast Inserter
Fast Inserter
Posts: 235
Joined: Sun May 22, 2016 4:41 pm
Contact:

Re: Ceophoros's Mods

Post by Anson » Wed Jan 04, 2017 10:48 am

cpeosphoros wrote:Sorry for the delayed answer, was in new year's holidays.
welcome back and a happy (and healthful and peaceful) new year!
cpeosphoros wrote: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) :-).
cpeosphoros wrote: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.
cpeosphoros wrote:... 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
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)

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Ceophoros's Mods

Post by cpeosphoros » Wed Jan 04, 2017 5:23 pm

Anson wrote:
cpeosphoros wrote:Sorry for the delayed answer, was in new year's holidays.
welcome back and a happy (and healthful and peaceful) new year!
You too.
Anson wrote:
cpeosphoros wrote: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.
Anson wrote:
cpeosphoros wrote: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.
Anson wrote: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.
Anson wrote:
cpeosphoros wrote:... would not remove worker mods after adding them.
thanks for the future fix.
It'll be in the next version up.
Anson wrote: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.
Anson wrote: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.
Anson wrote: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
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
Anson wrote: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.
Anson wrote:(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.

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Cpeophoros's Mods

Post by cpeosphoros » Wed Jan 04, 2017 5:32 pm

Nexela wrote: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
Fast Inserter
Fast Inserter
Posts: 235
Joined: Sun May 22, 2016 4:41 pm
Contact:

Re: Ceophoros's Mods

Post by Anson » Sun Jan 08, 2017 12:57 am

cpeosphoros wrote: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)
cpeosphoros wrote:I'm working on a configuration GUI that will allow you to toggle mods on/off, wholesale or per roboport.
Anson wrote: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.
cpeosphoros wrote: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
cpeosphoros wrote:
Anson wrote: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)

User avatar
cpeosphoros
Inserter
Inserter
Posts: 40
Joined: Fri Dec 23, 2016 10:57 pm
Contact:

Re: Ceophoros's Mods

Post by cpeosphoros » Sun Jan 15, 2017 1:52 pm

Anson wrote:
cpeosphoros wrote: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.
Anson wrote:
cpeosphoros wrote:I'm working on a configuration GUI that will allow you to toggle mods on/off, wholesale or per roboport.
Anson wrote: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.

Anson wrote:the functionality to pull bots from roboports is not from vanilla :-)
Sure it is not. That's exaclty what my small hack does.
Anson wrote: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
Fast Inserter
Fast Inserter
Posts: 235
Joined: Sun May 22, 2016 4:41 pm
Contact:

Re: Ceophoros's Mods

Post by Anson » Sun Jan 22, 2017 5:46 pm

cpeosphoros wrote:

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}
?
cpeosphoros wrote: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 :-)
cpeosphoros wrote: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 :-)

User avatar
DRY411S
Filter Inserter
Filter Inserter
Posts: 608
Joined: Sun Mar 13, 2016 9:48 am
Contact:

Re: Cpeophoros's Mods

Post by DRY411S » Wed Feb 08, 2017 5:47 pm

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.

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2086
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Cpeophoros's Mods

Post by Optera » Sun Feb 12, 2017 1:55 pm

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
Inserter
Inserter
Posts: 27
Joined: Tue Jun 28, 2016 1:07 am
Contact:

Re: Cpeophoros's Mods

Post by admo » Sun Feb 26, 2017 4:24 pm

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.
Attachments
Capture.PNG
picture of issue
Capture.PNG (8.43 MiB) Viewed 5920 times

Post Reply

Return to “Mods”

Who is online

Users browsing this forum: jinks