[Twinsen] [0.15.18] - Disabled/Unpowered Inserter Inserts Hand Content

[marvk4]

I also second this be changed back, or at least be made into a checkbox to switch this new behaviour off and on.

[Killcreek2]

Imho, worst patch since that one that accidentally corrupted savegames ...

I get you're upset, but I think this is a bit of an exaggeration. I was pretty dismayed to find a bunch of my stuff broken too, but this isn't anywhere close to the level of corrupting savegames.

I appreciate that this change gives us finer-grain control of inserters, but it complicates "1 pulse = 1 inserter movement" so much that I really hope the developers can give that functionality back to us with some kind of checkbox in the UI.

Well I did not say "as bad as" ~ I said "worst one since then".
I welcome changes, improvements & updates, but I will speak my mind if I think it is a BAD change, or a step in the wrong direction [like this one is].

This really has broken sooo many useful setups, or made them massively more complex to do. & for no good reason.
Just think about a filter inserter ~ it can now get locked, holding an item that is no longer needed, and unable to pick up a different item type as it's hand is still full. Just one example of many available.

As a redditor remarked: "one tick pulse" to move A to B seems more intuitive to "n tick hold until hand is empty"

[Smokey0815]

As MasterBuilder already mentioned, the classic circuit based train unloading is broken and there are usually quite a lot of these around my base. Just wanted to give an example for this. The bluebrint requires creative-mode: h**ps://mods.factorio.com/mods/Mooncat/creative-mode (sry, not allowed to give you a clickable url on my first post ^^)

Blueprint

