| Age | Commit message (Collapse) | Author |
|---|
|
|
|
to not confuse it with image_index from *VehInfo.
|
|
depot
|
|
as bitmasks
|
|
|
|
casts when converting Vehicle to specialised vehicle types. Includes safety check
|
|
|
|
|
|
code style.
|
|
vehicles in more places. Esp. they were only invalidated for trains.
|
|
|
|
for all vehicle types
|
|
company-based settings, so in a multiplayer game everyone can change them.
|
|
constant and unduplicate a few lines.
|
|
unnecessarily add it.
|
|
vehicles/stations/industries are deleted.
|
|
messages. Esp. do not close them automatically after some time.
|
|
|
|
struct so (some vehicle related) NewGRF cache 'desyncs' can be tested easier.
|
|
|
|
from VehicleRail to Train
|
|
|
|
|
|
|
|
time, binary size and run time (with asserts disabled) should be improved
|
|
was deleted
|
|
PoolItem::IsValidID() and PoolItem::Get()
|
|
introduce shiny new IsPlainRailTile()
|
|
PoolItem::IsValidID(index)
|
|
|
|
wanted to go to the same depot again.
|
|
creating vehicles, instead of arbitrary sprites not related to the vehicle. (though that also applies to the question mark)
|
|
|
|
|
|
some code.
|
|
-Fix [FS#2864]: autopause and manual pausing conflict with eachother
-Fix: new game + pause on new game + autopause make the game not unpause on the first join
|
|
this ID' from 'some' strings and replace the string name with something more sensible.
|
|
|
|
stations
-Fix: insanely fast trains would sometimes 'jump' over waypoints/via stations within a tick, which would cause the order not to be processed causing the train to go in loops until (with luck) it 'hit' the tile
|
|
|
|
with only one station that has either middle or near end stop location and where the platform is (significantly) longer than the train.
|
|
end, middle or far end of a platform from the point of view of the driver of the train that enters the station.
|
|
even if not at the end of the train.
|
|
follow the vehicle in front of them.
|
|
|
|
sources too
|
|
information in purchase-list/after building before users have a chance to blame OpenTTD for incorrectly autorenewing/-replacing.
|
|
process of moving the vehicle which means that only the (orientation) data for the vehicles in front of it is valid. Now the data for the vehicles behind the vehicle are valid too.
|
|
VehiclePositionChanged and EndVehicleMove.
|
|
(though spec stated they are). Caching these variables can yield a 10+% speed increase when those vehicle variables are queried often.
|
