Roboport Robot filter

[bobingabout]

This might seem like a bit of an odd request, but, it could benefit the base game, as well as my mods.

The request: The ability to set an item filter on the robot storage slots of a roboport.

Why?

Base game reason:
Have you ever had the issue where all your construction bots gather at one end of the base where you've been building things, preventing logistic bots docking there? then you go to the other side of your base, try and build something, and have to wait for the construction bots to fly over?
Same situation with logistic bots, all collect in one area, then have to fly a long way to pick something up from the other side of the base, because there's no bots stored locally?

Solution: Add filters.
The filters would be, one option for every type of construction robot, base game that's one option. One option for every type of logistics robot, base game that's one option. Blank, for "Any robot" which is the default, Plus that X you see in chests which means "Don't store in these slots".

This would allow you to specify how many construction and logistic robots dock in each roboport. And limit the number with that X if you use it.

Docking priority: When deciding where to dock, a construction robot would prefer first to try and dock in any roboport on the network with it's own filter set, even if it's on the other side of the base. This in a way makes these filter slots double as a robot request slot. Second in the priority list would then be a blank slot. And 3rd, If, and only if there are no other slots available, Maybe in the X slot? (Which kinda makes it a, emergency parking spot, rather than a "don't park here" spot)


Additional Mod solution:
Since my mod includes additional types of construction and logistic robot, each robot would also be added to the list. This allows you to set filters of the highest tier robot only. Alternatively, because it also functions as a request slot, not just a filter slot(Since robots prefer to dock in a slot reserved for their type over a blank default slot), you could set up a roboport with a filter for lower tier robots set, and an inserter to pull them out, as a means of removing old robots from your network.


Well, there's my idea. What do you think, and what is the likelihood of that actually making it into the game?

[Sirenfal]

+1. This would be great even in vanilla

[Xeanoa]

I think in vanilla, Roboports shouldn't even be able to host 300 robots, since they can't even handle more than 50-100 of them working. They either need a serious buff to recharging capacities, or just plain not allow more than 100 of them to dock.

[bobingabout]

I'm thinking I should have posted this in Ideas and Suggestions. I don't think I can move it myself, I'm only mod of my sub forum.

I think in vanilla, Roboports shouldn't even be able to host 300 robots, since they can't even handle more than 50-100 of them working. They either need a serious buff to recharging capacities, or just plain not allow more than 100 of them to dock.

I think this is somewhere in the ideas and suggestions, of someone basically suggesting to reduce the stack size of Robots. If the robot stack size was reduced to 10 or 20, that would help solve this issue.

[Deadly-Bagel]

A "desired number of robots" would also be a beneficial feature or could be tied into this one. Quite often I have storage chests throughout a factory and a point that I would enter range. Robots pick up stuff from the chests and cart it to me, then dock in the nearest Roboport remaining inactive for quite some time.

When I next enter range, the robots have to fly all the way down the factory, pick up the items and bring them back, essentially doubling the response time. There are several other situations this can happen as well, such as building a Solar grid, the Construction Robots will always dock in the Roboports right up by the Solar Panels where they will literally never be able to do anything without flying back to base first.

I kind of feel like adding a slider or number field for this would feel tacky, but if a Roboport has one of these filtered slots then robots could prefer it over non-filtered slots. Combine this with the ability to lock out slots entirely (as we can with chests and wagons) and that should be able to tackle any situation.

[ssilk]

There are some thoughts I have made meanwhile and I want to share:

If you have the issue, that the robots need to transport things only into one direction, then - well - I can ask the question, if you use the robots right...
Because you can solve that for example simply by moving other items into the other direction. Or using belts instead.

The idea to have a default value of robots in each roboport is old. And would be simply implemented (if I can order a single robots to do some job), cause all you need to do is to look into all roboports, and if there is not the average available robots in the roboport searches for other roboports, which have too much in and order them to fly to this roboport.
But on the other hand: This will optimize the bots eventually too much. The fun is to find your own solution. If the robots just simply work, well, then I'm not sure, if that is useful. We need some mod first, which simulates this. But there is currently no API for the bots to make them doing, what's needed to test that.

And about changing the default number of robots for each roboport yourself: That is a direction, which sounds in my eyes again too much into micromanagement. But that is also, what I would like to test with a mod.

[Deadly-Bagel]

