Speed limit for trains

[StefanV]

Hello everybody,

I'm not quite new here, I just lost my login data of an username I've made years ago. At the moment I'm playing OpenTTD every now and then. But I have an suggestion which I would like to see in a new version / nightly of OpenTTD. When I'm creating networks of trains, I'm used to put Intercity's and 'Stoptrains' (Yes, I'm Dutch) on the same line. The thing is: they both have other maximum speeds. That means that there is no possible way to let them run on the same line without getting troubles. And when you want to create a section of only 40km/h (nearby big stations etc., like in real life)... there's no possible way to create that.

So this is what my suggestion is about: create an option which allows you to set a speed limit on sections of railway tracks between two waypoints, OR create an option which allows you to set a speed limit in the order list of a train, between two checkpoints or stations.

Thanks.

- Stefan

[ChillCore]

NuTracks is your friend.
No wait, search is ...

http://www.tt-forums.net/viewtopic.php? ... t=nutracks

You can download the grf ingame -> "check download content".

[wallyweb]

Strange how great minds think alike. I did a forum search for "speed limit" which returned a ton of topics of which this one is the most recent.
First, a disclaimer ... those who know me know that I am a TTDPatch player and have not yet installed OTTD. They also know that I occasionally exhibit a serious need of a sanity check. This suggestion could change the first part of this disclaimer. The second part could be worthy of serious debate in the Off-Topic section of these forums.
So, why post in an OTTD forum? Because there seems to be a lot of action on the development side, there appears to be more OTTD developers who are active, and the OTTD developers seem to be equally at home programming for both OTTD and TTDPatch and I think this suggestion might be equally appropriate to both games.

I tend to disagree with Chillcore's

NuTracks is your friend.

I suspect this feature might be more easily implemented as a form of a signal tile or a waypoint tile. I don't know if these are a part of NuTracks.

First, some known parts of the game:
- Train engines are coded with a set maximum speed limit which I know is addressable under TTDPatch and probably OTTD too.
- Under TTDPatch, Realistic Acceleration can alter a train's speed in curves and on hills. I think this is currently under development in OTTD. Am I mistaken about this?
- Under TTDPatch signaling, a point/switch can be programmed to pass only trains known to be above or below a specified maximum speed. Is this available or under development in OTTD?
- A train knows when it is on a station tile or a signal tile and reacts according to an order schedule or tile setting.

How I envision this being made to work:
- A waypoint or signal tile is modified to be a type of signal that, when accessed by a train, temporarily resets the train's maximum speed condition to a value/level set by the waypoint/signal tile.
- The condition persists until modified/reset when the train accesses another similar waypoint/signal tile.
- If such a waypoint/signal tile is programmable as is done with pre-signals and PBS signals, then one would only need one waypoint/signal tile to be designed. There would be no need of separate implementations of entry and exit tiles.
- For a block of track (Railyard? station?) to be of restricted speed, the player would place and set/program waypoint/signals at each end of the block.
- For a block of single track that is used by trains running in both directions, perhaps the waypoint/signals should accommodate two settings, one for entering the block and one for exiting the block. The waypoint/signal would function simultaneously for both exit and entry conditions. Furthermore, this way, one could have a series of restricted speed blocks of various speeds.

[JGR]

and the OTTD developers seem to be equally at home programming for both OTTD and TTDPatch

Erm, [Citation Needed]

- Under TTDPatch, Realistic Acceleration can alter a train's speed in curves and on hills. I think this is currently under development in OTTD. Am I mistaken about this?

The lookahead is still half a tile, and that doesn't include negative accelerations.
So it's not all that realistic, or greatly useful for what you're really proposing.

- Under TTDPatch signaling, a point/switch can be programmed to pass only trains known to be above or below a specified maximum speed. Is this available or under development in OTTD?

There are various simplified implementations available in patch form for OTTD, all of which are heavily out of date with respect to trunk AFAICT.
(That said I did see a programmable signals feature in recent development, so that might be modifiable to be of some use).

- A train knows when it is on a station tile or a signal tile and reacts according to an order schedule or tile setting.

I'm not sure what you mean by this/how this helps... Is this just a reiteration of using waypoints for speed markers?

How I envision this being made to work:
- A waypoint or signal tile is modified to be a type of signal that, when accessed by a train, temporarily resets the train's maximum speed condition to a value/level set by the waypoint/signal tile.
- The condition persists until modified/reset when the train accesses another similar waypoint/signal tile.
- If such a waypoint/signal tile is programmable as is done with pre-signals and PBS signals, then one would only need one waypoint/signal tile to be designed. There would be no need of separate implementations of entry and exit tiles.
- For a block of track (Railyard? station?) to be of restricted speed, the player would place and set/program waypoint/signals at each end of the block.
- For a block of single track that is used by trains running in both directions, perhaps the waypoint/signals should accommodate two settings, one for entering the block and one for exiting the block. The waypoint/signal would function simultaneously for both exit and entry conditions. Furthermore, this way, one could have a series of restricted speed blocks of various speeds.

Again, there is the issue of players making a mess and forgetting to place exit waypoints which remove the speed limit.
Also, having to use waypoints will inevitably result in a lot of extra waypoints (how big is the OTTD station array?), I'd be more inclined to use signals, as they are more flexible to position and it is no great issue to lay hundreds of them. There are plenty of patches for increasing the data capacity of signal tiles.
You still have the ridiculous deceleration issue though as trains will suddenly slow down half a tile before your new speed restriction waypoint/signal/whatever.

Frankly rather than (or perhaps as well as) going through all that you could just bite the bullet and do it properly.
ie. using a long reservation system as has been proposed many times before, but with a minimum length of the trains (more realistic) stopping distance. This makes the whole issue largely go away as ideally trains are no longer at full speed until half a tile before where they need to stop/corner/etc.
That is a lot of work though.

[ChillCore]

First, a disclaimer ... those who know me know that I am a TTDPatch player and have not yet installed OTTD.

Shame on you. You should be playing both.
TTDP and OTTD both have their advantages. I will not get in the arguement of which one is better. I like both. period.

So, why post in an OTTD forum? Because there seems to be a lot of action on the development side, there appears to be more OTTD developers who are active, and the OTTD developers seem to be equally at home programming for both OTTD and TTDPatch

I disagree. If I am not mistaking TTDP is written in Assembler. C++ is easier to read, understand and write. I speak for myself and I admire people that can read and write Assembler. I do agree that graphic set developers have a pretty good understanding of how to get things done for both TTDP and OTTD.

I suspect this feature might be more easily implemented as a form of a signal tile or a waypoint tile. I don't know if these are a part of NuTracks.

NuTracks is developed with having more tracktypes available in mind, IIRC. The different speeds is a nice side effect.

- Train engines are coded with a set maximum speed limit which I know is addressable under TTDPatch and probably OTTD too.
- Under TTDPatch, Realistic Acceleration can alter a train's speed in curves and on hills. I think this is currently under development in OTTD. Am I mistaken about this?

Realistic acceleration is part of OTTD.
Long trains in curves and on slopes do slow down if the switch is set.
Road vehicles slow down going uphill too.
See advanced settings.

- Under TTDPatch signaling, a point/switch can be programmed to pass only trains known to be above or below a specified maximum speed. Is this available or under development in OTTD?
- A train knows when it is on a station tile or a signal tile and reacts according to an order schedule or tile setting.

How I envision this being made to work:
- A waypoint or signal tile is modified to be a type of signal that, when accessed by a train, temporarily resets the train's maximum speed condition to a value/level set by the waypoint/signal tile.
- The condition persists until modified/reset when the train accesses another similar waypoint/signal tile.
- If such a waypoint/signal tile is programmable as is done with pre-signals and PBS signals, then one would only need one waypoint/signal tile to be designed. There would be no need of separate implementations of entry and exit tiles.
- For a block of track (Railyard? station?) to be of restricted speed, the player would place and set/program waypoint/signals at each end of the block.
- For a block of single track that is used by trains running in both directions, perhaps the waypoint/signals should accommodate two settings, one for entering the block and one for exiting the block. The waypoint/signal would function simultaneously for both exit and entry conditions. Furthermore, this way, one could have a series of restricted speed blocks of various speeds.

Owen(No, not that Owen) is working on programmable signals. Maybe in the future he could implement such an option.
http://www.tt-forums.net/viewtopic.php?f=33&t=47690

In combination with (even)more conditional orders this could provide for some very interesting gameplay.


IMHO, signals are for allowing or disallowing trains to enter a certain signal block.
It is much easier to just use different track to limit a trains speed.
You may want to give NuTracks a go. They are fun to play with.

[wallyweb]

lots of stuff

lots of stuff here too.

Hi JGR, thanks for replying to my post. Your thoughts and comments are always valued highly. On the "citation" part, in North America, that usually means a piece of paper that a policeman gives you for traffic violations such as excessive speeding, but that is probably not the context you intended. Although I haven't seen anything in the TTDPatch trunk, I have seen occasional references by some OTTD devs about their work probably being compatible with TTDPatch, especially with respect to their contributions to the GRF specs. It would take a bit of time and some digging for me to rediscover some of those references, but if you really need them, I can try.

The reason I included waypoints alongside signals is because I think I have seen (do I need citations here too? ) some OTTD discussions about using waypoints for some signalling/track control functions. I agree with you that signals would be definitely more appropriate for exactly the reasons you cited.

Some questions:
- Does "look ahead" have to enter into the equation? The setting would only take place when a train encounters an appropriate signal.
- Does acceleration/deceleration, although nice to have, really have to be considered?

Perhaps one should take this one step at a time ... the first(?) being to have a working speed limit function for a block/section of track. If this can be made to work, then one could consider the implementation of acceleration/deceleration in conjunction with "look-ahead" for a train approaching the block. Of course, one could also consider implementing acceleration/deceleration without "look-ahead" as they would be a function of the train reacting to the speed limit signal it has just crossed. This part needs more thought as to which solution would be better.

As for players forgetting to place the required second signal at the other end of the block, they would soon learn that if they did not do so, the consequences could be expensive.

Hmm ... I see ChillCore has just replied as well. Give me a moment to read it.

[JGR]

I see what you mean with the TTDP/OTTD interoperability now, but that only really applies to codebase-neutral aspects which have been directly derived from TTD (ie. GRFs (excluding many newer features) and some of the savegame format).

You can't really transplant code from one to the other (at least not without writing a very fat API translation layer, which probably wouldn't work very well).

