News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Waypoints act no longer as signals

Started by prissi, August 09, 2011, 08:44:02 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

prissi

I propose that waypoints act no longer as signals. This would cure two points, i.e. the short stop at a waypoint and an sometime unexpected behaviour of trains.

Fabio

This means waypoints would only be used in routefinding (choosing the route passing through that point)?
i think this is also the most intuitive use for them.

jamespetts

I agree that this is a sensible idea.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vonjo


Ters

I have been considering proposing a new type of waypoints that only guide the path finding, but simply changing the behavior of existing waypoints to no longer act as invisible block boundaries is just as fine.

Dwachs

I have never noticed that waypoint act as signals  :-X
Parsley, sage, rosemary, and maggikraut.

Colin

Quote from: prissi on August 09, 2011, 08:44:02 AM
I propose that waypoints act no longer as signals. This would cure two points, i.e. the short stop at a waypoint and an sometime unexpected behaviour of trains.

Great idea Prissi, the sooner that's implimented the better. It will make it so much easier to use Waypoints as routing guides.
I may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

wlindley

Playing devil's advocate -- Currently you can create a two-station line, with a single passing side-track in the middle, and by setting a waypoint in each direction (one on the side-track, one on the main-line) operate two trains. If you watch the block reservation, you will see each train depart its end-station and reserve the track up to its waypoint; then the trains meet each other in the siding and proceed to the alternate terminus.   This would no longer be possible.

That said, I support the change -- because it would force proper signals to be installed.  Very early railways before the advent of signals can still operate by using stations, right?

skreyola

That pause has always bothered me. It's one reason I don't use waypoints.
:support:
--Skreyola
You can also help translate for your language with SimuTranslator.

Colin

Quote from: wlindley on August 09, 2011, 07:28:17 PM
Playing devil's advocate -- Currently you can create a two-station line, with a single passing side-track in the middle, and by setting a waypoint in each direction (one on the side-track, one on the main-line) operate two trains. If you watch the block reservation, you will see each train depart its end-station and reserve the track up to its waypoint; then the trains meet each other in the siding and proceed to the alternate terminus.   This would no longer be possible.

That said, I support the change -- because it would force proper signals to be installed.  Very early railways before the advent of signals can still operate by using stations, right?

I suppose you could always build three stations and use Platform Choose Signals but the your passing train would have to stop at the center one if the other two were full. Nah! on second thoughts it would be better to make it so that Choose Signals could be made to detect a train that wasn't scheduled to stop, and pass it through the center line?
I may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

prissi

It will not influence the routing whatsoever. If a train has to turn around at a waypoint or similar stuff, it will search a new route from there.

TurfIt

Is something like this workable?

prissi

Not yet, since it ignores the fact that waypoint cancel choose signals and act as signals. (Maybe the latter is rather unexpected and should go anyway?)

jamespetts

Quote from: prissi on August 31, 2012, 08:00:58 AM
Not yet, since it ignores the fact that waypoint cancel choose signals and act as signals. (Maybe the latter is rather unexpected and should go anyway?)

That might be sensible - it would be helpful if, if at all possible, waypoints could have no effect on signalling at all.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Isn't that the title and purpose of this discussion?

AP

I support this proposal.

As a marginally-related aside, I have also previously suggested a 'signal that does-not act as a waypoint' (i.e. a "one way sign" for rail).

Fifty

Quote from: AP on August 31, 2012, 05:08:01 PM
(i.e. a "one way sign" for rail).

Such a thing exists, at least in pak 64 and pak 128. I think it's called "rail close" or something like that.
Why do we park on the driveway and drive on the parkway?

prissi

#17
The function of a selective choose signal cancellation by a waypoint seems imho needed (but that is not difficult to add anyway).

With the above implementatation a choose signal before the waypoint could lead to the situtation that the schedule is not advanced. If there are two waypoints before the next stop, then the convoi will go back instead forward at the end of the route.

EDIT: see the attached patch, which still needs testing.

TurfIt

Choose signals! Knew I forgot something.  ;D

The implementation in the -2 patch makes sense. A convoi enroute to a waypoint that encounters a choose signal/sign should ignore the choose function.
I can think of a use for waypoints between the choose and the station; Waypoints used to limit the possible platforms chosen from. But it's such a limited/specialized use it's hardly worth the time to implement IMHO.