Yeah I agree, that level of micromanagement is a bit far which is why I would just say you can lock slots to a robot type and robots will prefer Roboports with those slots.

As for using them as intended, well, in my last big game I had Storage Chests at the top of my base where I was likely to enter and used Active Providers for everything. This meant the robots were always at the top of my base (after dropping something into storage) and were only picking up stuff from storage so it worked quite well. However in my most recent game (Bob's Mods) I had outposts with individual Logistics Networks that fulfilled personal logistic requests, usually stuff like belts or crafting machines. The problem was I couldn't use Storage Chests, I needed to use my auto trash for wood and artefacts but these could only go to specific depots so if every depot has storage chests they would quickly fill up with junk those outposts couldn't use.

There are other examples as well, when you've got oil unloading handled by the logistic network it's not convenient to have it on a separate network, but when a train arrives you want robots nearby to handle that. If you've triggered a large logistic request at some point (eg walked in with 5,000 wood to collect) then your robots have to take a long journey back. Unfortunately there isn't an easy way of manually moving them back as well, you would need to set up a chest to request (missing robots * stack size) but then you need to detect when the robots are moving oil and somehow get rid of the items you're requesting (since if you just put them into a provider chest the robots you've just retrieved will take them away and park up by your storage again).

[ssilk]

Yeah, I think I understand what you mean. In my current game I have those outposts, too. The problem with the wood etc. I think I solved by using logistic trains mod to bring that items to the central storage.

But what is really needed is different networks: one network to handle the garbadge one for the ores, etc. Either with logistic bots or with logistic trains... not that much difference...

[ssilk]

I added this to viewtopic.php?f=80&t=18093 Roboport/Logistic Network/Robot enhancements
below "Handling of the Number of Bots in a Network".

[Deadly-Bagel]

Yeah, I think I understand what you mean. In my current game I have those outposts, too. The problem with the wood etc. I think I solved by using logistic trains mod to bring that items to the central storage.

But what is really needed is different networks: one network to handle the garbadge one for the ores, etc. Either with logistic bots or with logistic trains... not that much difference...

Many of my outposts didn't have room to load extra stuff onto trains =/ Bob's Mods has a lot of stuff. I did consider having a train that collected all the junk but it's a fair bit of work and contributes to the initial outpost setup, takes up room, and there's a bunch of problems that come with it, not least of which that you either need to filter the trains (limiting their capacity for any one trash item) or have a dedicated stop for them which takes up a lot of space.

Yes we could implement split roboport networks or whatever that solves that particular problem but the original suggestion solves a bunch of logistic problems in a relatively simple (?) manner.

[TI-89]

The thing is that all these suggestions (and trust me, I thought I wanted many of them before I learned to reason about the way things currently work) add complexity but not functionality. I don't think there's much that's not possible in the current system. But it takes some care in how you choose to manage things to get it working well. I think this is good; while factorio seems to be moving more towards sandbox style, it still has a core based on survival / exploration themes. I think that some things should feel kinda clumsy at first, because being stranded on this hostile planet means one has to rely on what one has available. But the only true limit on functionality should be the player's ingenuity.
In other words, you have the tools to solve this problem. Many things get tricky pretty quickly when you try to maximize performance, but you can always improve by adding complexity to your designs. Some of the more finicky problems involve handling multiple handling mixed resources. But there are many ways to address this. I haven't totally found one that I like yet, but the simplest way is with train conditions, waiting for inactivity. However this can cause trains to travel when it's not actually necessary. But to address this, I can add a dedicated train for the resources which often cause trains to have space leftover (in particular, wood and alien artifacts), or I can use circuit logic. This leaves a huge number of options as well, from controlling inserters to controlling requests, to adding custom logic to tell the train when to leave.
The key though is that different resources flow in different ways. Any universal solution will have inefficiencies, up to the point where the game just manages it for you. And if there's no challenge, I'm not sure what I'm building this virtual world for.

[TI-89]