0eNrtnV9uo0gQxu/Csz2i/ze5yiqKHLsnQXKwBTiaKPIB9h57sj3JQjw7mWGg9+sP3tiXRHbIj0p1VXXVR1t5zx6Pl3Cuy6rN7t6zcn+qmuzuj/esKZ+q3bF/r307h+wuK9vwkm2yavfSvwrfznVomm1b76rmfKrb7WM4ttl1k5XVIXzL7sT1fpOFqi3bMtyIHy/eHqrLy2Oouwt+sPZ12LXla9i+nA7hob/Ptjld6n3obnc+NR3hVPWGdNStKDbZW/ddd3f6Wh7bUN/g/971E3o6n0O9PR93bciu99fNbwZIzgC3mAGKM8AvZoDmDDCLGWA4A+xiBljOAL2YAY4zQCxmgOcMkIsZUFAGLFcGRM55IF/OAq4ULleIBFcKlytEgiuFyxUiwZVCtZwBXClcrhAJshQuZwBXCpcrRIIqhQuWAaoSLheCkiqEy/lfUmVwuRogqSq4XAZKqggutwtIqgYu14vJzxL4Eg7l5WUbjmHf1uV+ez4dR3P/e/Kp6xjus6B93TXttqyaUHf2RYYK2f0R3QDU1qfjw2N43r2Wp7q/Zl/W+0vZPnQ/O/z4xa9l3bQPv41Jr2XdXrp3ftz8dsU2vIb6rX0uq6fsdpem3fUzV96/eDnv6l3b3yz7+8+/Pi74fstuIQ4Pz7vq0N+87f7Ezr1tfQmfV3z88OOyfrH6wesDX3WuKz+GufdM9F+e6hCqnwex8tA5qeiWYtR7U9X4cDkfy333RvW03T+Hpo34c3xdPL4ubsXrsvnlDZ1PLVSBu9Ov1p124E7pJ9yp8jlx7yJxr8Qcso+RJR4CZgUhUIfDMACUGgSAclMBoHBn2pU6U075Ts8JcRMLcTOHbGNkm9p1CBXDOTx89GrDZ7C3qal48nNWXceWKWHXFGvdNbueY7BQemKhdI67U662CfHDPWiq+dazWgURiXst55BljIzvm8VK654bptNUE6o1nk75WtNJDUckM9WW6DnNQ2yU1XZONsXEC423EW6d2aSH1dRMVlNccPAr9aVDOzJdzIj42HRs5szdseHYiNT+PjYtGHzUNqttG/UwM81ENBk1Y9Fj46LBN1C11mXqVuXXZbJ2apkM7E29Wm8Oh1ozNSuZOU1DTHowcyT72LBsEhT7dW6gZtiL2qkN1ODCg1ypL4eNnZ6Sau0srT4S8HbO/B0bkq1MbEaiVsITd/5/JN2ycmpEsDOE69gYZ+Gdc7VtiB0+mnNTTzot/EB/tRKjGbbedqr1tjOahVgTYmdI9tHKCe+bK33CaYdPON1UA+pgsX613fxk2rgZnUFsYHUzdPlY6+7gHmGlMuJ0lsASwkpPATiFdlduhv4e0wzdjEk6JvI5l9ilx/RH5//rM1PT5+f61TiU9W0xuv1xDF8Q+JtT81/peuzDITlNHxo/ihcE3sO+8ZLAW9g3iqZDvtEE3ozi7RjeEHiN4y2BF/jKOgIvcTyRswUcNwULR8KmYDI2R20vBE2HjCcS1sExWRAJ63H6lIRw3jVN/yJUoX56i3yY6cste/MvZmwfKYiENXDEF0S+KjhqHAuHgoZIVo07hshWiTpG5DlLRzwjciZd4YgXeXq65gn09HRV8LKKPH17lQn09GQ1Y0EzDk/PVY3DHQnHAtKTfsHo6bnqYMeI9FS1OFyQcCiThCT9gtHT87TAHZOeph6Hp2fp9x4Voqen6XgjNk5Pz1OhcHp6ngqJ09PzVODlUaYnqsDro0zPVIEXGZmeqQKvMjI9UwWeqjI9VQWeqzL6+fjXU3kY2bBH02m0iElLCx0S2Jmko/HIxic9LUVA1hc0HrFe5exALIHAUfzICuElazzkGkUbD+E1O29DrjHsvA3RLTsPQ3QiYS1O9+xAjAwfqmDpiO06Z8dtiE5PrIhntGTHbYiuWNshz2jWdohOtMK4YyypE0BwR1oOucWTlkPwghQ4ELeYnNQ3ILggLUfcYiRpOQRXpAABuUWT2gkEZyUlyC2spATBHSk/QG7xpHICwVlBCXGLZQUlCC5IUQZxi5WkKAPBWTkJcgsrJ0FwWk6C/ELLSRDdsbZDnvGs7RC9YKUwxDMuZ6UwiC5Y2xHPOMnaDtEVK7RBdM2KhBDdsHRoVS3rGYjuWJEQ8oxnBU6IXrB0xDPEcSWBdwPEaSWB7x7EYSWBb3yeln4hz9DSL0TnpV8JSL/e0njk8ZjnpV+FOMfTx8QgPC/9InjqtJLC8YI+5AbhJX3IDcIr+pAbhNescg3RDa1cQ3jLKtcQ3bHKNUT3rHIN0QtWuQbokjmwpHC6YLVliC5ZfRaiK1afheiaVDkhuCFVTghuSa0QgjtSK4Tg7GElCF6QihsCJ84qORzOnlWC4JJUfyC4ItUfCK5ZBQWiG1ZBgeiWVSEgumNVCIju2UkeohfsJI/QmaNKeKIyR5XwTJX0vArRFTtRQnRNj3xqOPLdb27/Gevup3+ktcleQ93cLtBamsIIqez1+g87h9H5

[engin33rguy]

I'm in favor of this change being reverted- It broke a ton of circuit setups around my factory. The only way I see this working is if we have the option to choose between which mode we want like others have mentioned. I use a setup similar to what OP had in his "bug" report but you guys already have a way in game to fix it- filter your train wagons! Then you can't get random garbage in it. Now that this "fix" got pushed, the ONLY thing that changes is we don't have to filter wagons. It's not like it improves loading efficiency because the inserter is still stuck holding the "wrong" item over the train wagon that you didn't want to put it into. I fail to see how this fixes anything that using filters in wagons didn't already do. All this seems to have done is broken tons of people's setups because one poster didn't filter their train wagons.

I get that this game is still in alpha and is subject to change at any time, but to be perfectly honest with you this is the first time I've been legitimately disappointed with an update you've pushed. It will take a lot of work to update my base (Especially since the power keeps cutting out and my fuel production is all messed up) so for now I'm rolling back to a previous version.

[DerGraue]

