| Age | Commit message (Collapse) | Author |
|---|
|
separate schemes for each of steam, diesel or electric engines. Savegames from the previous revision will not load.
|
|
replaces the original colour selection window and bumps the saveload version. Liveries are supported for all vehicles, not just those with 2cc support. Thanks to lakie for GUI inspiration.
|
|
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
|
|
of DoCommandP
with a boolean type.
|
|
accidentally readded in r6393
|
|
costs (could spend more than allowed when estimate and actual cost were not the same)
-Fix: [autoreplace] fixed a very rare failure when building an engine could cost more than the player could pay before selling the old one
this happened when the replacing the front cost so much that the the rear end didn't have enough money to build as expected
now the estimate keeps track of the price for the wagons/engines in front of the unit it's currently looking at
-Codechange: [autoreplace] added function to learn if and what cargo type to refit to. Needed to allow the estimation to tell refit costs
|
|
|
|
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
|
|
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
|
|
turned out to be a failure to run the wagon remoral code if the player didn't have enough money to do the replace after the replace took place
the cost animation failed to show in this condition as well
Now the test is not run anymore after the replace took place
|
|
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)
|
|
|
|
vehicle list windows
this list is also used by mass goto depot to ensure that they use the same vehicles
right now only the list of all vehicles use this for goto depot, but eventually all the types will use this
|
|
CMD_SEND_TRAIN_TO_DEPOT instead of CMD_TRAIN_GOTO_DEPOT
|
|
(forgot to disable the button in this condition)
-Code cleanup r6246: simplified SendAllVehiclesToDepot() and moved an { in PlayerVehWndProc()
|
|
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.
|
|
-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
|
|
invalid ones
-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.
|
|
whitespace fixes only except for a few comments to make them uniform for the whole enum/struct.
|
|
based at the year 0.
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.
|
|
Not Refitted To Correct Cargo (Mart3p)
|
|
vehicles. (mart3p)
|
|
|
|
turned off, the vehicles failed to enter any depots
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
|
|
date.[ch]
-Cleanup: fix whitespace related coding style issues in date.[ch]
-Cleanup: make original comments doxygen compatible and remove/change outdated comments
|
|
|
|
actually means
|
|
make it a bit clearer what's going on
|
|
Reflect this in the code
|
|
every tick to keep it exactly the same on server and clients (it doesn't fix the real source of the problem, but should solve it). Thanks TrueLight for hunting this bug.
|
|
why the makefile failed to warn about this)
also removed a few lines of debug code
|
|
cargo capacity to one with cargo capacity will now make autoreplace refit the engine to carry the cargo type from the last wagon in the train
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
|
|
type, that is set to max 0 (spotted by roboman)
somebody might add a better string than "too many vehicles in game" since none are allowed, but at least it will not crash anymore
|
|
|
|
|
|
checking its refit mask. If aircraft can be refitted to passengers, no change happens, else the first refittable type is chosen. Also use refit capacity to determine the default capacity.
|
|
|
|
|
|
only consumer
|
|
into a DiagDirection. Use it for bridge ramps and ship depots
|
|
_new_vehicle_id is enough.
|
|
as the original (pointed out by bobingabout)
[autoreplace] the same applies to autoreplaced trains if the engine is a single unit (not dualheaded or articulated)
|
|
|
|
for the first engine in the test run as well as execute run (to improve speed. The result should be unchanged)
|
|
and was number of vehicles (of a type, not total) was reached
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
|
