| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
meant the same thing, but only one was used. Keep PATH_TOO_LONG since it has the better documentation.
|
|
waiting position from a waypoint.
|
|
too long condition, as destination should not be considered in the former case.
|
|
path and applying penalty.
|
|
codestyle of derived structs.
|
|
static cast type, operator methods.
|
|
would make the end-of-line-is-red setting ineffective
|
|
others were still regular inline), but make sure inline is always a 'forced' inline (I am looking at you MSVC)
|
|
|
|
one-way path signals so those aren't preferred over other possibilities
|
|
|
|
penalty when the signal is a path signal.
|
|
road vehicles and trains.
|
|
making sure other waypoint entries are evaluated as well when they are occupied, e.g. when there are no signals before the waypoint but a train just beyond the waypoint is stopped (like for stations)
|
|
vehicle speed is meant.
|
|
|
|
|
|
about the fact that the backside of an one-way path signal can be a safe waiting point.
|
|
divisions with rounding.
|
|
'made up' data that shouldn't go into the cache, causing desyncs in MP
|
|
entering a signal block via a 'block' signal. This way you won't get double penalties, both red signals and reservation costs, for the block signalled tracks
|
|
reachable waypoint tile if the closest one is free but there is no safe waiting point directly after it. Now check for a free safe waiting point beyond the waypoint unless there are junctions before the first safe waiting point.
|
|
|
|
a separate directory
|