Please revert this change, it broke my entire base

or give us an option to reenable the old setting

[otobot1]

This "fix" broke every single train unloading station I have, my uranium production, and dozens of other things around my base. As mentioned before, the "problem" that the OP was having can be fixed by filtering wagons, or just planning your train network better. Please revert this "fix" ASAP. Until then, I'll be sticking with 15.21 because I can't be bothered to redesign all of my circuitry.

[Mailbox23]

Both use cases don't seem too problematic to me. Like I said, it will break some things but i believe they can mostly be worked around.

I'll keep an eye on this thread. Depending on what people say I can keep or revert the change.

I am very much in favor of reverting the change or having an check-box option for the inserter to change between these modes. The change breaks a lot of simple inserter controls and seems to over-complicate nuclear control especially.

[bradicai]

Um... this breaks all sorts of things.

I believe the proper response to "my inserters are loading the incorrect materials onto trains" should be something along the lines of, "You can set an item type filter of a cargo train the same way you set your hotbar".

[Ripshaft]

Well I've seen a number of people talking about the change breaking their stuff but not really providing much useful detail so that the scope of impact can be established....

will be terse:

Circuit condition [everything] = 0, read hand contents, hold signal

Connect all inserters with wire on an unloading line

Effect - No inserter will grab more items until all hands are empty, leading to a reasonably balanced unloading of chests.



I can already think of alternate ways to wire my circuits to accomplish this same effect, but none of them are as piss-simple as the above option.

But I want to lay that out so that you get an idea how much this messes my stuff up - literally every place where I have multiple inserters depositing items onto a belt, and many areas where multiple chests are being loaded to then be unloaded to a common belt... this is an extremely impactful change.


HOWEVER, to be clear - I do not want to discourage the change based purely on impact, I think it makes more sense intuitively to disable the function of inserters when they are... disabled.. it does seem like the method I'm using shouldn't really work, it's just nice because it does and proves useful. Changing my setup is really not that much of a hassle, and blueprints make it easy to rapidly implement more complex wiring.

Though I think it's really important to get decent feedback on the perhaps unforeseen consequences of a change and how the community may experience it.


Anyhoo love what you guys do, even when you bring my mighty engine to ruin... it will rise again!

[Killcreek2]

Well I've seen a number of people talking about the change breaking their stuff but not really providing much useful detail so that the scope of impact can be established....

Good point.
However, it is hard to cite / screenshot a specific example from the hundreds of now-broken circuit / logistics enabled inserters scattered around the entire factory, which is in the middle of a main-power blackout & under biter assault on all sides...

will be terse:
Circuit condition [everything] = 0, read hand contents, hold signal
Connect all inserters with wire on an unloading line
Effect - No inserter will grab more items until all hands are empty, leading to a reasonably balanced unloading of chests.

Would work, but would be as slow as the slowest inserter. Previous behaviour allowed maximum speed for all the inserters, very easily.
Replicating that max throughput with this new behaviour will require a time-delay signal = to the time it takes the inserter to rotate. Going chest-to-chest is predictable timings, but belt-to-chest is rather variable and a whole lot more complex.
Even a 1-tick pulse that is stored until the hand is empty requires an additional combinator per inserter.

"1-tick pulse = 1 inserter rotation & dropoff" is so much simpler, easier to remember, build, and upgrade [as different inserter types would need different timings].

[golfmiketango]

So, to convince an inserter to move a single item, this means we need to know the rotation timings. But this is a function of where on the arc of motion the inserter was rotated to when it was disabled. As this information is not available to the circuit network directly, I guess this means we must track the rotation ourselves, by remembering how long the inserter was rotating for...., which really starts to feel like I've entered a long, dark tunnel.

Are people really correct that inserters pulse when they pick up and not when they drop? By any chance, was that changed to solve this? In my distelzombie-ish nuclear build, I have a two-combinator solution to this problem based on the assumption that they pulse when they drop and it does seem to work. But two combinators per inserter feels like a lot compared to the zero combinators per inserter it took formerly. (EDIT: it seems there was a bug in that; now I'm convinced they indeed pulse when they pick up. So I guess I'll need to use "hold"... requiring ... a third combinator per inserter? Hopefully not, so back to the drawing board...).

