Advanced town growth

[Kogut]

It is not exactly suggestion, rather question: is anybody interested in patch with advanced towngroth? Especially: is it chance for trunk inclusion higher than 0?

Done: goods, food may be required in arctic based on town size.

Possible: goods, food, passengers, mail & water cargos required in all climates, requirement may be based on city size, constant flat rate, contant flat rate for snow/desert.

[Voyager One]

Not a bad idea, not at all!

Sometimes, I had cities that grew too much only because I had a good bus service within them, and other times I was angry that cities didn't grow enough even if I transported massive ammounts of goods to them.

Thumbs up!

[frosch]

The problems with such a patch are:
* Either it is not general enough to cover whatever players might want.
* Or it creates a mess of configuration options, which are too much to deal with, while not being extensible at the same time.
* Relying on certain cargotypes creates incompatibilities to other extensions, esp. industry and house grfs.

So my (biased!) opinion is that towngrowth should be controlled via "plugins". (i.e. NewGRFs. )
At the top of http://wiki.openttd.org/Frosch/Town_Control (be careful, lots of technical gibberish) you also find some links to what other people did in the past.

[Kogut]

* Either it is not general enough to cover whatever players might want.
* Or it creates a mess of configuration options, which are too much to deal with, while not being extensible at the same time.

I thought about additional subgroup of settings ("town growth") in "town" group - that shoul allow for all needed settings without readibility problems.

* Relying on certain cargotypes creates incompatibilities to other extensions, esp. industry and house grfs.

Yes, for example FIRS have buggy TE_GOODS flags.
But what is problematic with house grfs?

So my (biased!) opinion is that towngrowth should be controlled via "plugins". (i.e. NewGRFs. )

I think that it will be better to have settings in avanced settings than in newgrf. Why?
- easier to implement than towngroth newgrfs handling
- I think that it is not the best idea to have newgrfs working as part of advanced settings (there are already few towngroth settings)

At the top of http://wiki.openttd.org/Frosch/Town_Control (be careful, lots of technical gibberish) you also find some links to what other people did in the past.

I am doing sth a bit different - using TE flags should allow for good communication with industry newgrfs.

[planetmaker]

So my (biased!) opinion is that towngrowth should be controlled via "plugins". (i.e. NewGRFs. )

I think that it will be better to have settings in avanced settings than in newgrf. Why?
- easier to implement than towngroth newgrfs handling
- I think that it is not the best idea to have newgrfs working as part of advanced settings (there are already few towngroth settings)

At the top of http://wiki.openttd.org/Frosch/Town_Control (be careful, lots of technical gibberish) you also find some links to what other people did in the past.

I am doing sth a bit different - using TE flags should allow for good communication with industry newgrfs.

I'm quite sure that frosch doesn't mean to add any part of the town growth effect to the advanced settings. Given the nature of cargos being a completely newgrf-defined property (generation, transport, acceptance, revenue), it also seems a logical continuation to extend it to the last piece: town effect. You'd select this then via your newgrf settings and not anywhere in the adv. settings.

Ease of implementation is not necessarily the best argument

[Kogut]

Given the nature of cargos being a completely newgrf-defined property (generation, transport, acceptance, revenue), it also seems a logical continuation to extend it to the last piece: town effect. You'd select this then via your newgrf settings and not anywhere in the adv. settings.

And make it possible to select any requirements? With my solution it will be not possible but implementing new grf behaviour is way beyond my possibilites.

Ease of implementation is not necessarily the best argument

But it is sth that is quite important

So that approach is very unlikely to be accepted into trunk?

[planetmaker]

Given the nature of cargos being a completely newgrf-defined property (generation, transport, acceptance, revenue), it also seems a logical continuation to extend it to the last piece: town effect. You'd select this then via your newgrf settings and not anywhere in the adv. settings.

And make it possible to select any requirements? With my solution it will be not possible but implementing new grf behaviour is way beyond my possibilites.

The newgrf approach would easily allow such selection. After all newgrf allow for quite a lot of choices being made, even on different conditions or so (e.g. you could have prior to 1950 have towns require coal, till 2000 require oil and have things you like configurable via newgrf parameters.

So that approach is very unlikely to be accepted into trunk?

Well, when I have to choose between newgrf and hard-coded in the game, newgrf is the approach which offers way more potential and - from my perspective - follows better also the general pattern how things fall into place.

[Torrasque]

So, the best we to do it would be to make a big brainstroming on the forum, then define a NewGRF specification.
Once a common agreement is reached on the specification, then it is worth that someone implement it.

Am I right?

[Kogut]

So, the best we to do it would be to make a big brainstroming on the forum, then define a NewGRF specification.
Once a common agreement is reached on the specification, then it is worth that someone implement it.

Am I right?

someone implement it <- the biggest problem is with finding person with time, knowledge and interested in coding it.

[Alberth]

Brain storming at IRC is probably more efficient, and indeed, a spec is useless without that someone.

[Torrasque]

Brain storming at IRC is probably more efficient, and indeed, a spec is useless without that someone.

Yes indeed. But in my opinion it's better than some spare code written 2 years ago which was never included in the trunk.

[WWTBAM]

Wpould a setting that allowed the user to pick which cargos they want to be required be suitable? Then the user can pick each cargo from all the available cargos.

[Kogut]

Wpould a setting that allowed the user to pick which cargos they want to be required be suitable? Then the user can pick each cargo from all the available cargos.

Unfortunatelly it would be needed to have cargos named by id - what is bad solution.