the disturbing slowdown, still

Hello trainzers,

Trainz is my way of travelling. It is a wonderful product also because it allows the user to make and add his/her own creations. Still there is an ongoing annoyance for me.

After all these years of Trainz, we still have the non-prototypical slowdown way before the location of a yellow signal. Even way before a yellow/green signal if it uses a standard signal state.
Yes I know that for some very heavy trains, that may be realistic.
On the other hand, if a slowdown is purposely imposed by the route creator, i.e. there is a speedboard signal on the line, the train only starts slowing down when it is quite close to the speedboard and needs an emergency type of deceleration to avoid speeding (which nonetheless it often does by 1 km/h...)
From time to time we read on the forum about placing additional invisible signals to avoid the slowdown. That affects the AI, however, and may have a negative effect in complicated trackwork.

Why o why has this behaviour never been adjusted in the base code (or made into an option)? I find it annoying, the more so because it unnecessary lengthens AI-driven rides. (I prefer riding trains over driving trains, which is a personal preference indeed.)

Maybe Tony Hilliam or one of the programmers involved can comment on this? I would appreciate that. My opinion may be unjustified after all. Thanks

Regards
Paul

Just as in real life, the AI drivers interpret a yellow signal as a caution signal and as an advance to an upcoming stop. The rules for most railroads including those in the US and UK at least, that I am somewhat familiar with, state that a yellow signal means slow down to half the posted speed and prepare to stop at the next signal. There are some variations on this with blinking yellow signal meaning the next upcoming signal will be at caution, so prepare to start slowing down ahead with variations on them including the addition of distant signals and other indicators.

You might want to take a look at this here for UK:

https://www.bing.com/ck/a?!&&p=9749...TIwdGhlJTIwZWxlY3RyaWMlMjB0ZWxlZ3JhcGgu&ntb=1

The US has a bit more complicated system which is speed governed but the principles are the same. The US also suffers from different variations depending upon the railroad, timeframe when the signaling system was developed and what region which complicates matters more but overall, they all work in the same way. There are operating rulebooks and regional guidelines with many of the signals based on line-of-sight, meaning the driver can only move the train as fast as he can stop it at the next upcoming signal should that be a red one.

US rail signal information:

https://www.bing.com/ck/a?!&&p=3671...ydGhfQW1lcmljYW5fcmFpbHJvYWRfc2lnbmFscw&ntb=1

The issue I see, which N3V needs to address, is how far down the line the AI see a caution signal. They appear have super telescopic vision and can see for miles/kilometers ahead because the AI can see way ahead long before the signal is within sight of the driver in real life.

Outside of the AI issue mentioned, there are other issues that I have found that cause the AI to slow down including not enough distant (advance) signals within a block. From my personal experience, inserting some distant signals within a block allows the block to not only hold additional trains as one train moves, along and another can come in right behind, but also prevents the AI from seeing all the way to the very end of a block where there may be a red signal which will cause the AI to slow down in preparation to stop at that signal. In those locations where there can't be signals even in real life, invisible signals work.

Adjusting the paths, meaning the junctions for the route ahead of time, really helps a lot too. This will ensure that the path is always green for the AI driver and there's now no excuse to think and do something else. I will go through my route and ensure that the switches are always set for the mainline and not for crossovers or sidings to ensure that through trains will run at speed.

There are other real-life things we can do such as placing those distant (advance) signals to divide up longer blocks and to adjust the length to accommodate longer or shorter trains depending upon the setup. Longer trains running in shorter segments can tie up lines just as shorter trains running in longer blocks because this prevents the fluid movement of trains.

Hello John,

Thanks for your reply.

The systems that I am familiar with do not dictate a slowing down to half the line speed, but just the necessary preparations for being able to stop for the red signal. That is, unless there is a speed signal attached to the caution signal (be it fixed or one with a matrix of lights).
The interesting link that you give above, discussing the UK system, does not mention any requirement other than being able to stop in time, as far as I can see. For some trains it will mean that they have to move slower than line speed. That is understandable, but Trainz does not differentiate.
In Trainz we see that there is a rather firm slowing down to half the speed, way before the yellow signal. So even with the requirement that you mention for the systems that you are familiar with, this is not a realistic behaviour.

Yes, the junctions can be set favourably in advance, like you indicate. But that does not touch the problem that I want to bring to our attention.

Regards,
Paul

hutten said:

Hello John,

Thanks for your reply.

The systems that I am familiar with do not dictate a slowing down to half the line speed, but just the necessary preparations for being able to stop for the red signal. That is, unless there is a speed signal attached to the caution signal (be it fixed or one with a matrix of lights).
The interesting link that you give above, discussing the UK system, does not mention any requirement other than being able to stop in time, as far as I can see. For some trains it will mean that they have to move slower than line speed. That is understandable, but Trainz does not differentiate.
In Trainz we see that there is a rather firm slowing down to half the speed, way before the yellow signal. So even with the requirement that you mention for the systems that you are familiar with, this is not a realistic behaviour.

Yes, the junctions can be set favourably in advance, like you indicate. But that does not touch the problem that I want to bring to our attention.

Regards,
Paul

Click to expand...

I agree, Paul. The AI have super-telescopic vision and already see the red signal ahead and will slow down miles ahead. Does placing interim signals in between help with your setup? I find that helps with mine. I use distant or advance signals within the larger blocks. This not only allow other drivers to occupy a larger block and continuously move, but this also smooths out the operation so that the AI that are running don't see the red ahead and start slowing down immediately. While our system is fairly prototypical, we need to "trick" the AI to do things the right way and that is sometimes not prototypical but works.

