Age | Commit message (Collapse) | Author |
|
Additionally changes the behaviour of placing sea on sea/river/canal and placing canal/river on canal to (over)build, instead of disallowing it
|
|
IsTileType() also considers ship depots and locks water. IsWaterTile() does the right thing.
|
|
It is not like we will drain the sea first, to put water back in it after.
Besides, the cost for draining the sea isn't calculated for all other cases either.
|
|
|
|
|
|
|
|
|
|
|
|
When a vehicle is cleaned up, all news that points to the news is
also removed. This was a bit evil, as it would also remove any
news related to crashed, acting like the crash never happened.
This left players a bit in the dark what was going on exactly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
building lock.
|
|
|
|
water-based objects, the water class was always set to canal.
|
|
data is now always accessible
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
needlessly (MJP)
|
|
information for situations when we only want to know if a tile is flat or not (cirdan, LordAro)
|
|
|
|
river/canal continuation.
|
|
insanely expensive; there is no real need to fill the river with dirt first, just excavate it a bit and build borders
|
|
cannot not leave invalid canals
|
|
restore the river, if possible also on slopes (based on patch by Supercheese)
|
|
|
|
NewsFlag instead.
|
|
lock-infrastructure costs. The other two tiles may be owned by other companies. Also do not count the middle tile of a lock as canal, independent of whether it is build on ground or river slope.
|
|
|
|
|
|
enabled to a header file allowing compilers to inline that check
|
|
|
|
canals/locks/ship depots wasn't updated properly when a company went into bankruptcy or was taken over.
|
|
|
|
and restore rivers, if locks are deleted
|
|
|
|
|
|
|
|
over a ship going perpendicular to the axis of the new lock
|
|
|
|
unsupported tile types.
|
|
|
|
related variables
|