Smart chests / better networking

[Factoruser]

Smart chests should have filters that are working for requesting items. An inserter only inserts those and as much items as are requested like in assembling machines or furnaces. A smart inserter could be forced on the other hand to put in as many and any items (smart inserter's filter) until the chest is full.

Any smart inserter connected to a network could be activated, the long specific items are requested by chests in the network.

- Pure convenience suggestion. It could be already done with the wires, but it's much more complicated, especially if you just want to tell an inserter how much of one item type you want inside a chest...

[ssilk]

Could you please rewrite that, cause I think you're mixing smart chest with requester chest.
https://forums.factorio.com/wiki/inde ... tle=Chests

Also I do not understand the role of the smart inserter here. Maybe this should be an extra suggestion?

[Factoruser]

I'm suggesting that smart chests should work similar to requester chests; but for the wired network. Further, that inserters are considering the chests' request settings - or ignore them if you properly set up a smart inserter for this.

[bobingabout]

I'm suggesting that smart chests should work similar to requester chests; but for the wired network.

you do know you can use requester chests on a wired network, right?

[ssilk]

Sorry, this is total irritating for me. I really don't understand this.

I try to say with my words:
A smart chest that tells a smart inserter somehow, how much to insert.

So what is the difference to a requester chest in a logistic network?

[Factoruser]

Inserters are ignoring the requester chests' configuration. They fill them simply like a wooden chest. This should be changed. And smart chests should be like requester chests, but not working for the logistic system, just for neighboured inserters.

[ssilk]

Inserters are ignoring the requester chests' configuration. They fill them simply like a wooden chest. This should be changed.

Why? They are thought to be filled by robots. And should not suddenly behave completely different to all previous chests.

And smart chests should be like requester chests, but not working for the logistic system, just for neighboured inserters.

A request assumes communication. How would you obtain that with this configuration?

[Factoruser]

Inserters are ignoring the requester chests' configuration. They fill them simply like a wooden chest. This should be changed.

Why? They are thought to be filled by robots. And should not suddenly behave completely different to all previous chests.

Why do inserters recognise what and how much to put in furnaces and assembling machines, but are incapable of dealing with smart chests ? And to emphasise: smart chests aren't filled(/emptied) by robots and shouldn't be.

And smart chests should be like requester chests, but not working for the logistic system, just for neighboured inserters.

A request assumes communication. How would you obtain that with this configuration?

There is this flat ribbon cable you're pluggin in between the inserter an the smart chest... How d'you think an inserter knows that a chest is full or something's in it to take it out ?

The big point is: smart chests are currently superflues, except for building requester, provider and storage chests. The same applies to the wired network. The robots are far too OP compared to fiddling with transport belts and inserters.

[Koub]

I find smart chests pretty useful when you don't have a robotic network yet, but want to control what you build. I do use them, even if I tend to switch to passive provider chests once my robotic network is up anbd running.

[ssilk]

Why do inserters recognise what and how much to put in furnaces and assembling machines, but are incapable of dealing with smart chests ? And to emphasise: smart chests aren't filled(/emptied) by robots and shouldn't be.

Ah, well, this kind of communication.
Well, this might look like a bit to quibble over details, but the inserter doesn't communicate! This is how it is working (as far as I understand it yet):
- inserter: What is at the position I would insert?
- If there is a device it looks at the device: what recipe is it producing?
- Device is labeled for example with "electronic circuits". So it knows now - by looking into the list of recipes: "Iron-plate" as stack 1 and "Copper wire" as stack 2.
- Inserter: Looks now at the stacks only. Think about them, as if there are lamps on on the top of assembly, which display the status of the stacks. Some kind of global state, that can be read by any instance.
- Device displays: Stack 1 could be filled, 2 is full/enough in.
- Inserter searches for copper wire (2) on input.
- Device display says "I need now also items for stack 1".
- Inserter searches now also for iron-plate.

So you see: It never communicates with the device. It just looks at it, this is a technical difference. This kind of communication is really, really stupid. But it's fast, which is very important here.

There are the new predefined stacks in wagons. Well: They are a bit more complex. I hope they make it into the game to be able to set them for the chests too. Is it that, what you mean?

But you want to change that to a much more complex system, what I simply label with "Communication". Indeed you want to create "small invisible circuit networks", that do this. I see really problems in doing this, because that would take too much CPU, if this is done for many inserter/chest combinations.

A request assumes communication. How would you obtain that with this configuration?

There is this flat ribbon cable you're pluggin in between the inserter an the smart chest... How d'you think an inserter knows that a chest is full or something's in it to take it out ?

He doesn't! He looks, if something is needed. Some kind of global available information...

The big point is: smart chests are currently superflues, except for building requester, provider and storage chests.

Smart chests are just counters. Sensors. Nothing else. The smart chest and the logistic have no difference, when we are speaking about the circuit network. See https://forums.factorio.com/wiki/inde ... ol/Devices . And you have the stack limitation, that give you a lot of direct control, when used clever: https://forums.factorio.com/wiki/inde ... limitation

The same applies to the wired network. The robots are far to OP compared to fiddling with transport belts and inserters.

Well, make an (<strike>concrete</strike> Edit:) specific example. I really cannot follow, what you mean with superflues and not OP and my current guess is, that you eventually don't know everything about the chests and circuit network.

[aka13]

Ssilk, German-english interference. COncrete means zement, not "specific". A specific example, not a concrete one.

[ssilk]

Eieiei... Always the same stupid mistakes. Thanks for mentioning, I'm really glad about that.

[Nagshell]

Smart chest... I'd love to be able to do on smart chest that cargo wagon/toolbelt thing, where you reserve one spot for exactly one item

[ssilk]

I think a good questin is then: How would you use it. Cause it is not so clear, how.

Think: You can use up to 8 inserters (4 normal and 4 long-arm) to feed/unload a chest. That is extremely complex to built and it won't simply run then. Even with only 4 it is complex. What is needed instead, would be a bigger chest, with more surface (2x2 or 3x3 tiles), that works as a "storage device".

But the question is then: What makes this more useful, than just many storage chests, which are filled by robots?

[Factoruser]

Smart chests are just counters. Sensors. Nothing else.

And they should become requesters for attached inserters. Don't think this would be very demanding, 'cause you only have to check smart and requester chests; noone would use smart chests en masse instead of steel chests, and if one does, it's his problem.

The smart chest and the logistic have no difference, when we are speaking about the circuit network. See https://forums.factorio.com/wiki/inde ... ol/Devices . And you have the stack limitation, that give you a lot of direct control, when used clever: https://forums.factorio.com/wiki/inde ... limitation

Doesn't. If a stack gets "eaten up", you lose your filter effect. Requester chests ensure that you always have all demanded items in stock - if you don't fill them with stupid inserters. The goal is to have a chest automatically filled with stacks of different items; there should be always at least one stack of one kind of item. That doesn't work if inserters are simply filling a chest until all slots are full.

The same applies to the wired network. The robots are far too OP compared to fiddling with transport belts and inserters.

Well, make an specific example. I really cannot follow, what you mean with superflues and not OP

- Typing mistake - "too" not "to". OP = "overpowered" i.e. robots are much much more handy than anything with belts and inserters. You're simply researching robots instead of building something with the wired network. - You'd even do if you'd need alien artifacts to build robots...

To make a requesting smart chest somehow comparable to the requester chest, you need a smart inserter for each item type/stack, putting it in the smart chest, activated, if the stack in the chest is too low. This is extremely complicated compared to the requester chest, which isn't even requiring inserters, belts and so on... - no additional space.

[DerivePi]

Hilarious! Factoruser, I understand your request and I agree that it would be nice to have that additional control. Further, I will refrain from producing quasi-physical, half thought through game rules to defend or attack it.

The way I'd explain it -
Under the current wired system, the smart chest is a counter that can be read by connected smart inserters. In this system, the smart inserter determines individually what to do with that information (ex. if CU ORE < 100 - operate inserter).
Under the robot system, the requester chest determines what the robots do in the system (ex. Requester Chest demands delivery of wood until wood is 10,000). - As an aside, could you imagine how irritating it'd be to have to instruct each robot what to do?

The proposal - allow smart chests in the wired system to request items that the connected smart inserters will fulfill (ex. smart chest tells smart inserters to operate on filtered item(s) until the wired smart chest counters are met for those items - 100 Defenders, 100 advanced shotgun ammo, 50 laser turrets, 200 walls, electric poles, inserters, belts, etc..)

Why? Consider this scenario - Far distant outpost is connected back to main base with a red wire system and a rail network. The player is low on supplies and takes defender bots and ammo from a wire connected smart chest at the outpost. Back at the mainbase, a single smart inserter begins to take replacement ammo and bots from a general storage chest and place it into another, locally located, wire connected smart chest for rail delivery and resupply. Or, even better, you're at an outpost and you need more walls (and you forgot to set up a "Fetch" train https://forums.factorio.com/forum/vie ... ilit=fetch ). You go to the wired smart chest and set it to request 200 walls and then wait for train delivery thanks to a savvy infrastructure and delivery system you had previously implemented.

Further thoughts -
- Do we still want to have local smart inserter controls (other than filters)? I think so
- Does this make the game easier, harder, more confusing? - I don't think it does any of these. It would just add options for gameplay
- Is this really something people are interested in? - In my opinion, not really. Only a few savvy players really get into the wired system. For most, I think the robot system overshadows the more intricate and elegant wired system. Further, the wire spaghetti is very confusing and hard to read. Once the robot system comes along, it becomes too easy to just drop an "In" box and an "Out" box rather than figure out flow controls and belt routing.
- For train deliveries, why not just have an extra wagon loaded with common items? - In response I'd ask Why not implement a better system that gives the player more control?
- I really like the idea of clicking a chest and ordering items to deliver to that chest. It's like ordering a pizza, except that you, as the player, have already figured out how to make and deliver the pizza the Factorio way.

[ssilk]

To make a requesting smart chest somehow comparable to the requester chest, you need a smart inserter for each item type/stack, putting it in the smart chest, activated, if the stack in the chest is too low. This is extremely complicated compared to the requester chest, which isn't even requiring inserters, belts and so on... - no additional space.

I get the reason, but not the point. I mean: How should that look, what you want to build? I underline it: Give us an specific example.

[DerivePi]

This is the mess required to deliver specific items for a wire connected outpost without implementing a wired "requester" smart chest. Even in schematic it's confusing (in game it is way worse and takes hours to build):
- The outer loop - multiple items are cycled around on the outer loop and are removed by filtered smart inserters on the right side (each filtered item is listed on the right - from the bottom: Unique item "wood", walls, laser turret, ammo, etc...).
- Storage Chests - The first column of smart chests are locally connected and are set to receive a minimum amount of items from the main factory. Using a timing loop (not shown), the quantity of items in these smart chests is maintained. On one cycle these chests are filled and counted and on the next timing cycle they are emptied to the left.
- The delivery belts - when the items are emptied from the storage chests, they are belted within reach of 4 separately wired smart inserters representing 4 outpost locations. If any of these wired locations are low on selected supplies, that smart inserter will operate and deliver those items onto it's delivery belt. The delivery belt moves those items down to be inserted into a local chest for later railroad delivery.

Each one of the smart inserters has to be programmed and wired. For 4 outposts, that's 60 smart inserters.

[ssilk]

What do you want to say with this? Do you mean, a supply for an outpost should be made like this, and therefore we need this "feature"
I think this special problem should be solved completely different.

And when you are on it: How should a layout look like, if we had this feature? Cause my imagination with this lost me.

And btw: I never would use this idea you posted in the picture, cause it is just far too slow to make that all by belts. But that is just my own opinion.

[Factoruser]

And btw: I never would use this idea you posted in the picture, cause it is just far too slow to make that all by belts. But that is just my own opinion.

Of course, robots are far much better, the wired network is crap ;-p

If you want a specific example: take any example for a requester chest and replace it with a request-enabled smart chest, belt, and inserter...

To avoid confusion:

• smart chests should have the same interface as requester chests. The difference is, that smart chests are not filled by robots resp. are part of the logistic network
• inserters - maybe just smart inserters - should put in only requested items in smart chests and requester chests, like they do in assembling machines
• you can get and "answer" request informations via the wired network, i.e. you'll additionally have in the smart inserter UI the option "?" (without count) to "<", "=" and ">"

Therefore you won't need the network in many cases; you can simply use belts stupidly and fill chests, but without getting deadlocks because the chest couldn't longer get filled with just one item.