Train Conditions in Train Stop, not in Train

[ssilk]

TL;DR
In viewtopic.php?f=6&t=28453#p20447 Juergen Erhard suggest to put the train conditions into the train stop instead of the train.
Indeed I think this is a very good idea, so I make now an own suggestion out of it.

How this might work?
Cause it makes no sense to break the current (working) behavior, I think the train conditions in train stop is a new research, which reveals a new train-stop-type or extends the train-stop with a new interface for the condition-setting etc.

When a train stops at such a new train-stop it uses the waiting conditions of the train-stop, and overrides the waiting condition of the train.
But by default this new train-stop behaves identical to the old. Which means the default is "Use waiting condition of train". Sorry, two steps forward, one step back, but I think this is the right way it should work. :)

Besides that new default, there are similar waiting conditions as in the trains. The interface could look identical.

Exit and Entry condition
Instead of "waiting condition", we might rename it to "exit condition". That has some reasons, cause unlike the trains, that needs to be very stupid (for many, many reasons), we can have not only an exit condition, but also an "entry condition". Which means in general: We can turn train stations on and off.

Besides other conditions an entry condition might be "if train is routed to this stop", "if no train is routed to this stop", "if train is stopped" (and vice versa), and combination of both, "if amount of fuel is below xxx joules" (refuel stations) etc.

The details of this is of course more or less a new subject on it's own, but for now I think this is enough to be said.

Train stop with identical name
I'm not sure, if it makes much sense that train-stops with equal names can have different waiting conditions (this is a subject for discussion!).

But for big stations it makes sense to be able to change train condition only once for all stations with the same name. For this case it would be useful to be able to interlink the conditions of train stops.

Input and Output Circuits
The new train stop needs two input circuits (for entry- and exit-condition to be set from external) and one output (to read train contents etc.).

Cause of that and for the case that the new train stop is not only an interface extension, the new train stop might be a bit bigger (not only graphically! Maybe it takes 2x4 tiles?) because of that.

Interface changes for the trains
The interface should work exactly as now. There is only a new feedback in the train conditions and in the train-stop-list. It shows in a simple way:
- This train stop behaves like a "normal" train stop. That might be an "old" train stop, or a train stop, which has default waiting condition.
- This overrides the trains waiting-condition. And in that case it shows also the current conditions (entry/exit) and expecially for the entry: red or green, if currently all open or closed and blue, if minimum one station is opened.

Interface changes for the stations
There should be some global menu for all train-stations (like for the trains), which enables also to see
- Normal train station or new
- For new stations it shows the current waiting condiions and state of entry and exit.
- Stations with equal names are handled here as different stations (but grouped together). This is unlike for the trains!
- You should see also, if stations are interlinked (same conditions for all, see above)

[zebediah49]

Yes. This would make design faster for a number of workflows: you can have the conditions "car is empty -> leave" programmed once on the station, rather than on every train using the station.

Train stop with identical name
I'm not sure, if it makes much sense that train-stops with equal names can have different waiting conditions (this is a subject for discussion!).

But for big stations it makes sense to be able to change train condition only once for all stations with the same name. For this case it would be useful to be able to interlink the conditions of train stops.

If you mean some can be on and some can be off, that is critically important. If you mean "all stations called 'Iron Mine' have the same entrance condition of 'iron > 4000'", I think it would be fine to have them tied together. In the case where the user wants them to be different, they could probably accomplish that task with circuit network conditions (i.e. all stations are "wait for A>0", and then each station has a separate circuit to determine 'A').

I personally think that having them be separate but copy-pastable would be the best solution though. Or maybe a "make all stations with my name have my settings" button.

[ssilk]

Well. I think when you interconnect trains stops of the same name together, it could add a new condition "Automatic round robin", which opens the entrance of only one train stops at a time and closes in the moment, one of that trains chooses a path to that special stop and round robs to the next station in the list. The result is, that each train stop gets the same amount of trains.

The same needs to be computed really complicated with circuits.