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

[Hoefnix]

Yeah, since I use combinators a lot myselft I feel this change is absolutely horrible, I actually think it should function in the complete opposite way. In my opinion if I tell an inserter to enable for 1 tick it should complete at least 1 swing. I already had to work with memory cells/timers to change a 1 tick signal to something that lasts long enough for the inserter to pick up the item, now I have to tweak it so it still receives the signal when the arm completes its swing.
This is all horribly sensitive to power shortages since they slow down the inserters which means the signal should be sent for more ticks, its horrible!
Please change this so when I tell an inserter to enable, no matter how short, it completes at least one swing.

[weltvagbund]

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.

THIS!

If you are filling to precise item count, you need to set the Inserter controlling circuits to react at ItemCount-Stacksize to avoid overloading. If the OP would have tinkered a bit, he would have found out. This single change broke my whole base. All my train Setups, whicvh rely on precise item counts are screwed up. Additionally my Smart Smelting, my refinery and my nuclear power plant are doing nothing. And my Emergency Power Saving circuits decided to power down the "unimportant" part of the base.

This is such a horrible change, it is unintuitive as many people already said. My solution after the damage assessment is, to revert back to 15.21 and really hope this gets to be optional, or reverted in future versions.

[Twinsen]

Ok, since this topic exploded I'll revert and release ASAP.

The best way to get feedback was to put in in a release. So now I have the feedback I wanted.

[mpd_steam]

I personally have experienced the pros and cons of both setups, so I'm not too fussed either way.

Just chiming in to say that while the Twinsen said he would keep an eye on the thread, I'm sure he meant he was looking for constructive feedback. Most of it is, but I think a few people need to remember that they opted in to an experimental version of a pre-release game. These kinds of changes can happen sometimes.

[Tekky]

Yes, I agree that we cannot blame Twinsen for using us as lab rats, since we all signed up to be lab rats.

If people don't want their bases to be broken from time to time, they should not be using experimental versions and use stable versions instead.

All in all, I would say that the Factorio devs are doing a great job. My overall impression is that Factorio's experimental versions are nearly as stable as the 1.0 releases of many mainstream games, and that Factorio's stable releases are a lot more stable than most other games.

[oisyn]

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.

Not necessarily.

I know it's reverted already, and I'm actually glad that it is, but it wouldn't be too hard to let the inserter drop the item if it's holding one. You just need to convert the enabled condition from "condition X" to "condition X OR while I'm holding an item". Of course, you need to configure the insert to read its hand contents as "hold", so if you're already using the pulse setting you'll need more logic to convert the reported contents to a pulse (not hard, but it creates an extra tick delay)

[mrvn]

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

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.

You need to change your circuits so the inserters only activate when the train has enough room to receive the items and the train to leave only when the inserters have nothing in their hand. Overall I think your example makes no sense though.

First you have a train stop that will load rocket fuel only into one specific train and do nothing for all other trains. Then why would any other train stop there at all?

Second why not set a filter on the train cars? If the car has no place to receive rocket fuel then the inserters won't drop rocket fuel.

[Veklim]

