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

[life]

Dear JihadJ0e!
If the railcar arrives empty for loading fuel, it is possible to count the required number of 400 items of fuel in each railcar...

[mrvn]

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

This seems to be a special case of trains, only place where the drop of point moves away and a different one comes in later (ignoring cars on a belt as you can't read car content).

In this case I think the inserter could return to the pick up point when the train leaves. It would then sit there till activated again by a new pulse. This would solve the problem of dropping the item on the wrong train.

[Tekky]

In this case I think the inserter could return to the pick up point when the train leaves.

Related thread:

viewtopic.php?f=6&t=45550 Stack inserters with negative stack size should operate in reverse mode

[JihadJ0e]

Dear JihadJ0e!
If the railcar arrives empty for loading fuel, it is possible to count the required number of 400 items of fuel in each railcar...

Each rail car has a fairly random amount of stock when it arrives. I suppose I COULD completely unload it then reload it.

[mrvn]

Dear JihadJ0e!
If the railcar arrives empty for loading fuel, it is possible to count the required number of 400 items of fuel in each railcar...

Each rail car has a fairly random about of stock when it arrives. I suppose I COULD completely unload it then reload it.

That's the design I use. After all driving items around in a circle without unloading is wasteful. But it basically means all your train schedules should have exactly 2 stops. Load till full and unload till empty.

[Nethris]

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

This seems to be a special case of trains, only place where the drop of point moves away and a different one comes in later (ignoring cars on a belt as you can't read car content).

In this case I think the inserter could return to the pick up point when the train leaves. It would then sit there till activated again by a new pulse. This would solve the problem of dropping the item on the wrong train.

Trains are also a special case in that train cars are the only circuit readable containers where you can't read the specific container an inserter is aimed at, which lets you avoid trying to overfill to begin with. Both reading specific car contents and any sort of inserter reset have their own complications though.

Dear JihadJ0e!
If the railcar arrives empty for loading fuel, it is possible to count the required number of 400 items of fuel in each railcar...

Each rail car has a fairly random about of stock when it arrives. I suppose I COULD completely unload it then reload it.

If you're already checking for your rocket fuel train in your circuits, I feel like filter inserters set to unload rocket fuel from all other trains would be a simpler workaround.

That's the design I use. After all driving items around in a circle without unloading is wasteful. But it basically means all your train schedules should have exactly 2 stops. Load till full and unload till empty.

While that works, that's very inflexible, and is inefficient in its own ways, such as needing extra storage at destinations that don't really need a trainload of items, and needing a lot more circuity. Keeping a single train loaded with extra items you may not need yet only wastes time once rather than being an ongoing inefficiency, so often isn't worth worrying about if it improves something else.

[mrvn]

If you're already checking for your rocket fuel train in your circuits, I feel like filter inserters set to unload rocket fuel from all other trains would be a simpler workaround.

Simply add a filter inserter at the train stop with "T != <ID>" that returns any rocket fuel that might get accidentally loaded. good idea.

That's the design I use. After all driving items around in a circle without unloading is wasteful. But it basically means all your train schedules should have exactly 2 stops. Load till full and unload till empty.

While that works, that's very inflexible, and is inefficient in its own ways, such as needing extra storage at destinations that don't really need a trainload of items, and needing a lot more circuity. Keeping a single train loaded with extra items you may not need yet only wastes time once rather than being an ongoing inefficiency, so often isn't worth worrying about if it improves something else.

Not inefficient but makes deliveries take a very long time. For more complex items with low throughput I go by item count. E.g. the military science train has: Wait for 200 military science and wait for empty. So I just made the train car smaller to increase the frequency to something usable.

As for extra storage a single steel chest holds more than a train car. Or a few wooden chests. And you don't even need that. Since all trains only have 2 stops you can have them simply block on loading or unloading. It just needs enough waiting bays if you have more trains than loading or unloading stations. Earlier today I tried the trick of simply having many loading/unloading bays with underground belts going across all lanes. That is really simple to build, very compact and easy to extend. Every time you add for example a new train that needs to pick up iron plates you add a loading bay to the smelter.

[JihadJ0e]

What if we could attach red/green wires to the rail segments? When a train was over that rail segment it would send the selected information to the circuit network ? This would be consistent with how the conveyor belts work and could probably be abused in all sorts of interesting ways. It could also improve aspects of the rail network where you currently have to use a train station. The downsides to using a train station is that the train must be scheduled to stop at the station AND come to a full stop.

A circuit network connected rail segment could have the following:

• Read Train Contents (everything on the train)
• Read Car Contents (everything on a car)
• Read Train ID
• Read Car Type (locomotive, cargo wagon, fluid wagon)

Combined with the existing Read Train ID feature, this might also allow for some interesting train routing options.

Not sure how hard this would be to implement, but it seems like most of these components already exist.

[Tekky]

What if we could attach red/green wires to the rail segments? When a train was over that rail segment it would send the selected information to the circuit network ?

I believe it would be more meaningful to connect rail signals to the circuit network instead of individual track pieces. Whenever a train passes the signal, it can send its Train-ID and cargo contents to the circuit network. In "pulse" mode, the signal is sent only for one tick, when the train passes the signal. In "hold" mode, the signal will be sent for as long as the train occupies the block of the signal.

I have already suggested this two months ago in the following suggestion thread:

viewtopic.php?f=6&t=47541 Signals should send Train-ID to circuit network

[JihadJ0e]

What if we could attach red/green wires to the rail segments? When a train was over that rail segment it would send the selected information to the circuit network ?

I believe it would be more meaningful to connect rail signals to the circuit network instead of individual track pieces. Whenever a train passes the signal, it can send its Train-ID and cargo contents to the circuit network. In "pulse" mode, the signal is sent only for one tick, when the train passes the signal. In "hold" mode, the signal will be sent for as long as the train occupies the block of the signal.

I have already suggested this two months ago in the following suggestion thread:

viewtopic.php?f=6&t=47541 Signals should send Train-ID to circuit network

I was originally going to suggest the same thing, unaware that you already did. In the context of a loading/unloading station; however the signals would get in the way of the inserters.

[mrvn]

What if we could attach red/green wires to the rail segments? When a train was over that rail segment it would send the selected information to the circuit network ?

I believe it would be more meaningful to connect rail signals to the circuit network instead of individual track pieces. Whenever a train passes the signal, it can send its Train-ID and cargo contents to the circuit network. In "pulse" mode, the signal is sent only for one tick, when the train passes the signal. In "hold" mode, the signal will be sent for as long as the train occupies the block of the signal.

I have already suggested this two months ago in the following suggestion thread:

viewtopic.php?f=6&t=47541 Signals should send Train-ID to circuit network

I was originally going to suggest the same thing, unaware that you already did. In the context of a loading/unloading station; however the signals would get in the way of the inserters.

And with reporting for the whole block you wouldn't be able to read cars.

I was thinking: Hey, not signals, but maybe some kind of sensor for just reporting without being a signal. But then you mentioned "however the signals would get in the way of the inserters". The sensors would too. I think simply connecting a red/green wire to the rail should work. The graphics could then show a sensor item at that point, just like with belts, without needing an extra tile that would get in the way of inserters.

Note: This would also allow reading the car content of the locomotive, meaning the fuel. Or determining the length of the train: 2 sensors report a train ID => locomotive + car.

[SilentStorm]

I was just going to report this exact issue, when searching revealed it already being addressed, but unfortunately reverted because people were relying on a weird mechanic / quirk of the system.
Now I've taken the time to read most of what's been said in this thread, and I can't say that I know what kind of weird / intricate train loading / unloading mechanics people use in their factories. I use a simple array of inserters along a cargo wagon for speed, fed by belts and buffer chests.
When I saw that you can read the train ID, I thought it offers some great use case for my station to disable inserters for a specific train, that is supposed to carry ingredients to the part of the factory and transports away the products as well, if necessary (so limiting wagons to a certain item is out of the question).
Now since the broken mechanic of "I do something even though I'm disabled" has been reintroduced, this ends up putting stuff into cargo containers that other trains are supposed to carry. I cannot filter my cargo wagons either as other people suggested, obviously that's the first thing that comes to mind and was already attempted. I'm not one of those people that build circuitry unless they have to. If I can get shit done without them just fine why bother with complicated circuitry wasting space and complicating things with all the weird wires hanging around, potentially causing havoc with feedback.
In any case, because of Smeltery inserters still having items in their hand that couldn't be put on the previous train anymore, they now unload on the wrong wagon when the other train arrives. This will eventually break that train, as it fills up with the wrong items, not being able to carry the intended item anymore, which then would require me to manually do stuff about it (aka take them out).

The only "solution" would be to have a separate train driving around needlessly for the product transport, which is meh...

[Tekky]

I agree that the best solution to this problem would be to introduce an additional feature that would allow the circuit network to read the contents of an individual train carriage.

However, it should also be possible to read the free space of the train carriage, not just the contents, and if filtered slots are used in the train carriage, it should also be possible to read the free space in filtered slots for an individual item. That way, inserters could be programmed by the circuit network to only be enabled when it is guaranteed that they will also be able to unload into the correct train.

[SilentStorm]

However, it should also be possible to read the free space of the train carriage, not just the contents, and if filtered slots are used in the train carriage, it should also be possible to read the free space in filtered slots for an individual item. That way, inserters could be programmed by the circuit network to only be enabled when it is guaranteed that they will also be able to unload into the correct train.

I'll just take your word for that it could be done, since I'm having a hard time getting anything remotely complex done with them.

Sounds like a lot to do when you have just a few signals that you can deal with. I suppose every option you mentioned would be a checkbox like "Read stopped train" or "Read Hand content", but even then how would it work if there is a carriage with differently locked slots?

Even if there were just one locked item and/or (only) regular unlocked slots, the circuitry to make this happen reliably sounds like it would be extremely complicated and convoluted. You'd have to make sure the inserters are disabled from the get go (ok that's easy), and run through some decider circuitry that checks if however many items the inserter can pick up (which is different depending on type and research) would fit into the space available for whatever item the inserter would pick up. So you'd end up "programming" every inserter separately and would have to account for all of them combined as well. If every inserter of 6 can pick up a single item, but you only had 5 space they'd all go and you'd end up with the same problem to begin with.
All in all it sounds like you'd have to allot more space for the logic than for the actual inserters, buffer chests and belts carrying the items to be inserted, which for me at least seems like a bad thing.

[mrvn]

I agree that the best solution to this problem would be to introduce an additional feature that would allow the circuit network to read the contents of an individual train carriage.

However, it should also be possible to read the free space of the train carriage, not just the contents, and if filtered slots are used in the train carriage, it should also be possible to read the free space in filtered slots for an individual item. That way, inserters could be programmed by the circuit network to only be enabled when it is guaranteed that they will also be able to unload into the correct train.

See viewtopic.php?f=6&t=47435

[mrvn]

I was just going to report this exact issue, when searching revealed it already being addressed, but unfortunately reverted because people were relying on a weird mechanic / quirk of the system.
Now I've taken the time to read most of what's been said in this thread, and I can't say that I know what kind of weird / intricate train loading / unloading mechanics people use in their factories. I use a simple array of inserters along a cargo wagon for speed, fed by belts and buffer chests.
When I saw that you can read the train ID, I thought it offers some great use case for my station to disable inserters for a specific train, that is supposed to carry ingredients to the part of the factory and transports away the products as well, if necessary (so limiting wagons to a certain item is out of the question).
Now since the broken mechanic of "I do something even though I'm disabled" has been reintroduced, this ends up putting stuff into cargo containers that other trains are supposed to carry. I cannot filter my cargo wagons either as other people suggested, obviously that's the first thing that comes to mind and was already attempted. I'm not one of those people that build circuitry unless they have to. If I can get shit done without them just fine why bother with complicated circuitry wasting space and complicating things with all the weird wires hanging around, potentially causing havoc with feedback.
In any case, because of Smeltery inserters still having items in their hand that couldn't be put on the previous train anymore, they now unload on the wrong wagon when the other train arrives. This will eventually break that train, as it fills up with the wrong items, not being able to carry the intended item anymore, which then would require me to manually do stuff about it (aka take them out).

The only "solution" would be to have a separate train driving around needlessly for the product transport, which is meh...

The other solution is, as mentioned, to wire up an inserter to remove those items from the train when the train is not supposed to get them. So anything droped wrongly gets taken of right away again.


A quick fix at the source for this issue I also mentioned: Have the inserter return to the starting position when the train leaves and wait for a new enable signal. It wouldn't fix the issue that the inserter might have the wrong thing in its hand but it would stop it from putting it on the wrong train at least.