The UK system requires that the drivers move at a slower speed and in modern signaling they utilize a series of yellow signals. I need to find a link on that, or you can probably find one. Like in the US, there's a series of yellow blinking signals as if to say, "Hey driver watch out ahead", that is then followed by a solid yellow which then indicates there's a stop ahead.

Hello John,

Yes, an extra (invisible) signal does help in some cases, it makes a green precede a yellow at a short distance. It does, however, introduce additional signal lights on the line schematic at the bottom of the screen. More importantly, this trick does not work when one uses signals that can display all aspects, which is common in light signalling systems. The same goes for three-position mechanical signals.

For the (only) route that I have signalled myself, a route formed by merging seven relatively small Belgian routes, I have resorted to using the extended signal states for all aspects other than stop and proceed. I have basically used the standard script written by author bloodnok for a 'vsrsemaphoresignal' and changed the code. The extended signal states have descriptions that relate to the "average" US signal system, but I do not know whether any of the advanced Trainz US signal systems actually uses these codes in precisely that way. Some of the extended states do also cause premature slowdowns, which is hard-coded in Trainz just like the response to the caution state. I have only used the codes without speed effects. There were just enough codes available to make it work for the Belgian system of mechanical signalling.
The result was really satisfying, but this does not help me with other routes.

Regards,
Paul

I have run into the same issue as well when using the invisibles due to what you mentioned. I never dissected a signal script before and looked at the states but as you noted the AI will slow down. Diverging and interlocking signals do imply a slower movement based on their setup since these govern speed through the switches and crossovers as well as being determined by track signals ahead. I wonder if this is a case of applying something that isn't meant for what its intended elsewhere.

On a 3-head interlocking signal with Red over Yellow over Green for instance, this would indicate: MEDIUM APPROACH SLOW Medium Speed through turnouts, crossovers, sidings, and over power operated switches; then proceed, approaching next signal not exceeding Slow speed.

I'm not sure how this applies elsewhere in the world.

In my current project I have a branch-line that is 88km (~50mi) long and, in real life, it was totally unsignalled. If I duplicate that then the AI would slow to half speed simply because it could not see any signals at all.

There is a maximum distance that the AI can "see ahead" but I have no clue what that distance is - some of the yards on that branch line are up to 10km apart. I have resorted to placing invisible signals (3 in close proximity to each other - i.e. about 100m apart) at the approach to each yard and this, in most cases, overcomes the half speed problem. But I have noticed that the issue also seems to be specific to certain locos but not to others - perhaps differences in the individual loco engine specs or scripts?

In any case the appearance of the invisible signals in the track profile line is not an issue to me. I treat their appearance as both an indication of the approaching yard and as a digital equivalent of the driver's "local road knowledge".

My observations.

My understanding (which may not be 100% accurate but should add more to your understanding), is that the AI determines when to begin slowing down based upon the max-decel parameter and works out when to begin "braking" to reach half speed at the signal.

Given that there is an enormous variation is the value used in various engine specs, you'll see "slow braking" locos begin to slow down very early, while "super-fast braking" locos will get close to the signal before slowing.

And as pointed out, in most cases there will be a yellow prior to a red. If there's a 10km gap between signals, you'll run at half speed through that block.

Hello,

Thank you, Tony Hilliam, for contributing to this discussion.
Thanks, pware, too. You discuss slightly different situations.

I would be happy to accept that the speed is halved in the block between the yellow and the red signals, but all the locos that I have "ridden" have shown a fast deceleration at about half a mile in advance of a yellow (warning/caution) signal. If speeds were reduced only in the block before the stop signal, I could choose to reduce the distance between signals as much as possible without being un-prototypical.

I can't help feeling that I cannot get the message across, however.
If the way that a train reacts to yellow signal would be similar to its behaviour when approaching a speedboard, I would not make this point. Obviously, programming such a behaviour is possible, it is already in the base code.

And as far as engine specs are involved: there have been cases in which I had to increase the deceleration values since the loco would invariably pass red signals, not being able to reduce its speed sufficiently. This happened with some DMU's and with loco's with only a light train in tow.

Regards,
Paul

hutten said:

Hello,

Thank you, Tony Hilliam, for contributing to this discussion.
Thanks, pware, too. You discuss slightly different situations.

I would be happy to accept that the speed is halved in the block between the yellow and the red signals, but all the locos that I have "ridden" have shown a fast deceleration at about half a mile in advance of a yellow (warning/caution) signal. If speeds were reduced only in the block before the stop signal, I could choose to reduce the distance between signals as much as possible without being un-prototypical.

I can't help feeling that I cannot get the message across, however.
If the way that a train reacts to yellow signal would be similar to its behaviour when approaching a speedboard, I would not make this point. Obviously, programming such a behaviour is possible, it is already in the base code.

And as far as engine specs are involved: there have been cases in which I had to increase the deceleration values since the loco would invariably pass red signals, not being able to reduce its speed sufficiently. This happened with some DMU's and with loco's with only a light train in tow.

Regards,
Paul

Click to expand...

Deceleration can also be affected by having the incorrect i.e. too heavy values for the mass of wagons and carriages in the consist, more weight in tow the longer to slow down. Wrong mass in wagons and carriages is or was a common issue, probably due to creators having to guess a value, same with some epecs.

Thanks Malc, I will consider that when such a situation arises.

Paul