I bring up lookahead, because the problem you are trying to solve is created by the lack of look-ahead.
If trains did look ahead and slowed themselves down in advance you wouldn't need to explicitly set speed limits in advance to preserve realism.

Another idea is to attach a tile count to a speed-restricted waypoint/signal, such that the speed restriction expires after that many tiles, even if it doesn't encounter an end speed restriction point. This would be overriden if it encountered another speed restriction of whatever type first though...

Chill's suggestion of nutracks looks like it would do for the most part...

[wallyweb]

Shame on you. You should be playing both.
TTDP and OTTD both have their advantages. I will not get in the arguement of which one is better. I like both. period.

I agree, and without a doubt I will be there eventually. Canada is a rather large country for a scenario and larger maps would definitely be of advantage, but that is for another topic.

If I am not mistaking TTDP is written in Assembler. C++ is easier to read, understand and write. I speak for myself and I admire people that can read and write Assembler. I do agree that graphic set developers have a pretty good understanding of how to get things done for both TTDP and OTTD.

Agreed ... I did some C/C++ AND Assembler in college. Unfortunately not enough to be proficient in any of it.

NuTracks is developed with having more tracktypes available in mind, IIRC. The different speeds is a nice side effect.

I'll give the NuTracks topic a good read.

Realistic acceleration is part of OTTD.
Long trains in curves and on slopes do slow down if the switch is set.
Road vehicles slow down going uphill too.
See advanced settings.