Hey there, just felt it right to chime in at this point, first post here but have approx.500 hours of gameplay (half of that in the .15 experimental builds).
This inserter behaviour change has most certainly broken a VAST number of inserter control methods to the point where, at the bare minimum, I will need to double the number of combinators in most of my factory just to START trying to fix it all. Whereas I understand and agree that experimental builds will occasionally break stuff, go loopy or do something else undesirable, I also feel I should defend both sides of this little debacle by pointing out that much of the most broken circuits and devices centre around control of the Kovarex process and nuclear power control systems which have not long been implemented themselves. Many players are only just getting to grips with the full applications and design requirements for nuclear power (me included, I'm currently building my first automated pulse-burn nuclear reactor after a long time on a solar-only build) and we are thusly rather irked by the sudden change, yes. The REAL issue for many of these people though, is not actually the behaviour issue of the inserters per se, it is actually to do with the fact that many of them cannot revert their saves now, and are stuck waiting until something changes again.

Personally, I didn't load up the game after the update, I read up here and on Reddit, spoke to a friend and decided to roll back and wait on a fix for the fix

I discussed this issue at great length with that same friend, and we both agreed the new inserter behaviour has merit and application which will expand possible gameplay and inspire new methods and ideas, this is a good thing.
We also both agreed that the loss of the old behaviour REDUCED overall gameplay possibilities, making the simplest of single combinator circuits and mini memory blocks unworkable without serious embellishment and some sort of tick counter latch to allow a second timed pulse for release, this is a bad thing.

With these two things in mind, I must personally say the option to toggle said behaviour on a use by use basis would be ideal, but I do not see how removing options in favour of markedly differing ones will enrich the experience of the game, it will merely change it. The old behaviour was not really broken, and did not need to be fixed, what might have been a better choice would have been to add the option to toggle in the first place, rather than fundamentally changing a well understood and practically applied behaviour of a core device.

All that said, I love Factorio, the devs are masters of the art, truly, and I see myself playing this for literally years to come.

[oisyn]

Having an option in the inserter settings is also completely analoguous to the hand read mode option. It, too, could have a "pulse" and "hold" setting.

[MrGrim]

I discussed this issue at great length with that same friend, and we both agreed the new inserter behaviour has merit and application which will expand possible gameplay and inspire new methods and ideas, this is a good thing.

While preparing for the possibility that it would not be reverted I was racking my brain for positives, and I honestly couldn't come up with a use for the new mechanic that wasn't available before in a simpler fashion. I'm not the most creative person on these forums by far, so I'm really curious what applications you and your friend had thought of.

[cyberdude]

Ok, since this topic exploded I'll revert and release ASAP.

The best way to get feedback was to put in in a release. So now I have the feedback I wanted.

<3
Awaiting update
This answer here is a perfect example of the reasons why the Factorio team is a classic example, for every indie game development out there to look up to.

Ever since I bought Factorio I've been fascinated by the involvement of the team with the users, the FF blogs, the attitude towards users, modding, support, bug handling, release schedules. Everything is near perfect!
We have a small update which breaks stuff, people voice their opinion, and devs respond and listens. This is truly why I'm admiring the team.

If it is possible to make this is a selectable option/setting on the inserter, then it might be useful.

Keep up the good work

[Tekky]

Awaiting update

Your wait is over now.

Factorio version 0.15.23 has been released.

[Pippin]

Here's a suggestion (not sure if anyone else has already suggested it as I haven't read the whole thread!)

In the inserter circuit network UI, have one tick box for "check condition on pick-up" and another for "check condition on drop". By default just the former would be ticked. Then we can have an item transferred by a one-tick pulse, but if we prefer, the pulse can be to drop instead of to pick up, or we can have the current situation (2 1-tick pulses or 1 longer pulse to transfer an item) or... I suppose you could untick both to stop the inserter checking at all! Hmm, I wonder if that could be useful...

Edit: Oh yes, another possibility: Maybe if an inserter can drop the object immediately when it first tries to, it does so. If it is blocked for some reason, it only drops later on if the circuit condition allows it to. That would work nicely for my nuclear plant (the only thing this update broke for me) but isn't very consistent so it might cause more problems than is solves.

[bradicai]

Thank you for the revert. The issue brought up by the original "bug report" is a very specific one, that can be solved with a specific set of logic. where as the intended solution changes a lot of the capability, requires more separate specific logic circuits to re-enabled.

If trying to prevent inserters from holding goods due to no valid drop point, there should be logic(two combinators) to only allow only enough items to be picked up by inserters. I don't see this behavior as being unintentional, as there already is a fairly simple way to limit the throughput of an inserter with a precision of 1. You could over-complicate the inserters' with extra check boxes if many people wish for a "don't drop" but the logic condition currently uses a "don't pickup" which can be used the same way, and can be used for a lot more.

Personally i prefer things to have 1 mode, so all fine controls are easy to understand in all circumstances, but you could have a checkbox like, "Use Drop condition", which could invert the current behavior. when check it will always pick up, but it will only drop when enabled. and instead of pulsing/holding once pickup, pulse when dropped. this can cause more problems then you might think in terms of assumptions. just my two cents

Thanks again for listening. these devs rock.

[EpeeGnome]

What about having powered inserters work in the original/reverted way, but making unpowered inserters unable to drop hand contents. It would allow both use cases and it makes intuitive sense that an inserter with no power would be unable to finish its insertion.

[life]

I'm for option to add the additional options of retaining the item and the reading signal at the time to drop item.

[JihadJ0e]

