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
-Codechange: DestroyVehicle is called by DeleteVehicle to remove all things where a vehicle depends on.
Last 2 changes to prepare for new pool system. Not pretty now, will be soon.
-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
-Codechange: use IsValidXXX where ever possible
Note: both changes to prepare for new pool system, which needs those changes.
For every pool there are 2 ugly lines, which will be removed when done
implementing new pool system.
Based on FS#13 by blathijs, partly implemented.
The game date subsystem now allows someone to start in the year 0 and continue
up to the year 5 000 000. However, you currently cannot build anything before
1920 as there is no newgrf support for dates before 1920 or after 2090 yet.
now they will quickly go to a depot if set to be replaced
the tradeoff is that a vehicle set to be replaced and without a depot in the orders will forget about the orders and head for a depot. If the replace fails (lack of money), it will exit and try to head for the depot again
also all vehicles of that type will rush to the depots at once, risking causing traffic jams. This is because there is no way to even it out like normal depot visits offers
Tip: add a depot to the orders of all vehicles, set it to service only and it will always be skipped unless the vehicle is set to be replaced. This should help on the jam issue and if the replace fails, the vehicle will go though a whole round of the orders and make more money before trying again
-Cleanup: fix whitespace related coding style issues in date.[ch]
-Cleanup: make original comments doxygen compatible and remove/change outdated comments
if the train is carrying the type of cargo, that is default for the engine, it will not be refitted
if the last wagon do not carry cargo, the refit will be to the type of the last wagon, that do carry cargo
now the new vehicle gets the same number as the old one, completely removing the problem where we could run out of numbers
since we don't have to find free numbers for the new vehicles, autoreplace should be somewhat faster, specially in late games
NOTE: in CmdBuildRailVehicle(), bit 0 and 1 in p2 have been switched to make the meaning of bit 0 consistent with the other build commands. CmdCloneVehicle() is modified to follow this as well
now cloned vehicles get the same service interval as the original vehicle
I applied this to autoreplace as well even though it's not mentioned in the bug report (autorenew should not alter service interval)
There's exactly one implemented function (unbarring a level crossing) and one place where it can be triggered (a train leaves a level crossing)
It's a bit overkill, so just handle this one case where it can happen
1) Improved the road vehicle allocation (aka slotting) for multistop. Stops can now accept unlimited, er... 256, vehicles.
2) Removed the "wait for stop" feature, because it did not work in practise.
3) Slotting now ignores unreachable stations. Uses NPF at the moment because the old pathfinder cannot do it (yet)
4) Now matter how many vehicles approach a station, they will always be distributed evenly over existing stops.
5) Hopefully the last fundamental change to multistop