Quote from: prissi on August 31, 2012, 07:36:55 PM
If there are two waypoints before the next stop, then the convoi will go back instead forward at the end of the route.
I assume this is only for the choose/waypoint/waypoint/station case in my original patch? And not an issue in -2?

Quote from: prissi on August 31, 2012, 07:36:55 PM
EDIT: see the attached patch, which still needs testing.
Much testing still needed.
Found fpl_target wasn't cleared when schedule edited while enroute to a waypoint. To be fixed tomorrow...

p.s.
GCC doesn't much like your -2.   ;)
vehicle/simvehikel.cc: In member function 'bool waggon_t::is_weg_frei_choose_signal(signal_t*, uint16, int&)':
vehicle/simvehikel.cc:2637:1: error: jump to label 'skip_choose' [-fpermissive]
vehicle/simvehikel.cc:2586:8: error:   from here [-fpermissive]
vehicle/simvehikel.cc:2589:23: error:   crosses initialization of 'const grund_t* const target'
make: *** [build/default/vehicle/simvehikel.o] Error 1



Vladki

The fact that waypoints cancel choose signals, is IMHO also not intuitive in the same way as the fact that waypoints act as signals.
Intuition says that end-of-choose signs shall cancel all effects of choose signals, including path reservation. I was quite surprised to see a train reserving path through the whole map, because of choose signal, enven when his path went over an end-of-choose sign. Perhaps a possibility to combine end-of-choose with a signal should be worth considering.

On the other hand, when I learned that waypoints act as a sort of one-way signals I was glad, because this allows for some tricky configurations on single track railways that cannot be done with classic one-way or two-way signals. I needed a one-way signal, that would be ignored if passed form the other side. So, if waypoints are going loose this functionality, I'd like to see new sort of one-way signals.

What about stations, will they still act as signals?

Ters

Is more complexity the solution to non-intutiveness? Though I've often wished for more signals to make thing work just the way I like, I sometimes wonder if we'd be better off without presignals and choose signals. The former is mistaken for something else, while the latter is often used where it shouldn't.

If more complexity is the direction to go, my primary wish would be for the ability to have different signals for each direction on the same tile. A combination of a no entry sign and a one-way signal would be equal to the one-way signals we have today. Only signals should work as signals, that is places where reservation temporarily stops. This would eliminate the need for long block signals, though it would create a challenge for reservation when a train changes direction.

prissi

Since the blocks went away, signals only working in one way are easily possible. However, the would require lots of clicks for the most common tasks. I think a signal, which has a different graphics an only works in one way would be more helpful. That way pak designer can decide between easy access and complex handling.

Ters

It's just that I have sometimes found myself wanting to place a choose signal or presignal, as well as a normal signal on the same tile, but facing in opposite directions. Having signals only affect one direction always, and be able to share it's tile with another, would solve both that problem and my more common need for one-sided signals.

How difficult would it be to have a tool that adds both a one-way signal and a no entry sign on the same tile with a single click, and swaps them on the next? Though if you need to remove just one of the signals, the game would need a way for the player to tell which one.

Vladki

I think it's not necessary to have two different signals on the same tile. If the one way signal is ignored from the other side, then you could put different signals on adjacent tiles and get almost the same behavior as if they are on the same tile.

Prissi: I would really like to see such signals, as they are much closer to reality, is there anything I can do to help to make such signals?

Ters

Quote from: Vladki on September 02, 2012, 09:18:54 AM
If the one way signal is ignored from the other side, then you could put different signals on adjacent tiles and get almost the same behavior as if they are on the same tile.

The problem is that most of the time when different signals for each direction would have helped, I don't have a lot of space. Setting aside a single tile with just a straight track (no junction) might be hard enough. Still, single sided signals are on their own more than useful enough to be done first. It's just that one then either has to place a no entry sign on the next tile to replicate today's behaviour, or have two types of one-way signals, both of which I imagine would be confusing for beginners.

Fabio

#25
Signals have IsSignal=1 in their dat.
One way signs have OneWay=1.
It would be enough if IsSignal parameter would only be bidirectional (i.e. Not working anymore as one way, but possibly being read and obeyed only in one direction).
Paksets could then make simple signals (IsSignal), one way signs (OneWay) and one way signals with present behavior (IsSignal + OneWay).
The parameters would add to one another, just like one way + speed limit for Autobahn signs.




