Inserters have wrong things in hand...

[nuhll]

... and again the same problem as always.

I have barells and some random other item in inventory.

First train gets barells, some (around 90!!!!!) barells are stuck inside the inserters.
Next train comes, wanna get some random item, get 9 to 10 slots filled with barells...

As far as i know, its not possible to not have that happen... correct? (besides only one station per item)

What about adding a (if that is posssible) script to just let all inserters swing one time back into their chest when the train leaves...? (easiest, coolest solution ever?!?!)

- if swing back is not possible, just cheat it back into the inventory?

[boran_blok]

you want to have 1 reserved slot per item you want to insert into a wagon. This results in the overflow going into that slot (which only has a few items in it) and the inserter being empty and ready to pick up something else.

edit: reserved slots is a signal value by the way.

[nuhll]

i use reserved slots, for most items its just 1 slot, so that is working good, but is a complete shit if you load barells, becaus ei need to block 10 slots for this to work...

[eduran]

For items with small stack sizes you can reduce inserter hand size or the number of inserters.

What about adding a (if that is posssible) script to just let all inserters swing one time back into their chest when the train leaves...? (easiest, coolest solution ever?!?!)

- if swing back is not possible, just cheat it back into the inventory?

Neither of those suggestions is possible.

[nuhll]

why should that not be possible? e.g. as a extra mod

*on remove filter from filter inserter*
*remove item in hand* (or if possible swing back)

[eduran]

why should that not be possible? e.g. as a extra mod

*on remove filter from filter inserter*
*remove item in hand* (or if possible swing back)

The event you describe does not exist. A mod would have to cycle through all inserters on the map, read the settings and compare them to the setting from one tick ago. That would bring down any CPU even on a medium sized map. And inserter hand position as well as the item held by an inserter are not writable.

[nuhll]

If that event doesnt exist, then we can ask the devs to implement it.

[nuhll]

If that event doesnt exist, then we can ask the devs to implement it.

Also im not the expert to ask how to implement it the best way. Its just an idea, maybe someone can come up with an (technical) solution other then "DOENST WORK".

[Deadlock989]

If that event doesnt exist, then we can ask the devs to implement it.

Been asked, many times, I'm sure. The answer was no, because it would cripple game performance to have an event call on every single inserter swing and drop.

There is a technical solution: don't build train stops that don't work very well.

[eduran]

Locked slots and inserter hand size limits already provide a very good workaround for that particular problem. Set up 10 inserters per wagon with a hand size of 2 and you will never need more than 2 reserved slots. And yes, that makes loading slightly slower. The other option is to use only one type of barrel on that stop. Speed vs cost/footprint is the trade-off you have to make.

Also im not the expert to ask how to implement it the best way. Its just an idea, maybe someone can come up with an (technical) solution other then "DOENST WORK".

I am not saying it is a bad idea. I also understand that as a non-modder, you can't know what is and isn't possible. But sometimes there is no solution to a problem. As far as I am aware (and I do consider myself a decent modder), this is one of those cases. Within the current API there is simply no way to do what you suggest. And any API request that would impact inserter performance is going to be shot down on sight. You are of course free to try and come up with something that proves me wrong.

[eradicator]

The event you describe does not exist. A mod would have to cycle through all inserters on the map, read the settings and compare them to the setting from one tick ago. That would bring down any CPU even on a medium sized map. And inserter hand position as well as the item held by an inserter are not writable.

on_train_changed_state does exist, maybe not the cheapest if you have several hundred trains but it exists. So i'd say it certainly is in the realm of the possible to make inserters "swing back" *once* by teleporting the items back into the buffer chest when a train leaves. Not sure how likely it generally is that there is space left in the buffer chest though, mine are usually full. And without space it's pointless. And it would need to be a junky solution where they only swing back if the held item doesn't match the current filters.

Filtered wagons or seperate stops are a much easier solution for sure. Wasn't there even some mod that could circuit-control wagon filters?

[eduran]

on_train_changed_state does exist, maybe not the cheapest if you have several hundred trains but it exists.

Given a train that just changed state, how do you find the station's inserters?

[nuhll]

on_train_changed_state does exist, maybe not the cheapest if you have several hundred trains but it exists.

Given a train that just changed state, how do you find the station's inserters?