Good.

Owen(No, not that Owen) is working on programmable signals. Maybe in the future he could implement such an option.
http://www.tt-forums.net/viewtopic.php?f=33&t=47690

In combination with (even)more conditional orders this could provide for some very interesting gameplay.

Really really good. This might get me into OTTD even sooner.

IMHO, signals are for allowing or disallowing trains to enter a certain signal block.
It is much easier to just use different track to limit a trains speed.
You may want to give NuTracks a go. They are fun to play with.

I will take a look at it. From the point of view of modelling real life, my understanding is that the engineer/driver of a train will alter speed in response to a signal, flag or posted speed limit which are usually located on the approaches to areas requiring such limits. In other words, in the absence of a fully automated railroad system, the driver needs a visible cue to react to.

even more stuff

I like your thoughts regarding the tile count.

[eis_os]

Entertaining, the concept of speed limit signs for trains I discussed ~7 years ago... (The basic code was simply adding a vehicle consist limit, until a unrestricted speed limit sign was seen)

http://www.tt-forums.net/viewtopic.php?p=69693#p69693

People really didn't liked the concept...
(Reference German) http://www.stellwerke.de/signal/deutsch/lf.html

[michael blunck]

[...]
http://www.tt-forums.net/viewtopic.php?p=69693#p69693

