| Age | Commit message (Collapse) | Author |
|---|
|
acceleration.
|
|
rail/road combinations (including signals)
|
|
debugging levels to
use in debug.h. grfmsg() is now used as a specific debug-function for grf.
|
|
multiplier instead of a vehicle. Fixes incorrect display of total
train capacity.
|
|
vehicle of a chain after reffiting
because free wagons present in depot can have the same type as the one bought and refitted by autoreplace
|
|
braking
force is applied. This ensures trains will stop when going down hill.
|
|
small amount of power being applied whilst moving off and then double the power at 1 mph. This resulted in a perceived delay before trains moved. Fix this by applying the full power of the engine (or the kick off, whichever is greater). Essay over.
|
|
orders from current orders (caused refit error popup when not having no orders)
|
|
DeleteVehicle to the sell commands as they are not called as often
Also added a return to the window loop prevent looking at the rest of the windows once the right depot window is found
|
|
around.
During this procedure the train is split into parts which can result in
incorrect images being used.
|
|
player, resulting in an empty vehicle purchase list. Specify the player
as an argument to IsEngineBuildable()
|
|
|
|
warrant a redraw, so call
that after the WE_INVALIDATE_DATA event and remove (some of) the superflouous calls.
|
|
multiplier for the weight of cargo on freight trains, to simulate longer heavier trains. The default value of 1 behaves as before.
|
|
values to avoid possible overflows.
|
|
'disable electrified railways'.
(original patch by maedhros, ideas: peter1138, Darkvater, Rubidium, Patrick, Eddi|zuHause, ..)
|
|
lost" message (peter1138)
|
|
immediately when pathfinder can't find the path. (thanks MeusH, peter1138 and Brianetta for ideas and help).
|
|
a single engine with ctrl-click.
|
|
|
|
articulated engines. As this could result in more parts being added than previously counted, we check to see if we need to allocate more vehicles as we add parts.
|
|
could read from a NULL pointer
|
|
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
|
|
in the train purchase list.
|
|
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
|
|
(can only be done in goto depot orders)
Example: make a train transport iron ore from A to B, then it visits a depot and refits to steel
It then transport steel back to A or near A if there is a factory and then it visits another depot to refit to iron ore again
This is controlled in the orders. If a goto depot order is lightlighted, then "Unload" changes to "Refit"
Control click "Refit" removes the refit part of the order (as the tooltip says)
The player will still pay the normal refit costs
Known issues:
If a vehicle is not in a depot, then the refit window will fail to tell refitted cargo capacity
Refit costs in the refit window can sometimes print 0 when it should not because the refit calculation is unaware that the vehicle will be refitted in between
Warning: autoreplace got a protection against replacing something so you get a new cargo type, but it can fail here. In the iron ore/steel example, it can see that
the vehicle carries iron ore and the new one can be refitted to iron ore, then it will replace. It will not check to see that it's valid for steel as well.
This is something to look into in the future
|
|
may change.
|
|
priority isn't supported.
|
|
vehicles in a depot.
IsWholeTrainInDepot() is removed as CheckTrainInDepot() could be used instead
Cleaned up the check to see if a vehicle is valid for start/stop
|
|
|
|
from each time the window is redrawn
To do this, the player struct contains an array, that contains the count of each engine type that the player owns
Those arrays are updated each time a vehicle is build or deleted and is calculated on load (it's not saved)
It's possible to access the arrays outside of the autoreplace GUI, so feel free to read from them in other patches as well
|
|
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.
|
|
|
|
into GetRefitCost()
Now it's possible to tell refit costs for an EngineID without actually having build a vehicle
|
|
Now all vehicles are serviced when it's time for service and they are in a depot
This will avoid the goto depot order from ever showing up when in a depot
|
|
large as any type of destinataion (StationID, DepotID, WaypointID) it can hold
DestinationID being a union of these types is just hassle without benefit and cannot be handled correctly everywhere because of local lack of information
|
|
now vehicles can't be sent to a depot when they are already inside a depot
before they would remember the order and try to turn around when leaving the depot
|
|
vehicles to depots
|
|
will now alter the service/stopping in depot flag instead of cancelling the goto depot order
|
|
goto depot button
-Codechange: unified the code for mass goto depot to avoid duplicated code
-Fix: Vehicles already on the way to depots will not be cancelled by mass goto depot (made it really hard to send all vehicles at once)
|
|
depot" button
it's located in the vehicle list screen and does the same as in the shared orders window (send all vehicles in list to a depot)
it will still not inform the player if a vehicle failed to find a depot, so don't take for granted that all of them go
|
|
this will try to send all vehicles in the list to depots/hangars
currently if one fails to find a depot, it will not tell the player
|
|
{' -> '} else {', tabs between code and comment, etc.
|
|
'/*' or '*/' in '//' style comments.
|
|
at the depot and leave right away.
To tell the difference the status of stopping vehicles will be in red,
while servicing vehicles will be green.
-Codechange: remove some dead code in CmdSendAircraftToHangar() since it is
conflicting with new functionality. Now p2 means the same for all types
|
|
off due to absence of distance-normalization (Rojer)
|
|
-Codechange: introduced DestinationID, which is in fact an union of several types
Used in Order struct, so no longer StationID is abused for all targets.
Hangars are a big exception, as they use a station-id with GOTO_DEPOT (go figure)
|
|
-Codechange: IsValidXXXID now also checks if XXX is really valid, not if the number is within range
Both changes again in preperation of the new mem-pool system, which requires this.
IsValidXXXID is not a bit less pretty, but that will be cleaned up after the new mem-pool system
|
