Recently, I have had lots of issues with the assignment of jobs to the different roboport types:
1. I wanted to relocate the smelters by a few tiles. I did the usual blueprint, deconstruct, place blueprint thing. The old position was barely in the construction range of a stationary roboport and it took most of the smelters and stored them far away. The new position was out of range of the stationary roboport and I had hardly any smelters in inventory.
2. I placed a large array of assemblers and had all things needed in my inventory to get it done fast. The game decided to get the stuff from who-knows-where far away. 10% of the ghost objects where never placed (no idea why, there are enough in the logistic system and not miles away) and I had to reprint the blueprint.
3. I deleted some storage chests by deconstruction planner. Bad idea. Instead of relocating the items into other (sufficiently provided) storage chests, this job was given to my personal roboport. The bots inserted a colorful collection of 30k items into my inventory.
Of course you only notice the examples where things go wrong. The examples also show that there is most likely no strategy that fits it all. The main problem is, that you never know what will happen and I have no control. And there are two more broken examples:
4. I built a train station that contains a roboport. The roboport was built first and then all the other ghost objects where assigned to this roboport. Instead of taking all the stuff from my inventory, it complained about missing objects. I had to give construction bots to the roboport and put the items in a storage chest to get the train station completed.
5. I deconstructed a train station, again with roboport (containing construction bots). The roboport got most of the deconstruct jobs and sent its bots out. Then the port itself was removed. Instead of returning to me, all bots in the air decided to return to my main factory thousands of tiles away. Slowly. With all the items I intended to use for a new train station.
Questions:
a) Is there any way to control the job assignment? Currently I resort to dirty tricks like removing personal roboports or stationary roboports first.
b) Are there any pending suggestions or planned improvements in this regard? (Edit: Found: viewtopic.php?f=80&t=20566 . Lots of fodder for reading, most probably contains ideas regarding these problems.)
c) How can you escape scenario 3 (thousand of bots trying to insert ten thousands of items)?
d) Is scenario 4/5 a bug of intended behavior?
Assignment of jobs to personal/stationary roboport
-
- Long Handed Inserter
- Posts: 56
- Joined: Thu Jun 16, 2016 11:02 am
- Contact:
Re: Assignment of jobs to personal/stationary roboport
Part A) Make sure Roboports cover your desired construction areaLastmerlin wrote:Recently, I have had lots of issues with the assignment of jobs to the different roboport types:
1. I wanted to relocate the smelters by a few tiles. I did the usual blueprint, deconstruct, place blueprint thing. The old position was barely in the construction range of a stationary roboport and it took most of the smelters and stored them far away. The new position was out of range of the stationary roboport and I had hardly any smelters in inventory.
Part B) In current gameplay, set down some storage chests and "prime" them with one of the things you are about to deconstruct. This part is teh suck
I agree there should be a calculation with respect to placing items to optimize where items are brought from. The reverse of this could also be true, however, that I don't want you to take ANYTHING from my inventory but that's a whole different argument.Lastmerlin wrote:2. I placed a large array of assemblers and had all things needed in my inventory to get it done fast. The game decided to get the stuff from who-knows-where far away. 10% of the ghost objects where never placed (no idea why, there are enough in the logistic system and not miles away) and I had to reprint the blueprint.
Goes back to my first commentLastmerlin wrote:3. I deleted some storage chests by deconstruction planner. Bad idea. Instead of relocating the items into other (sufficiently provided) storage chests, this job was given to my personal roboport. The bots inserted a colorful collection of 30k items into my inventory.
This says to me that A) you have all the things in chests somewhere... and B)Should not connect to your logi network if you want to strictly pull from inventory. But yes this is broken.Lastmerlin wrote:Of course you only notice the examples where things go wrong. The examples also show that there is most likely no strategy that fits it all. The main problem is, that you never know what will happen and I have no control. And there are two more broken examples:
4. I built a train station that contains a roboport. The roboport was built first and then all the other ghost objects where assigned to this roboport. Instead of taking all the stuff from my inventory, it complained about missing objects. I had to give construction bots to the roboport and put the items in a storage chest to get the train station completed.
Roboport bots and personal bots don't mix...which is what it sounds like you expected. Also priming some storage chests might help/Lastmerlin wrote:5. I deconstructed a train station, again with roboport (containing construction bots). The roboport got most of the deconstruct jobs and sent its bots out. Then the port itself was removed. Instead of returning to me, all bots in the air decided to return to my main factory thousands of tiles away. Slowly. With all the items I intended to use for a new train station.
a) Deconstruct or Build a roboport to control the overlap with your personal roboportLastmerlin wrote:Questions:
a) Is there any way to control the job assignment? Currently I resort to dirty tricks like removing personal roboports or stationary roboports first.
b) Are there any pending suggestions or planned improvements in this regard? (Edit: Found: viewtopic.php?f=80&t=20566 . Lots of fodder for reading, most probably contains ideas regarding these problems.)
c) How can you escape scenario 3 (thousand of bots trying to insert ten thousands of items)?
d) Is scenario 4/5 a bug of intended behavior?
b)
d) Prime some storage chests closer by with at least one item of each type being deconstructed
d) I dont know if I would call it a bug or intended but it is existing behavior. The workarounds mentioned will help but much of this is mildly borked imo
-
- Long Handed Inserter
- Posts: 56
- Joined: Thu Jun 16, 2016 11:02 am
- Contact:
Re: Assignment of jobs to personal/stationary roboport
It seems that you have misunderstood some of the situations or I have not described them sufficiently.
I dont understand this tip. Of course you need at least one type of roboport (stationary/personal) to build. If you have exactly one, everything will be as expected. In each cases the operating area was covered by both stationary and personal roboport and this leads to the problems.Shokubai wrote: Part A) Make sure Roboports cover your desired construction area
I had nothing in chests. Case 4 was a completely new expansion far away from any existing bot network. I put the things in chests afterwards, because the jobs were assigned to the stationary roboport and it would not take from my inventory. B) I dont understand how you can avoid having both types of roboport present if you use personal roboport to place a blueprint that contains a roboport.Shokubai wrote: This says to me that A) you have all the things in chests somewhere... and B)Should not connect to your logi network if you want to strictly pull from inventory. But yes this is broken
I don't see how chests will really solve the problem. Perhaps the bots will place their items there, but thereafter they will still fly miles back to the base (slowly!). Not really what I want (as the bots belong to the expansion as well). It boils down to the simple question: How to you properly deconstruct an expansion that contains roboports? Is manually deconstructing all roboports first the only way?Shokubai wrote: Roboport bots and personal bots don't mix...which is what it sounds like you expected. Also priming some storage chests might help/
Re: Assignment of jobs to personal/stationary roboport
"The new position was out of range of the stationary roboport and I had hardly any smelters in inventory."Lastmerlin wrote:It seems that you have misunderstood some of the situations or I have not described them sufficiently.
I dont understand this tip. Of course you need at least one type of roboport (stationary/personal) to build. If you have exactly one, everything will be as expected. In each cases the operating area was covered by both stationary and personal roboport and this leads to the problems.Shokubai wrote: Part A) Make sure Roboports cover your desired construction area
If there were no items in your logi network(local or global if connected) then they would come out of your inventory if your personal roboport construction area overlapped the ghost. They don't get assigned if they don't exist.Lastmerlin wrote:I had nothing in chests. Case 4 was a completely new expansion far away from any existing bot network. I put the things in chests afterwards, because the jobs were assigned to the stationary roboport and it would not take from my inventory. B) I dont understand how you can avoid having both types of roboport present if you use personal roboport to place a blueprint that contains a roboport.Shokubai wrote: This says to me that A) you have all the things in chests somewhere... and B)Should not connect to your logi network if you want to strictly pull from inventory. But yes this is broken
There are a few ways to do this. If it''s a large deconstruction then i will strategically delete a roboport to segregate the logi network where i want to deconstruct. It may be necessary to manually transplant some bots.Lastmerlin wrote:I don't see how chests will really solve the problem. Perhaps the bots will place their items there, but thereafter they will still fly miles back to the base (slowly!). Not really what I want (as the bots belong to the expansion as well). It boils down to the simple question: How to you properly deconstruct an expansion that contains roboports? Is manually deconstructing all roboports first the only way?Shokubai wrote: Roboport bots and personal bots don't mix...which is what it sounds like you expected. Also priming some storage chests might help/
Priming chests does help keep the deconstructed materials close and as many bots as can charge and dock will stay locally until needed elsewhere. Having ENOUGH roboports locally to charge all your bots also helps. When I am building Solar I do not integrate roboports into the design. I do build them temporarily around the array to assist in construction. I may drop 5 or 10 in an area to recharge the delivering bots for the return trip which may be a long way away since I dont generally segment my logi network.
Generally I unequip my personal roboport for anything of scale. I dont want or need all that crap in my inventory.
As I said, some of this works wonky. Placing or deconstructing when both your personal and global logi network overlap does not work efficiently.
Re: Assignment of jobs to personal/stationary roboport
Keep in mind that jobs will be assigned to your personal roboport up to the number of bots in your inventory, up to the limit of 10x(number of personal roboports). If you are maxed out with 50, your personal roboport will construct/deconstruct up to 50 items. If you are taking down a large structure that has more than 50 items, items 51+ will be allocated to the network. Likewise, if you put down a blueprint with more than 50 items in a region with a roboport network, your bots will place the first 50 items (assuming they are available in your inventory) and the rest will be placed by the network.