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

[JihadJ0e]

If an inserter was enabled, and was unable to insert the hand content because the destination was full, then is subsequently disabled or unpowered it will still insert the hand contents into the next non-full receptacle.

Stop-Inserting.png (409.62 KiB) Viewed 26386 times

This especially breaks conditional loading of trains as a small quantity of unintended items are loaded onto the wrong trains, breaking all sorts of stuff down the line.

I have tried this with stack inserters, fast inserters, setting the stack size to one, unpowering the inserters, and disabling the inserters - no matter what I do I can not get them to stop inserting their hand contents.

My expected behavior is that if the inserter is disabled or unpowered it should NOT insert the hand contents.

I think this is new to 0.15, as I do not recall having this issue previously. I searched through other postings, but could not find anything.

Also... this game is amazing, I'm at 567 hours now. Keep up the great work.

[njaard]

I have a "Stack inserter". Sometimes it picks items up and then doesn't unload them because the destination cargo wagon leaves, so it is left holding an item. The next time a cargo wagon arrives, the item will unload even though the circuit network has disabled it.

The circuit network's signal is a train signal sent through two decider combinators in parallel, followed by an arithmetic combinator.

[Aeternus]

That's normal. Inserters only check activation/deactivation conditions when they are ready to start a cargo move. If the inserter has cargo left over on it's arm, it'll finish that cargo movement before it reevaluates circuit conditions. This can be a problem with filter inserters and changing filters, but it's just how they work - an inserter can't return leftover cargo to where it got the cargo from.

[Twinsen]

Not necessarily a bug. Inserters finish dropping what they are holding when disabled.

But seeing this use case I believe it is better to have them keep the item in hand if disabled.
This change will break some contraptions, but let me know if anything significant breaks.

Changed in Version: 0.15.22.

[MasterBuilder]

But seeing this use case I believe it is better to have them keep the item in hand if disabled.
This change will break some contraptions, but let me know if anything significant breaks.

If I understand this right, won't this make inserters working with a single pulse to move one item break?
- Inserter gets pulse.
- Inserter picks up item.
- Inserter rotates but doesn't drop the item as the pulse is over.

Is a second pulse now required to actually drop the item or not?

My gut says this will break more things than it fixes.

Edit: Case where this might break:
Circuit balanced unloading.

I link inserters unloading from a wagon together with a condition like "anything == 0". This allows all the chained inserters to all pickup at once and then they all unload together.
None of the chained inserters will swing back and pick up anything until ALL the inserters hands are empty. Thus balance is achieved.

If they can only drop items when "anything == 0" then they will never drop anything and remain 'stuck' forever, no?

[Twinsen]

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.

[orzelek]

Won't it break simpliest way of managing Kovarex process where you use pulse from U-238 removal to remove one additional U-235 that was produced?

