The International Simutrans Forum

 

Author Topic: Potential Bug: signs imply a maximum speed  (Read 320 times)

0 Members and 1 Guest are viewing this topic.

Offline Freahk

  • Devotee
  • *
  • Posts: 1355
  • Languages: DE, EN
Potential Bug: signs imply a maximum speed
« on: October 25, 2020, 07:18:54 PM »
All railway signs imply a maximum speed, which defaults to 160 km/h if nothing is set explicitly.
Preciesely, minimum speed, one way and end of choose signs imply such a speed limit, which does not make a lot of sense to me.
Such signs should by default not imply any speed limit. If desired, a speedlimit can explicitly be set.

Minimum speed signs as well as end of choose signs do not exist as such in the real-world and it's nothing the train actually needs to take care about. It's an information about the tracks which you can pass to the virtual simutrans train dispatcher by using those signs.

The same for oneway signals. Such do not exist in the real-world. The dispatcher will handle such things. A train driver does not need to take care about this, so a slowdown doesn't make sense here as well.

Offline Ranran

  • Devotee
  • *
  • Posts: 1283
  • Languages: ja
Re: Potential Bug: signs imply a maximum speed
« Reply #1 on: October 25, 2020, 10:18:07 PM »
Perhaps James explained that it was the speed at which the contents of the sign could be seen. When moving at high speed, the driver cannot read the letters on the sign. That's why high-speed trains need cab signals. If it is a very visible sign, I think you should set the speed limit higher in dat file.

Offline Freahk

  • Devotee
  • *
  • Posts: 1355
  • Languages: DE, EN
Re: Potential Bug: signs imply a maximum speed
« Reply #2 on: October 26, 2020, 01:50:48 AM »
that it was the speed at which the contents of the sign could be seen.
This indeed applies to actual signals, as it's the train drivers responsibility to handle these properly, but the listed signs are just the simutrans way to code informations that are outside of train drivers responsibility. Those three mentioned signs do not exist (that way) in the real-word.

As the coded information is not addressed to the train driver, but to the virtual simutrans train dispatcher, it doesn't matter if the virtual simutrans train driver can see these at high speeds or not.
« Last Edit: October 26, 2020, 02:04:36 AM by Freahk »

Online prissi

  • Developer
  • Administrator
  • *
  • Posts: 10303
  • Languages: De,EN,JP
Re: Potential Bug: signs imply a maximum speed
« Reply #3 on: October 26, 2020, 02:00:38 AM »
However, using waypoint you can avoid these signs, if you really dispatch your trains ...

Offline Freahk

  • Devotee
  • *
  • Posts: 1355
  • Languages: DE, EN
Re: Potential Bug: signs imply a maximum speed
« Reply #4 on: October 26, 2020, 02:11:02 AM »
Yes, but that's not the point and quite impractical.
Those signs are simply a hint to simutrans pathfinding. Nothing more.
As such, they are a much more comfortable way to ensure that trains do not enter a track they shouldn't enter. (oneway and min speed signs)
End of choose signals cannot be avoided in many situations.
« Last Edit: October 26, 2020, 10:28:40 AM by Freahk »

Offline Vladki

  • Devotee
  • *
  • Posts: 3497
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Potential Bug: signs imply a maximum speed
« Reply #5 on: October 26, 2020, 03:16:02 PM »
However, using waypoint you can avoid these signs, if you really dispatch your trains ...
If all of those sings could be replaced by waypoint, why would those signs exist?
Imho at least end-of-choose is not avoidable by using waypoints.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20342
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Potential Bug: signs imply a maximum speed
« Reply #6 on: November 21, 2020, 12:14:18 PM »
The intention is that only signals, not signs other than signals, have a maximum speed. As far as I can tell, this is in fact the case: although signs have a maximum speed parameter, this is unused except in the case of signals. Perhaps a UI revision is needed to make this clearer?