Factorio Forums

First to be clear, i do not mean the amount of "Available" robots since it has already been implementetd in the recent patch. I mean that the content of one specific roboport shoud be readable through a circuit network.

The reason being that if you had this information then you could for example pick and chose in wich roboport all your robots should be available (with help of chests and inserters) and in wich roboport they should'nt. Also if you would like a roboport to only have one type of robot then this could also be constructed.

The first time i ran 0.13 and discovered this i was confused that is was not implemented, but that the"available" information was, i can see a lot more use of the informations on one specific roboport contents than the total amount. Also, if you had the information on one roboport then the information on all could be constructed with a network.

Is there a balance issue? or something else that i have missed?

Changed subject.
Also I put this into viewtopic.php?f=80&t=18093 Roboport/Logistic Network/Robot enhancements
See below "Handling of the Number of Bots in a Network"
Sister threads:
viewtopic.php?f=6&t=8925
viewtopic.php?f=6&t=10152

See also viewtopic.php?f=80&t=19991 Collection of ideas around robots and self-moving objects

...

Yes. This is one method (let the logistic bots make the right distribution), but I think the devs-plan is, that each roboport can say "I need bots", and then the free robots fly to this roboport themselves.

Would be much easier and faster?

each roboport can say "I need bots", and then the free robots fly to this roboport themselves.

Okay, that would work, but there are two issuess with this.

The first is a practical one for the devs, as i see it; either the devs could design a system that would spread all the bot evenly and automatically or you could send the contents to the network and let the player do it themselfs using an automated network. If you ask me the second option is a win-win situation since by letting the player solve the problem; one does acually have to think out a plan and invent an solution(ist that the purpose of the game as whole?) and secondly this seams to be way quicker to implement by the devs.

The second one is that if i may paint you a problem; lets say that we have a base and the player, coming from outside the logistics range and would want to dump resources from the inventory trash slots to the storage network. if all the bots where evenly distributed to all roboports then it would take time to fly over to the player from the other side of the base or in the "transit" zone and pick up resources. If however the player could chose where all bots would be i.e. the edge of the base, then dumping resources would go much faster. Alot more problem solving could be done if this was available.

I guess all i want is to be able to read the contens of one roboport like you do with a chest, it may seam like a small implemation but the applications would be huge! i have alot of more ideas how you could use this if it was implemented.


Edit: I scoured through those threads but the suggestions that was presented seamed rather vauge and hypothetical compared to mine, i think you could solve some of those problems using the tools provided ingame if you could implement the ability to read the RP content.

Roberth wrote:either the devs could design a system that would spread all the bot evenly and automatically or you could send the contents to the network and let the player do it themselfs using an automated network.

I see the point.
Well, to implement such ideas to be really working reliably it takes much time. That can be seen with the past of Factorio development. SO:
Step 1: Implement even distribution of robots (Free robots / Number of Roboports = Number of Bots in a roboport)
Step 2: Implement weighted distribution (see viewtopic.php?f=6&t=8925 )
Step 3: Implement own distribution by using ideas out of this suggestion.

The idea is basically: improve in small steps. Every of these steps is better than NOW, so they improve always game-play.

lets say that we have a base and the player, coming from outside the logistics range and would want to dump resources from the inventory trash slots to the storage network. if all the bots where evenly distributed to all roboports then it would take time to fly over to the player from the other side of the base or in the "transit" zone and pick up resources. If however the player could chose where all bots would be i.e. the edge of the base, then dumping resources would go much faster. Alot more problem solving could be done if this was available.

Right. But currently the problem is, that there are just NO bots at the borders. Or ALL bots. Depends on how weighted your logistic network is (weighting out a logistic network (so that no bot needs normally to run empty) is in my eyes an art ).

I guess all i want is to be able to read the contens of one roboport like you do with a chest, it may seam like a small implemation but the applications would be huge! i have alot of more ideas how you could use this if it was implemented.

Well, I don't see, why boths methods could not be implemented. They can exists in parallel and are useful. What I really want is, that the player don't need to micromanagement the bots in his roboports. I think the logistic should work itself in a more or less optimal state. But he COULD, if he wants to, to optimize special stuff!

I mean also that is the difference between your idea and mine, mine (viewtopic.php?f=6&t=8925) works automatically, yours need some kind of configuration.
And also: Between all those ideas is a lot of space. For example I can imagine also a micromanagment, where you input the number of robots, that a roboport SHOULD request, instead of inserting the bots via inserter, and the bots fly to that roboport themselves. Small, but important difference to this suggestion.

I scoured through those threads but the suggestions that was presented seamed rather vauge and hypothetical compared to mine

Well, that is, because they are much, much older.