Also the idea of having to manage different networks for different resources totally goes against how the logistics network operates. It is the only class of transport in the game that can handle any number of resource types with ease. I had the idea of virtual networks at first, allowing certain resources to flow between networks as specified, but this is not functionally different from having two separate logistics networks with a requester -> provider between them. Which is functionally the same as requester->belt->provider or requester->train->provider.
This also solves the problem while allowing precise control with existing game components. For example, if you use a fast inserter, it will constrain your throughput. This means the maximum throughput for a chest uses four stack inserters (and really it takes quite a network to meet this limit). If you need more than this, you need another chest. Which means that the throughout between networks is hard limited by the size of the interface between them. Or your train network if that's how you link them.
Not that I think there are no useful changes, but the only things I see as crucial are improving the construction/logistics distinction (why don't touching construction networks link?), creating more clarity in general as far as logistics operation and options for improving performance (aka in game tutorial), and improving tools for players to document and share their solutions on the forums and the wiki (Screenshot only get you so far).

[greep]

Unless I'm mistaken, couldn't this also be "solved" by increasing the bot limit instead? Instead of 7 stacks of 50, 7 stacks of 999. The thread someone made regarding lowering the stack size was about recharging, although I admit I'm not sure that's even how recharging code works. I personally don't find this an issue in vanilla as I end up overproducing on roboports for recharging reasons and a lack of need for more than a few hundred con bots, though.

[TI-89]

I just realized, I was addressing "junk trains" but not the original topic of the post. Filter slots also are not necessary. Active management is possible, but approximate. This creates a complex optimization problem without a precisely calculable solution, and thus infinite tinkering and improvement is the only way to improve. Rather than a filter slot though, I suggest using a filter inserter into an active provider.
Currently one of the more restrictive mechanics is the inability to perform logic on the contents of a particular roboport, so my solutions for this are clumsy still, but not ineffective. But in the current system you can use filter inserter to make a particular port logistics/construction only, and requester + inserter to always have the port filled with bots of the type requested. But I have not found a way to manage ports effectively allowing either type of bot, except in networks small enough where the robot count can be controlled precisely.

[Deadly-Bagel]

Rather than a filter slot though, I suggest using a filter inserter into an active provider. Currently one of the more restrictive mechanics is the inability to perform logic on the contents of a particular roboport, so my solutions for this are clumsy still, but not ineffective.

What, are you going to set this up on every single Roboport you create? This solves the problem of how to remove old bots from the network to upgrade them in the case of mods adding upgrades, but not many of the other problems such as ensuring that particular roboports always have robots in them. As you say we can't even detect how many robots are in a particular roboport, I have a (somewhat messy) solution if we could but we can't.

But in the current system you can use filter inserter to make a particular port logistics/construction only, and requester + inserter to always have the port filled with bots of the type requested. But I have not found a way to manage ports effectively allowing either type of bot, except in networks small enough where the robot count can be controlled precisely.

This doesn't work though. Say with the oil unloading example, you want to ensure maybe 20 bots are available to move oil barrels around but you have no way of telling how many are in the roboport so you can only fill it up to 70. When robots are dispatched to move the oil you can only fill it again to 70, meaning the robots you just dispatched have nowhere to dock, and all you're doing is slowly increasing the number of bots in your network until they've got nowhere to go at all.

I'm not saying there aren't solutions, you could have a second roboport that you take the bots out of to put back into the first one to try to mitigate the increase but then you need a system to ensure you don't catch extra robots and take them out of commission. You may also want something to prevent overproduction, just because I occasionally walk into base with 10,000 items in trash slots doesn't mean I want 5,000 robots.

It's not that it's complex, it's that you've got a toaster and you need to use it to iron your shirt. Sure, it's possible, but the solution is just so complex and requires so many bandages to get it working that you just wear the wrinkly shirt.

[bobingabout]

TI-89... I think you miss the point of the suggestion.

The main idea is that by setting a Construction Robot filter to the inventory slot inside the roboport, that basically says "I would like at least one stack of construction robots inside me whenever possible".
Similarly, with a logistics robot filter, it requests a stack of Logistics robots.

This means that when a robot decides to park in a roboport, it will prioritise those roboports that have an unfilled slot of it's type.

If you set every roboport to have 1 slot filtered for Construction, and 1 slot for Logistics (Which would be saved as part of a blueprint, and therefore easily reproducible) this means that at any one point in time, every roboport should have at least 1 construction robot and 1 logistics robot within it. So when a request happens, nearest roboport can deal with it.

Current situation is that if you had a construction project at the far north east corner, all the construction robots will dock at the nearest roboport and pool into that area of the base. When there is a biter attack down in the south west... a Construction robot has to fly across your entire base to get to it, which can take a long time.

If the filters were implemented, and set, then when the construction job finishes, the robots will distribute themselves evenly, so when the biter attack happens, robots would be on hand.

Similar happens for Logistics drones, they pool into the roboports near the destination of the latest surge, hence filters to request them to be distributed.



The fact that it requests specific robots has the secondary benefit to my mod of being able to request lower level robots to allow easier removal from the network. Of course, this also has the complication that you'd have to go and replace the filter on every roboport with the newer tier robot.

[TI-89]

Rather than a filter slot though, I suggest using a filter inserter into an active provider. Currently one of the more restrictive mechanics is the inability to perform logic on the contents of a particular roboport, so my solutions for this are clumsy still, but not ineffective.

What, are you going to set this up on every single Roboport you create? This solves the problem of how to remove old bots from the network to upgrade them in the case of mods adding upgrades, but not many of the other problems such as ensuring that particular roboports always have robots in them. As you say we can't even detect how many robots are in a particular roboport, I have a (somewhat messy) solution if we could but we can't.

It depends on the level of control you want to have over the network. The thing is, the logistics network behaves differently at different scales. Basically you can think of ports not attached to providers as "passive" or "un-managed" and those with inserters as "managed". In a small, high bandwidth network, you're probably going to want to manage all of your ports, because otherwise you could have thousands of bots accumulate in a tiny area. This is the classic example of a train station (or other sorting area) which has surges when a train comes, but may slow down at other times.* It's possible to precisely control bot number in such a network with circuits. One port has requester+inserter, with condition to insert if there are less than 50 bots available. All others have inserter+provider. Generally, this network will reach equilibrium with 50 + [bots in flight] bots.

In a large network though, I can't just look at bots available, because they might not be nearby. And I can't just look at total bots, because the total number necessary may fluctuate. Though incredibly frustrating while the solution is not clear, this actually creates an interesting mechanical restriction once you figure it out. Instead of precise reasoning about the number of bots, you have to reason with respect to large scale flow of bots.


The biggest problem with filter slots is that it adds a configuration setting to every port -- if you want to change it later you have to change every single one, or make a new blueprint and rebuild. But if you say, "this port should have bots" you create a positive flow of bots to that port. As you noted:

Say with the oil unloading example, you want to ensure maybe 20 bots are available to move oil barrels around but you have no way of telling how many are in the roboport so you can only fill it up to 70. When robots are dispatched to move the oil you can only fill it again to 70, meaning the robots you just dispatched have nowhere to dock, and all you're doing is slowly increasing the number of bots in your network until they've got nowhere to go at all.

The problem is, you have an inflow but no outflow. Of course this will happen. If this is all you are using the network for, disconnect if from your large scale network. Then you can remove bots when available is above 50 (for example), and it will fluctuate just the way you want it to. Bots will go in when there's demand, then be removed when it drops. I mean if you want to insert a new bot, it has to come from somewhere. Obviously reading individual port contents would just let you do this in a large network, but then theres no challenge or trade off involved. Logistics is so powerful already, the only thing you really have to manage is latency in large networks. So why should there be a new game mechanic to solve a problem which the player has the tools to solve?

It's a lot harder to mange things in intricate detail when you make one giant network, but I think that provides a nice trade off with respect to how the whole system works. If you want precise control you can have small networks and link them together, but then resources can only propagate through them one by one (and require precise control of quantity to avoid overproduction), not just fly automatically to exactly where they need to be. If you want things to be automatic, there's a much higher latency, but by nature of the number of ports needed to make a large network you usually have some pretty damn good throughput.

Current situation is that if you had a construction project at the far north east corner, all the construction robots will dock at the nearest roboport and pool into that area of the base. When there is a biter attack down in the south west... a Construction robot has to fly across your entire base to get to it, which can take a long time.

This is exactly the choice you have to make in managing your network topology. Construction needs fairly high throughput (lots of items to place, no stack bonus) but because you can place and walk away the latency is not critical. In a defense network, you want everything to be available right away. Thus defense networks should be small (I have a dedicated one for each wall essentially), and should always be partitioned from your more wide-area coverage construction network. You can still use your larger network to supply the walls as well, you just need to maintain a small buffer to account for the extra latency in having items delivered. Which is automatic if you use requester->provider at the interface of separated networks, and set chest filter to restrict insertion amount. Max throughput depends on 1) request size, 2) network delay, and 3) class of inserter used.

