### Author Topic: Negative acceleration of trains.  (Read 4646 times)

0 Members and 1 Guest are viewing this topic.

#### Erik

• Posts: 219
• Languages: NL, EN
##### Negative acceleration of trains.
« on: October 17, 2011, 11:00:57 AM »
Hi everyone.

I was more or less gone for a view mounds but now winter starts I'm back.

Jamespetts has has shown his interests in the announce signal I had made.
This because the next two things are playing.

At first in real life it takes a sudden distance to get a train to a full stop.
With a speed of over 100km/h it needs more than its own length.
But in simutrans a few tile's are enough. For a train of more or less 9 tiles it will stands still in less than half its length.

The second thing is that in real life a train driver can't see the red signal far enough to get the train to a full stop in time.
Fore that distance signal are invented. (In some languages known as pre signals.)
By that signal a train driver can see what the next signal will be red and brake on time if necessary.

I want a discussion about how big the negative acceleration of the train has to be.
Meanwhile I will start developing this signal.

The results of this topic would determine some details about the way the distance signal will work.

#### Milko

• Devotee
• Posts: 829
##### Re: Negative acceleration of trains.
« Reply #1 on: October 17, 2011, 02:32:24 PM »
Hello

With a speed of over 100km/h it needs more than its own length.
But in simutrans a few tile's are enough. For a train of more or less 9 tiles it will stands still in less than half its length.

I think the problem is the graphic representation of the world simutrans. Take a train, calculates the length of the train in tiles. Transform the tile length in meters; and the number that emerges is very high. A train of two tiles, which typically consists of 4 / 5 parts means that the train is 500 meters long (by selecting a tile = 250m). The trains consist of 4 / 5 pieces are not so so long.
A train of 4 / 5 pieces seems bigger than it should be just to make it visible in the game, its scale factor is greater than all the rest.

Giuseppe

#### Erik

• Posts: 219
• Languages: NL, EN
##### Re: Negative acceleration of trains.
« Reply #2 on: October 17, 2011, 09:31:04 PM »
I know the tiles represent a bigger distance than the actual painting let scale it.
I have read previously that it was 1km travelling distance and 20m for buildings.
So it is now 250m, but still the scale is way off.

I can't find anything that is one tile on the game and 250m in real.
I would say 100m is much better.
For most objects it will be still just too much but for some other object (big ships and big industries) will it be just too less.

#### sdog

• Devotee
• Posts: 2039
##### Re: Negative acceleration of trains.
« Reply #3 on: October 17, 2011, 10:31:25 PM »
For distances related to movement, the tile length, not the length scale of the images, should be taken. This is a parameter set to 250m in simutrans experimental. The scale of the images is rather arbitrary, defined by the number of pixels of the pak set.

If you want to have plausible negative acceleartion it can be done based on breakforce, mass of the train and possibly a maximum acceleration acceptable for passenger trains.
Take a look a this discussion here: http://forum.simutrans.com/index.php?topic=8098.0

#### isidoro

• Devotee
• Posts: 1130
##### Re: Negative acceleration of trains.
« Reply #4 on: October 17, 2011, 10:43:45 PM »
The problem with scale is that if it is realistic, it isn't appealing.  Imagine that you can see a train in reality going between two cities 30 km apart.  First, you would not be able to see the train, it would be too small.  Second, its speed would seem very low even if traveling at 100 km/h.  And acceleration would therefore also very difficult to notice.

I think the designers of ST decided to make things look attractive in the game, not realistic because of that.

#### Erik

• Posts: 219
• Languages: NL, EN
##### Re: Negative acceleration of trains.
« Reply #5 on: October 18, 2011, 12:27:23 PM »
@sdog: Thanks that discussion is going about the same development. The discussion about the braking it self will I continue there.

About the graphical scaling it self there is nothing to chance.
The looks are fine now, only the interpretation of the travelling distance.

I wonder what I get about the movement of the vehicles if I say one tile = 100m.
The vehicles will move much quicker on the screen but need more space for acceleration.
This would also be interesting for situations about Intercity and slow trains.

Know someone how (or where) this is implemented in the source code?
Then I will chance and try it.
Perhaps it's awful.
That I can only find out by doing.
« Last Edit: October 18, 2011, 12:49:53 PM by Erik »

#### jamespetts

• Simutrans-Extended project coordinator
• Moderator
• Posts: 18763
• Cake baker
• Languages: EN
##### Re: Negative acceleration of trains.
« Reply #6 on: October 24, 2011, 12:48:16 AM »
Erik,

