Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Several problems preventing towns from growing #1700

Closed
DorpsGek opened this issue Jan 25, 2008 · 5 comments
Closed

Several problems preventing towns from growing #1700

DorpsGek opened this issue Jan 25, 2008 · 5 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

divide opened the ticket and wrote:

I hereby present you with the ultimate local politics nightmare: a town with so much disagreement as to the expansion policy, that it wouldn't ever grow.

Seriously, though: in the attached picture you see a town which could never (or hardly ever) grow with better roads. Let me walk you through all possible expansion directions and explain why they can't be taken.

A. (Chance 1:3 * 1:4 = 1:12.) The only chance a road would be built here is if we get to GrowTownInTile labeled 0 and then choose DIAGDIR_SE on line 1009 of town_cmd.cpp. Alas, before we get there, we check whether IsRoadAllowedHere(0, DIAGDIR_NE) -- which always fails (because of the slope).

B. (Chance 1:3 * 1:4 = 1:12.) This one is tricky. When we first get there, we check whether IsRoadAllowedHere(B, DIAGDIR_NE). Surely enough, it is; then we check if we are perhaps randomizing the target_dir. If we aren't, we're checking if IsRoadAllowedHere(1, DIAGDIR_NE) -- which fails (because it's a railway station). If we are randomizing (chance 1:4), we have 1:3 chance (that's 1:12 total, or a whopping 1:144 including the chance to get to B). so it's we pick either DIAGDIR_SE or DIAGDIR_NW. Let's suppose we have chosen the former. What we do now is check whether IsRoadAllowedHere(2, DIAGDIR_SE); but because of better roads, this fails: there is a tile with ROADBIT_SE in radius 2 already (that's tile 3). Same goes if we have chosen DIAGDIR_NW when randomizing target_dir earlier (but it wouldn't be much use for town expansion anyway).

C. (Chance 1:3 * 1:4 = 1:12.) IsRoadAllowedHere(C, DIAGDIR_SW) always fails because of the ROADBIT_SW on tile 4.

D. (Chance 1:3.) We can't build a road here without sloping or terraforming. So we have 1:8 chance to even consider terraforming; but that won't do, because towns care greatly of the environment and wouldn't do such a thing as dirtying a lake. But luckily! we can also consider making foundations for the road: that's 1:3 chance (for a total of 1:24, or 1:72 including the chance to get to D). But even that won't do: if we would even hit this path in any time in future, further expansion would be made impossible by the roadbit on 4.

Reasumming: only one in 1:72 random walks (and even that is assuming the PRNG is well-behaved, which isn't necessarily true) cause any construction at all -- and even that is in vain. Please also note that 1:3 of random walks immediately hit spurious roadbit on 4. The total effect is that the town tries to grow every tick -- and fails with every try.

Proposed solutions:
- removing leading-to-nowhere bits (such as the one in 4) when encountering them on walks;
- switching the order of operations, so that any target_dir randomization is done before checking the road for feasibility;
- adding a random chance that a town disregards it's road plan (BETTER_ROADS).

Attachments

Reported version: 0.5.3
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/1700
@DorpsGek
Copy link
Member Author

divide wrote:

Um... I don't mean to impose, but why feature request? I consider it a bug -- and a serious one at it.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1700#comment3361

@DorpsGek
Copy link
Member Author

Belugas wrote:

You do, i don't.

There is a difference between a bug (something that is supposed to work in this or that way) and the impression that it is a bug because it does not work the way you want it to be.
Well, i may be wrong, but as far as I can see, towns do grow. So...

Furthermore, You said it is in 0.5.3.
We are dealing with betas with 0.6
Maybe you should verify if the described behaviour still happens in pre 0.6


This comment was imported from FlySpray: https://bugs.openttd.org/task/1700#comment3362

@DorpsGek
Copy link
Member Author

divide wrote:

Yes, towns do grow most of the time, but there are some corner cases where they don't grow at all -- and I have tried to outline all those cases (although there might be more, and actually I do have one more in mind). In some circumstances (rocky, watery landscape) those corner cases happen very often.

About the version -- this is my honest mistake, I've pasted pre-prepared text detailing the report and hit submit, forgetting to fill all those correct details above -- something I am unable to fix now. In fact, the behaviour I've described is in nightly (tested in r11339, but the code concerned haven't changed much if at all, from what I can see) -- I'm not even sure 0.5.3 even had 'better roads'. Also, please note that my report isn't strictly from observation -- although I did observe towns not growing, I've investigated into the code at why is that and above striven to offer a complete analysis -- based on code and observation (with my town growth observation patch, to be found on the mailing list).

But, please, if you ack me on it (and I mean by that saying that you might consider using my code, so that I will know my work has any chances to become useful), I will put my code where my mouth is and implement a brand new town growth algorithm that has been on my mind for some time recently, which I believe to be not only more robust, but also more efficient. Otherwise, I can offer to try to fix the bugs in the existing framework, although the current algorithm itself has its problems and because it was created with the original TT growth behaviour in mind, it doesn't really lend itself well to being abused to build on slopes, to build better roads, let alone the grid layouts -- honestly, it's a hack (at least that's my impression after spending several hours analyzing it); a hack that does work most of the time, but as the corner cases show, sometimes it fails miserably (using lots and lots of cpu at that).


This comment was imported from FlySpray: https://bugs.openttd.org/task/1700#comment3363

@DorpsGek
Copy link
Member Author

skidd13 wrote:

You describe two issues in your task.

The first is the PRNG, which is not so random as it could be. There is the mersenne twister in the code, but it's abandoned (more or less) cause the sync process is horrible. If someone want's to replace it, feel free to do so.

The second it the growth process itself. I invented the growth algorithms cause I wanted to have additional layouts, but to keep the original town growth algorithm in the code (Some people like it the way it is now). If you want it in another way, feel free to add an additional one. ;)


This comment was imported from FlySpray: https://bugs.openttd.org/task/1700#comment3364

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

Flyspray clean up: more than 5 years old, and not obvious what should be done with this next, so closing. If this offends, discuss with andythenorth in irc. Thanks.


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

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant