| Age | Commit message (Collapse) | Author |
|---|
|
- A proper ./configure, so everything needs to be configured only once, not for every make.
- Usage of makedepend when available. This greatly reduces the time needed for generating the dependencies.
- A generator for all project files. There is a single file with sources, which is used to generate Makefiles and the project files for MSVC.
- Proper support for OSX universal binaries.
- Object files for non-MSVC compiles are also placed in separate directories, making is faster to switch between debug and release compiles and it does not touch the directory with the source files.
- Functionality to make a bundle of all needed files for for example a nightly or distribution of a binary with all needed GRFs and language files.
Note: as this merge moves almost all files, it is recommended to make a backup of your working copy before updating your working copy.
|
|
move the low level network functions to network/core, so they can be reused by the masterserver and website-serverlist-updater.
|
|
debugging levels to
use in debug.h. grfmsg() is now used as a specific debug-function for grf.
|
|
always load cargo
if it's available with full load any (Maedhros)
|
|
of a running game.
This is only possible in SP (or in the intro menu). During game play you will
get a confirmation window when applying the changes as some actions can crash
OpenTTD and/or make your current game unplayable.
|
|
vehicles that are outside the map.
|
|
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
|
|
This turned out to be due to continue to drag the old vehicle, that autoreplace sold
This could also be triggered if more than one player used the same company
Now deleting a vehicle will remove all depot highlights of that vehicle
|
|
GetNumXXX() and add GetMaxXXXIndex() functions. This prepares for the new pool interface.
|
|
pool", so the new pool implementation can be committed alongside it.
- Codechange: Rename pool.[ch] to oldpool.[ch].
|
|
|
|
incur the expense as running costs, not new vehicles.
|
|
|
|
|
|
The last parameter should point to the end of the buffer (eg lastof(buf))
Courtesy of Tron.
|
|
custom name.
|
|
vehicle type
|
|
stopped and the player gets a message (like vehicle stopped in depot)
This should prevent a vehicle from failing to be refitted and then show up and block a station with full load.
In such a case, it's better to stop in a depot (that will not stop any other vehicles) and notify the owner
|
|
against CT_NO_REFIT to checks for valid cargo IDs
This should prevent any bugs made by mixing up CT_NO_REFIT and CT_INVALID
|
|
in shared orders and station lists
|
|
vehicle if the old type can refit to the cargo types being used in the refit orders and the new one lacks one or more of those refit capabilities
|
|
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
|
|
switch-case into using a function, that was added in r6647
|
|
This moved a few of the strings and sprites a few pixels. Hopefully this will work out ok.
|
|
selling the old vehicle to build the new one
Say we got 40k for selling the old one and the new one costs 60k, then the player only needs 20k to replace
The new engine is still built before selling the old one for various reasons, but now the player gets a loan
of the sell value, which is always repaid when replace fails or the old engine is sold. The player will never notice this loan.
|
|
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
|
|
DBsetXL, amongst others. This requires a savegame bump to save the cargo subtype.
|
|
|
|
for testing)
|
|
vehicles having a certain depot in their orders
It got one known issue though. The top bar got a plural issue so expect to see stuff like "1 trains" until we figure out why it behaves this way
Added the button to the depot windows. Made the autoreplace button bigger while I was moving some widgets anyway
Made road vehicle depot windows start with one more row to make room for the buttons
|
|
allocation over and over if possible (like BuildDepotVehicleList() )
This will prevent some reallocations when sorting vehicle list windows
It also prevents moving the whole array into a new one each time the list is generated/updated (it used to make the list in one array and then move it into another one each time)
Also ensured that neither GenerateVehicleSortList() or BuildDepotVehicleList() will never allocate lists longer than the total number of vehicles in the game
|
|
failed to restart after being replaced
Also fixed an issue where cost animation could fail to show (trigger events appeared to be linked for those two issues)
|
|
autoreplace in a depot window could result in asserts
It still got an issue where it fails to restart moving vehicles after they are replaced though. The cause of this will hopefully be found shortly
|
|
vehicle lists
|
|
depot" button
Like the "sell all" button, this one lacks a sprite as well. We will hopefully get one shortly
|
|
It's right below the sell button (sell whole chain button for trains)
It's still missing a sprite. That one will be added as soon as anybody draws something we can use
To make room for this button, all depots except train depots now opens with an additional row and can't be resized shorter than that
|
|
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
|
|
windows
|
|
This will ensure that you can always get the same list when checking for vehicles in a depot (no need to duplicate code for each place, that needs such a list)
Since the vehicles are only looped once for each redraw, drawing speed is around twice as fast (measured to be 114%-121% faster depending on the number of vehicles in the game)
|
|
none, your
own, or all companies.
|
|
autoreplace to ensure that such a failure will not break a game
We should only reach this error() if there is a bug, that would otherwise make the vehicles carry a different type of cargo without telling the user
This also kills the warning added in r6464 (oops)
|
|
added an error popup in the game if autoreplace fails to refit
Since it's only triggered by conditions bugs can trigger, it works kind of like a non-fatal assert in builds without asserts
|
|
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
|
