Priority and other fancy signaling without "programmimg"

[Alberth]

Besides priorities, a desire that often pops up is merging or separating of fast and slow traffic (pax and freight usually) in a nice way.
The former is either about unifying the speed of everything, so fast trains don't stop in front of signals when stuck behind a slow train, or pass-by sections where both kinds diverge for a section, so fast pax trains can overtake slow freight. (probably with a priority merge at the end of the section).

A more extreme form of the latter is building parallel tracks all the way, and separate traffic at the start.

Having a speed limit is something you cannot do currently, I think. Splitting traffic could be done with waypoints as well, so maybe this is less important.

[Eddi]

you can set a speed limit in orders (e.g. between two waypoints), but i find this a rather bad solution. better IMHO would be "timetabling" the signals at the merge, so there will be a timeframe for (slow) freight trains, a timeframe for a gap, and a timeframe for (fast) passenger trains.

[WWTBAM]

It wouldn't have to be a speed limit. It could be dine with a cargo is (not) passengers expression.

[Pyoro]

I really loved those cargo separation possibilities in TTDP. It might not be important for gameplay, but it just feels nice if at stations trains use the visually "correct" platform etc. And you don't need to bother with running out of space for waypoints or adding them to orders or whatever, the signals take care of that and if you add additional trains they'll automatically be "sorted". Great feature, imo. And really not that difficult to understand [if] you understand basic logic. Or whatever that is. ^^

[michael blunck]

couldn´t the same behaviour be established by placing a programmable signal at the location of your lo-prio signal, checking signal states of block signals located at the location of your hi-prio signals? I.e.: SHOW red IF sig1 OR sig2 == red?

With 2-tile long trains and 2-tile long signal distance you would have to connect with every second signal which is between the beginning of hight prio and the junction, not just the first one.

Well, that´s a problem with your short and frequent block signal distance. But nevertheless, this could be handled by one single programmable signal as well.

YNM, what's your opinion about programmable signals then? Would you like to have them?

First of all, not anyone would have a need for programmable or restricitive signalling, hence there´ll be always a small crowd of potential users. As already written, there´d be more use cases and thus more demand and acceptance for restrictive signalling, but nevertheless, most people would have never a need for more advanced signalling than just block or PBS signals.

Now, IMO the main reason for people potentially interested in programming signals in TTDPatch (most users got never aware of their mere existence!) but not using them, would have been the need to get accustomed to a more sophisticated GUI than that for block, presignals, or PBS signals. But I think that was a failure, because even setting up a medium-sized presignal block might have been trickier than "programming" a programmable signal in TTDPatch. In any way, there was a clearly arranged GUI where the user could program a signal just by some mouse clicks, the only cumbersome thing I see here was that prefix notation which might have been quite unusual to many users. But anyway, most people should understand the meaning of "and" and "or", don´t you think?

fast pax trains can overtake slow freight.

This is neither a case for waypoints nor for special orders nor for time-tabling. But this is the classical use case for "restrictive signalling".

It wouldn't have to be a speed limit. It could be done with a cargo is (not) passengers expression.

Right, i.e. restrictive signalling.

I really loved those cargo separation possibilities in TTDP. It might not be important for gameplay, but it just feels nice if at stations trains use the visually "correct" platform etc. And you don't need to bother with running out of space for waypoints or adding them to orders or whatever, the signals take care of that and if you add additional trains they'll automatically be "sorted". Great feature, imo. And really not that difficult to understand [if] you understand basic logic. Or whatever that is. ^^

Those are "restrictive signals", not "programmable signals":

The difference is that "restrictive signalling" is based on train properties, and how they´re handled by the signal in question, but "programmable signalling" is based on evaluating other signal´s states.

Although, in TTDPatch both were using the very same GUI.

regards
Michael

[Eddi]

fast pax trains can overtake slow freight.

This is neither a case for waypoints nor for special orders nor for time-tabling. But this is the classical use case for "restrictive signalling".

maybe you misunderstood me here, i wasn't talking about separating the passenger trains from the freight trains, but about merging into one main line.

Like when they come from a station like this:
Cottbus Transport, 21. Okt 1925.png
The exit signals of the freight station should be forced to red for a portion of time to make a gap for passenger trains.

[michael blunck]

[...] from a station like this:
[Cottbus Transport, 21. Okt 1925.png]
The exit signals of the freight station should be forced to red for a portion of time to make a gap for passenger trains.

Well, there are 3 free tracks and the only train needs still another 92% for a full load?

BTW, nice town, Harzberg.

regards
Michael

[YNM]

Like when they come from a station like this
Cottbus Transport, 21. Okt 1925.png
The exit signals of the freight station should be forced to red for a portion of time to make a gap for passenger trains.

Yeah, that'd be mostly the only rarely and occasional potential use for programmable signal, if that waiting at signal option ever realized too as well...

[adf88]

Is this about time-based signal switching? Programmable signals are event-based...

[2457]

i think.. after reading this topic, that the main problem is not the programmable signal it self.
fancy stuff can be built without programmable signals, restrictive signals and waypoints.
ottdcoop does that on epic level.

actualy they do program signals, just use the tracks them self as a very crude UI.
I would compare this to computers.
instead of having any software, every program has its custom circuit board.

sure, it can even be better for a specific task.


but, there are limitations at the present moment at ottd signalling.
imagine a signal, that is a hybrid blend of PBS and pre-signal.
there is no easy way to emulate that via tracks, or exsisting signals.

i think the thinkering should be around an easy to use interface, programmable signals are not wrong as an idea.
but, they do require quite a lot of fiddling till an imlentation that can be used with ease by the majority of the players can be realised.