I would love to change presignals behavior.
If the path till next signal/presignal (1) is reserved, show red and stop the convoy.
If the path till next signal/presignal (1) is free and from there to next signal/presignal (2) is free again, show green, reserve the track till (2) and let the convoy pass.
If the path till next signal/presignal (1) is free BUT from there till next signal/presignal (2) is reserved, show yellow, but reserve only till (1),  read which convoy is reserving from (1) to (2), read its current speed and let the convoy pass with that max speed limit.

This would help greatly when a track is shared by trains with different speed limits.

kierongreen

QuoteThis would help greatly when a track is shared by trains with different speed limits.
But not when using presignals to help avoid blocking junctions.

Ters

The name "presignal" really needs to be changed. After that, we can think about whether the benefits of introducing presignals to the game outweighs the drawback of more complexity.

Vladki

I like Fabio's proposal about presignals, even if such signal will be called some other name. Anyway, I use pre-signals on junctions which could be solved with signals obeyed only in one direction. So if such signals are implemented, pre-signals might become unnecessary, and used for speed signalling.

merry

#29
OK, this thread is addressing a number of 'known issues/complexities' in way-points and signalling.

I can see the following issues which people want to address:

WAY-POINTS cause an end of reservatoin in the middle of a siganl section. This has two problems: one eye-candy, in that the train stops before calculating the route ahead; one functional, in that deadlocks can be created if one is not exceptionally careful. BUT way-points are also used to force routing in complex trackwork, and the routing effects of any change in behaviour will need to be carefully assessed.
Proposed solution: at or just before the last signal before the waypoint, the route from the waypoint to the next stop/waypoint should be calculated, which is necessary to allow reservation of route from the waypoint up to the next affected signal. To avoid the graphical 'glitch', said route calculation must probably be be a background task.

