When a city wants to build a new building, one of the factor that the cityrules should take into consideration is empty tiles that are covered by a passenger/mail station's coverage area.
These areas should have a higher probability of getting new buildings than non-covered areas.
I'm under the impression that this is already the case, though I might be wrong.
If this is already implemented then I'm not feeling the effects of it in the game. In game the cities don't seem to take this factor into consideration when choosing the location of a new building.
I've been looking into the cityrules.tab file (of pak64) and haven't found anything related to this.
The only thing I've found is a symbol in the rules to create a rule which includes a stop on a neighbouring tile.
# Symbols in rules:
# S = must not be road
# s = must be road
# n = must be bare land
# H = must not be house
# h = must be house
# T = not a stop // added in 88.03.3
# t = is a stop // added in 88.03.
# U = allowed slope for roads
# u = forbidden slope for roads
What I'm suggesting is more like an affinity like the ones that specify how residential/comercial/industrial buildings influence each other:
#
# relative affinities for certain building types which can lead to clustering of certain building types
#
# avoid building next to industry
res_start_score = 0
res_near_ind = -8
res_near_com = 0
res_near_res = 8
res_near_passenger = 3
res_near_mail = 1
# everywhere is good, next to com best
com_start_score = -10
com_near_ind = 1
com_near_com = 8
com_near_res = 1
com_near_passenger = 1
com_near_mail = 2
# next to res means expensive filters and no truck after 10 pm => avoid this ...
ind_start_score = 0
ind_near_ind = 8
ind_near_com = 0
ind_near_res = -8
ind_near_passenger = 2
ind_near_mail = 1
Note: the affinities in bold are my suggestion and the values are just examples I made up without any testing and shouldn't be considered for balancing purposes.
Perhaps this topic would be better placed under the pak64 section instead of the general extension request section. If that's the case I ask the moderators to move this topic accordingly.
City growth is only modified on a global level (i.e. affecting the whole city area). Modification is based on passengers who want to travel vs passengers who actually found a route.
Passenger generation is a CPU heavy task already, putting more calculations in there will not be liked, I assume. Bit Prissi and the current developers must decide finally.
Hajo, I don't think that's what is being requested. I think (and generally support) the idea is to build/upgrade buildings in areas covered by the stations in preference to those outside of station area. So it is more about making the citybuilder more sophisticated rather than making the passenger generator more sophisticated.
I see. That should be fairly easy then, although again time consuming (At least the old code had no flag for a tile "is covered by station" but the program had to actually look through the station list if there is a station nearby. Maybe this was changed in the past years?)
I guess it makes sense, though. Sorry for the confusion.
Quote from: The Hood on February 26, 2010, 01:58:05 PM
Hajo, I don't think that's what is being requested. I think (and generally support) the idea is to build/upgrade buildings in areas covered by the stations in preference to those outside of station area. So it is more about making the citybuilder more sophisticated rather than making the passenger generator more sophisticated.
Yes, that's just it.
Quote from: Hajo on February 26, 2010, 02:09:23 PM
Sorry for the confusion.
No problem.
Quote from: Hajo on February 26, 2010, 02:09:23 PM
I see. That should be fairly easy then, although again time consuming (At least the old code had no flag for a tile "is covered by station" but the program had to actually look through the station list if there is a station nearby. Maybe this was changed in the past years?)
I guess it makes sense, though.
Simutrans is done in C++ right? if that's the case, the Class that represents each Tile (I suppose you have a class for that, although I'm try to guess here ;) ) could have boolean atribute(s) to indicate passenger/mail/goods station coverage.
QuoteSimutrans is done in C++ right? if that's the case, the Class that represents each Tile (I suppose you have a class for that, although I'm try to guess here Wink ) could have boolean atribute(s) to indicate passenger/mail/goods station coverage.
Ah, an expert! That's very good! You should know that Simutrans is open source, so feel free to implement it yourself! If it's good enough, the developers will undoubtedly incorporate your patch!
Quote from: mad_genius on February 26, 2010, 02:17:22 PM
.. the Class that represents each Tile [...] could have boolean atribute(s) to indicate passenger/mail/goods station coverage.
Sure it could. But such a map has plenty of tiles, and big maps already need a big amount of memory. While I was active, I wanted to save the memory, and let the CPU do search (memory bandwidth was a problem those days, CPU load less of a problem). Prissi might have changed this in between, I haven't checked the code since years.
Anyways, the feature will come with a certain overhead, be it memory, or more CPU load, and it's hard to say if the benefit from the feature is worth the additional CPU load or memory requirement. Actually the feature only has very minor benefit to gameplay, it "nice to have", but might not change the players experience enough to rectify the additional overhead ... but as said above, Prissi or one of the other developers must decide if they want to include it. Technically it's possible and not very difficult.
Implementation would be very easy. Even the information whether a tile is in reach of a station is already there.
However, this feature would also enable to block the citites development unintentionally. In order that a city is able to expand, the player has to enlarge the catchment areas of his stations first.
Edit: I see, you want only influence the probability of building on such tiles. This should be perfectly doable without much perfomance hits.