(svn r14683) -Change: only say a engine/vehicle is refittable when it can be refitted to at least two cargo type or when it has subcargos.
NOTE: it is still possible that a vehicle is marked refittable when there is nothing to refit to, e.g. when only one subcargo is available but that cannot be determined without a vehicle chain.

(svn r14680) -Feature(ette) [FS#2434]: Use property 4 (model life) also for wagons.
Setting property 4 to 0xFF will protect the vehicle (engine or wagon) from expireing. (Necessary since early introduction dates)
Savegames will only be affected after 'resetengines'.

(svn r13251) -Codechange: rename _patches to _settings as that is more logic.
-Codechange: move all Settings into substructs of _settings in a way that they are logically grouped.

(svn r11822) -Codechange: Replaced fixed size custom name array. Names are now attached to their object directly and there is
no limit to the amount of names.
-Fix: NewGRF engines could not be renamed.

(svn r8862) -Cleanup: doxygen changes, again. Mostly @files missing tags and a few comments style.
Some documentation addition, when i can easily supply them

(svn r8660) -Fix

-Codechange: Remove _avail_aircraft
Its name is misleading. It is rather _avail_airports, but then only some of them, which leads to inconsistencies when using it.
Further it is unnecessary to store it in savegams.

(svn r8610) -Codechange/Feature: rewrote the list handling in the 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

(svn r8455) -Codechange: Give a more meaningful name (railveh_type)to member 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.

(svn r8410) -Fix

-Fix: Fix an out of bounds array access when assigning the engine type in the _engine array
This usually hits the _engine_name_strings array and causes an invalid StringID, though it depends on the compiler which data structure gets placed after the _engines array.
Most probably this was exposed by removing railtype from Engine, which changed the size of this struct.

(svn r8385) -Fix

-Regression (r8314): I only did half the necessary changes to move railtype from Engine to RailVehicleInfo. Now do the rest.

(svn r8314) -Fix

-Codechange: Move the railtype from EngineInfo to RailVehicleInfo, because having a railtype for non-rail vehicles isn't that useful