My first impression is: this partially defeats the purpose of configurable inserter stack counts, and puts me back in the 0.14 situation, where excessive cleverness is required to get anything done with exact-item-count precision using circuit-network-controlled inserter enablement. Very possibly, however, I just need to think about it harder, or I should really be thinking in terms of set-filters instead of enablement, now, or something like that....

Admittedly, it's a bit hard to think clearly about such things when all the lights are out and aliens are tearing my lasers to bits... maybe I'll warm up to it once that phase of the adjustment is over . I can, indeed, think of some ways to exploit this which formerly would have been impossible.

[looney]

IMHO *if* you want to keep any of this change, then I would implement something like; A pulse will enable the inserter, only if the inserter cannot drop the current item and is therefore waiting for something, should it check the enable condition again.

[golfmiketango]

IMHO *if* you want to keep any of this change, then I would implement something like; A pulse will enable the inserter, only if the inserter cannot drop the current item and is therefore waiting for something, should it check the enable condition again.

Perhaps a better way would be to offer two modes, say, "pulse enable," in which inserters queue stack-size-or-less insertion requests every tick, and "hold enable" which behaves like 0.15.22. But that would complicate the already record-holding-ly-complex circuit interaction configuration gui of inserters, which seems like a less-than-wonderful thing.

[MrGrim]

This increases the complexity of a lot of circuits using things like decider combinator feedback counters by forcing an edge detector to turn a pulse into a sustained signal, and even then, as others have pointed out, you can't be sure when the inserter is done and stop it before it picks up another item.

The OP's problem wasn't the inserters behavior. The OP's problem is an off by one error. They should have disabled the inserter as it was moving the last item, not when it picked up the overflow item.

Please revert.

[Philip017]

+1 for revert this change,

possible options:
- add a check box to allow dropping on second pulse,
- add option to return inserter to pickup location on deactivation. (it no longer operates on a pulse, and requires a hold signal, it could simply rotate back to the pickup location on deactivation, still holding it's item(s), it could pickup a new stack when reactivated, thus the item(s) are not inserted into the entity until the activation signal is sent and held again)
- have option to operate on either a pulse or a hold signal.

although i do love the ability to have the inserter move on a pulse now instead of a hold signal, by default.

EDIT:
also to answer the OP's problem, i filter my wagons to not have items in them i don't want.

also i have over 2000hrs in the game. and have learned quite a few things, making this change in the game overly complicates many simple inserter circuits. many examples of them have been documented already here. yes there are work arounds, but tutorials will have to be rewritten for things like the balanced loader/unloader that many people frequently use as one example. i understand why this could be a good change, but there also many ways that this is a bad change, there are work arounds to each situation, but so far the majority seems to be that this change should be reverted. and i wholly agree. you could always add option(s) to make them work in either situation.

[ElPresidente]

please revert this asap or add checkbox to disable.

[Uggeli]

this broke everything at my base

[chrisgbk]

Both use cases don't seem too problematic to me. Like I said, it will break some things but i believe they can mostly be worked around.

I'll keep an eye on this thread. Depending on what people say I can keep or revert the change.

I'd like to suggest reverting the change, but add additional functionality to cover the case presented in the thread:

Add a checkbox labelled "Reset when disabled"

Checking this checkbox would cause the inserter, if it is disabled while it is holding something, to attempt to put it back where it picked it up from immediately. If it can't place the item in the chest/on the belt, the inserter will simply continue holding the item until it is enabled again, at which point it will skip the pickup step and immediately spin and try to place the item.

[Ripshaft]

Hm, seems people mostly use a method I never did.. what I described is much simpler as you dont need a decider or arithmetic combinator but that pulse one sounds better.

For the people having trouble with a workaround, not sure how common this is, but I'm guessing most people are familiar with how to use an arithmetic combinator to evenly load chests - you can use the exact same method to evenly unload chests too, just flip the direction from <= 0 to >= 0 on the unloading inserters....

That seemed alot easier to explain in my head, hopefully that helps a handful of people who know what I'm talking about lol


Welp, bout an hour into changing all my circuits, almost got like... some stuff working again =p

[bzzz]

Add a checkbox labelled "Reset when disabled"

I really like this idea as a clear solution for both of the problems.