On town growth and new switches (long)
Marcin Grzegorczyk
in TTD, and what my new switches ('towngrowthlimit' and 'largertowns')
really do, here's an explanation (with technical details).
(A reminder: TTD simulation engine works synchronously. One /tick/ of
the simulation engine takes ca. 27 ms, if the machine is fast enough.
One TTD day is ca. 74 ticks.)
The /expansion state/ of a town is determined by two fields in town
structure: bit 0 in the word at the offset 0x12 (I'll call it the
growth_flag) and the byte at 0x0A (idle_countdown):
growth_flag idle_countdown state
----------- -------------- -----
0 any blocked
1 0 expanding
1 nonzero idle
Town status update (including expansion) is performed on every tick in a
round-robin fashion; since the town array can hold 70 entries, the main
town status update procedure is called every 70 ticks for each town. If
the town is blocked, nothing happens. If it's idle, idle_countdown is
decremented. If it's expanding, an attempt to place a new building or a
piece of road (or a bridge) is taken; if it succeeds, the expansion
state is changed to idle (by setting idle_countdown to the byte at 0x39,
a.k.a. growth_rate).
growth_rate is reset each month, and depends on the number of 'active'
stations within town's transport zone as follows (it's a countdown init
value, so smaller value = faster growth):
# 'active' growth_rate
stations normal funded[1] funded[2]
---------- -------- --------- ---------
0 160 [3] 60 60
1 210 60 60
2 150 60 60
3 110 60 50
4 80 60 40
5 or more 11 [4] 60 30
[1] When a town building fund is active (i.e., up to 3 months after
using the "Fund new buildings" option).
[2] As in 1, but with TTDPatch 1.9.1 alpha 25 or later, if
'generalfixes' or 'largertowns' is active.
[3] There's a 11/12 probability of the town being blocked in this case,
so the effective mean growth_rate is 1920.
[4] This is a bug in TTD. TTDPatch now fixes this if 'generalfixes' or
'towngrowthlimit' is active, and uses 55 instead.
Town growth is also blocked:
- in the sub-arctic climate, if the central tile of the town is above
the snow line and no food has been delivered to the town in the last month;
- in the sub-tropical climate, if the central tile of the town is in
desert and no food and water has been delivered to the town in the last
month.
TTDPatch modifies this (if 'largertowns' is active) by not blocking
towns with population less than 90 in sub-arctic or 60 in sub-tropical
climate, so they get a chance to grow enough to accept food.
If 'largertowns' is active, growth_rate is halved for selected towns
(except the case marked as [3] above, so transport is still necessary to
make towns grow).
A station is 'active' if any cargo has been picked up or accepted there
within the last 50 days. The type of cargo is irrelevant, so if there's
a coal mine in the middle of a town and you're picking up coal there, it
will contribute to the growth of the town. This also means that more
small stations make a town grow faster than one big station, as long as
they're serviced regularly.
The town's transport zone is a circular area around the town's central
tile. Its radius (in tiles) is a function of the number of town
buildings as follows:
# town buildings radius of transport zone
---------------- ------------------------
0..3 2
4..7 4
8..11 5
12..15 6
16..19 7
20..35 8
36..71 9
72 or more 0
Notice the last row. If there's more than 71 town buildings, the
transport zone vanishes and stations no longer contribute to the growth.
TTDPatch's 'towngrowthlimit' changes this by sort of interpolating the
function for larger values.
For the fans of hex-editing: The word at offset 0x14 in a town structure
holds the transport zone radius squared. (There's no point in editing
it though, it'll get reset very soon.)
TTDPatch also now fixes a bug in TTD: originally, if a town building
under construction was removed, the internal number of buildings (word
at offset 0x36) was not updated.
The function called if a town is in 'expanding' state starts by
performing a sort of silly-walk to find a piece of road in the vicinity
of town's centre. If no road is found, an attempt is made to create it.
If a road piece is found, the function randomly 'walks' the roads trying
to find a place to create a new house. Normally, this 'walk' is limited
to 20 steps (a tunnel counts as one step), which limits the maximum
possible extents of a town. TTDPatch's 'towngrowthlimit' may be used to
set this limit to any other value, up to 128.
Regardless of all the town growth processing mentioned above, each town
building's status is updated periodically (every 256 ticks I think).
This includes construction progress and 'production' of passengers and
mail. If the town the building belongs to is not 'blocked', this also
includes destroying the building (and, with 61/64 probability,
immediately building a new one in its place) at random intervals. I
mention it here to point out that this has nothing to do with town growth.
I hope someone will be able to understand what I wrote above :-)
--
Marcin Grzegorczyk
Mario Schmidt
around 30000 people in it like in TTO?
Josef Drexler
> With all these new switches, is it now possible to have large cities with
> around 30000 people in it like in TTO?
Easily. I just made one with a population of 50000. This might be
dangerous though, because if it grows a lot more (to 65535), it'll reach
the integer limit and wrap around to zero...
--
Josef Drexler | http://publish.uwo.ca/~jdrexler/
---------------------------------+---------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Avoid showers. Take a bath. | Don't remove the "nospam" part.
Jan Willem
<mgrz...@itma.pwr.wroc.pl> wrote:
>Since there are no doubt many people curious as to how town growth works
>in TTD, and what my new switches ('towngrowthlimit' and 'largertowns')
>really do, here's an explanation (with technical details).
Great explanation, thanks.
> # 'active' growth_rate
> stations normal funded[1] funded[2]
> ---------- -------- --------- ---------
> 0 160 [3] 60 60
> 1 210 60 60
> 2 150 60 60
> 3 110 60 50
> 4 80 60 40
> 5 or more 11 [4] 60 30
The growth_rate at 5 stations does indeed seem a bit low. But are you
_sure_ it is a bug? Combined with...
>
> # town buildings radius of transport zone
> ---------------- ------------------------
> 0..3 2
> 4..7 4
> 8..11 5
> 12..15 6
> 16..19 7
> 20..35 8
> 36..71 9
> 72 or more 0
...I get the impression that Chris Sawyer deliberately put a limit to
how big he wanted towns to grow.
Of course, what CS wants is irrelevant to us industrious patch
afficionados, so welcome to the new switches, but I wouldn't be so
sure to call them bugfixes, rather than new features.
>
>The function called if a town is in 'expanding' state starts by
>performing a sort of silly-walk to find a piece of road in the vicinity
>of town's centre. If no road is found, an attempt is made to create it.
>If a road piece is found, the function randomly 'walks' the roads trying
>to find a place to create a new house. Normally, this 'walk' is limited
>to 20 steps (a tunnel counts as one step), which limits the maximum
>possible extents of a town. TTDPatch's 'towngrowthlimit' may be used to
>set this limit to any other value, up to 128.
>
Only 20 steps? I seem to recall towns to spread out over much greater
distances? Maybe I'm mistaken.
>
>I hope someone will be able to understand what I wrote above :-)
I _think_ I did. But then again, I may be wrong :-)
Jan Willem from Odijk, Netherlands
e-mail in From-field is wrong, real e-mail is:
jw.van.dormolen @ hccnet.nl (without the spaces)
--
And then there's this:
Why should we do anything for Posterity? What's he ever done for us?
Marcin Grzegorczyk
> On Wed, 12 Feb 2003 17:55:14 +0100, Marcin Grzegorczyk
> <mgrz...@itma.pwr.wroc.pl> wrote:
>> # 'active' growth_rate
>> stations normal funded[1] funded[2]
>> ---------- -------- --------- ---------
>> 0 160 [3] 60 60
>> 1 210 60 60
>> 2 150 60 60
>> 3 110 60 50
>> 4 80 60 40
>> 5 or more 11 [4] 60 30
>
> The growth_rate at 5 stations does indeed seem a bit low. But are you
> _sure_ it is a bug?
Yes. It looks like Chris Sawyer meant to limit the influence to 4
stations (so the last row wouldn't be there). But he apparently got
confused by the fact that the rate table (if you fancy looking into my
IDA database, I named it 'baTownExpansionRates') had to be indexed from
1 up (0 is a special case as seen above), and made a simple off-by-one
error. So if there are 5 or more stations, the index is 5, and the
first value in the next table is taken (it happens to be 11, at least in
DOS versions).
This bug could be fixed in two ways: change the upper limit to 4 (which
seems to have been Chris's intent), or use a reasonable value if
index=5. After some hesitation, I chose the latter, ultimately because
of the Law of Fives. ;-)
Apart from that, I thought it's kind of silly that while you funded new
buildings transport didn't matter at all. So I changed it, too, but not
drastically, as you can see in the rightmost column.
In any case, it'll be hard to see the difference if you don't increase
the town growth limit, because the transport zone is rather small and
it's sort of silly to stuff 5 separate stations in it. (Although that
won't stop the AI from doing it, if they feel like it :-) ).
> Combined with...
>
>> # town buildings radius of transport zone
>> ---------------- ------------------------
>> 0..3 2
>> 4..7 4
>> 8..11 5
>> 12..15 6
>> 16..19 7
>> 20..35 8
>> 36..71 9
>> 72 or more 0
>
> ...I get the impression that Chris Sawyer deliberately put a limit to
> how big he wanted towns to grow.
Yes, that's obvious. If the radius is zero, the number of 'active'
stations is always zero, so growth becomes slow, possibly even too slow
to compensate for the random vanishing of buildings (I haven't made such
calculations, yet), which would put the town in a sort of equilibrium.
Since this limit is so obviously deliberate, the transport zone radius
calculation is not changed by generalfixes, only by towngrowthlimit.
> Of course, what CS wants is irrelevant to us industrious patch
> afficionados, so welcome to the new switches, but I wouldn't be so
> sure to call them bugfixes, rather than new features.
Well, a proliferation of switches is not a Good Thing, either :-)
Perhaps 'generalfixes' should accept a bit-coded value to selectively
disable some of the more controversial features.
By the way, towns not building on waterbanks is a bug, too, because the
town expansion code makes special provisions for waterbanks in a few
places, and then calls the appropriate construction function with the
'can't build on water' bit set (waterbanks belong to the 'water' class).
>>The function called if a town is in 'expanding' state starts by
>>performing a sort of silly-walk to find a piece of road in the vicinity
>>of town's centre. If no road is found, an attempt is made to create it.
>>If a road piece is found, the function randomly 'walks' the roads trying
>>to find a place to create a new house. Normally, this 'walk' is limited
>>to 20 steps (a tunnel counts as one step), which limits the maximum
>>possible extents of a town. TTDPatch's 'towngrowthlimit' may be used to
>>set this limit to any other value, up to 128.
>
> Only 20 steps? I seem to recall towns to spread out over much greater
> distances? Maybe I'm mistaken.
A simple (if a bit tedious) experiment with creating a mesh of roads (3
tiles apart from each other) on a flat land in the scenario editor, then
putting a town in the middle and expanding it until your finger aches
shows this limit quite clearly.
If you have a savegame or scenario where you think a town has expanded
over a greater distance (without 'towngrowthlimit', of course), feel
free to point me to it or send it to me.
Keep in mind that a tunnel counts as one step, so if you drill a road
tunnel across a half of the map and put a town at one end, houses will
start to appear at the other, too (as long as there's no other, nearer
town there).
--
Marcin Grzegorczyk
Jan Willem
<mgrz...@itma.pwr.wroc.pl> wrote:
>Jan Willem wrote:
>> The growth_rate at 5 stations does indeed seem a bit low. But are you
>> _sure_ it is a bug?
>
>Yes. It looks like Chris Sawyer meant to limit the influence to 4
>stations (so the last row wouldn't be there).
Interesting, and convincing.
>
>This bug could be fixed in two ways: change the upper limit to 4 (which
>seems to have been Chris's intent), or use a reasonable value if
>index=5. After some hesitation, I chose the latter, ultimately because
>of the Law of Fives. ;-)
How about a bugfix in generalfixes (or someplace else) that sets the
upper limit to 4, like intended; but with the extra option
towngrowthlimit for people who want to override it.
Or better still, have the appropriate switch accept 'off' to not
change the game, or a number, in which case '4' (default) would yield
the original intent.
>Perhaps 'generalfixes' should accept a bit-coded value to selectively
>disable some of the more controversial features.
Personally I think that 'generalfixes' should contain only obvious
bugs. Anything that can give raise to discussion should be in a
switch. Just my opinion.
>By the way, towns not building on waterbanks is a bug, too, because the
>town expansion code makes special provisions for waterbanks in a few
>places, and then calls the appropriate construction function with the
>'can't build on water' bit set (waterbanks belong to the 'water' class).
It would be great if people could switch waterbank building on and off
separately (I mean independant of the other things mentioned above and
below).
>>>The function called if a town is in 'expanding' state starts by
>>>performing a sort of silly-walk to find a piece of road in the vicinity
>>>of town's centre. If no road is found, an attempt is made to create it.
>>>If a road piece is found, the function randomly 'walks' the roads trying
>>>to find a place to create a new house. Normally, this 'walk' is limited
>>>to 20 steps (a tunnel counts as one step), which limits the maximum
>>>possible extents of a town. TTDPatch's 'towngrowthlimit' may be used to
>>>set this limit to any other value, up to 128.
>>
>> Only 20 steps? I seem to recall towns to spread out over much greater
>> distances? Maybe I'm mistaken.
>
>If you have a savegame or scenario where you think a town has expanded
>over a greater distance (without 'towngrowthlimit', of course), feel
>free to point me to it or send it to me.
>Keep in mind that a tunnel counts as one step, so if you drill a road
>tunnel across a half of the map and put a town at one end, houses will
>start to appear at the other, too (as long as there's no other, nearer
>town there).
That's probably it. I'll look a little closer. Is it just tunnels or
bridges too? If not, I think I have an example of a game that's
counted past 20 (sent to you by separate mail)
Jan Willem from Odijk, Netherlands
e-mail in From-field is wrong, real e-mail is:
jw.van.dormolen @ hccnet.nl (without the spaces)
--
And then there's this:
Do not adjust your mind, there is a fault in reality.
Chris
wrote:
>It would be great if people could switch waterbank building on and off
>separately (I mean independant of the other things mentioned above and
>below).
No, waterbank building is definitely a bug - in the original TT the
buildings would appear on the waterbank. Marcin has said that most of
the code to make them do it this time is there too, but a bug means
that it won't let them....
Chris.
Marcin Grzegorczyk
> On Thu, 13 Feb 2003 17:59:18 +0100, Marcin Grzegorczyk
> <mgrz...@itma.pwr.wroc.pl> wrote:
>>This bug could be fixed in two ways: change the upper limit to 4 (which
>>seems to have been Chris's intent), or use a reasonable value if
>>index=5. After some hesitation, I chose the latter, ultimately because
>>of the Law of Fives. ;-)
>
> How about a bugfix in generalfixes (or someplace else) that sets the
> upper limit to 4, like intended; but with the extra option
> towngrowthlimit for people who want to override it.
Well, the way this bug worked it seemed pretty irrelevant to me which
way I fixed it. If you prefer it the other way, this can be done by
hex-editing the .exe. Just search for
80 FD 05 76 02 B5 05
and replace both 05s with 04s.
>>Perhaps 'generalfixes' should accept a bit-coded value to selectively
>>disable some of the more controversial features.
>
> Personally I think that 'generalfixes' should contain only obvious
> bugs. Anything that can give raise to discussion should be in a
> switch. Just my opinion.
And what if there's more than one way to fix a bug, like here? :-)
Well, I'm not very fond of the idea of having a separate switch for
every little feature... we'll run out of switches soon.
Still, I'd like to hear Josef's opinion on that matter.
>>By the way, towns not building on waterbanks is a bug, too, because the
>>town expansion code makes special provisions for waterbanks in a few
>>places, and then calls the appropriate construction function with the
>>'can't build on water' bit set (waterbanks belong to the 'water' class).
>
> It would be great if people could switch waterbank building on and off
> separately (I mean independant of the other things mentioned above and
> below).
That's another reason to have 'generalfixes' bitcoded.
>>[how far towns can expand]
>
> That's probably it. I'll look a little closer. Is it just tunnels or
> bridges too?
(repeating things I said in a mail, for public benefit)
AFAICT only tunnels count as one step, bridges are treated as normal
roads here.
> If not, I think I have an example of a game that's
> counted past 20 (sent to you by separate mail)
Note that it's a limit of the road walk, not how far houses can be built
-- that may be a few squares away from the final location. Besides, I'm
not completely sure that one step cannot 'walk' over two tiles in some
rare situations. That 'walk and build' function is complicated :-)
--
Marcin Grzegorczyk
Josef Drexler
> On Thu, 13 Feb 2003 17:59:18 +0100, Marcin Grzegorczyk
> >disable some of the more controversial features.
>
> Personally I think that 'generalfixes' should contain only obvious
> bugs. Anything that can give raise to discussion should be in a
> switch. Just my opinion.
That was my original intention too. Changes that affect the gameplay
shouldn't be in generalfixes.
--
Josef Drexler | http://publish.uwo.ca/~jdrexler/
---------------------------------+---------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Walk with a light step. | Don't remove the "nospam" part.
Josef Drexler
> Jan Willem wrote:
> > Personally I think that 'generalfixes' should contain only obvious
> > bugs. Anything that can give raise to discussion should be in a
> > switch. Just my opinion.
>
> And what if there's more than one way to fix a bug, like here? :-)
>
> Well, I'm not very fond of the idea of having a separate switch for
> every little feature... we'll run out of switches soon.
We'll just run out of command line switches... there's no real limit on
the switches in the .cfg file. I think at some point we'll just have to
stop defining command line equivalents.
> Still, I'd like to hear Josef's opinion on that matter.
Well, generalfixes shouldn't contain anything but bugfixes, and it would
be good to have a switch for every feature, just the way it is now.
Marcin Grzegorczyk
> Marcin Grzegorczyk wrote on Fri, 14 Feb 2003 14:42:32 +0100:
>>Jan Willem wrote:
>>>Personally I think that 'generalfixes' should contain only obvious
>>>bugs. Anything that can give raise to discussion should be in a
>>>switch. Just my opinion.
>>
>>And what if there's more than one way to fix a bug, like here? :-)
>>
>>Well, I'm not very fond of the idea of having a separate switch for
>>every little feature... we'll run out of switches soon.
>
> We'll just run out of command line switches... there's no real limit on
> the switches in the .cfg file.
Yes, that's what I meant, of course.
>>Still, I'd like to hear Josef's opinion on that matter.
>
> Well, generalfixes shouldn't contain anything but bugfixes, and it would
> be good to have a switch for every feature, just the way it is now.
(also quoted from another message:)
> Changes that affect the gameplay shouldn't be in generalfixes.
Hmph. Some bugfixes definitely affect the gameplay. Take the oilfield
cargo acceptance fix, for example.
On one hand, I do agree with this point of view; on the other, there
*is* a problem of things that can be fixed in various ways, or of
bugfixes that some people may not like (e.g. towns building on
waterbanks). I woudn't add a new switch for each little modification
(like whether towns should recognize up to 4 or 5 stations, or whether
the growth rate for a funded town should be flat or not), but I would
like to give people the ability to tweak such things.
As a compromise, I propose a new switch: 'miscmods', which would take a
bitcoded value to turn on/off, selectively, some little modifications
that are now in 'generalfixes' (more may join in the future) and are
sort of idiosyncratic to your/my taste. Currently, I propose that the
following would go there:
* modified behaviour of planes' go-to-hangar when taking off
* modified house and bridge availability years
(for modders; warn in the manual that leaving it off will crash
TTD if year<1930 unless specifically modded)
* recording of years after 2070 in L3 (if eternalgame is off)
* towns building on waterbanks
* whether to use the original town growth rate calculation (with the
stations influence limit fixed to be 4 instead of 5) or the new,
improved one in which the stations influence limit is 5
What do you think?
--
Marcin Grzegorczyk
Jan Willem
<mgrz...@itma.pwr.wroc.pl> wrote:
>Hmph. Some bugfixes definitely affect the gameplay. Take the oilfield
>cargo acceptance fix, for example.
It'll be hard to find a bug that _doesn't_ affect gameplay, methinks.
However...
>On one hand, I do agree with this point of view; on the other, there
>*is* a problem of things that can be fixed in various ways, or of
>bugfixes that some people may not like (e.g. towns building on
>waterbanks). I woudn't add a new switch for each little modification
>(like whether towns should recognize up to 4 or 5 stations, or whether
>the growth rate for a funded town should be flat or not), but I would
>like to give people the ability to tweak such things.
That's sensible thinking.
>As a compromise, I propose a new switch: 'miscmods', which would take a
>bitcoded value to turn on/off, selectively, some little modifications
>that are now in 'generalfixes' (more may join in the future) and are
>sort of idiosyncratic to your/my taste.
Good idea.
>Currently, I propose that the following would go there:
>
>* modified behaviour of planes' go-to-hangar when taking off
I'm not sure what this involves, so I cannot opinion on it.
>* modified house and bridge availability years
Definitely
>* recording of years after 2070 in L3 (if eternalgame is off)
I don't understand?
>* towns building on waterbanks
Good
>* whether to use the original town growth rate calculation (with the
> stations influence limit fixed to be 4 instead of 5) or the new,
> improved one in which the stations influence limit is 5
Very good
>What do you think?
A sound idea well implemented.
Jan Willem from Odijk, Netherlands
e-mail in From-field is wrong, real e-mail is:
jw.van.dormolen @ hccnet.nl (without the spaces)
--
And then there's this:
I wouldn't be paranoid if people didn't pick on me.
Josef Drexler
> Josef Drexler wrote:
>>
>> Well, generalfixes shouldn't contain anything but bugfixes, and it would
>> be good to have a switch for every feature, just the way it is now.
>
> (also quoted from another message:)
>
>> Changes that affect the gameplay shouldn't be in generalfixes.
>
> Hmph. Some bugfixes definitely affect the gameplay. Take the oilfield
> cargo acceptance fix, for example.
I guess I didn't express myself clearly.
What I really meant was, "generalfixes" should contain the things that are
obviously bugs in the game, and it's also obvious what the intended correct
behaviour is.
If there are two ways to fix it, it shouldn't be in generalfixes. This
applies to the growth of small towns for example, because it's not clear
that the game wasn't designed this way.
> On one hand, I do agree with this point of view; on the other, there
> *is* a problem of things that can be fixed in various ways, or of
> bugfixes that some people may not like (e.g. towns building on
> waterbanks). I woudn't add a new switch for each little modification
> (like whether towns should recognize up to 4 or 5 stations, or whether
> the growth rate for a funded town should be flat or not), but I would
> like to give people the ability to tweak such things.
Yes, well I would just introduce a new switch :)
> As a compromise, I propose a new switch: 'miscmods', which would take a
> bitcoded value to turn on/off, selectively, some little modifications
> that are now in 'generalfixes' (more may join in the future) and are
> sort of idiosyncratic to your/my taste. Currently, I propose that the
> following would go there:
It sounds to me like this would be overkill, but I wouldn't say no if you
did this.
> * modified behaviour of planes' go-to-hangar when taking off
I'm not sure what you mean by this?
> * modified house and bridge availability years
> (for modders; warn in the manual that leaving it off will crash
> TTD if year<1930 unless specifically modded)
Actually, I think at least the houses can safely go in generalfixes because
the game crashes. About the bridges, can TTDAlter can change these years
now? Hmm, either way this shouldn't be in generalfixes, I agree.
> * recording of years after 2070 in L3 (if eternalgame is off)
This is really a minor issue, but if you want to make it selectable, go for
it.
> * towns building on waterbanks
And this can safely go in generalfixes too, because it's also clearly a
bug as you say. I can't come up with a reason why you wouldn't want to
enable this, unless you want to stop a town's growth.
> * whether to use the original town growth rate calculation (with the
> stations influence limit fixed to be 4 instead of 5) or the new,
> improved one in which the stations influence limit is 5
That should be a seperate switch.
> What do you think?
Personally, I wouldn't bother, and just put all of them in 'miscmods'
without a bitmask selection. But I wouldn't mind either :)
--
Josef Drexler | http://publish.uwo.ca/~jdrexler/
---------------------------------+----------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Play Hockey, not Baseball. | Don't remove the "nospam" part.
Marcin Grzegorczyk
> On Mon, 17 Feb 2003 15:30:40 +0100, Marcin Grzegorczyk
> <mgrz...@itma.pwr.wroc.pl> wrote:
>>As a compromise, I propose a new switch: 'miscmods', which would take a
>>bitcoded value to turn on/off, selectively, some little modifications
>>that are now in 'generalfixes' (more may join in the future) and are
>>sort of idiosyncratic to your/my taste.
>
> Good idea.
OK, so now let's collect things that would go there:
>>* modified house and bridge availability years
>
> Definitely
>
>>* recording of years after 2070 in L3 (if eternalgame is off)
>
> I don't understand?
Currently, even if you set eternalgame to OFF but generalfixes is ON (to
fix the bug with last-serviced dates), TTDPatch records the number of
days it had to 'push the clock back' to keep on 2070. I can imagine
that some people may not like it.
OTOH, it's easy to clear this value with SV1Codec and a hex editor :-)
>>* towns building on waterbanks
>
> Good
>
>>* whether to use the original town growth rate calculation (with the
>> stations influence limit fixed to be 4 instead of 5) or the new,
>> improved one in which the stations influence limit is 5
>
> Very good
OK, then both will be there, too.
--
Marcin Grzegorczyk
Marcin Grzegorczyk
> What I really meant was, "generalfixes" should contain the things that are
> obviously bugs in the game, and it's also obvious what the intended correct
> behaviour is.
>
> If there are two ways to fix it, it shouldn't be in generalfixes. This
> applies to the growth of small towns for example, because it's not clear
> that the game wasn't designed this way.
OK. I take it so the 5-station fix should be to limit the number to 4
by default.
> Marcin Grzegorczyk wrote:
>>As a compromise, I propose a new switch: 'miscmods', which would take a
>>bitcoded value to turn on/off, selectively, some little modifications
>>that are now in 'generalfixes' (more may join in the future) and are
>>sort of idiosyncratic to your/my taste. Currently, I propose that the
>>following would go there:
>
> It sounds to me like this would be overkill, but I wouldn't say no if you
> did this.
I'd say 3 or 4 separate switches would be a bigger overkill ;-)
>>* modified behaviour of planes' go-to-hangar when taking off
>
> I'm not sure what you mean by this?
If 'generalfixes' is on and a plane needs to go to hangar while it's
taking off (whether because of the maintenance period or because you
clicked the button), it will go to its current target airport's hangar.
Normally, it would take off and land back.
Seems that everybody takes this for granted (even though this is not an
obvious bug), so I think I'll leave it in generalfixes for now.
>>* modified house and bridge availability years
>> (for modders; warn in the manual that leaving it off will crash
>> TTD if year<1930 unless specifically modded)
>
> Actually, I think at least the houses can safely go in generalfixes because
> the game crashes.
The same is true for bridges, when a town needs one.
> About the bridges, can TTDAlter can change these years
> now? Hmm, either way this shouldn't be in generalfixes, I agree.
I think I'll make it possible to switch it *off* via miscmods. That'll
solve the problem of people who fail to upgrade ttdpatch.cfg when a new
version comes...
>>* towns building on waterbanks
>
> And this can safely go in generalfixes too, because it's also clearly a
> bug as you say. I can't come up with a reason why you wouldn't want to
> enable this, unless you want to stop a town's growth.
Neither do I, but Jan wants it, and it's easy to do :-)
>>* whether to use the original town growth rate calculation (with the
>> stations influence limit fixed to be 4 instead of 5) or the new,
>> improved one in which the stations influence limit is 5
>
> That should be a seperate switch.
OK, that's a good point. Hmm, perhaps I'll just integrate it into the
town growth rate calculation scheme selection switches(*) when they're
ready, i.e. there'll be several schemes to select from, as customizable
as I can make them.
(*) 6 levels of attributes. I wonder how would that look like as a
compound word in German :-)
> Personally, I wouldn't bother, and just put all of them in 'miscmods'
> without a bitmask selection. But I wouldn't mind either :)
OK, I'm putting it as a high-priority feature in my TODO list (at least
it can be done fairly quickly :-) ).
--
Marcin Grzegorczyk
Michael Blunck
> town growth rate calculation scheme selection switches(*)
> (*) 6 levels of attributes. I wonder how would that look like
> as a compound word in German :-)
Mmh, let´s try ...
Stadtwachstumsratenberechnungsschemaauswahlschalter.
Indeed, seems to be a good start for the construction of a rather long word ...
:o)
Michael
Josef Drexler
> Marcin Grzegorczyk wrote:
>
>> town growth rate calculation scheme selection switches(*)
>
>> (*) 6 levels of attributes. I wonder how would that look like
>> as a compound word in German :-)
>
> Mmh, let´s try ...
>
> Stadtwachstumsratenberechnungsschemaauswahlschalter.
You'll notice that it's an exact word for word translation, just leaving
out the spaces.
I think when German was invented, the typewriters didn't have the space bar
yet, so German has to do without... :)
Or perhaps it was considered to be a waste of paper to leave so many empty
spaces when you can instead fill them with beautiful letters.
--
Josef Drexler | http://publish.uwo.ca/~jdrexler/
---------------------------------+----------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Walk with a light step. | Don't remove the "nospam" part.
Jan Willem
<nospa...@joesbox.cjb.net> wrote:
>> Stadtwachstumsratenberechnungsschemaauswahlschalter.
>
>I think when German was invented, the typewriters didn't have the space bar
>yet, so German has to do without... :)
>
>Or perhaps it was considered to be a waste of paper to leave so many empty
>spaces when you can instead fill them with beautiful letters.
That would have been a consideration for the _Dutch_, but maybe not
for the Germans. (us being a trading people and all that)
Notice that German uses a lot of verbs on top of each other (gethiset
gethatet gewesen geblieben etc) whereas Dutch leaves out all these but
the most meaningful one.
Jan Willem from Odijk, Netherlands
e-mail in From-field is wrong, real e-mail is:
jw.van.dormolen @ hccnet.nl (without the spaces)
--
And then there's this:
The secret of being a bore is to tell everybody.
This signature was made by SigChanger.
You can find SigChanger at: http://www.phranc.nl/
Marcin Grzegorczyk
> Michael Blunck wrote:
>>Marcin Grzegorczyk wrote:
>>>town growth rate calculation scheme selection switches(*)
>>
>
> You'll notice that it's an exact word for word translation, just leaving
> out the spaces.
>
> I think when German was invented, the typewriters didn't have the space bar
> yet, so German has to do without... :)
>
> Or perhaps it was considered to be a waste of paper to leave so many empty
> spaces when you can instead fill them with beautiful letters.
Or perhaps German was invented by people who liked to bend other
people's minds :-)
OTOH, compound words sometimes (definitely not always) help solve the
'large car factory problem'...
--
Marcin Grzegorczyk
Marcin Grzegorczyk
>>
>>I think when German was invented, the typewriters didn't have the space bar
>>yet, so German has to do without... :)
>>
>>Or perhaps it was considered to be a waste of paper to leave so many empty
>>spaces when you can instead fill them with beautiful letters.
>
> That would have been a consideration for the _Dutch_, but maybe not
> for the Germans. (us being a trading people and all that)
> Notice that German uses a lot of verbs on top of each other (gethiset
> gethatet gewesen geblieben etc)
English does the same ('would have been done'), it just uses shorter
words...
> whereas Dutch leaves out all these but
> the most meaningful one.
So how do you say "it would have been done" in Dutch?
--
Marcin Grzegorczyk
Jan Willem
<mgrz...@itma.pwr.wroc.pl> wrote:
>Jan Willem wrote:
>> whereas Dutch leaves out all these but
>> the most meaningful one.
>
>So how do you say "it would have been done" in Dutch?
Well, perhaps not all but the most meaningful one ;-)
"het zou gedaan zijn" (litt. 'it would done be')
Jan Willem from Odijk, Netherlands
e-mail in From-field is wrong, real e-mail is:
jw.van.dormolen @ hccnet.nl (without the spaces)
--
And then there's this:
The very powerful and the very stupid have one thing in common: Instead
of altering their views to fit the facts, they alter the facts to fit
their views... which can be very uncomfortable if you happen to be one of
the facts that needs altering.