Network Inserter

[Tinyboss]

I'd love to have an inserter that would filter based on the circuit network: it will grab anything that has a signal on the input wire with a positive value.

[GopherAtl]

this is on my to-do list, will probably have time to put it together in the next week or so. At the moment, after a week of busy moding (2 fniished and 1 wip released this week) I'm taking time today to actually, y'know, play factorio XD but I'll be back to modding soon, and this is one of the first 2 things I expect I'll finish, got an idea for the how and don't think it'll be too difficult to get working properly, so probably this weekend, possibly tomorrow morning even. I'm leaning towards a sort of emerald or forest green, darker than the smart inserters, which are more of a lime green, assuming it doesn't look too much like a burner.

[Tinyboss]

Awesome! I've just gotten started with modding Factorio, and I've been trying to think of a way to do this without direct access to the circuit network. Apparently we can check an arbitrary number of conditions (e.g. are green circuits > 0?) per tick, yes? So by checking every item in the game manually, we can build a list of items that have a positive signal on the network. Then we can set the inserter's filter to that list of items. I don't know whether we can set more than five items in the filter via Lua, but if not, we could just cycle among them every few ticks, and that would probably be good enough.

Do circuit networks have "blocks" like the train networks? If so, we could do all this testing per-block instead of per-inserter for a massive reduction in overhead.

Is that roughly what you have in mind, or do you know something better?

Also, emerald green sounds great. I don't think confusing them with burners will be a big problem, since burners see very limited usage by the time smart inserters are in use.

Edit: I thought of a couple of improvements. Obviously, if it's taking from an inventory, we only need to check the circuit network for the items it can actually take. And if it's pointed at a belt or the ground, we can look for "item-on-ground" entities in a suitable area and only check the network against those item types. The size of the area and the rate at which we do the update would have to be matched so that we don't miss anything or degrade performance.

[GopherAtl]

oh, no, definitely don't check every item in the game XD That would be... evil. Yeah, like you edited in later, using the source inventory to build the candiate list to test is the way to go. It only needs to update about as fast as the inserter can perform an operation, so I'd try to tune it that way. Unless it's literally picking up off the ground, it can keep track of the entity it's taking from, monitoring events for placing and removing item, and if it is taking off the ground, it's reach is limited to one tile, so searching an area the size of a single tile a couple of times a second shouldn't be too onerous? (if it is, then I'd respectfully urge the devs to optimize that function XD)

[Tinyboss]

oh, no, definitely don't check every item in the game XD That would be... evil. Yeah, like you edited in later, using the source inventory to build the candiate list to test is the way to go. It only needs to update about as fast as the inserter can perform an operation, so I'd try to tune it that way. Unless it's literally picking up off the ground, it can keep track of the entity it's taking from, monitoring events for placing and removing item, and if it is taking off the ground, it's reach is limited to one tile, so searching an area the size of a single tile a couple of times a second shouldn't be too onerous? (if it is, then I'd respectfully urge the devs to optimize that function XD)

What about belts, though? A blue belt can whisk items past pretty quickly. Is there any way to query what's on a belt, or is it all just considered to be on the ground? We could try to get clever with following the belt backward, but inserters could be aimed at it, too, so maybe just checking the tile and the one(s) immediately inputting to it about 10 times a second wouldn't be too unreasonable. We could go slower for red and yellow belts.

I just thought of yet another angle of attack: every tick we check whether the held item has changed from nothing to something. So we know it has just picked something up. Then we check the circuit network for that item, and if necessary, tell the inserter to immediately put it back. Since it's only been holding it for a single tick, it will (hopefully) be able to do that. Seems kind of hacky, but maybe worth a try.

[GopherAtl]

polling the held slot is a good thought; belts are pretty much the worst-case for this, but I think it'll be manageable. Hopefully by 0.13 we'll have a way to test signals values that isn't slightly evil, though in this case we only have to do the one test per item type, so it's less evil than when you need to determine the actual value, which takes 32 tests per signal.

[Tinyboss]

polling the held slot is a good thought; belts are pretty much the worst-case for this, but I think it'll be manageable. Hopefully by 0.13 we'll have a way to test signals values that isn't slightly evil, though in this case we only have to do the one test per item type, so it's less evil than when you need to determine the actual value, which takes 32 tests per signal.

Yeah, surely at some point we'll be able to request it as a table like {"iron-plate"=1000, "copper-plate"=-400, "electronic-circuit"=2}.

[GopherAtl]

hmmm. Belts. More of a problem than I thought.

They kindof have an inventory? but not really. Not an inventory you can get and inspect, except through functions like get_item_count, which will return the number of items in total, or how many of a particular type... but as we discussed earlier, building the list of circuit network values for all possible item times is not reasonable, so we don't know what types to check for on the belt, and therefore don't know what kind to filter for.

I've got something that is not polished or efficient but works with chests and proves that at least that part of it is possible. But kindof against a wall with belts, I hadn't had reason to check before but I knew you could use some inventory functions on them and so just assumed get_inventory could be called on them.

Anyway, yeah. tl;dr: hit a wall here, can't complete the concept at present.

I Could make a version that just doesn't pull from belts, but since I expect the main market for this is people making smarter mixed-belt and passive provider belt setups, I can't see much point in that. Could also make version that polls every possible item on the circuit network to find the signals that are true. That would be insane, performance-wise, so just not gonna do it.

API changes that could fix this, or enable work-arounds:

• being able to access circuit networks, as in get an array of the input signals and their values.
• being able to call get_inventory on belts, or being able to call a get_contents-like function directly on the entity instead of through an inventory returned by get_inventory.
• being able to access "neighbors" through any wireable entity instead of just electric poles - not a perfect solution, but could allow this to work if the circuit conditions had to come from a direct neighbor, worst case I could implement a companion combinator-variant that selects a set (up to 15) possible signals to pass through, similar to my logistic combinator, which are the potential items to filter. Not as flexible that way, and obv requires the special additional entity, but should be workable for the majority of cases, where you are unlikely to want a given inserter to ever pull more than 15 different types of items.

[Tinyboss]

I really appreciate the effort, and I learned quite a bit by reading about what you tried. Thanks!