| Age | Commit message (Collapse) | Author |
|---|
|
CargoID loops.
|
|
carry mail
|
|
|
|
pixels) caused odd aircraft movements. On oilrigs, this caused a full crash as movement would take helicopter out of airport/station tile.
Corrected by maneuvering aircraft directly over these tiny movements, rather than relying on movement by changing facing.
|
|
|
|
check if they are in use
|
|
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.
|
|
0xFF bit 10,
which is set when a vehicle was built during the exclusive testing phase.
|
|
be used for more than just the gradual loading status.
|
|
from an aircraft and removing the airport it was heading:
- the aircraft would go to (0, 0) and circle there. Clicking the 'eye' to jump to the aircraft in the main window could cause a segmentation fault.
- when rebuilding an airport with the StationID of the old airport could crash as the FTA state of the aircraft is higher than the number of states of the new airport, causing a crash of all clients and the server when assertions are enabled.
- when rebuilding an airport with the StationID of the old airport can bring the aircraft in a state where is keeps circling the airport.
To solve these issues all aircraft without a valid order will try to go to the nearest hangar it can safely get to (large jets do not land on small airports). If there is no hangar to go to, the airplane crashes (out of fuel).
|
|
Change the signature of GetNewVehiclePos():
-void GetNewVehiclePos(const Vehicle *v, GetNewVehiclePosResult *gp);
+GetNewVehiclePosResult GetNewVehiclePos(const Vehicle *v);
|
|
comments style.
|
|
files with the @file tag as well as a few general comments style
|
|
Remove dead code
|
|
Do not pass something to a function it better could figure out by itself
|
|
Variable scope, const
|
|
Don't do bogus initialisations and prefer simpler code
|
|
on approach direction. Note: they're not yet used, but will be soon
|
|
Abbreviate GetAirport(st->airport_type) to st->Airport()
|
|
error under Win32. Changed to AIRPLANES
|
|
-Codechange: Do not hardcode the airports with a short airstrip anymore, but make it a flag in AirportFTAClass
|
|
-Codechange: Make the encoding of accepted aircraft types of airports a bit more sensible and move the enum into struct AirportFTAClass
|
|
-Codechange: Add a Z adjustment attribute for helicopter pads to AirportFTAClass to get rid of some special cases for oilrigs and heliports
|
|
blocks are stored
|
|
|
|
a sprite is too big to fit (ships and aircraft only)
-Codechange: depot windows default now makes a 1x1 matrix and resize the window by block size*number of blocks
This will make less vehicle type specific code and easier to read resizing based on sprite sizes
|
|
Remove redundant assignments. The function call just before already does it
|
|
Fix harmless typo: s/,/;/
|
|
and enummed some speed limits. This should give a more steady display in the status bar during taxiing
|
|
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
|
|
-Codechange: Put the airport movement data into struct AirportFTAClass
|
|
Building a vehicle does not involve allocating orders, so do not check whether orders could be allocated
|
|
Do not check whether the end of the depot array has been reached when building an aircraft. This cannot happen, just assert it really does not happen
|
|
Remove redundant second retrieval of the AircraftVehicleInfo when building an aircraft
|
|
Remove redundant second retrieval of the station and airport when building an aircraft
|
|
depending on their altitude and velocity
|
|
-Codechange: Move the update of the oil rig airport type to the recently (r8485) added loop
|
|
(most?) compilers...
|
|
Replace the rather obscure control flow for handling aircraft/ship/train orders by something remotly comprehensible (see r3584)
|
|
magic numbers and add a function IsNormalAircraft() which tells us whether the aircraft is in fact some flying device or a rotor/shadow.
|
|
Above that, wince-gcc gave "unused variable" on every file which included airport.h... pretty annoying ;)
|
|
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.
|
|
OT_LOADING and OT_LEAVESTATION) replaced by v->BeginLoading() and v->LeaveStation() calls. This should allow easy hooking of those state transitions in order to maintain vehicle loading queue.
|
|
macros by a simple template function max(), that requires two arguments of the same type. While I'm at it change a variable called "max" to "maxval" in a function that calls max().
|
|
stillunknown and pv2b.
|
|
|
