Belugas wrote:

First, let me bring a little precision: industries will not be in any way controlled other than by the current system. There are many reasons for that. One of those is regarding grfs. You can control everything using callbacks and such. Therefor, it would be a bit illogical to add yet another system on top of the first one. Which is in fact the second one...
But still...
Another reason is that there are 39 industry types available in game (given all climates). So the gui required to handle them would be ... unpleasant to say the least.
Still another reason : once you have loaded industry grfs, you MUST let them decide how many industries are going to be generated. So any eventual manual specification will be discarded. Try to explain that to regular-user-i-do-not-need-to-read...

As for the tows, it can be done. A popup specifying the number you want, on a custom number. No grf specs do mangle with town amount (yet). So the change can be done. I just do not know if it's really needed, since you can build your map the way you want in the scenario editor.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672#comment5636

vc wrote:

I'm not a programmmer (had I be - I'd do it myself a long ago and uploaded the altering code for you), so I got what I could.
...
As I understand, nothing can be done about industries (or doesn't worth the efforts). Yet it's unclear for me how then that initial pre-set "number of industries" works (and it certainly works). Do you mean it's just initial start quantity (I use to set it to "no industries" to prevent littering the map from the very beginning), which doesn't affect the temp of generation during the game? Then, at least, the precision initial control (like pre-set number instead of "low" or "very low") yet makes sense for me (as it is done for starting year, FE). You need some (I mean - player needs), very few, in the beginning, just to help you rise your funds fast, but later I preffer just to fund industries at the best suitable locations, or serve the automatically generated ones, placed at suitable locations and wipe out the rest (otherwise the map becomes littered too much with the industries, as well as the long curved servicing roads, connecting these industries, not saying about ones placed inside future town limits or too close to each other).
So, resuming: the initial pre-set of starting amount for industries is also desired if possible (assuming that it's impossible to control in-game-generated amount).
...
Now, as per towns.
If it can be done, then it's certainly highly desired. See, with current "very low" initial settings the automatically generated amount of towns, in practice, does not allow you to play 2048x2048 maps, given the human mind, simply saying, is not able to navigate in such a waste amount of service-demanding points.
...
As per scenario editor - yes, it can be done using this tool, of course (and I used it not a once). But it takes a lot of time even to clean up the non-desirable towns, comparing to few seconds waisted for altering pre-sets (have it been possible). Then, you cannot withstand your tention to make more alterations, to make it look perfect, and so on, and, finally, you end up with some about-to-look-perfect map (and a lot of waisted time), which later (in game) proves to be boring (too regular and easy to develop), or something-forgotten one (and you abandon the game and come down to map editor again). So, it turns to be a scenario editing business instead of playing the game.
So, resuming for towns:
- Yes, it's in high demand. Besides, in couplre past years, I saw other folks, demanding the same and complaining that for large maps the town quantity is overkill. So, actually, this post is just a "demand-reminder".

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672#comment5638

vc wrote:

...Yet one thing remains uncleared. Is it possible to arrange the town funding in game?
Without that feature the waste part of the game turns to be just a money-stamping business, or, which is even worst, plane-crash-replacement business (another huge problem for big maps, related to large amount of towns, on which I'm going to place separate request-reminder).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672#comment5639

Belugas wrote:

For industries :
There is a certain mathematic involved using tables of data. I will spear you the complexity of it.
But let say that for Very Low, the resulting number is 1 (one) per industry type - roughly.
Then, that number is scaled up by the size of the map. The grf system, by the way, is already in action there. So unless the scaling factor is changed, not much can be done on these numbers. And i'm not going to change that scaling, since there is no real clean way to encode such a change. Therefor, no matter how hard users are crying for it, it will always be NO.
Here is the main array of data:
static const byte _numof_industry_table[NB_DIFFICULTY_LEVEL][NB_NUMOFINDUSTRY] = {
/* difficulty settings for number of industries */
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, //none
{0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}, //very low
{0, 1, 1, 1, 2, 2, 3, 3, 4, 4, 5}, //low
{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10}, //normal
{0, 2, 3, 4, 6, 7, 8, 9, 10, 10, 10}, //high
};

For towns, the automatic generation goes about the same process.
static const byte _num_initial_towns[4] = {5, 11, 23, 46}; // very low, low, normal, high
Here are the numbers per difficulty level. To this number, a random number is added (from 1 to 7) before getting one more time scaled by the size of the map.
So the only way to get what you require is to provide a manual number instead of the computed and scaled one.
And you'll be then able to generate random games with your preferred without having to work on an home made scenario.
By the way, I have no desire to code it myself.

I have to point out that the scaling is based on an initial map of 256*256. All higher values are computed based on that proportion.

There is a patch for town funding in the forums.

After having serious work done my a few guys, including me, it seems users have lost interest on it.
And it's far from been mature enough to be in trunk

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672#comment5640

vc wrote:

Well, you probably cannot accept the simple fact that the waist majority of users are not the programmers, and, therefore, they'll certainly loose interest to the process itself quite soon. End user demands a result, not an explanation (given he cannot help you anyway).
As an end user, I got the only thing clear from your explanation: you're not ready to do it now. Quite fair, although too sad.
Well, I'll place the reminder a year later, when the problem will be matured enough.
But I suggest you not to close this task and leave it undecided, for some amateur genius to pick it and get into, given you already exposed some initial points to start from.
...
BTW, if I got it right, the implementation of exact initial number of towns is possible. I'd say that it will certainly work for me, as well as for others, playing big maps.
Look, the basic mathematics (although I'm too weak even in it) states that to completely serve 20 towns by aircrafts (in terms of logistics integrity, assuming 1 plane per line) you have to involve something around 20x19=380 planes, which is certainly far beyond current OTTD's practical limit (due to plane-crash issue). Now, considering that even on 1024x1024 map the "very low" preset causes computer to generate something around 180 towns, how'd you imagine one to play 2048x2048 maps?..
...
And just in case, out of topic:
- My personal big thanks to Frosch for implementation of "#2671" (yet not tested), - it's very nice of him and should be very helpful for us (players).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672#comment5648

Belugas wrote:

"End user demands a result, not an explanation (given he cannot help you anyway).
As an end user, I got the only thing clear from your explanation: you're not ready to do it now. Quite fair, although too sad."
It's not a matter of being ready or not.
It's a matter of not wanting the feature to be in, since there are reasons why it should not and will not get in. As devs, we are aware of the potential problems that may appear when a new feature is introduced. As end user, you are not. Therefor, no matter how sane you think a feature might be, if you are not aware of the problems that will arise while developing it, you will never accept a no as a final answer. We all know devs can do anything they please. Are you sure? for your information, there are limits to what we can do. And of course, there are limits to what we want to do.
Because, don't forget, we are the ones who will have to live with the consequences of this or that feature in the long run, when you will move away to the newest passion in your leasure time.

I hope you do see our situation and our decisions on a new day, now. I do understand your point. I just hope it's reciproque

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672#comment5670

Belugas closed the ticket.

Reason for closing: Implemented

in r15695

This comment was imported from FlySpray: https://bugs.openttd.org/task/2672