[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.

This completely breaks my entire nuclear setup all the way from kovarex fuel reprocessing to the reactor fuel inserting. I use a memory cell that counts how many uranium are picked up and enables inserters using modular arithmetic to evenly split the output of the fuel cell reprocessing to feed into kovarex to generate a 1:1 used to new fuel cell. My kovarex enrichment itself is broken as the enriched uranium now won't be dropped. And the inserting of fuel into the reactor itself which relies on the empty fuel cell being taken out enabling the insertion of a new fuel cell.

[hardingt]

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.

Breaks two things on my build
Breaks my train unloader that causes all arms to swing once they are empty (1 tick of empty)
Also my science buffer, which causes them to swing once every X number of ticks. Not sure how I would recreate that without adding a lot more circuitry to have them stay on until empty, and then swing again next time the clock timer runs out.

[CornedBee]

This breaks my nuclear setup. I generate a single pulse signal when the steam buffer falls below a threshold. Now the inserter is stuck holding the fuel over the reactor, without inserting it, and my power goes out.

It also breaks a design posted on reddit (can't link, first post. thread is called Nuclear Fuel Control Circuit without Combinators by AlatarSkysong).

I don't see an easy way to work around this. Generate a delayed second pulse perhaps? That would make the circuitry a lot more complicated.

[bzzz]

I hope this fix will be reverted. Or some additional checkbox is added at least.
Staying on 0.15.21 for now.

[Tekky]

I hope this fix will be reverted. Or some additional checkbox is added at least.

I agree.

I am unable to find any easy workarounds to adapt my existing circuit networks to this new behavior. Having to send a second pulse at a certain delay would seem complicated to me, especially since the required delay would not be trivial to calculate. Also, the required delay would be dependant on several factors, such as the speed of the inserter and also whether the inserter is fully powered (underpowered inserters swing slower).

[FunMaker]

I get why this was changed but Reactor plant broken

EDIT: Ok, just another Combinator that keeps the inserters active until the inserters have dropped their cargo.

[Tekky]

EDIT: Ok, just another Combinator that keeps the inserters active until the inserters have dropped their cargo.

The problem is that there is often no easy way to determine when the inserter has dropped the item, since inserters send their pulse only when picking up items but not when dropping items.

[svercer]

This "fix" is really frustrating me because (a) it's just making a certain logistical challenge easier for one bug reporter, but (b) it doesn't even actually make that challenge simpler in general; it just makes one specific case simpler. The general challenge is "inserters drop what they're holding even when some external factor means that you expected them not to transfer any more items." It's entirely possible to still hit that exact same challenge in 0.15.22 with no circuit networks. I don't have Factorio handy to make a screenshot, but it's a simple enough setup to describe:

You have two parallel train stops, say for eastbound trains. The tracks have 4 tiles between them. Both wagons at a certain position in the stop are fed from the same initially-full chests (one will have to use long inserters). A train comes by on the northern track and leaves once full — so some of the inserters are holding items still. Now trains come by on the southern track until the chests are completely empty. The empty chests are now the "external factor expected to inhibit transfer", just like falsifying the circuit condition, but without circuits. But if a train comes by in the northern track now, it's going to get a few items, even in 0.15.22, and even though the chests were empty so you wouldn't expect item transfer.

So the problem (really, the puzzle) wasn't solved; all this "fix" does is break a lot of people's setups. Now, getting your gadgets broken is part of playing an alpha game, but we at least expect that we get real improvements in return. As I've demonstrated, we haven't.

Finally, I want to point out that an in-game solution existed for OP (and after all, isn't finding in-game solutions to logistical challenges like this part of playing Factorio?): you can have a "cleaner" train come in between every real train, stop for one second to receive all the dropped items, and go back to where it started, putting the items in to any kind of "priority" system to be put back in the chests. This also has the massive advantage over the "bug fix" that the inserters in question are now free to move other kinds of items instead of just sitting there uselessly holding the previous items, quite possibly forever if you wanted to switch up what kind of item is being transferred. That is unintuitive.

Oh, and Twinsen, about "anything significant breaks" — I'm not sure what counts as significant, but the very popular design mentioned at https://www.reddit.com/r/factorio/comme ... 2/dj7jr7d/ is broken, as well as the nuclear control thingy at https://redd.it/69i4el, and a ton of others along the same lines.

[DaveMcW]

I love this change. It's great to have control over inserters the entire time, not just on the tick they pick up an item.

The old method is like "pulse" mode, the new method is like "hold" mode.

Of course, since we have an option to switch between pulse and hold mode, it would be nice to have an option for this too.

[Rhamphoryncus]

Would this work better if inserters only interrupt if the inventory changes? A reactor is always the same inventory so you finish your pulse whereas if a train leaves it's a different inventory and you interrupt.

That said if you extend the OP's usecase to include set-filter inserters there's no way to make it work short of returning the held items to the source chest (even if full, somehow).

[cyberdude]

Update 0.15.22 that "changed" this, is up until now the most annoying update unfortunately.
I don't find this sudden change very handy.
It has completly ruined several parts of my factory built during 0.15. Now I can no longer downgrade and use the save there, so for now I'm unfortunately going to stop playing.
I'd really appreciate if we had control over whether inserters would act like before (pulse) or hold. I think we need somehow to decide between the two different handlings.

The current change really ruined the experience for me, so I'm really really hoping this will be rethought.

Otherwise I absolutely love factorio! Keep up the good work guys, and I hope you twinsen will take a second look at this?

[Killcreek2]

Not necessarily a bug. Inserters finish dropping what they are holding when disabled.
But seeing this use case I believe it is better to have them keep the item in hand if disabled.
This change will break some contraptions, but let me know if anything significant breaks.
Changed in Version: 0.15.22.
...
I'll keep an eye on this thread. Depending on what people say I can keep or revert the change.

Well. This has broken my main nuclear power plants, chemical backup power, all smart train loading & unloading [belts AND bots!], nuclear fuel processing, refinery operations, smelters, my automatic walls repair / replace/ resupply, player shop, auto satellite launching, and even train refuelling!

None of those are easy to fix with the "new" mechanic: It would require at least 1 extra combinator per setup [possibly per inserter!] to ensure that a 1-tick pulse will fire the inserter properly, as previously expected.

Wow. I know you guys like to "keep us on our toes", but I'm rolling back to 0 15.21 while you guys seriously rethink this change.

I did not like it much when the pre-heating was killed when steam changed ~ that just broke the powerplant, I can redesign that & move on ~ but this breaks the whole damn factory!
Imho, worst patch since that one that accidentally corrupted savegames ...

[kaldskryke]

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.