| Age | Commit message (Collapse) | Author |
|---|
|
reverted?) automatic railtype conversion when building track on existing rail.
|
|
rail/road combinations (including signals)
|
|
debugging levels to
use in debug.h. grfmsg() is now used as a specific debug-function for grf.
|
|
warrant a redraw, so call
that after the WE_INVALIDATE_DATA event and remove (some of) the superflouous calls.
|
|
'disable electrified railways'.
(original patch by maedhros, ideas: peter1138, Darkvater, Rubidium, Patrick, Eddi|zuHause, ..)
|
|
signal-dragger, do not bail out
at (certain) errors, just silently ignore them.
|
|
rail type should be converted
|
|
variable railtype instead of using p1 in the function. Also assign p2 to track only after it has been checked for validity
|
|
|
|
normal and
electrified rail. If building electrified rail, normal rail is upgraded
for you (for the normal cost).
|
|
instead of printf and the
verb is build/built/built not build/*/build or build/*/builded.
|
|
PLAYER_SPECTATOR and
put it into player.h where it belongs (instead of map.h)
|
|
InvalidateWindowData() in rail_cmd.c
Moved the actual modification of railtype to WE_INVALIDATE_DATA in the train depot handler
-Codechange: added SetWindowDirty() to WE_INVALIDATE_DATA as it made no sense to update the list without making the window dirty
|
|
used for all vehicle types
|
|
This gives the ability to invalidate some window data and recalculate as needed instead of doing it for each WE_PAINT
This event is called right away when using InvalidateWindowData(), so it may be a good idea to set a bool or similar in the window
or similar and then act on that bool in WE_PAINT instead of doing a lot of stuff in WE_INVALIDATE_DATA as it might be called more than once before WE_PAINT is called
InvalidateWindowData() will not automatically repaint the window, so if you want to repaint it as well, you need to mark it dirty as well.
Made the depot windows use WE_INVALIDATE_DATA to set when to generate the engine and wagon lists instead of at each redraw
It makes no sense to regenerate the list when say using the scrollbar if we know that no vehicle have entered or left the list
NOTE: currently there is a piece of code to generate the list when it's not needed and compare it to the stored list and assert if they mismatch
This check is somewhat slow and kills the whole idea of WE_INVALIDATE_DATA, so it's a short lived one to verify that InvalidateWindowData() is used everywhere where it's needed
|
|
VehicleEnterDepot()
This revealed duplicated code like aircraft lists got invalidated twice
Moved invalidation of the vehicle detail window to VehicleServiceInDepot() as it should always be updated when serviced
|
|
This change is intended to make it easier to make depot behaviour consistent
and faster to code when adding more features in the future
The user interface should hopefully not be affected by this
|
|
it accepts
DiagDirections, and add TileOffsByDir that handles Directions.
-Codechange: Make the treeloop use TileOffsByDir().
|
|
of trains that are in it
|
|
more uniform.
-Cleanup: whitespace alignment of a few tables.
|
|
|
|
bool flag and replacing it by a simple goto
|
|
|
|
|
|
|
|
{' -> '} else {', tabs between code and comment, etc.
|
|
-Codechange: DeleteDepot removes a depot from the pool
-Codechange: DestroyDepot is called by DeleteDepot to remove all things where a depot depends on.
Last 2 changes to prepare for new pool system. Not pretty now, will be soon.
-Codechange: Removed DoDeleteDepot as it was stupid
|
|
whitespace fixes only except for a few comments to make them uniform for the whole enum/struct.
|
|
|
|
ramps on steep sloped tiles
|
|
instead of a TileInfo
|
|
size_{x,y,z}
|
|
depots and waypoints
|
|
instead of GetRailTile{T,Subt}ype() - this is more concise and a bit more flexible if/when the rail tile encoding changes
|
|
above performs the same test
|
|
|
|
prohibit building rails on a road tile while road works are in progress
|
|
build rail on all road pieces without really building it ;)
|
|
- Simplify an expresssion: c ? f(x) : f(y) -> f(c ? x : y)
|
|
|
|
They were all aimed at fixing the terraform-into-tunnel problem, but introduced new sideeffects while doing so
|
|
it just contains redundant information
Yup-yup-ed by: peter1138
|
|
This fixes some glitches like "turning" the excavation by adding/removing road bits or removing the road piece
|
|
shorter, more comprehensible, less dependent on magic numbers
|
|
scope, CSE for readability, DeMorgan, if cascades -> switch, whitespace, parentheses, bracing, misc.
|
|
|
|
-Feature: Bridges can now be placed above:
Any railway track combination (excluding depots and waypoints)
Any road combination (excluding depots)
Clear tiles (duh), including fields
Tunnel entrances
Bridge heads
Thanks to Tron for idea and implementation, KUDr for the yapf synchronization and many others for hours of testing
There are still a number of visual problems remaining, especially when electric railways are on or under the bridge.
DO NOT REPORT THOSE BUGS FOR THE TIME BEING please.
|
|
support and users for testing.
|
|
It serves no real purpose except causing confusion
|
|
|