Like i said, i have no mod expierince.

What i was thinking was something like on_filterinserter_change_filter - if that is not there already, then it can get added if we ask devs, maybe.

So basically a hook (?) when a filter in a inserter gets changed (after train leaves, the filter inserters should get their filter settings removed, right?)

So on on_filterinserter_change_filter

1.) If it gets changed from SOMETHING to NOTHING
- If nothing "in hand", do NOTHING
-> check if something "in hand", if so, "swing back" (or if that is not possible, teleport, put into internal inventory or just destroy - what ever is possibel idk)
- That there is space in the inventory is super easy to archive in using wires to only allow something in if its less then X..

2.) If it gets changed from NOTHING to Something
-> do nothing

So it should only be called when filter inserters get filters changed (usually shouldnt hapen often and nroamly only on train stops, right?)

There is a technical solution: don't build train stops that don't work very well.

I hate this - i call it - flame.

This is not because the station is wrong, its because its a problem. I already said that i know i can build 192839182348120312 seperate stations, but i dont want to. The station desgin, is btw, just from the "use this LTN stations if you have problems thread".

Its like oh doctor if i move my head it hurts and doctor says: then DONT MOVE your HEAD!

[Optera]

There is a technical solution: don't build train stops that don't work very well.

I hate this - i call it - flame.

This is not because the station is wrong, its because its a problem. I already said that i know i can build 192839182348120312 seperate stations, but i dont want to. The station desgin, is btw, just from the "use this LTN stations if you have problems thread".

Its like oh doctor if i move my head it hurts and doctor says: then DONT MOVE your HEAD!

Sounds more like
"Doctor my head hurts"
"Stop hitting it against the wall"

Like you said you are no developer. Events like on_inserter_idle or on_inserter_filter_changed would fire so often it would utterly tank performance for everyone so Wube will never add those.
Use my designs and set locked slots to stacks all inserters of a the station load per inserter cycle * items, problem solved.

[eradicator]

on_train_changed_state does exist, maybe not the cheapest if you have several hundred trains but it exists.

Given a train that just changed state, how do you find the station's inserters?

Get the inserters:
on_train_changed_state -> event.train -> for x in train.cargo_wagons -> cargo.wagon.surface.find_entities_filtered{area=double_box_size(cargo_wagon.prototype.collision_box),type=inserter}

Check if inserters are the ones you want:
inserter.drop_target == cargo_wagon
(this is probably untrue if the train already left one tick before, timinig might be solvable)

or

is_position_inside_box(inserter.drop_position,cargo_wagon.collision_box)
(this is easier as in one tick the wagon position won't change that much)

[nuhll]

There is a technical solution: don't build train stops that don't work very well.

I hate this - i call it - flame.

This is not because the station is wrong, its because its a problem. I already said that i know i can build 192839182348120312 seperate stations, but i dont want to. The station desgin, is btw, just from the "use this LTN stations if you have problems thread".

Its like oh doctor if i move my head it hurts and doctor says: then DONT MOVE your HEAD!

Sounds more like
"Doctor my head hurts"
"Stop hitting it against the wall"

Like you said you are no developer. Events like on_inserter_idle or on_inserter_filter_changed would fire so often it would utterly tank performance for everyone so Wube will never add those.
Use my designs and set locked slots to stacks all inserters of a the station load per inserter cycle * items, problem solved.

I dont think on_inserter_filter_changed would fire that often in a normal world.

I mean, how often do your filters get changed? If u have like 100 stations, maybe 20 filter (* 20 inserters) a minute?

[nuhll]

Ive posted it here:
viewtopic.php?p=434691

Maybe devs can say somethign to it.

[eradicator]

I'll be betting 1M green circuits that the answer is going to be "No." with at most one sentence of explanation, containing the word "performance".

[nuhll]

I'll be betting 1M green circuits that the answer is going to be "No." with at most one sentence of explanation, containing the word "performance".

In a normal megabase, you DONT change filters?

Only on train stations, what is the problem??? You most likly dont have 1000 stations working at the same time, changing constantly filters?!

Also it dont need to fire on filter change, just on filter remove.

[eradicator]

In a normal megabase, you DONT change filters?

Ever heared of "smart smelting"?

Also i'm just predicting results. I don't have a "problem".