Interface and mechanics suggestions for robot networks

[Ghosty4]

Robot networks do a wonderful job of simplifying the micromanagement parts of the mid to late game, but there are some aspects that are themselves awkward and add in more micromanagement. I'd like to list some of the problems I've had and suggestions as to how to fix them:

Firstly, if robots and repair packs are being automatically created, it's easy to lose track of numbers of items and with them the most effective ways of organising them.

I'd like to propose that Construction Robots, Logistic Robots and Repair Packs that are actively being used in robot networks have a special listing in the contents window for the logistic network, separately to their listing as regular items.

To clarify, while the number of each item present in storage/provider chests in the network is displayed, this would be a separate entry for those robots/packs actually being used in the network. Here are some common problems this has caused in my games that I feel this change can solve:

1) When initially automating construction of various robots, I can either continuously add them to the network by directly inserting them into roboports (with no fine control over how many I eventually end up with) or I produce them like regular end products into chests (with no means to gain gradual benefit until the entire batch is done), I'd prefer to construct and add them automatically, while still being able to set a limit on production.

2) Over time and through expansion, outposts for mining are created, which will usually have a single port for automated repairs and over the course of time the odd robot and repair pack will be lost/used up and any system of resupplying these outposts has to be manual, as an automatic method will have no ability to register a change in the contents of the roboport or network. I'd prefer to be able to signal how many I want in a network, so that a train or some other automated transport can travel around resupplying each outpost without ending up massively oversupplying each one in turn.

3) When my main base becomes a huge network of interconnected roboports, it becomes next to impossible to determine how many construction robots or repair packs are actually present, as it involves manually checking and noting the contents of each port and hoping nothing requires the attention of them in the meantime, which is close to never unless you have very light alien settings. Logistic Robot numbers do appear in the listing over any logic network component, but those numbers aren't directly readable by the logic network itself. I'd like a simple way to know how my robot network is doing that fully informs me of it's contents.

These aren't strictly serious issues, since there's various work-arounds, but it seems that the underlying code to solve them already exists, logic networks already indicate the number of logic robots, construction robots (added to the total number of logic robots during de/construction work) and repair packs (since there's alerts for when numbers of packs are missing). I would just like that information to be usable by the network itself.

[Ghosty4]

Secondly, in the context of a construction network, there are only a few components, with warnings for any that are missing, such as robots, repair packs and any items themselves that should be placed down. There is just one part of the network that doesn't give warning:

My second proposal is that there should be an interface warning for missing or lack of space in storage chests

Commonly in my games I form an outpost by placing down a roboport, a storage chest full of needed materials, a few construction robots and use blueprints to first remove any trees and then to place the outpost I need. In the admittedly rare but possible event that all storage in that network has been used up due to my own mistakes or simply a huge density of trees that are removed, the robots will usually halt in place once there is no longer available storage, usually making them perfect targets for wondering aliens and the only alert I have that this has taken place is the warning that my robots are indeed becoming crawler fodder.

Similarly in huge bases, it's possible to chew up large numbers of my construction robots with various deconstruction work only to find they've been unable to find storage space when they aren't available to help with repairing against a severe attack, usually long after finding out would have been useful.

Again, since the robots have the behaviour coded to simply stay still, there must already be underlying code to indicate when there's a problem, so it should just be a simple change that is needed to solve this problem.

[Ghosty4]

Finally, my only suggestion that involves directly changing mechanics of the game is to do with expansion and the logic of how robots choose locations to retrieve or send items.

A Requester Chest is an essential part of the network, but by its nature can only be the end point of a logistical chain, if you want materials gathered for the purpose of construction, or simply to sort out huge messes of storage chests, you cannot use requester chests in the process without leading to infinite looping of requests, since the materials brought to it must be placed into a provider or storage chest to be used by construction robots, potentially leading to them being requested to be moved back to the requester chest and so on and so on. Similarly, the current system of storage chests isn't particularly beneficial to construction or deconstruction, as storage chests aren't chosen by proximity, meaning that a laser tower creeping strategy can be undone by an electrical pole needing to be grabbed from the other end of the base.

My third proposition is to create a "passive requester chest" analogue for the purpose of sorting storage chest output and aiding construction efficiency

The aim would be to have a method to request items, but in such a way that those items can themselves still be considered part of the construction network.

There's two ways I can think of to achieve this:
1) A priority system that a "passive requester" type of chest is filled between "active" requesters and storage chests when delivering materials, but doesn't allow materials to also be taken from it by logistic robots, only construction robots.
Or
2) A "construction" chest that is usable by construction robots only and provides a kind of read-only function for the logistic network, so it could be filled by a regular requester chest inserting into it without making a loop.

I've struggled with how to best implement this suggestion and I'd love to hear other ways to make this work.

(Edited for clarity)

[ssilk]

Can you please stop posting your own follow ups? thanks.
You know you have this nice "save draft" below the editor?

[Ghosty4]

Sorry, I was working off the "one suggestion per post" rule in the Read This thread and seem to have misinterpreted it.

[ssilk]

Lol. sorry. One suggestion per thread. A thread is this conversation. A post is one ... erm... post in a thread...
Nice that there are some, which read this.

But when I'm on it:

1: yes. I want to see exactly how many robots are doing what job.

2: I think this is a very good idea.

3: I don't think that adding new types of logistic chests solve this general problem. They won't. I think currently again a lot about this problem and I think this problem can be solved by
A) introducing "colors" for separating logistic network (to connect a logistic network the both areas need to be near enough AND have the same color).
B) we need a fourth transport system, which is most useable to spread low to medium number of items (1-500) over large, large areas, tries to figure out the needs in the logistic networks it should deliver and fulfills them as good as possible, and very, very fast, but also very, very expensive.

I think we have here a mod about teleport chests... Something like so, but instead of the "air" which transports the item, this should have a medium, some teleport control or so.