CHOOSE SIGNALS are terribly non-intuitive for most players, and often have unintended consequences, as they choose & reserve route through all signals ahead up to the next stop/way-point. I'd suggest this is not a helpful behaviour: a real-life junction signal generally reads only onto the next running signal, which might itself be a splitting (junction) signal).
Proposal: choose signals be modified to reserve route only up to the next normal signal or end-of-choose, whichever is met first. For me, and I suspect most other players, long-range choose is unnecessary at best, and downright disastrous at worst (i've had a network take a game year to recover from a major choose reservation oddity). I know this changes a long-standing behaviour, but I have never seen a justification, only a statement that 'it is'. There are also ways to avoid wrong-direction traffic in complex junction areas by using no-entry signs.

NORMAL SIGNALS are available in 2 'flavours', neither of which replicate a common real-world signalling behaviour. A signal can be 'stop both ways' or 'stop 1 way, no-entry reverse'. In real life, back-to-back signals are incredibly rare (they do exist but only in special circumstances). In the game, they are a recipe for easy deadlock especially for the novice. Real life signals are obeyed in one direction, but have no effect on traffic passing the other way. This is very desirable to allow sensible signalling to be implemented. Rail 'no-entry' signs would be needed to build effective signalling implementations, but those can exist already! The 'pre-signal' woudl be nearly redundant if this were done, as blocked junctions could largely be avoided with correct signal placement.
Proposal: amend (or allow paks to implement) the basic signals such that a signal is by default obeyed 1-way, and has no effect (passes traffic) the other. This is correct rail signalling behaviour. Implement rail 'no-entry' signs in any pak choosing this behaviour, if not already present. Known issue: if some paks are this new behaviour, and others the old, the graphics will need to be designed to avoid confusion. Also, it'll break lots of rail networks when they are imported.

PRE-SIGNALS are not well understood. The name is incorrect, they are 'TWO-BLOCK' signals. Currently, with the 'stop both ways' signal being the only one that can be used on single bidirectional lines, two-block signals are absolutely essential. The above change in signal behaviour would make the existing 'presignal' or 'two-block' signal nearly (but not quite) obsolete. The idea of implementing speed signals ('Distants' in UK/Aus parlance) is not really needed. Experimental is planning to implement multiple aspect signalling and speed-related braking so a fast train will brake earlier, perhaps a couple of signals before the end of it's reservation.
Proposal: keep the signal, but only ever refer to it as 'TWO-BLOCK' signal.

Two related (and indeed dependent) issues not directly discussed above are:

LONG-BLOCK signals - Rarely do i need these, BUT they are valuable and i propose Long-Block signals should be kept, unless the change in platform behaviour (below)  is implemented and routing always operates throughout a signal block to the next signal, regardless of platforms and way-points.

PLATFORMS are a form of signal, if a train stops - because they are waypoints. I am uncertain about how platforms should be considered.
If we implement the waypoint change (which affects stops too, perhaps?), and my suggested change in normal signal behaviour, then logically platforms should cease to be implicit signals as that only stems from the existing waypoint issue (the root thought in this whole thread). Instead, a signal can be placed at a platform end if needed, and a no-entry at the other end to prevent reverse direction running. This gives immense flexibility in station design and lots of control over operation.

Whew! Another monster post. I don't contribute often, and that must be why...
...anyway, hope the above is a useful summary of the discussion with some suggestions thrown in. The thread seemed to be starting to ramble on...so I thought it was time to bring together the very much related issues. Thanks for the opportunity to put forward & crystallise some of my long-standing ideas about signals in ST.

TTFN!
Merry

PS you'd never guess I have a particular interest in signalling and railway operations, would you?

Ters

Quote from: merry on September 03, 2012, 01:28:58 PM
CHOOSE SIGNALS are terribly non-intuitive for most players, and often have unintended consequences, as they choose & reserve route through all signals ahead up to the next stop/way-point. I'd suggest this is not a helpful behaviour: a real-life junction signal generally reads only onto the next running signal, which might itself be a splitting (junction) signal).
Proposal: choose signals be modified to reserve route only up to the next normal signal or end-of-choose, whichever is met first. For me, and I suspect most other players, long-range choose is unnecessary at best, and downright disastrous at worst (i've had a network take a game year to recover from a major choose reservation oddity). I know this changes a long-standing behaviour, but I have never seen a justification, only a statement that 'it is'. There are also ways to avoid wrong-direction traffic in complex junction areas by using no-entry signs.
Choose signals are for reserving one of several related platforms. The easiest way of doing that is simply to reserve all the way there. However, many players seem to use choose signals where they shouldn't. In addition, a choose signal's dynamic behaviour is a bit at odds with the otherwise static routing in Simutrans.
Quote from: merry on September 03, 2012, 01:28:58 PM
NORMAL SIGNALS are available in 2 'flavours', neither of which replicate a common real-world signalling behaviour. A signal can be 'stop both ways' or 'stop 1 way, no-entry reverse'. In real life, back-to-back signals are incredibly rare (they do exist but only in special circumstances). In the game, they are a recipe for easy deadlock especially for the novice. Real life signals are obeyed in one direction, but have no effect on traffic passing the other way. This is very desirable to allow sensible signalling to be implemented. Rail 'no-entry' signs would be needed to build effective signalling implementations, but those can exist already! The 'pre-signal' woudl be nearly redundant if this were done, as blocked junctions could largely be avoided with correct signal placement.
Proposal: amend (or allow paks to implement) the basic signals such that a signal is by default obeyed 1-way, and has no effect (passes traffic) the other. This is correct rail signalling behaviour. Implement rail 'no-entry' signs in any pak choosing this behaviour, if not already present. Known issue: if some paks are this new behaviour, and others the old, the graphics will need to be designed to avoid confusion. Also, it'll break lots of rail networks when they are imported.
I've seen a lot of signals back-to-back here in Norway. They're at the edge of stations, where one signal allows entry, and another allows exit. There also might be some distance between them. In Simutrans terms, the entry signal could be a choose signal, depending on the station. Signals also stand back-to-back between blocks on single tracked lines (which most lines in Norway are), and possibly dual track lines where each track can be run both ways. These won't work in Simutrans, as they would cause deadlocks without human guidance.

Signals in Simutrans are by the way actually front-to-front, which I would assume was rare in real life.

I think someone once commented that in some country, or maybe just on some lines, seeing the back of signal actually meant that you were going the wrong way and should stop.
Quote from: merry on September 03, 2012, 01:28:58 PM
PRE-SIGNALS are not well understood. The name is incorrect, they are 'TWO-BLOCK' signals. Currently, with the 'stop both ways' signal being the only one that can be used on single bidirectional lines, two-block signals are absolutely essential. The above change in signal behaviour would make the existing 'presignal' or 'two-block' signal nearly (but not quite) obsolete. The idea of implementing speed signals ('Distants' in UK/Aus parlance) is not really needed. Experimental is planning to implement multiple aspect signalling and speed-related braking so a fast train will brake earlier, perhaps a couple of signals before the end of it's reservation.
Proposal: keep the signal, but only ever refer to it as 'TWO-BLOCK' signal.
I agree, and have for quite some time.
Quote from: merry on September 03, 2012, 01:28:58 PM
LONG-BLOCK signals - Rarely do i need these, BUT they are valuable and i propose Long-Block signals should be kept, unless the change in platform behaviour (below)  is implemented and routing always operates throughout a signal block to the next signal, regardless of platforms and way-points.

PLATFORMS are a form of signal, if a train stops - because they are waypoints. I am uncertain about how platforms should be considered.
If we implement the waypoint change (which affects stops too, perhaps?), and my suggested change in normal signal behaviour, then logically platforms should cease to be implicit signals as that only stems from the existing waypoint issue (the root thought in this whole thread). Instead, a signal can be placed at a platform end if needed, and a no-entry at the other end to prevent reverse direction running. This gives immense flexibility in station design and lots of control over operation.
I've also been thinking along these lines for signals. It's not quite realistic in terms of how I understand signaling works over here, but I don't think that would be easy to simulate.

merry

Quote from: Ters on September 03, 2012, 03:01:39 PM
Choose signals are for reserving one of several related platforms. The easiest way of doing that is simply to reserve all the way there. However, many players seem to use choose signals where they shouldn't. In addition, a choose signal's dynamic behaviour is a bit at odds with the otherwise static routing in Simutrans
Absolutely. The problem comes in mixed-traffic networks, where one service stops at a platform, but another may pass through non-stop. Even worse, ECS & Light engine trains ['Empty Carriage Stock'='dead-head' for the Americans amongst you (I always thought of dead-heading as an autumnal garden activity...)] will route as they like. These can result in long reservations beyond the station. Hello to deadlock!
And although way-points are a workaround, they are also a horrible kludge, and make a mess of schedules on a complex mixed-traffic network.
ST routing is indeed static, and I suppose that choose signals are the rather elegant kludge to get round that. I do think choose signals would be better if the end-of-choose were to be properly obeyed in all circumstances

Here's another proposal: Choose should 'give up' on a branch route when (a) a viable platform is reached, (b) another non-useable platform of the correct station is reached (c)end of choose is reached (d) after a (quite restricted, perhaps 20 tile) distance, (e) a signal in the running direction is reached , unless it's mid-platform, and (f) should never pass through another platform (of the intended or any other station). That's make it quite safe, and it'd still choose a directly accessible platform. I only use choose at the immediate entry to a station, and that is i believe the intended result. With the above rules implemented, choose would, I believe, work correctly and not put the network at risk of excess reservation.

QuoteI've seen a lot of signals back-to-back here in Norway. They're at the edge of stations, where one signal allows entry, and another allows exit. There also might be some distance between them. In Simutrans terms, the entry signal could be a choose signal, depending on the station. Signals also stand back-to-back between blocks on single tracked lines (which most lines in Norway are), and possibly dual track lines where each track can be run both ways. These won't work in Simutrans, as they would cause deadlocks without human guidance.

Hmm, I think there is some terminology here: I mean 2 signals reading in opposite directions on the same line, located at exactly the same point, certainly without an overlap between them.
It is OK to have one signal at the end of a platform, protecting the line beyond, and another the other side of the station entry pointwork ("throat"), protecting the entrance to the station. If there are two platforms, one each direction, and the signals allow traffic to pass the in the reverse direction [which is normal], this would be OK in Simutrans.

QuoteSignals in Simutrans are by the way actually front-to-front, which I would assume was rare in real life.
I suppose so  :) - being in the same square it's purely a graphical issue, the function's the same. [I think it's just UK English usage to say back-to-back]

QuoteI think someone once commented that in some country, or maybe just on some lines, seeing the back of signal actually meant that you were going the wrong way and should stop.I agree, and have for quite some time.I've also been thinking along these lines for signals. It's not quite realistic in terms of how I understand signaling works over here, but I don't think that would be easy to simulate.
That is not the way it works in most places. On a bidirectional line, one has to see the back of signals, and ignore them, otherwise the signals woudl have to clear in the reverse direction which is dangerous. In semaphore usage, that means the arm must be on the correct side of the post, otherwise you can't tell when a silhouetted signal reads onto your direction [OK, in the UK drivers must have route knowledge, so should be well aware which signal is which, but it's an important design feature to avoid confusion - and also off topic so let's ignore this!].

For bidirectoinal lines, there is some restricted opportunity in Simutrans to have signals mid-block. Let's do some ASCII art!! > is a signal allowing traffic to pass in reverse, P is a platform, <> is a two-way signal, |> is a signal not allowing traffic in reverse, N> is a rail no-entry All signals allow traffic in the arrow direction.

___>__N>_PPPP__>____<_________________________>___N>_PPPP_>____
    \_<__PPPP__<N_/   one bidirectional line    \_<__PPPP_<____ two unidirectional lines


This will work very well, and alows one train to enter the single line, whilst another is in the exit platform. there is limited scope for deadlock; if the line fills up in one direction...unless a signal only allows a certain number of trains to pass before they return again on another line, of course. The current system really can only have signals at the platform exits and runs at lower capacity (it's only capable of low-density single line use).
Similarly, a single line junction is easier with the new signal concept, provided there is a passing facility later on:
___>_N>______________<__________N>_PPP___>_____ a single line carries on...
_______/           \          \_<__PPP__<N_
                    \
                     \_N>__and a branch  too
                      \_<__


The current system requires pre-signals in some combination, depending on your traffic priorities. Note that reservations prevent deadlocks.

OK, enough messing about with examples.
Is there anyone interested in implementing such a change (or changes), and/or a consensus for (or against)?
Are there operational problems worse that the ones with the existing situation?
And of course, is this a big job to implement? I'm no coder (algorithms? yes. Code? not these days.)

Ters

#32
Quote from: merry on September 03, 2012, 05:36:36 PM
Absolutely. The problem comes in mixed-traffic networks, where one service stops at a platform, but another may pass through non-stop.
That's the catch. You're not supposed to use choose signals unless all trains passing it stops at the platforms just beyond. And having choose signals on station with traffic going straight through it is in my eyes unnecessary and a cause for problems beyond the long reservations of the choose signal.
Quote from: merry on September 03, 2012, 05:36:36 PM
Hmm, I think there is some terminology here: I mean 2 signals reading in opposite directions on the same line, located at exactly the same point, certainly without an overlap between them.
It is OK to have one signal at the end of a platform, protecting the line beyond, and another the other side of the station entry pointwork ("throat"), protecting the entrance to the station. If there are two platforms, one each direction, and the signals allow traffic to pass the in the reverse direction [which is normal], this would be OK in Simutrans.
I suppose so  :) - being in the same square it's purely a graphical issue, the function's the same. [I think it's just UK English usage to say back-to-back]
In Norway, there's a multitude of ways signals can be at stations. Some feature signals at the end of the platform, but that's not necessarily the signals guarding the exit from the station. That might be a different signal beyond that. See http://www.youtube.com/watch?v=E764YThSRlE for a cabride example. The signal at the end of the platform is an inner signal a repeating signal from what I've read. It is green if the next main signal is green. The bridge is actually part of the station, with signs that seem to indicate where trains of different lengths should stop. Beyond the bridge is what I belive to be the station's exit signal. Just beyond that, facing the other way, must be the entry signal, with presignal for exit signal at the other end of the station. However at 5 minutes, the train approaches a station now only used as a passing loop (and storage area apparently). Here the exit signals are placed at the end of (what's left of) the platforms, much like your description. Not shown in this video are stations with entry signals, but no exit signals. Such stations are either staffed (signal lit), or inactive (signal not lit). Trains stopping at such a station are given the signal to proceed using a hand held sign or torch. I also think there are staffed station with exit signals. The sign or torch then give the train clearance to proceed from platform to exit signal. I have read about this a while back, but my memory is sketchy, and the proper English words hard to find, so I might be a bit wrong here and there.

That two signal are face-to-face on the same tile in Simutrans is not just a graphical thing. The fact that two blocks overlap by a single tile helps avoid deadlocks, as it's only possible to reserve up to one of the signals at a time. The overlap prevents the next block from being allocated by a train from the opposite direction. In real life, proper train schedules is used to avoid such deadlocks.

Vladki

Quote from: merry on September 03, 2012, 01:28:58 PM
WAY-POINTS cause an end of reservatoin in the middle of a siganl section. This has two problems: one eye-candy, in that the train stops before calculating the route ahead; one functional, in that deadlocks can be created if one is not exceptionally careful. BUT way-points are also used to force routing in complex trackwork, and the routing effects of any change in behaviour will need to be carefully assessed.
Proposed solution: at or just before the last signal before the waypoint, the route from the waypoint to the next stop/waypoint should be calculated, which is necessary to allow reservation of route from the waypoint up to the next affected signal. To avoid the graphical 'glitch', said route calculation must probably be be a background task.
I think route calculation should calculate the route from one station to another station in one pass. Pathfinder should not stop at the waypoint but continue to next waypoint until a station is found.

Quote
CHOOSE SIGNALS are terribly non-intuitive for most players, and often have unintended consequences, as they choose & reserve route through all signals ahead up to the next stop/way-point. I'd suggest this is not a helpful behaviour: a real-life junction signal generally reads only onto the next running signal, which might itself be a splitting (junction) signal).
Proposal: choose signals be modified to reserve route only up to the next normal signal or end-of-choose, whichever is met first. For me, and I suspect most other players, long-range choose is unnecessary at best, and downright disastrous at worst (i've had a network take a game year to recover from a major choose reservation oddity). I know this changes a long-standing behaviour, but I have never seen a justification, only a statement that 'it is'. There are also ways to avoid wrong-direction traffic in complex junction areas by using no-entry signs.
I also had this problem - reservation through half of the map... I would like the choose signal modified so, that it will not only find alternative platform, but also an alternative route. Imagine a station with several platforms, where some trains stop, some trains pass, and a choose signal in front of station. A train occupies the platform in straight line (waiting for cargo, or for clearance on branching track), and all other platforms are free, but a passing train cannot overtake, because its calculated route goes through the occupied platform. Intuitive use of choose signal would be to search alternative paths, whether the train stops there or not. It is just a question how far the search should go - a fixed number of tiles, signal blocks, or till some new special sign. (truly end-of-choose, not to be confused with forbidden platform)


Quote
NORMAL SIGNALS are available in 2 'flavours', neither of which replicate a common real-world signalling behaviour. A signal can be 'stop both ways' or 'stop 1 way, no-entry reverse'. In real life, back-to-back signals are incredibly rare (they do exist but only in special circumstances).
Back to back signals exist (at least on CZ railroads) mostly on two track lines. However they are switched off in one direction. If the driver sees a signal that is switched off he has to stop immediately - he is probably going on the wrong track. The other direction is used only on special occasions - delayed express train overpassing a local train, or when one track is under maintenance. Both uses are not going to happen in ST. There are also some back-to-back signals on single track lines, to allow for more trains in the same direction, but more than one such signal on a line would cause a deadlock in ST. And third use of back-to-back signals is to split a long platform in two, again something not practical in ST.

Ters

Quote from: Vladki on September 03, 2012, 08:56:54 PM
I would like the choose signal modified so, that it will not only find alternative platform, but also an alternative route.

In earlier discussions, prissi has been rather adamant that such dynamic routing causes unpredictable behaviour that won't be allowed in Simutrans. I tend to agree. As demonstrated in Transport Tycoon, it causes more trouble than it's worth.

Quote from: Vladki on September 03, 2012, 08:56:54 PM
A train occupies the platform in straight line (waiting for cargo, or for clearance on branching track)

I think the realistic setup is for trains not to wait for cargo on through tracks. Waiting for cargo should always happen on side platforms. If there are multiple platforms, which there must be for choose signals to be an issue in the first place, trains for the branch should use one, the other trains another, and no choose signals.