| Age | Commit message (Collapse) | Author |
|---|
|
|
|
width.
|
|
dynamically if there's still not enough room for the text.
|
|
windows again to make room for all the text.
|
|
coding style (and rest of the code).
|
|
the code to figure out if an aircraft is buildable in the hangar in question
This should help ensuring that the build command and the list are consistent in what aircraft are buildable
|
|
velocities to from 8mph to 1km/h (peter1138), also give aircraft realsitic velocities (so that 1km/h is 1km/h independent of vehicle type) (peter1138). Introduce a flag to reduce aircraft speed in holding patterns to some realistic velocity. Use this flag for the city airport for the time being and make use of the different entry points for this airport type.
|
|
comments style.
|
|
struct array (with accessor) and implement new initialization method using cargo labels.
|
|
Variable scope, const
|
|
We should keep the list in sync with the build command as hacked clients can avoid a block in the GUI only
|
|
aren't the same (even though they both tell if it's a plane or helicopter)
|
|
that can't use the airport in question
Now it's even better than ever because unless the no jetcrash cheat is enabled, the small airports will not show fast aircraft
|
|
Abbreviate GetAirport(st->airport_type) to st->Airport()
|
|
too many lines in build vehicle windows and crash the game
|
|
-Codechange: Make the encoding of accepted aircraft types of airports a bit more sensible and move the enum into struct AirportFTAClass
|
|
EngineID with certain newGRF sets
|
|
VEH_Train is 0, VEH_Road is 1 and so on
This means that "v->type" can be used as array indexes instead of VehTypeToIndex() (or "v->type - VEH_Train/0x10 as the code still used in some places)
Surprisingly this can be done without changing the savegame format
|
|
autoreplace window
-The user will notice the following changes:
All vehicle types behaves in the same way
Adding/removing an engine (new design and so on) can no longer result in the window selecting a new engine
All valid replacements will be displayed since it looks at refitting options as well (this solves the missing ships with the newships GRF)
Since you can't replace an engine into itself, the engine selected in the left list will no longer appear in the right list
-The code changes:
Instead of looping all engines all the time, each list generates a list like the build windows
This ensures consistent list generation since only one function can loop all engines
Unified code for all vehicle types
It now use the lists to call the drawing code in the build vehicle window
Works on selected EngineIDs instead of selected index in the list
|
|
|
|
code, as 1 mph == 1.6 km/h is too far out for some people.
|
|
in appeantly random order
|
|
flags of RailVehInfo, as well as changing the code to reflect the fact that it was not a flag but rather a one value only variable. Doing so, some evaluations have been simplified.
-Codechange: Add and use RAILVEH_SINGLEHEAD when railveh_type is set to 0, which was implicit before.
-Cleanup: Remove some extraneous parenthesis.
|
|
Now it only works on first and last widget to resize
It now works with offsets correctly (no longer assumes the left is 0)
It's no longer needed to have a widget right of the ones you resize
Can handle any number of widgets
|
|
-Regression (r8314): I only did half the necessary changes to move railtype from Engine to RailVehicleInfo. Now do the rest.
|
|
for each window, a global ResizeButtons() is added
|
|
refitable detection. It had two variables doing the same thing, but not always set to the same (oops)
|
|
DrawVehiclePurchaseInfo() and renamed them into type specific names
|
|
the details with one line since some newgrf trains needs it
|
|
only add "(refitable)" if the engine in question is refitable
|
|
request wants to draw more vehicles than the list contains
|
|
loop to a function of it's own
-Fix (r8335): [vehicle build window] ship sprites were moved two pixels to the left
|
|
removed two switch-cases, that we can do without
|
|
intelligent) then other compilers when it comes to operator precedence.
A copy of code from train_gui.cpp to build_vehicle_gui.cpp was not exactly the same.
The earlier version did not require parenthesis to specify correct operator precedence.
|
|
Note: now all build vehicle windows are merged into build_vehicle_gui.cpp
|
|
build_vehicle_gui.cpp and added arrays + VehTypeToIndex() instead
|
|
0,1,2... for use for index to arrays
Used this function to get rid of some switch-cases in build_vehicle_gui.cpp
-Fix (r8335): ship build window didn't remember assending/decending sort setting
|
|
horizontally and contains sorting options
-Codechange: the build ship window is merged into build_vehicle_gui.cpp
|
|
|
|
instead of rebuilding the list and then rebuild it the next time it's redrawn
This should save CPU time in the (maybe unlikely) event that the list is invalidated more than once between two redraws
|
|
from build_vehicle_gui.cpp to aircraft_gui.cpp
|
|
in horizontal direction as well
-Codechange: merged train and aircraft build window code
|
|
values.
This lets us increase the sprite width from 14 to up to 29 bits,
effectively nulling the old sprite limit. Table changes in next commit.
|
|
stillunknown and pv2b.
|
|
renamed to .cpp)
|