for one, there is the event and time driven signalling.
they do open up new possible constructions.
surely a train can be used to form a "clock", but it is again just a waste of space if time driven signals are available.
splitters, flip-flops, and a whole lot of things require valuable tiles to construct, while not at all impossible, it is just again waisting space. nothing more than a "hack".


the best part of a proper implentation of programmable signals would be, that there would be no forcing of use.
those who prefer only block and pre-signals can just use those, or if needed use tracks as "hardwire" programming.

sure, alternative routes may provie usefull features too, but still i would think that instead of thinkering how to avoid programmable signals and use some clumsy hacks instead , a more feasable UI and logic for programmable signals may prehaps get even more benefical features.

[adf88]

Nice points but you don't refer the main topic much. So what's your opinion?

To all of you, PLEASE, DON'T GO OFF-TOPIC. I remembering you this topic is about PREPROGRAMMED signals (like instead of programmable signals), and it's not about restrictive signals.

Litany, again....

[michael blunck]

I remembering you this topic is about PREPROGRAMMED signals (like instead of programmable signals), and it's not about restrictive signals.

Now, this makes sense. It might not have been clear from the outset though («Priority and other fancy signaling without "programmimg"»). Let´s keep "pre-programmed signals" as a working title.

So, let´s update our list of signal types from above:

- block signals
- pre-signals
- PBS signals
- restrictive signals
- programmable signals
- pre-programmed signals
-- priority signals

Growing nicely ...

regards
Michael

[Hyronymus]

Aren't they all filling different parts of a "hole" in the game's signal code? Or is there an overlap that can be dealt with in another way more effectively?

[YNM]

Well, let's make a "wishlist" what kind of action that we all would want :

- Path-based
- Priority-based (whatever priority : line, weight, traction, speed, cargo)
- Time-based

Anybody to adds that ?

[Alberth]

Wishlists always quickly grow out of hand, or bundle several orthogonal concepts together that you cannot implement nicely in graphics.
In this case, wish-lists will likely end up with yet another form of programmable and/or restrictive signals, which is not what this topic is about.

In my view, the aim here is to make some common forms of more advanced signaling available for a large audience, as well as showing in the main-view what is happening.

Thus I'd say more concrete use-cases, if possible with signal graphics or ideas for them, would be useful.

[YNM]

Well, I make a wishlist thats really covers everything into a specific portion.

Pre-signal are path-based signal that holds everything in a farther place. When used in systems, they can give a priority-based signal effect.
Programmable signal use cases can be divided into path-based signal and priority-based signal.
Restrictive signal are a form of priority-based signal, by only allowing a certain number of train that fulfills the condition to pass/divert.
PBS are a path-based signal, of course.
Block signal are path-based signal that only allows one to enter and wait for it to clear off a segment.

The only thing that's new is time-based signals, which previously needs a priority system combined with "regulator" : mostly locomotive.

[Dave]

Nice points but you don't refer the main topic much. So what's your opinion?

To all of you, PLEASE, DON'T GO OFF-TOPIC. I remembering you this topic is about PREPROGRAMMED signals (like instead of programmable signals), and it's not about restrictive signals.

Litany, again....

I think the issue you have is that your ideas so far can all be replicated in more efficient ways. I don't want to discourage you, because any level of supplying ideas is pleasing, but do think about how your ideas would be implemented.

Also, remember that TTD Patch already fulfilled many of your wishes with restrictive/programmable signalling - so it's natural the concept will always refer back to that.

[michael blunck]

Yes, IMO it makes absolutely no sense to clutter the (existing and/or envisaged) signal system any further. Like Eddi said, something like this would be a severe obstacle in implementing a "unified", more consistent, signalling system one day. And even reasons like "this will be available for a large audience" don´t justify it, firstly because this underestimates the user, having already learned to fight with much more non-intuitive features of this game (PBS fine-tuning, advanced orders, autoreplace, time-tabling, cargodist, ...), and secondly, because it doesn´t comprehend this game as one that can be conquered on very different levels of complexity.

This is not a simple game.

But, the novice user can start simple. He does not need to start with the most complex available features. He does not even need to start with "programmable" or "restrictive" signals, if implemented some day, if that should be beyond his understanding. He can always start with basic block signalling or simple PBS.

I don´t see any problem with this approach. IMO, there´s absolutely no need for introducing ill-conceived "kludges", like already seen in the past.

regards
Michael

[2457]

but even so, we are heading somewhere, programming individual singals may not be an option.

but a new/old way has been mentioned , pre-programmed signals.
preahps just some new signal types need to be introduced into the game, pre-programmed just like the pre-signals.


maybe a list of things signals should deal with be listed, so a set of signalls to achieve these can be made ?

[michael blunck]

maybe a list of things signals should deal with be listed, so a set of signalls to achieve these can be made ?

Doesn´t need to. Everything can be handled by either "programmable" signals and/or "restrictive" signals.

(Well, TTDPatch had some more "advanced" signals (invertible signals (invert the one-way/two-way routing behaviour of selected signals), through signals (allow PBS reservations the opposite way through selected one-way signals)), but these might not be appropriate inside OTTD´s PBS signalling scheme.)


And just again, because these terms seem still not to be understood:

restrictive signalling
This approach is based on train properties (train length, speed, power, weight, cargo, station and depot orders, distance from signals, ...), and how they´re handled by the signal in question, realized by setting pathfinder weights.

programmable signals
These are signals with their signal aspects (red, green) being based on evaluating other signal´s aspects (not depending on train properties).

I.e., two very different application fields. Note that the term "programmable" doesn´t refer to the GUI (but to the fact that its behaviour is being totally controlled by the signal "rules" set by the user), because also a "restrictive" signal would have to be "programmed", GUI-wise.

regards
Michael