Keep in mind that bots are not the only thing that can go into a roboport - you also have repair packs that have slots there too. So there is more to this request than just managing bots.

Right now we have two options once you connect a roboport to a circuit network:
1. read the contents of the logistic network
2. read the available and total bots in the system

What we also need is:
3. read only the contents of THIS roboport (bots and repair packs)

Seems to me like a fairly simple thing to add to the game. Certainly this would seem to be a lot easier than implementing some kind of "roboports as requester chests" system.

EDIT: it would also be kind of handy to be able to choose a different one of these selections for red and green wires. Right now whatever you choose will be used for both red and green, if you want both sets of data you have to connect to a separate roboport.

Kelderek wrote:Seems to me like a fairly simple thing to add to the game. Certainly this would seem to be a lot easier than implementing some kind of "roboports as requester chests" system.

Hm. Game development is about game-play, not simplicity.
In this sense: These are just ideas. In some cases they work without changes. In most others not...

I'm sorry, it seems, that I pressed EDIT instead of REPLY, and so I overwrote/deleted this post somehow yesterday... Hadn't had this since more than a year now. Sorry again, but it's just the number of posts, that make such stuff happen. For the edited points: I didn't delete anything, there was just another paragraph above (which wasn't that important in my opinion, so I didn't quote it). So this resulting post is just a bit of accident, in my opinion too less broken to ask for the backup. -- ßilk

Interesting comparison.

I added my points to your list (in italics):


Ability to read the contents of one roboport to a circuit network.

Pro
+Gives the ability to manipulate the inventory of all the poboport content.
+Using a curcuit network gives you the ability to manipulate the numbers exatly how you want them, wich solves more than the robot distribution problem.
+Gives a creative challenge by letting the player solve robot distribution problem. (doesnt this give more game-play and the point of the game as whole?)
+Less effort to implement for the developers. [Very questionable. You cannot know this, cause it depends on the allover plan.]
+Can still be usefull even if the other method is implemented.

Con
-Must be configured for the first roboport you build. (On the other you just use blueprints) [you can reuse a blueprint from a former game]
-Takes more space in the world since you need a curcuit network with combinators etc.
- Micromanangement still needed, cause not connected with other roboport. The circuit system is not able to calculate and coordinate the "right" distribution (only with very much effort).
- Number of signals can get quite confusing with installed mods.


An automated robot distribution system.

Pro
+Takes less space on the map.
+The system runs as soon as a roboport is built. [should be an own research]
+Might be usefull for one of the few configurations that is not possible to build with a network.
+ It is a needed step for routing the bots in the logistic system. (see viewtopic.php?f=80&t=18093 -->
Handling of Robot-Routing / Pathing)

Con
-Not all of the inventory can be manipulated.
-Still limited to the minority of problem it solves.
-Takes alot more effort to implement for the developers. [again bad argument. And they need to do something with the routing of bots, see above]
-Takes away the creativity by dumbing it down, also makes the unpopular curcuits components even less usefull. [Also bad argument. You cannot know, how and for what this will be used. You need to see that in a much broader context. ]

Well first i wonder how you can argue that you can not know how much effort each of the suggestions would take. The way i see it if you would just ad both system straight up it would be the following implemation:

(Improvised programing setup)

Send contents to the network.

- read construction robots.
- read logistics robots.
- read repair packs.
- send the information.

Automated system.

- read construction robots.
- read logistics robots.
- read total logistics robots.
- read total construction robots.
- read total robots.
- compare to total robots (global).
- compare to total robots (local).
- read the settings for this roboport.
- send for robots.
- call for robots.
... and a lot more to it that i probably have missed.

- Micromanangement still needed, cause not connected with other roboport. The circuit system is not able to calculate and coordinate the "right" distribution (only with very much effort).

I wonder why in any case the roboports needed to be connected to each other? the need of bots is limited to the local logistics/construction area of each roboport and if you need to know the total amout of bots then it is already implemented as of this patch (0.13). For micromanaging the settings on each roboport you could just have 2-3 blueprints with default setup for each required need; one for a lot of bots and one for no bots etc. Also, blueprints are still needed for setting up the automated system since one individual built roboport cannot know how much bots it is going to need.

+ It is a needed step for routing the bots in the logistic system. (see viewtopic.php?f=80&t=18093 -->
Handling of Robot-Routing / Pathing)

I cant see how this is relevent, each of these system could be implemented independent of how the routing/pathing problem is solved.

You cannot know, how and for what this will be used. You need to see that in a much broader context.

What i meant is that in one hand the the player can build the system(creativity) and in the other the devs can build part of that system(not creative for the player). Of course i cannot know how this will be used, but the thing is that you can have the same system with both solutions so unless the "automated system" would alow for some creativity where "read contents" system would not then the "read contents" option would be more creative thus far.