roboports signals should not be exclusive

[mrvn]

Roboports can emit two kinds of signals: The logistic network content and the amount of robots. Why must it be either or? Why not allow selecting both?

[ssilk]

I think it's clear: because then you cannot add that signals simply to others.

If you want to keep this as a suggestion, please try to explain, how you would solve this problem. Otherwise I would move this to won't implement, cause it makes technically much more sense to have it how it currently is.

[OdinYggd]

Its inconvenient in some situations to not be able to access the bot network statistics while reading the network contents and vice versa.

Since bot statistics is already taking place over signals instead of item symbols, it should be possible to output both modes at the same time.


Likewise I see another thread talking about filtering the outputs- could merge that thread into this one.

It would be nice to have some means to deselect certain item symbols or signals from the roboport circuit output in order to avoid conflicts. Right now this can only be done by manually breaking out each signal into an n+0=n combinator and simply not adding ones for the signals that are not wanted.

[ssilk]

Since bot statistics is already taking place over signals instead of item symbols, it should be possible to output both modes at the same time.

Is possible by placing a second roboport.

Likewise I see another thread talking about filtering the outputs- could merge that thread into this one.

The problem is then: Each roboport needs to add the signals internally before he can provide it to any network. That is CPU intensive and a problem if you need to do that for all roboports. And much more: It makes then no sense to configure the output so, that it outputs the number of robots for example as "iron plates", cause that would be added to the existing iron plates. It's then a useless signal, you shrink the possibilites.
This all is not needed, because there is a simple and quite logical solution (2 roboports).
This is also in the philosophy of Factorio: Only such data is created, that is used. See viewtopic.php?f=80&t=19987 More Game Information (Statistics, Monitoring, Graphs)
If you read the first part of that article it explains the reasons for that philosophy.

Maybe you have better reasons? Well, convince me

[OdinYggd]

Likewise I see another thread talking about filtering the outputs- could merge that thread into this one.

The problem is then: Each roboport needs to add the signals internally before he can provide it to any network. That is CPU intensive and a problem if you need to do that for all roboports. And much more: It makes then no sense to configure the output so, that it outputs the number of robots for example as "iron plates", cause that would be added to the existing iron plates. It's then a useless signal, you shrink the possibilites.
This all is not needed, because there is a simple and quite logical solution (2 roboports).
This is also in the philosophy of Factorio: Only such data is created, that is used. See viewtopic.php?f=80&t=19987 More Game Information (Statistics, Monitoring, Graphs)
If you read the first part of that article it explains the reasons for that philosophy.

Maybe you have better reasons? Well, convince me

Of course placing a second roboport nearby is the easy fix, and the way I've addressed this since my logi networks are usually spread out enough that I can dedicate one roboport to regulating the active bot level while the others provide the logi contents to the circuits.

But would it not decrease the total CPU usage to implement the logi => circuit connection such that only the signals the user wanted were being copied into the circuit network? Offer a UI similar to a chest where wee could click on the signals we wanted to enable, and any that were not would be ignored internally to the robport.

You still have to do a foreach iteration on the array of signals, but with this change you could skip the signals that you don't want to make use of, reducing CPU load by decreasing the number of times that the array must iterate to copy the necessary signals.

[<NO_NAME>]

This all is not needed, because there is a simple and quite logical solution (2 roboports).

This is not really a good solution. Roboports are expensive, need a lot of energy and take huge amount of space. They solve the problem by generating a few other.
The perfect solution would be a small, not expensive device that lets you fetch information about logistic network, e.g. another type of combinator. But since this doesn't exist, the logical solution is to fetch all information using single roboport.

It makes then no sense to configure the output so, that it outputs the number of robots for example as "iron plates", cause that would be added to the existing iron plates. It's then a useless signal, you shrink the possibilites.

We just need to have two checkboxes: one for robots and one for logistic chests.

The problem is then: Each roboport needs to add the signals internally before he can provide it to any network. That is CPU intensive and a problem if you need to do that for all roboports.

You don't need to do that for all roboports. Only for those which are connected with circuit network. I think using one roboport to get two types of information is actually faster because the game have to perform some actions only once (e.g. idetifying logistic network).

[Deadly-Bagel]

Wouldn't it make more sense for storage chests to have the option of outputting logistic network contents instead of its own? If I am not mistaken you could even restrict the contents of the chest to 0 slots if you don't actually want to use it for storage.

[ssilk]

This all is not needed, because there is a simple and quite logical solution (2 roboports).

This is not really a good solution. Roboports are expensive, need a lot of energy and take huge amount of space.
They solve the problem by generating a few other.

Sorry, no, in this case it is vice versa.

The perfect solution would be a small, not expensive device that lets you fetch information about logistic network, e.g. another type of combinator. But since this doesn't exist, the logical solution is to fetch all information using single roboport.

Well, a very simple mod would fix this: It adds a roboport, that has no slots and looks like a combinator and is quite cheap would fix this.
I'm sure most readers of this forum would be able to do this, if they take existing mods, that add new roboports.
New types of roboports is so or so needed in my opinion. The devs just need to add such roboports into vanilla and a check, that you don't need to choose the output, if the roboport has no internal slots.

[mrvn]

I think it's clear: because then you cannot add that signals simply to others.

If you want to keep this as a suggestion, please try to explain, how you would solve this problem. Otherwise I would move this to won't implement, cause it makes technically much more sense to have it how it currently is.

The roboport already has 2 buttons to enable the logistics signals and robot counts signals. My suggestion is simple:
Allow both buttons to be enabled at the same time.

If you don't want the logistics signals then don't enable them. If you don't want the robot count then don't enable them. But if you do want both of them you enable both and don't need to place a 100% useless roboport just to add the two.

And while we are at it: How do I get the number of repair packs and robots in a specific roboport? I have to stop the filter inserter from inserting repair packs when the roboport is nearly full or it gets stuck when it can't place all the repair packs it has picked up (the problem with inserters picking up too many items).