What is a town zone.

[mauried]

Making a scenerio and when trying to add houses to a small town I frequently get this error message.
Cant build house here, not allowed in this town zone.
The house is a basic cottage and it has a house zone of 0 1 2 3 .
Sometimes the add house works , but I cant understand why it sometimes works and other times doesnt.
Is a house zone and a town zone the same thing?
Generally if I try sufficient squares in a town eventually I find one where I can place the house.
The only option which tells you something about the squares in a town is the Land Area Information , but it doesnt say anything about town zones.
tnx

[jfs]

Which zones are in a town depends on how many buildings are in the town. The code that calculates how big each town zone is, is in town_cmd.cpp function UpdateTownRadius.
Zone 0 is the outermost zone, zone 4 is the innermost zone in towns with 24 or more houses.
Note that the data in the table in the function are the squared radius, so when the number in the table is 9, the actual radius is 3 tiles, and when the table reads 36, the radius is 6 tiles.

So when your house can be in zone 0/1/2/3 and you get an error about wrong zone, either you're placing it too close to the town centre in a large town, or you're placing it too far from the town centre and entirely outside the town.

[mauried]

Thanks heaps, seeing the code makes it much easier to understand whats going on.

[ebla71]

Which zones are in a town depends on how many buildings are in the town.
Zone 0 is the outermost zone, zone 4 is the innermost zone in towns with 24 or more houses.
So when your house can be in zone 0/1/2/3 and you get an error about wrong zone, either you're placing it too close to the town centre in a large town, or you're placing it too far from the town centre and entirely outside the town.

I have another question with regard to town zones:

In the following document, five different town zones are defined:

https://newgrf-specs.tt-wiki.net/wiki/N ... town_zones

TOWNZONE_EDGE
TOWNZONE_OUTSKIRT
TOWNZONE_OUTER_SUBURB
TOWNZONE_INNER_SUBURB
TOWNZONE_CENTRE

However, even when I grow a city really large (population > 200.000) and visualize the town zones in the CityMania version, I only get to see four town zones, which are colored - from inside to outside - in red, orange, green-yellow, and white.

The innermost town zone is TOWNZONE_CENTRE and I assume the tiles not colored are not part of a town zone at all.

However, it seems like the TOWNZONE_INNER_SUBURB is never created ...

[Eddi]

there are two sets of town zones, for small and for large cities:

• 0,1,2
• 0,1,3,4

where 0 is the outermost zone. 2 is the center of small towns, and 4 is the center of large towns.

[ebla71]

there are two sets of town zones, for small and for large cities:

• 0,1,2
• 0,1,3,4

where 0 is the outermost zone. 2 is the center of small towns, and 4 is the center of large towns.

Thank you very much for the explanation - but how do these map to the pre-defined town zone variables? And even for the large cities, there are only four zones, not five as in the list here

TOWNZONE_EDGE
TOWNZONE_OUTSKIRT
TOWNZONE_OUTER_SUBURB
TOWNZONE_INNER_SUBURB
TOWNZONE_CENTRE

In the Citymania client, for very small towns (population < 250) there is only a "white zone" shown - is this zone 0 or zone 2? Or in other words, is counting "from inside out" or "from outside in".

And is this "white zone" then equal to TOWNZONE_EDGE or TOWNZONE_CENTRE - or is there at least a way to easily show?

Only care at the moment of creation of an industry to check if allowed or not, since industries are supposed to be static afterwards, unless "bulldozed" by player.

[ebla71]

Something that particularly confuses me is that town zone 0 appearently incorporates both the outermost zone of the town as well as all other tiles not part of a town?!?

For example, I use the following code to control if an industry can be built in town zone 0 or not:

switch(FEAT_INDUSTRIES, SELF, Shopping_Centres_town_zone,
(town_zone(0,0) == 0)) {
0: return string(STR_ERROR_ONLY_IN_TOWNZONE_EDGE);
return CB_RESULT_LOCATION_ALLOW;
}
...
item(FEAT_INDUSTRIES, Shopping_Centres, 106) {
property {
...
}
graphics {
...
location_check: Shopping_Centres_town_zone;
}
}

That generally works, but the extent of the zones is not as I expected, see the following three screenshots taken with the CityBuilder version:

The first one is just the town zones displayed:



The second has town zones and "no-build zones" overlapping:



And the third one displays only the "no-build zones" which here should be all tiles which are not covered by town_zone(0,0) == 0



Is there a simple way to allow building of industries only in town zone zero (= white area in the first picture) but not the surronding non-town tiles?

[ebla71]

Another interesting thing is that in the 1st picture above, "Nonborough" actually has five town zones, from inside to out side: red, 2x orange, yellow-green, and white.

The two orange ones, I suspect, are TOWNZONE_INNER_SUBURB and TOWNZONE_OUTER_SUBURB, but in many town, their "width" seems to be so small that they are overlapping (due to rounding errors?!?)

The strange thing is that even in very large towns, sometimes there is only four and sometimes five zones and even if you grown the "4-zone ones" a lot, a 5th zone never becomes visible.

