What are the priorities for the train leave conditions?

[TheUnknown007]

It's certainly not worth the trouble to add parenthesizing and an appropriate UI for it.

As I've said before, the leave conditions don't really make train stations a lot more powerful than they were in 0.12. Even if you only had the "circuit condition" and the possibility to look into train wagons (connectable rails), you could do everything that you can do right now (and more) with reasonable effort without the need for special UI and all sorts of fine-grained conditions.

E.g.: "item count" = connect rails to station, use circuit condition; "train full / empty" = same if the rails output status signals that signify full (or empty) wagons; "inactivity" = counter that resets on wagon content change; "time passed" = simple counter

Nothing of this requires more than 2 combinators if you have connectable rails that provides reasonable outputs. You can also parenthesize to your heart's content, and even blueprint your "expressions" for re-use and sharing.

Also, show me a leave condition with more than, say, 4 terms and I'll show you that it's overengineered. That leaves simple expressions which don't require parenthesizing.

If you want powerful train routing you need "go to" or "jump to" inputs, i.e. you number the train stations on the schedule and then take the next stop from an input to the train station. So the trains won't be forced to follow a fixed route.

In short, I don't really care how fancy it is to tell the train (not) to leave, as long as I can't tell it WHERE to go after it leaves.

Excellent, if you don't think this is useful, make a suggestion for this stuff (or add something on the suggestions already made). But don't come here and tell me this is all completely useless and your idea is so much better. If you really think your idea is so great, go convince the devs it is. Tip: don't connect the rails, that is silly. Give the train stop an option to read the train contents (the same way a belt has such an option for its own contents)

Note: I, too, would be much happier with the ability to dynamically set the next train stop, but I think that I saw that a dev / moderator didn't really like the idea.

[siggboy]

I have made the suggestion in the post you quoted (why did you all quote it in full, BTW, not necessary).

Also, these suggestions where discussed at LENGTH in the thread where the devs asked for feedback (with a poll) about what should be added to circuit networks.

Connectable rails where also discussed in other threads. Of course you're right that a train station output would be similar (it's part of SmartTrains and I've also mentioned it just a few posts earlier). I personally think connectable rails are more flexible and correspond nicely to connectable belts. They also avoid the problem of requiring separate input and output ports on the train station (hard to represent graphically and not intuitive), and you could use them separately from a train station, e.g count trains in a waiting bay, even count the total amounts of stuff in the waiting bay, count trains passing a junction, and what's in them etc. etc. Much more powerful.

I, too, would be much happier with the ability to dynamically set the next train stop, but I think that I saw that a dev / moderator didn't really like the idea.

1. What the moderators think doesn't matter more than what you or I think. They're not part of the dev team and their opinion is an opinion like any other.
2. Where did the devs say they're opposed to having "goto"/"jumpto" scheduling? Can you quote or link something? Because I'm quite involved and I don't remember anything of this sort. Also the devs very rarely completely rule out adding certain features in advance.