This also applies to 'managed' roboports -- the number of bots they can deploy (or that can dock in them) per second is constrained by the number/type of inserters used and the number of bots that are 'provided' for them to insert. But when you talk about bots pooling, you are observing a pattern of traffic within the network you have created. A uniform distribution of bots (which is what you will get with blueprinted filters) is optimal for a completely random pattern of requests. Pooling does not occur with random bot movements. But you can optimize your network by creating a 'drain' where pooling occurs. How many active providers you need (rate of outflow) depends on the rate at which bots attempt to dock (rate of inflow). Unlike a port which you are loading, the charge time is the main constraint on outflow, not inserter speed.

It's not that it's complex, it's that you've got a toaster and you need to use it to iron your shirt. Sure, it's possible, but the solution is just so complex and requires so many bandages to get it working that you just wear the wrinkly shirt.

This is great, and a pretty accurate description of how it felt trying to figure it all out. But I think that the biggest problem is that it's not yet clear how exactly this should be done. But I think that if people start experimenting and sharing on forums, it will very quickly become clear how powerful the current lognet is.
But my point is, the tools to optimize the performance of networks large and small are available. And I think it is better for the community to learn to solve it in terms of existing game components, then ask for tweaks, than to have devs solve it for the community, then run into issues where it doesn't work as players want it to. Because there's a whole host of decisions to be made on when a robot would decide to leave one port and enter another. But the probabilistic nature of the current problem is great for infinite style play, where you can always eke out a bit more performance if you fine tune your solution. And I think the people who enjoy that are largely the ones building roboport networks large enough to run into these problems.

