summaryrefslogtreecommitdiff
path: root/src/town_cmd.cpp
AgeCommit message (Collapse)Author
2009-08-07(svn r17107) -Codechange: store type of subsidy source and destination in ↵smatz
the Subsidy struct instead of determining it every time it's needed
2009-08-05(svn r17075) -Codechange: rename ~750 strings to be more uniform with their ↵rubidium
relatives
2009-07-29(svn r16978) -Fix(r16977): tab indentation instead of space indentation at ↵belugas
beginning of a line, please
2009-07-29(svn r16977) -Fix(r1772)[FS#3059]: make it so that failing to generate many ↵belugas
random towns in scenario editor returns a failing message. Fix by therken Doxygen comments by me
2009-07-22(svn r16912) -Codechange: split waypoint.h in waypoint_base.h and ↵rubidium
waypoint_func.h
2009-07-20(svn r16886) -Codechange: unify naming of some string IDs related to string ↵rubidium
codes and group them logically
2009-07-18(svn r16868) -Codechange: unify UpdateAll[Station|Waypoint]VirtCoordsrubidium
2009-07-16(svn r16849) -Codechange: replace GetCargo() by CargoSpec::Get()smatz
2009-07-16(svn r16841) -Cleanup: spaces/tabs where they don't belongrubidium
2009-07-13(svn r16825) -Codechange: unify dirtying when updating the viewport signs.rubidium
2009-07-13(svn r16821) -Codechange: unify the naming of type::UpdateVirtCoord and ↵rubidium
UpdateAll[Type]VirtCoords.
2009-07-12(svn r16795) -Fix [FS#3025]: houses wouldn't get build on the map edge.rubidium
2009-07-08(svn r16764) -Codechange: unify the way viewport signs are marked dirtyrubidium
2009-07-07(svn r16761) -Codechange: make UpdateViewportSignPos(ition) a class function ↵rubidium
of ViewportSign
2009-07-05(svn r16746) -Codechange: use Town::PostDestructor() instead of not very ↵smatz
clean construct for invalidating nearest town for road tiles
2009-07-01(svn r16714) -Codechange: use pool-like accessors for Subsidysmatz
2009-06-27(svn r16678) -Codechange: Turn CargoArray into a class, so one does not have ↵frosch
to deal with sizeof() wrt. typedef-ed arrays.
2009-06-27(svn r16676) -Codechange: Rename AcceptedCargo to CargoArray and its ↵frosch
instances to more meaningful names.
2009-06-27(svn r16673) -Codechange: rename GetProducedCargo() to AddProducedCargo() ↵smatz
and change its behaviour accordingly
2009-06-26(svn r16667) -Codechange: replace GetRandomTown() and GetRandomIndustry() by ↵smatz
Town::GetRandom() and Industry::GetRandom()
2009-06-26(svn r16666) -Codechange: replace GetHouseSpecs() by HouseSpec::Get(), hide ↵smatz
_house_specs[]
2009-06-26(svn r16665) -Codechange: replace GetTownByTile() by Town::GetByTile()smatz
2009-06-26(svn r16664) -Codechange: move house-related stuff from town.h and ↵smatz
town_type.h to separate files
2009-06-25(svn r16660) -Codechange: get rid of more dummy tile_type_procssmatz
2009-06-25(svn r16659) -Codechange: rename GetAcceptedCargo() to AddAcceptedCargo() ↵smatz
and change its behaviour accordingly -Codechange: remove dummy GetAcceptedCargo_*() handlers
2009-06-23(svn r16632) -Codechange: rename Town::flags12 to Town::flagssmatz
2009-06-01(svn r16498) -Codechange: Remove hardly used HASBITS.frosch
2009-06-01(svn r16491) -Codechange: Added parentheses around bitwise operators for ↵alberth
code style.
2009-05-24(svn r16416) -Fix [FS#2912]: Rework deleting of news when referenced ↵frosch
vehicles/stations/industries are deleted.
2009-05-23(svn r16403) -Codechange: move code related to subsidies to separate filesmatz
2009-05-22(svn r16379) -Codechange: remove GetNumTowns(), GetNumIndustries() and ↵smatz
GetActiveCompanyCount(), use PoolItem::GetNumItems() instead
2009-05-22(svn r16378) -Codechange: replace OldPool with simpler Pool. Compilation ↵smatz
time, binary size and run time (with asserts disabled) should be improved
2009-05-18(svn r16352) -Codechange: use PoolItem::GetIfValid() instead of ↵smatz
PoolItem::IsValidID() and PoolItem::Get()
2009-05-17(svn r16329) -Fix: possible desync when removing lots of towns in-game (not ↵rubidium
that we allow removing towns now, but better not have desync prone code lingering around)
2009-05-17(svn r16327) -Codechange: replace IsValidPoolItemID(index) by ↵smatz
PoolItem::IsValidID(index)
2009-05-16(svn r16325) -Codechange: replace GetPoolItem(index) by PoolItem::Get(index)smatz
2009-05-14(svn r16308) -Fix: parameter is invalid when it's equal to length of an ↵smatz
array (Yexo)
2009-05-11(svn r16277) -Codechange: enumerize values and remove unneeded values used ↵smatz
for testing town rating
2009-05-10(svn r16268) -Fix (r9876): When callback 2E returns an amount of 0, do not ↵frosch
transport 1 unit to the station.
2009-04-25(svn r16147) -Feature [FS#2635]: give the town generator a slight tendency ↵rubidium
to build towns near water by not discarding watery random tiles but by searching for near land (db48x)
2009-04-21(svn r16118) -Change/cleanup: remove the hexadecimal 'in TTD the string had ↵rubidium
this ID' from 'some' strings and replace the string name with something more sensible.
2009-04-20(svn r16101) -Cleanup (r14591): Remove an assertion to increase performance.frosch
2009-03-29(svn r15890) -Codechange: unify the way 'can a town be placed here?' checks ↵smatz
are done -Change: the requirements for location of 'random' town are now a bit less strict
2009-03-23(svn r15831) -Fix: make sure house class/ID counters don't overflowsmatz
2009-03-16(svn r15744) -Fix (r9667): when town generator failed to create requested ↵smatz
number of towns, there were too many cities
2009-03-15(svn r15729) -Fix: silence MSVC warningrubidium
2009-03-15(svn r15726) -Codechange: unify coding style for const pointerssmatz
2009-03-15(svn r15718) -Cleanup: apply some comment coding style on the rest of the ↵rubidium
sources too
2009-03-13(svn r15697) -Fix (r15695): warning about comparing signed vs unsigned.rubidium
2009-03-12(svn r15695) -Feature [FS#2672]: Allow the number of towns that will be ↵belugas
generated in the generate world window to be customized. Some warnings: -the maximum number of towns to be accepted is set to 5000 -the minimum number of towns to be accepted is set to 1 -the number that is specified is NOT guaranteed to be the exact number of towns generated. The normal mechanism of town creation has not been modified. So town placement can still fail. -setting a custom number of town will change your difficulty settings to custom as well