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

NewGRF tree growth control #6869

Closed
nielsmh opened this issue Jul 28, 2018 · 7 comments
Closed

NewGRF tree growth control #6869

nielsmh opened this issue Jul 28, 2018 · 7 comments
Labels
component: NewGRF This issue is related to NewGRFs enhancement Issue would be a good enhancement; we accept Pull Requests!

Comments

@nielsmh
Copy link
Contributor

nielsmh commented Jul 28, 2018

NewGRF trees suggestion:

  • Based on static tables supplied by NewGRF, no callbacks for every tree
  • Possibly allow tables to be modified during game on e.g. month change
  • Every species of tree is assigned a treetype 0-3
  • Chance of a tree being planted on a tile is a weighted sum based on landscape type of surrounding tiles in a radius
  • Landscape types are grass, water, snow, desert, farmland, forest (industry), building, treetype 0/1/2/3/mixed
  • Every treetype supplies an affinity -127 to +127 (with 0x80==-128 meaning "don't care") to each landscape type (so 4*12=48 byte array)
  • The affinities for all landscape types within radius of the candidate tile are summed, with tiles further away from candidate tile being scaled by a distance factor
  • If the affinity sum is negative, the treetype cannot grow on that tile, otherwise the affinity sum is used in a probability calculation
@nielsmh nielsmh added component: NewGRF This issue is related to NewGRFs enhancement Issue would be a good enhancement; we accept Pull Requests! labels Jul 28, 2018
@nielsmh
Copy link
Contributor Author

nielsmh commented Jul 30, 2018

On seccond thoght, having a "don't care" value for the affinity calculation makes no sense when it's not an average but just a sum. Either the affinity should be average of the tiles (in which case "don't care" means the tile doesn't count in the calculation, as opposed to a zero value which draws the average towards zero), or there shouldn't be any "don't care" value.

Perhaps the treetypes should also have a bitflag set of tree types they can mix with on the same tile. I don't know (yet) how trees present on a tile are actually handled when there's more than one, but gameplay behavior around it seems to be that it's completely random what any second and third tree are.

@planetmaker
Copy link
Contributor

It does make sense to use a "don't care value". But it is needed to use a threshold which is equal or higher than the sum of the "don't care" values.

Just use or interpret it as a (signed) afinity of a tree towards the landscape types. Then calculate the sum over a field (say 3x3). Then a negative afinity will push trees away from borders with a landscape they don't like - and 0 is a nice value for "don't care", too

@nielsmh
Copy link
Contributor Author

nielsmh commented Jul 30, 2018

My own idea for diameter has been 5 or 7 tiles, maybe circular instead of square pattern, with a weighting pattern tuned towards Euclidian distances rather than Manhattan distances.

@planetmaker
Copy link
Contributor

Such calculation has to be run for every tile in the tile loop. I fear that computationally expensive averaging or summation over larger areas will have quite a performance impact... as such I'd start low. Same reason to prefer manhatten over euclidean distance scale - especially as the impact on the distance is minor.
(Yes premature optimization is not good :P )

@nielsmh
Copy link
Contributor Author

nielsmh commented Jul 30, 2018

The summation is only performed when a new tree is planted, which isn't too often. The distance handling may as well be done with a static tile of weights, where inner tiles are multiplied by a larger value. I don't think the performance impact would be significant.

@nielsmh
Copy link
Contributor Author

nielsmh commented Jul 30, 2018

One more random idea: Also allow weights to be given to "tile slopes in $cardinal_direction", to allow certain trees to be more/less prevalent on slopes, or even on only hillsides facing certain directions.

@andythenorth
Copy link
Contributor

Although this would be nice to have, it isn't something we expect to fulfill in the next year, and on that basis I'm closing it. We do this to keep the project manageable, productive and fun. We hope you do understand. Thanks for contributing though! Here you can find more about how we handle feature requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: NewGRF This issue is related to NewGRFs enhancement Issue would be a good enhancement; we accept Pull Requests!
Projects
None yet
Development

No branches or pull requests

3 participants