People really didn't liked the concept...

I remember. But the question remains: What's the purpose of speed limitations?

IMO, none inside the current framework. O/c, one could think of additional constraints, like towns on lines with high-speed trains degrading ratings, but again: is this useful?

(Just playing devil´s advocate to "bait" ideas ..)

regards
Michael

[StefanV]

I want to play it realistic. That means that if I build a station like Amsterdam Central Station, I don't want to have trains travelling with 160km/h (vIRM - Dutch Trainset) into a station. In real life, a train is going 40km/h trough switches and such.

[michael blunck]

I want to play it realistic. That means that if I build a station like Amsterdam Central Station, I don't want to have trains travelling with 160km/h (vIRM - Dutch Trainset) into a station. In real life, a train is going 40km/h trough switches and such.

AFAIR, "realistic" is no valid argument here.

For your application, the best way to do would be indeed to use track types with a lower max speed in vicinity of your stations.

regards
Michael

[frosch]

wallyweb: With those expectations you might better not try OTTD. Better keep the myth than getting disappointed
OTOH you might of course discover other nice stuff.

and the OTTD developers seem to be equally at home programming for both OTTD and TTDPatch

Don't confuse "reading the code and following the ctags [0], while comparing it with the specs" with "programming". It's like reading a novel of 1000 pages vs. writing one

[0] Or is it "asmtags" in that case?

[wallyweb]

I have currently the same problem to add support for speedlimit signs.
ohh, now everyone knows what I am doing next

Now I remember where I got this silly idea.

But the question remains: What's the purpose of speed limitations?

IMO, none inside the current framework. O/c, one could think of additional constraints, like towns on lines with high-speed trains degrading ratings, but again: is this useful?

I want to play it realistic.

Stefan has said it all. For the inveterate scenario player such as myself, the challenge is to mimic reality. If we were not concerned with accommodating this challenge, then there would be no need for the Realistic Acceleration feature either.

(Just playing devil´s advocate to "bait" ideas ..)

[Kogut]

Realistic Acceleration feature also added new parameters to locomotives (tractive effort) and increased importance of power. That improve gameplay.

[michael blunck]

For the inveterate scenario player such as myself, the challenge is to mimic reality. If we were not concerned with accommodating this challenge, then there would be no need for the Realistic Acceleration feature either.

Realistic Acceleration feature also added new parameters to locomotives (tractive effort) and increased importance of power. That improve gameplay.

