[obsolete after V1.1] New Train stop condition: Next stop not deactivated

[Guenni7]

TL;DR

Trains ignore disabled stations and switch to next enabled station if so, which makes it difficult to build a stackers to serve many delivery stations and on the other hand let's trains run in unneccessary loops forever.

What ?

If we would have a wait condition based on next waypoint (wait til next waypoint is active), it would be sooooo easy to build stackers that hold all the full trains, and let them run when they are needed.



Edit: With Version 1.1 introduced Train stop Limit and it's behaviour this is no longer needed.

[Guenni7]

Hmm, interesting that this idea doesn't get any attention while the board is full of problems that could be solved by this simple enhancement

[steinio]

You can use "wait until circuit signal" and send the train stop activation signal to the train...

[Xoriun]

You can use "wait until circuit signal" and send the train stop activation signal to the train...

Technically yes, but if the stations are really far apart, (like mining outpost and main base), this is a lot of effort and could clump up your network really quickly.

[dimm]

My workaround is to check the contents of the train upon arrival from the mining outpost to the waiting station. If the train is empty, it stays here to wait until I move the outpost to another resource location. Cons: the train from the waiting station needs to be started manually after relocation the outpost.
Alternatively you can try the LTN mod.

[berggen]

TL;DR

A train stop condition that waits for the next stop to be enabled.

What ?

Current wait condition list is: Timed passed, Inactivity, Full cargo, Empty cargo, Item count, Fluid count, Circuit condition, Passenger present, Passenger not present.

The suggestion would be to add another one: "Next station enabled". It would become true iff the next station in the schedule was enabled. Usage would be more or less the same as the below images circuit conditions.

Currently you can achieve this functionality by using wiring to send signals about whether a given station type is enabled/disabled and wait for that, but it requires some finicky wiring (if the signal to leave hits the waiting train before the next station has become enabled, it will cause the waiting train to skip to the next stop immediately)

Screen Shot 2020-09-01 at 4.09.48 PM.png (99.63 KiB) Viewed 4939 times

Why ?

As a new player I recently proudly set a train schedule to go to the train depot, then a material pickup, then the material drop off. I expected it to wait at the depot until a load of cargo was ready to pick up, and was surprised instead when it would just cycle back and forth between the depot and drop off (wasting that precious fuel that it was picking up from the depot). This gets into a whole discussion around "skip conditions" or enabling and disabling train stops with relatively complex schemes. I think a pretty simple and elegant solution here is to add a wait condition that enables the expected behavior that trains do not skip to the next item in the schedule. This leaves the existing functionality intact, and may even allow a user to reason about the stop skipping behavior before seeing it in action. If you add this condition to the depot stop and material pickup stop in the above story, it will behave more like (some of us) expected.



I did look at the existing "New Types of Train Scheduling" post here (viewtopic.php?f=80&t=51028), and I hope this idea could be a simple feature that would provide a large fraction of the value of some of the more intricate ideas.

[conn11]

I think a pretty simple and elegant solution here is to add a wait condition that enables the expected behavior that trains do not skip to the next item in the schedule

A train stacker would also achieve your desired goal, having a loaded train (technically a buffer) ready in some sort of depot (though not necessarily a centralized one) until it can be unload.
Here's a thread about them. Or here on Reddit.

[berggen]

I think a pretty simple and elegant solution here is to add a wait condition that enables the expected behavior that trains do not skip to the next item in the schedule

A train stacker would also achieve your desired goal, having a loaded train (technically a buffer) ready in some sort of depot (though not necessarily a centralized one) until it can be unload.
Here's a thread about them. Or here on Reddit.

I think I failed to explain the original use case, or failing to understand what you mean by train stacker. My original attempt to 'fix' this problem in game actually used buffers, before I realized that I could simplify the buffer out.

Here's the user story I'm imagining:

1) You start with a "Load" and "Unload" station. Things are good, with your one train going back and forth.
2) At some point you add a new "Load" station and another train with the same schedule. Now these two trains take turns coming to the unloading station.
3) Now you add a new "Unload" station, but this one is low volume and you don't want trains coming here if it can't take a full train's cargo, so you start enabling and disabling it via circuits. Great. When it enables, someone comes and fills it back up. Otherwise both trains just keep going to the main "Unload".
4) You now add a few more "Load" stations (remote mines?). But you realize that trains keep going to the close mine that is almost out and takes 10 minutes to load a train. So you add enable / disable conditions to all of your "Load" stations.
5) Some of these new "Load" and "Unload" stations are remote and away from the fuel, so you decide to add a "Depot" station in the schedule to let these trains fuel up between cycles.
6) You realize one train is zipping back and forth between "Unload" and "Depot". After a confused moment you realize that it's because all of the "Load" stations are disabled, because the stations can't fill trains fast enough.
6b) (What you expected to happen): You wanted the train to go to "Depot", and then wait until it could go to "Load", and then wait until it could go to "Unload", the same way it did when you had just "Load" and "Unload". But instead, it's effectively forming a complete schedule with "Depot" and "Unload", and just bouncing between the two.
7) You come up with a complicated circuit control system where each station type needs (or a decider next to it actually) transmits a signal to the network indicating how many stations of a given name are open. Now trains wait for this signal to be positive before trying to go to the station that may be disabled.
8) After a while of staring at this finicky circuit network you realize that you just wrote an in game implementation of "Next station enabled".

[conn11]

Wich would make a train stacker viable.

Simply put your problem is, you have multiple trains from multiple load stations basically scheduled for one (ore few) unloading station(s).
You don't want trains to needlessly drive around and waste fuel.
The depot you are suggesting seems to be a centralized one.
I’m suggesting the use of a train stacker:
Multiple parralel lines of track to hold n amount of trains before a singular rail to the desired unloading station. All ends are controlled with chain signals, the train schedule is just set to go from A to B with the desired condition (e.g. Empty, circuit). Refuling can be done at the unloading sites.