The design I was attempting to achieve was to honorably abuse the feature where trains stop at each station with the same name. I have a number of large factories on a one way circular track. Every train has three stops, a Resource X stop, a Rocket Fuel stop, and a Exit stop. Every single train stops at each 'Resource X' stop and either loads or unloads resources, following the resource stop in each factory is a rocket fuel stop that trains use to refuel. There is one rocket fuel re-supply train that also goes around the track to each factory and resupplies the rocket fuel (just has two stops, a Rocket Fuel stop and a Exit stop). At the chemical factory the rocket fuel stop acts both as a refueling stop for trains picking up chemicals as well as a re-supply point for the rocket fuel train. Most of the time we just want the rocket fuel stop to load rocket fuel into the train engine. The exception is when the rocket fuel re-supply trains rolls up we also want to load rocket fuel into the cargo wagons. This seemed like the perfect place to use the new feature that allows reading the train id and reacting to it in some interesting way - which is to suggest that this is absolutely valid and sane use case, and should not require contortions to make work.

Regrading setting a filter on the cargo wagon, that would require setting a filter on about 60 cargo wagons for resource X solely to prevent a disabled inserter from inserting an item. That does not make a lot of sense.

Regarding preventing the inserter from picking up the item in the first place, as far as I know one can only read the TOTAL number of items on a train, and not in a particular cargo wagon. If one has two or more cars there is no way to tell if the car in front of an inserter is empty, so all the inserters pickup an item. If the inserter is unable to unload the item it instead drops off the item onto the next train that shows up. This only address the issue I am reporting when there is no more then a single cargo wagon.

Clearly this change caused some unintended consequences and needs some further refinement. The point however is still valid - why is a disabled/powered down inserter able to insert, or perhaps more more to the point how come it is not possible to prevent a disabled/unpowered inserter from inserting? Nothing else in this game works this way. Powered down / disabled means do not do anything, not finish what you started some time ago then don't do anything new.

My thanks to Twinsen for attempting to improve this, even if it did not really work out. I wish I had some sort of elegant suggestion on how to make this better without breaking other use cases. The best thing I can come up with is to handle the case where the receptacle is a cargo wagon differently as this is the only case I can really think of where the destination of the inserter is not more or less fixed and perhaps the only case where it really matters. The second best thing I can come up with is to have a gadget that reads the contents of the wagon directly over it, which would allow more precise loading/unloading then reading the content of the entire train.

[life]

Dear JihadJ0e!
Simple method to read the contents of the train and read the contents of the manipulators constantly. For a railcar to use 1 arm loading up to 400 on one item and the other handles up to 394 using the signals from the box on the same network.
Or limit all manipulators to 394 for railcar and train to limit the waiting time to 1 second.
I don't use T signal for your task.
T signal you can turn off the signals out of the box, then loading will work as required.

Can send save your map or blueprint in a PM, I will finish her nail file.
I don't use mods.
Sorry for my bad English.

[JihadJ0e]

Dear JihadJ0e!
Simple method to read the contents of the train and read the contents of the manipulators constantly. For a railcar to use 1 arm loading up to 400 on one item and the other handles up to 394 using the signals from the box on the same network.
Or limit all manipulators to 394 for railcar and train to limit the waiting time to 1 second.
I don't use T signal for your task.
T signal you can turn off the signals out of the box, then loading will work as required.

Can send save your map or blueprint in a PM, I will finish her nail file.
I don't use mods.
Sorry for my bad English.

Thanks for your response and suggestion, I think I'm following. I could limit the TOTAL items on the train to less then the contents of a cargo wagon. In my case I would set the max items that could go on the 4 cargo wagons. The downside to this is that the train would be 3/4 empty at any given time. I could also use just one cargo wagon and accomplish the same thing.

I guess the whole point of this bug report was more to point out that a foundational element of this amazing game, in combination with the new train id feature, does not work as expected. If I was trying to make some convoluted contraption function that would be one thing, but in my mind this is a very basic case - only insert some items on some trains.

[Engimage]

I think we are seeing two different things here. First one is that inserter should certainly drop its hand contents if it can do it immediately. This is behavior that most people did complain here about and which is used all over the place. And the second one is the problem which arises only with trains when inserter fails to drop its hand contents immediately and does so much later on another train. So maybe behavior should be altered so that inserter should not drop hand contents if it fails to do so immediately? This will keep the basic one-tick activation but will fix train problem