And that improvement is done by adding another "degree of freedom", in such a way that it adds in turn a new "economical niche" which didn´t exist before. Especially for locomotives this made sense, because without, many locomotive types were useless in-game because they couldn´t prove their superiority in a specific area, simply because this area didn´t exist. Insofar, adding degrees of freedom will make the game more "realistic", "reality" being the system with the highest-possible degree of freedom.

Well, now. What does "speed limitation" contribute to that special sort of "reality"? Does it open up new niches? For vehicles, apart from the fact that those capable of higher speed would lose their advantage, so that, in turn, lower speed vehicles will get more competitive, I don´t see any effect. Likewise for the overall effect on a whole railway company.

Remains the optical effect, aka "eye candy".

regards
Michael

[wallyweb]

Well, now. What does "speed limitation" contribute to that special sort of "reality"? Does it open up new niches? For vehicles, apart from the fact that those capable of higher speed would lose their advantage, so that, in turn, lower speed vehicles will get more competitive, I don´t see any effect. Likewise for the overall effect on a whole railway company.

I would agree if the speed limit were to be applied equally across an entire network. Ideally the speed limited blocks would be of a limited length. The challenge to the player would be to determine the most efficient block length. Yes, higher speed trains would be at a disadvantage but only within those blocks. Here are a couple of possible scenarios:
- A high speed train is due for service and must proceed through a rail yard in order to access a depot. Should that train be allowed to do so at maximum speed?
- A high speed train's route takes it through a suburban station, but that train is not scheduled to stop at that station. Should that train be allowed to do so at maximum speed?
Most networks consist of long stretches of open track running between destinations. The higher speed trains would retain their advantage. Perhaps not to the extent permitted by wide open access to the entire network. The challenge to the player and his/her company would be to minimize the inevital hit on the bottom line.

Remains the optical effect, aka "eye candy".

Indeed. If I did not want the eye-candy effect, I would play TTD unpatched.

[michael blunck]

[...] Here are a couple of possible scenarios:

- A high speed train is due for service and must proceed through a rail yard in order to access a depot. Should that train be allowed to do so at maximum speed?

If it´s in dire need for service? Possibly.

- A high speed train's route takes it through a suburban station, but that train is not scheduled to stop at that station. Should that train be allowed to do so at maximum speed?

Hehe. They do it all the time over here.

Wally, try harder.

regards
Michael

[wallyweb]

If it´s in dire need for service? Possibly.

That would depend upon how long the driver's sandwich was sitting in the sun by the windshield before he/she ate it.
Actually, if I remember correctly, in TTD, engines must periodically visit depots in order to restore reliability and hence efficiency.

Hehe. They do it all the time over here.

That must be why your suburban ambulance services are located next to suburban stations.
Actually, and I stand to be corrected, wouldn't such stations have the high speed tracks located away from the platform? And if so, would there not be the occasional occasion where the high speed train had to divert to the platform track?
Here in Canada this is not an issue as the roadbeds have yet to be upgraded to accommodate high speed trains. The only time we see such events is when the driver is feeling lucky and decides to text-message with his girlfriend while at 200km/h.

Wally, try harder.

OK ... How about this:
... because I need it, I want it and I shall throw a fit if I don't get it!

[Eddi]

[...]
http://www.tt-forums.net/viewtopic.php?p=69693#p69693

People really didn't liked the concept...

I remember. But the question remains: What's the purpose of speed limitations?

IMO, none inside the current framework. O/c, one could think of additional constraints, like towns on lines with high-speed trains degrading ratings, but again: is this useful?

(Just playing devil´s advocate to "bait" ideas ..)

regards
Michael

IMHO, with the game lacking stopping distances etc. the only valid gameplay reason for user-definable speed limits is preventing a faster train following a slower train constantly do stop-and-go. as in "if a train with speed limit X passed here less than Y ticks ago, allow train to go with speed limit Z".

you could also prevent that by using timetables, but that is very difficult to synchronize and involves a lot of micromanagement. an option for programmable signals "turn red for X ticks repeating every Y ticks" could be useful there