Since you seem to use a circuit activated less frequent unload and a permanent unload, you should use stackers before any of those stations.
If a station is deactivated trains pass through it and will not be delayed, so no stacking will occur.

Since the explanation is a bit lengthy see the relevant parts in this video.
Using stackers is a much more plain and simple approach, than trying to do it via sheduling.

[ssilk]

Merged with same suggestion — ssilk

My opinion: the scenario is a valid request, because it enables the player to control where he wants to build the stacker. Otherwise he needs to put a stacker on each station, which is somehow stupid.

For example this is very similar to the need of a depot for the LTN-mod. The depot must be quite big, but the outposts can be small.

The question is, if the solution is right.

Here it is suggested to use conditional start. The problem is, how to get the signals from the outposts.

And there is my counter-suggestion: instead of implementation of this questionable function (it is questionable, because it makes only sense for this scenario) I suggest to implement a radio transfer of signals.

I really like the implementation of https://mods.factorio.com/mod/shortwave
Because it just does it’s job quite well and the idea to use items as “frequencies” is really, really nice.

[Pat4yczek]

I post this topic before
There are 2 solutions
They gonna add this wait conditions, to be honest it too easy to make this, They have already data to work with

Or

They Just update mod API to able make new wait conditions, that would be fun to See what People gonna create

[Guenni7]

Looks like there is a demand for this "feature", not sure why not one developer has joined the topic.

I want to explain WHY this idea is so good and the "Limit trains per station"-feature will not come close to it:

Let's imagine you have a lot of stations that provide goods, and a lot of stations that need that goods.
Then you can play around with 1:N or N:1 or N:N (nor recommended) station routes, you can limit the trains for stations to decrease unneccessary train movements in V1.1, but one thing you can not achieve: That the full trains from far away stations are able to wait in a stacker NEAR to where they are needed til they are needed (Without laying down a ton of circuit logic).
"Wait til next stop is not deactivated" is a simple and elegant solution for this, just like the devs like it in other cases.
It also doesn't seem to be complicated to code, or is it?

[Nosferatu]

As far as I remember a dev posted a workaround for this a while ago:

Create one train stop which is not accessible and name it the same as the stations you want to protect from being skipped.

When all stations of that name deactivate themselves this one will still be there.
Trains in the stacker will not be able to path to it so they will wait a signal "no path" until a valid stop comes back online

[SoShootMe]

... you can limit the trains for stations to decrease unneccessary train movements in V1.1, but one thing you can not achieve: That the full trains from far away stations are able to wait in a stacker NEAR to where they are needed til they are needed (Without laying down a ton of circuit logic).
"Wait til next stop is not deactivated" is a simple and elegant solution for this, just like the devs like it in other cases.
It also doesn't seem to be complicated to code, or is it?

The idea does seem simple, elegant, and not complicated to code. But I think the train limit feature can be used to have a stacker near(ish) to unload stops, with one combinator per stop and a circuit network covering the unload stops and stacker; something I don't think qualifies as "a ton of circuit logic".

The idea I have in mind is to have the stacker lead to an "{Item} Hold" stop set to send the circuit network to the train. Each "{Item} Unload" stop, with no stacker and set to train limit 1, needs a single decider combinator that outputs "{Item}=1" when a train can be fully unloaded. This output can be used to enable the stop and (via opposite colour wire) must be connected to the "{Item} Hold" stop.

Train schedules would be:

• {Item} Load: wait until full
• {Item} Hold: wait until circuit network {Item} > 0
• {Item} Unload: wait until empty

The basic principles are that {Item} Hold is always enabled, so trains will come to it (preferably subject to train limit based on stacker size), and there will always be at least one enabled {Item} Unload stop when the train's {Item} Hold wait condition is met. Of course, I'm doing this all in my head so there's a good chance I'm missing something...

[Guenni7]

As far as I remember a dev posted a workaround for this a while ago:

Create one train stop which is not accessible and name it the same as the stations you want to protect from being skipped.

When all stations of that name deactivate themselves this one will still be there.
Trains in the stacker will not be able to path to it so they will wait a signal "no path" until a valid stop comes back online

Wouldn't that mean that when all stations deactivate, the trains on their way to the stacker would stop with "no path" too?

The idea does seem simple, elegant, and not complicated to code. But I think the train limit feature can be used to have a stacker near(ish) to unload stops, with one combinator per stop and a circuit network covering the unload stops and stacker; something I don't think qualifies as "a ton of circuit logic".

Well, a ton was maybe a bit exaggerated, I just don't like to wire large areas with circuit cables.

[Nosferatu]

As far as I remember a dev posted a workaround for this a while ago:

Create one train stop which is not accessible and name it the same as the stations you want to protect from being skipped.

When all stations of that name deactivate themselves this one will still be there.
Trains in the stacker will not be able to path to it so they will wait a signal "no path" until a valid stop comes back online

Wouldn't that mean that when all stations deactivate, the trains on their way to the stacker would stop with "no path" too?

You don't use that trick on the stackerstation itself so trains can path there without problems.

[Guenni7]

You don't use that trick on the stackerstation itself so trains can path there without problems.

Ah, right.
And what happens to the trains that have exited the stacker and then all stations deactivate? Do they repath to the unreachable station (and stop) or go to the next waypoint?

EDIT: No, they do not. When several trains leave the stacker because one station is open, first train arrives, station closes and the other trains stop with no path, blocking all other train traffic. It would work with train station limit=1 when V1.1 arrives I guess.
Still, a train stop condition would be the better solution IMHO