Before V1.1 I always wanted a new train stop condition, because I hated trains hunting delivery stations and then returning back home full because other train has loaded the unload station first.
With V1.1 we got the train station limit, and for me, it solved every single problem I had.
Ok, was a bit tricky to find out right values for train limit and have the right amount of trains in the network, but it now even works like a charm with N:N stations, that was a no-go before.
The rails are without congestion (heya, first time ) and the whole systems runs very smooth.
What are your experiences with the train stop limit, and did it solve all your problems?
What's your experience with the Train stop Limit feature from V1.1 ?
- 5thHorseman
- Smart Inserter
- Posts: 1193
- Joined: Fri Jun 10, 2016 11:21 pm
- Contact:
Re: What's your experience with the Train stop Limit feature from V1.1 ?
I've only run some tests but I was very happy with them, and am slowly chugging along towards a modular agnostic (each module doesn't care what the other modules are doing, just wants stuff imported and exported) megabase now.
Holidays and work means I'll likely not really see it in action until January probably, but if my testing is any indication my experience I expect will be pretty much spot on with yours.
I think it helps that the fix they put in is pretty much EXACTLY the fix I wanted.
Holidays and work means I'll likely not really see it in action until January probably, but if my testing is any indication my experience I expect will be pretty much spot on with yours.
I think it helps that the fix they put in is pretty much EXACTLY the fix I wanted.
Re: What's your experience with the Train stop Limit feature from V1.1 ?
It's fantastic and I love it. I was using a distinct-source agnostic-destination layout beforehand and train limits just dropped in like a charm and cut the traffic down on the net enormously. I wound up needing to build some more trains to ensure that they queued properly among all the possible terminal stops, but once that was done the entire thing just purrs.
I have some plans for a dynamic overflow stacker system that I want to try out, but there's so many other things to work on :v
I have some plans for a dynamic overflow stacker system that I want to try out, but there's so many other things to work on :v
Re: What's your experience with the Train stop Limit feature from V1.1 ?
I had some trouble with this new feature but I could solve it with some complicated combinator logic. However I did have a special use-case in which I was trying to prevent a full train waiting at a stacker while another dropoff location was in need of resources. Therefore I wanted to only request a followup-train when the unloading train gets close to empty.
In my scenario I'm using one train for each station (pickup or dropoff) and a single slot in the stacker for each dropoff station (so each dropoff can hold maximum 2 trains...one unloading, one waiting...and under extremely rare circumstances another one en-route).
First thing that came to mind was to have a combinator that sets the train limit to 1 when the train is at 10% of its capacity. This didn't work out because the stopped train still holds a reservation.
So I had to also give it a +1 on the train limit. That seemed to work at first. The unloading train was getting empty, then the limit went to 2, the second train was called and put into the stacker. However, when the unloading train was empty and departed the limit was still 2 and another train was requested into the stacker.
Then I made sure that the static +1 only was sent, when a train was actually stopped. This fixed that bug but it created a new one. When the train was empty but no train from the pickup stations was coming in yet it became a deadlock. Reason is: A train that's "no destinationing" no longer reports a train ID to the train stop, but still holds the reservation. So what happened was that I requested 1 and had 1 and trains from the pickup station had no destination while the train at the dropoff station had no destination as well.
That bug I solved by making sure that the trains do not actually depart from the station until at least one replacement (meaning at least 2 reservations) in on the way. The train effectively departs if (D(eparture) = 1 AND Train empty). Additionaly to make sure that the train does not get blocked up in case of an item jam there is another condition for departure which is (D = 1 AND Inactivity 5s).
This alone did not solve the problem of having 2 trains requested at once. I figured out that when the train departed there was exactly one single tick in which the request stayed at 2 with only 1 train incoming (to which another pickup station happily replied ).
What I did then was to give the D(eparture) signal a secondary signal: L(imit) := -1. This makes sure that at the moment the train is allowed to depart it no longer counts itself into the limit for requesting. This works because the D-signal is not set before at least another train is en-route.
Another condition for requesting a train is that it should request a train early if it detects that the buffer getting empty. This makes sure that if a train gets empty fast enough that the buffer runs dry automagically one additional train gets to the stacker to refill the buffer immedately.
For testing purposes fill the pickup station chests with 2400 copper ore each.
In my scenario I'm using one train for each station (pickup or dropoff) and a single slot in the stacker for each dropoff station (so each dropoff can hold maximum 2 trains...one unloading, one waiting...and under extremely rare circumstances another one en-route).
First thing that came to mind was to have a combinator that sets the train limit to 1 when the train is at 10% of its capacity. This didn't work out because the stopped train still holds a reservation.
So I had to also give it a +1 on the train limit. That seemed to work at first. The unloading train was getting empty, then the limit went to 2, the second train was called and put into the stacker. However, when the unloading train was empty and departed the limit was still 2 and another train was requested into the stacker.
Then I made sure that the static +1 only was sent, when a train was actually stopped. This fixed that bug but it created a new one. When the train was empty but no train from the pickup stations was coming in yet it became a deadlock. Reason is: A train that's "no destinationing" no longer reports a train ID to the train stop, but still holds the reservation. So what happened was that I requested 1 and had 1 and trains from the pickup station had no destination while the train at the dropoff station had no destination as well.
That bug I solved by making sure that the trains do not actually depart from the station until at least one replacement (meaning at least 2 reservations) in on the way. The train effectively departs if (D(eparture) = 1 AND Train empty). Additionaly to make sure that the train does not get blocked up in case of an item jam there is another condition for departure which is (D = 1 AND Inactivity 5s).
This alone did not solve the problem of having 2 trains requested at once. I figured out that when the train departed there was exactly one single tick in which the request stayed at 2 with only 1 train incoming (to which another pickup station happily replied ).
What I did then was to give the D(eparture) signal a secondary signal: L(imit) := -1. This makes sure that at the moment the train is allowed to depart it no longer counts itself into the limit for requesting. This works because the D-signal is not set before at least another train is en-route.
Another condition for requesting a train is that it should request a train early if it detects that the buffer getting empty. This makes sure that if a train gets empty fast enough that the buffer runs dry automagically one additional train gets to the stacker to refill the buffer immedately.
For testing purposes fill the pickup station chests with 2400 copper ore each.