[PikkaBird]

Something that particularly confuses me is that town zone 0 appearently incorporates both the outermost zone of the town as well as all other tiles not part of a town?!?

Yes, it's something of an oversight in the spec that that variable does not distinguish between town zone 0 and no town zone.

A full resolution, I'd say, would be to compare the variable town_euclidean_dist of the industry to town_zone_0_radius_square of the town - if it's less or equal, you're in the zone. Something like this:

Code: Select all

switch(FEAT_INDUSTRIES, SELF, Shopping_Centres_town_zone3, 
town_euclidean_dist(0,0) - last_computed_result) {
0..0x7fff: return CB_RESULT_LOCATION_ALLOW;
return string(STR_ERROR_ONLY_IN_TOWNZONE_EDGE);
}

switch(FEAT_INDUSTRIES, PARENT, Shopping_Centres_town_zone2, 
town_zone_0_radius_square) {
0: Shopping_Centres_town_zone3;
Shopping_Centres_town_zone3;
}

switch(FEAT_INDUSTRIES, SELF, Shopping_Centres_town_zone, 
town_zone(0,0)) {
1..4: return string(STR_ERROR_ONLY_IN_TOWNZONE_EDGE);
Shopping_Centres_town_zone2;
}

A simpler solution would be to wing it with some arbitrary distance that produces an acceptable result.

[ebla71]

Something that particularly confuses me is that town zone 0 appearently incorporates both the outermost zone of the town as well as all other tiles not part of a town?!?

Yes, it's something of an oversight in the spec that that variable does not distinguish between town zone 0 and no town zone.

Thank you very much for the explanation. In particular the code fragment below will be super helpful in the further development of the industry NewGRFs (yes, it's two now) I'm currently working.

A full resolution, I'd say, would be to compare the variable town_euclidean_dist of the industry to town_zone_0_radius_square of the town - if it's less or equal, you're in the zone.

I already thought along those lines but still hoped for a more simple or at least shorter solution Anyway, the example will help me a lot and is well appreciated.

[PikkaBird]

You're welcome.

Looking at it again this morning, I think I got "town_euclidean_dist(0,0) - last_computed_result" the wrong way around - it should be the radius minus the distance. But you get the idea.

[ebla71]

Looking at it again this morning, I think I got "town_euclidean_dist(0,0) - last_computed_result" the wrong way around - it should be the radius minus the distance.

No, actually the following code fragment - with the two sides of the equation as originally posted - work as intended when called by location_check within the graphics block of item(FEAT_INDUSTRIES, Moonshine_Destillery, 1)

Code: Select all

switch(FEAT_INDUSTRIES, SELF, Moonshine_Destillery_town_zone3,
	town_euclidean_dist(0,0) - last_computed_result) {
		0..0x7fff: return CB_RESULT_LOCATION_ALLOW;
		return string(STR_ERROR_ONLY_IN_TOWNZONE_EDGE);
}
switch(FEAT_INDUSTRIES, PARENT, Moonshine_Destillery_town_zone2,
	town_zone_0_radius_square) {
		0: Moonshine_Destillery_town_zone3;
		Moonshine_Destillery_town_zone3;
	}
switch(FEAT_INDUSTRIES, SELF, Moonshine_Destillery_town_zone,
		(town_zone(0,0) == 1) |
		(town_zone(0,0) == 2) |
		(town_zone(0,0) == 3) |
		(town_zone(0,0) == 4)) {
			1: return string(STR_ERROR_NOT_IN_TOWN);
			Moonshine_Destillery_town_zone2;
		}

The only thing that's still not possible with this code is to prevent building of the industry in very small towns (Population < 190 or so) which only have town zone 0 (the white area in CityMania). That would possibly need another switch to exclude building next to houses, assuming that there is little to no empty tiles in such small town?!?

And, btw, the above code also gives a hint on the topic of the industry set I'm currently working on

[PikkaBird]

That would possibly need another switch to exclude building next to houses, assuming that there is little to no empty tiles in such small town?!?

You could just check the population of the town, if you only want it in towns over a certain size.

[Eddi]

i think ecs-vectors calculated the population in an area around the industry.

[ebla71]

You could just check the population of the town, if you only want it in towns over a certain size.

That's an interesting suggestion, thank you very much.

It will certainly do the job, but what bothers me (if only from a "beauty of code" point of view ) is that it makes use of another variable, not town zone.

Any chance to get the issue with town zone 0 including both the othermost zone of a town plus all of the non-town tiles fixed?

Or not even worth to file a bug report since this is so hard-wired into the code and basis for many NewGRFs?

[Eddi]

Or not even worth to file a bug report since this is so hard-wired into the code and basis for many NewGRFs?

changing the spec is hard, but not impossible.

there would be two ways to do that:

1. waiting for a major bump in GRF version, to bundle such an incompatible change in.
2. adding a new variable, with the changed semantics. existing NewGRFs can still work with the old ones, but newer NewGRFs would be recommended to use the new one.