But the way to achieve a passable solution needs to become much more clear to players before it is time to fine tune the game mechanics.

* Not that this has to be managed, you could just select how many bots and put them in the network. But in my system bots are shared globally, each network can essentially acquire whatever number of bots it wants. So the total number in each system will vary with network load. This takes some overhead in management, but I find it worthwhile I guess.

P.S.: I'm so honored bob just replied to me. I used your logistics mod for my first round of experimentation after getting frustrated by vanilla logistics (though as I found out it doesn't hugely change the mechanics). But an array of robochests emptying into providers provides a lot of outflow: http://i.imgur.com/tHfE505.png. The idea is that this allows long-distance one way flows by having robots bring back other robots. The stack size bonus in particular makes this hugely effective, because you have a fraction of the number of bots flying back.

[Optera]

+1
Even with splitting them into segments my bot networks keep getting bigger and bigger.
I'm using mods to greatly boost speed of bots, otherwise they would take minutes to get to some rarely used spots in the network. However they still fill up all roboports around heavy trafficked drop off points.

[bobingabout]

See... one of the issue with splitting the network is that... how do you get the supplies needed for repair to the robots in the first place? one big network means that everything is somewhere in the network, even if it isn't at hand. If a robot needs to grab a repair pack... well, currently, the nearest construction robot could be anywhere in the network, with my suggestion the nearest robot would be... in the roboport nearest the chest with the pack in it.

You could use some sort of belt system to bridge the two networks together, but then you have a way more complex system to set up the control of quantity of items.

Also... you mention inserters. This idea has nothing to do with inserters putting robots into the network, the entire idea is about where robots choose to dock after doing work.

[Optera]

See... one of the issue with splitting the network is that... how do you get the supplies needed for repair to the robots in the first place? one big network means that everything is somewhere in the network, even if it isn't at hand. If a robot needs to grab a repair pack... well, currently, the nearest construction robot could be anywhere in the network, with my suggestion the nearest robot would be... in the roboport nearest the chest with the pack in it.

You could use some sort of belt system to bridge the two networks together, but then you have a way more complex system to set up the control of quantity of items.

A belt system is exactly what I came up with for connecting networks first. While it keeps bots in check throughput is so terrible I rather use one huge network.

belt bridge

2016-03-15 10-28-42_1.jpg (750.39 KiB) Viewed 11150 times

Currently I'm using a single network with speed modded bots and magazine delivery to have items available right where they are needed. HAving bots right where they are needed would make it very responsive.

Magazine Delivery

Magazine Delivery.jpg (229.02 KiB) Viewed 11150 times