apologies for not having replied sooner: I have had a very busy week, I am afraid, and my Simutrans time this week-end has been taken up with bug fixing and working on some new multiplayer features for the next release (see the running-powers branch on my Github repository for more information).

Firstly, the physics end of braking is already in progress: Bernd Gabriel has been adapting his physics model currently used only for acceleration and top speed for braking, which can be found on his Github repository here. Any signalling enhancements would have to work with the code being developed on that branch, in particular the methods for calculating the stopping distance.

Secondly, I am rather keen on improving the signalling to work better with the new braking physics that Bernd is developing, am very interested in Erik's previous work for the announce signal for Standard, and how it might be adapted and expanded to work with Experimental. Some specific thoughts on how this might work are in order, I think.

A good place to start is to look at some reference works on real life signalling practice, such as here and here. Obviously, we need some degree of simplification from the full panoply of real life signalling operation, which can be enormously intricate, but the current implementation of signalling takes the simplification a little to far for my tastes, not least because it fails to replicate some aspects of signalling (if you'll excuse the pun) of real economic significance.

One thing that I'd very much like to achieve, to which Erik referred as the second item in his opening post, is a recognition in the signalling system of the fact that a train driver cannot see a signal except when the train is quite close to it, by which time it is too late to stop except from a slow speed. The current implementation of signalling in Experimental (not Standard, which is even simpler) is that trains will always know the aspect of the next signal, and make sure that they are going slowly enough to stop at it if it is showing a restrictive aspect, and will further always try to reserve the next block far enough in advance so that, if the next block is clear, it will not have to slow down in advance of the next signal. This has the incidental positive side effect that faster trains reserve more blocks ahead than slower trains, and have some sort of priority over them as a result. A system of signalling priorities would be a useful thing to acheive, too, although that is secondary to an implementation of a system to recognise the limited signal sighting distance inherent in ordinary signalling (as distinct from cab signalling).

There would need to be a signal sighting distance parameter (in meters) in simuconf.tab. The trains would know where the next signal is, but not (necessarily) what aspect that it is. If a train does not know what aspect the next signal is, it should have to slow down so that, when it reaches the signal sighting distance away from the signal, it is at a speed within which it can stop before the signal. The only ways of a train knowing what the next signal are should be:

(1) the use of a distant signal;
(2) the use of multi-aspect signalling; or
(3) the use of cab signalling.

Cab signalling is not a priority, so that can be left aside for the time being, although it would be good to implement it one day. (1) and (2) are essentially very similar in principle; I shall describe a suggested implementation of the basic distant signal first, then describe the modifications necessary for multi-aspect signalling.

A distant signal should show clear if the next stop signal on the train's route is clear, and caution if the next stop signal on the train's route is at danger. Until a train is within sighting distance of or has passed a distant signal showing clear, the train must travel at such speed as would enable it to stop within the signal sighting distance of the next stop signal. A train approaching a distant signal should reserve its route from the next stop signal to the stop signal after that: a reserved route should never begin or end at a distant signal.

The effect of this is that, if distant signals are placed at a sufficient distance from stop signals and stop signals are placed at a sufficient distance apart, trains will be able to travel at their maximum speed (track speed permitting) for as long as the stop signals ahead show clear. What constitutes a sufficient distance will increase as (1) the trains' speed increases; and/or (2) their braking capability decreases. Some consideration should be given to showing in the depot/replace windows the necessary signal spacing for this train to travel at its full speed without interruption.

Note that, as one will observe from the descriptions in the links above, traditional semaphore signalling practice was that a distant signal would not just indicate the aspect of the next stop signal, but all of the stop signals (usually numbering two or three) on the train's route controlled by the same signalbox. I remain open to persuasion on whether this aspect is worth reproducing in Simutrans, but my provisional view is that it is not.

Multiple aspect signals combine stop and distant signals. See this page for more information on multiple aspect signalling. The most basic type of multiple aspect signal is the three aspect type: this is, in effect, a combined stop and distant signal. For a three aspect signal, the train should always try to reserve two blocks ahead. If it is able to reserve both blocks, it should show a clear aspect, and the train be permitted to run at a speed which will allow it to stop within the signal sighting distance by the signal after next. If it is only able to reserve the first block (it should not reserve only the second), it should show a caution aspect, and the train should travel no faster than will enable it to stop within the signal sighting distance of the next signal. If it cannot reserve any blocks, it should show a danger aspect, and the train not permitted to proceed beyond it at all.

A four aspect signal is the same as a three aspect signal, except, when approached by a train, it should try to reserve three blocks ahead, not two. If it is able to reserve all three, it should show clear, and the train be permitted to proceed at a speed commensurate with being able to stop within the signal sighting distance of the next but two signals. If it is able to reserve only two blocks, it should display a double caution aspect, and the train permitted to travel at a speed commensurate with being able to stop within the signal sighting distance of the signal after next. The single caution and danger aspects should have the same effect as with three aspect signals.

I do not think that Simutrans needs to distinguish between automatic and controlled signals, nor implement anything as intricate as flashing lights or route indicators (except as a graphic to distinguish platform choose signals, as now).

It would be good to implement moving block signalling, cab signalling, radio token block signalling and signalboxes (players must place signalboxes before placing signals, each signalbox can control a certain number of signals of certain types and within a certain radius, depending on its type, and have a purchase and maintenance cost), but these can be implemented later after the distant signals and multiple aspect signals described above.

It might also be worthwhile making these signalling features optional (via a setting in simuconf.tab - perhaps something like "simplified_signalling", which, when set to 1, reverts the signalling to its current behaviour), as I think that some players find realistic signalling difficult to cope with.

Erik - is this (just the distant/multiple aspect signals to start with) something that you think that you might be able to do? Everyone - does this seem like a sensible implementation of signalling? Are there any non-UK aspects of signalling that might also need to be implemented to allow for realistic signalling from other countries; and, if so, what would be a good implementation?

Edit:

Erik - to answer your questions in your last post - look for "meters_per_tile" in the source code, and also "calc_acceleration()". I think that you know where the signalling parts of the code are? As I indicated above, you should fork from Bernd Gabriel's Github repository to get the latest braking physics implementation, and use that.

#### Erik

• Posts: 219
• Languages: NL, EN
##### Re: Negative acceleration of trains.
« Reply #7 on: October 24, 2011, 08:15:27 AM »
Thanks James

I like this development also.

It will take some time to start and do it. Simutrans is not the only thing who gets my attention.
The multi-aspect signal is mostly the same as my announce signal, but the distance signal will be some more work.
This signalling seems sensible to me. (It's why I has started the development of the announce signal.)

There is one non-UK aspect I like to propose.
Here between two switches the signals are green except the last two or the two signals before the last train.
In other words a train get a reservation till the signal before the next switch if possible.

#### jamespetts

• Simutrans-Extended project coordinator
• Moderator
• Posts: 18763
• Cake baker
• Languages: EN
##### Re: Negative acceleration of trains.
« Reply #8 on: October 25, 2011, 12:00:36 AM »
Erik,

don't worry about the time - I'm in the same position, and have a whole long list of things that need coding. Do let me know how you get on and if you have any questions about the code.

As to the non-UK aspect of signalling that you propose - can you elaborate a little? I don't fully understand. How would this work in a Simutrans environment; what would be its economic or operational significance?

#### ӔO

• Devotees (Inactive)
• Posts: 2345
• Languages: en, jp
##### Re: Negative acceleration of trains.
« Reply #9 on: October 25, 2011, 01:10:53 AM »
I think he means something like this.
http://commons.wikimedia.org/wiki/File:Rail_signal.png

as far as I know, the speed adjustment is already there, but the signaling is not.

#### jamespetts

• Simutrans-Extended project coordinator
• Moderator
• Posts: 18763
• Cake baker
• Languages: EN
##### Re: Negative acceleration of trains.
« Reply #10 on: October 25, 2011, 08:41:06 AM »
AEO,

ahh, that is just the three aspect signal of which I wrote above - I imagine that Erik meant something different?

#### Erik

• Posts: 219
• Languages: NL, EN
##### Re: Negative acceleration of trains.
« Reply #11 on: October 27, 2011, 10:37:16 AM »
No, I don't mean the tree aspect signal.
However if will work great in combination with it.

I have put a few simple pictures on the attachment to make it clear.

It has no economic effect and the operational significance is also low.
On a long track it will make the graphics more nice. A signal will not turn on yellow or green just in front of the train each time.
Also this could be the first small step to think about a more advanced signal system.

#### jamespetts

• Simutrans-Extended project coordinator
• Moderator
• Posts: 18763
• Cake baker
• Languages: EN
##### Re: Negative acceleration of trains.
« Reply #12 on: October 27, 2011, 11:30:42 AM »
Ohh, I see, you mean automatic signals? Yes, we have those here, too. My view was that it would be a lot of work to implement with nothing other than cosmetic significance: but if you think that the cosmetic effect is worth the work, then go for it (as long as it doesn't make the signalling any more fiddly for users to implement - this means that the signals will have to decide for themselves whether to be automatic or controlled, rather than requiring users to pick one or other type manually).