Patch: The Rainfall River Generator
Moderator: OpenTTD Developers
Re: Patch: The Rainfall River Generator
That Rivers.png screenshot looks quite realistic. Nicely done.
With so many rivers though I could envision a game with the following companies:
Bridges Galore Co.
Never burn your bridges Ltd.
Bridge & Rail Co.
Broken & Late Ltd. (if !realistic_acceleration)
Bail Out! Ltd.
Riverboat Co.
NoRail Co.
and Barely Afloat Ltd.
With so many rivers though I could envision a game with the following companies:
Bridges Galore Co.
Never burn your bridges Ltd.
Bridge & Rail Co.
Broken & Late Ltd. (if !realistic_acceleration)
Bail Out! Ltd.
Riverboat Co.
NoRail Co.
and Barely Afloat Ltd.
NewGRF: Oil Wells in Temperate terrain now can Increase production, Better vehicle names, Use-able default aircraft, Oil Rig for Snowland and Desert, Speed for Suspension bridges.
Patches (OpenTTD): Improved smooth_economy [in trunk], More (diesel) smoke [in trunk], Realistic_acceleration finetune.
Keep 'em rollin'!
Patches (OpenTTD): Improved smooth_economy [in trunk], More (diesel) smoke [in trunk], Realistic_acceleration finetune.
Keep 'em rollin'!
Re: Patch: The Rainfall River Generator
dude, the last patch took 5 years, and now you're nagging after two weeks?
Re: Patch: The Rainfall River Generator
Some code cleanup, and a bugfix: As I have said before, I limit the size of connected components to 100000 tiles, to avoid memory-related problems. This essentially partitions oceans. And if one of these partitions was small enough, it could in the previous release enter the "make small oceans land" code, which then resulted in a bunch of cities being located in a quickly flooded area...
- Attachments
-
- rivers_v8.zip
- (193.78 KiB) Downloaded 89 times
Re: Patch: The Rainfall River Generator
This version has the last major feature I wanted to introduce:
City generation based on landscape.
The basic idea is, use the information the river generator collects anyway while it runs for positioning cities in a more real-world-like fashion than the old generator could. For this purpose, I first generate a bunch of scores (e.g. river_size_score, river_branch_score, flat_land_score) for each 16x16 grid section on the map.
Remember: In terms of town generation, the term "city" refers to big town that grows faster, and the term "town" to any other town.
Then, a bunch of so-called TownPlacers run with certain probabilities, and try to choose a tile that fits their particular requirement to a city. A short look into the source code:
First place 1/3 cities and 2/3 towns, then place only towns until all required cities and towns are placed. The total numbers is based on the well-known config-settings, I didn´t touch them.
In each of those two steps, iteratively call one out of the placers with the given probability. E.g. a HugeRiverCityPlacer is intended to place a city somewhere near a huge river. Its special implementation is rather straightforward:
Only consider grid sections that contain a river with at least 30 percent the flow of the biggest river on map, and with at least 40 percent flat tiles. Inside such a section, only consider tiles that are lower than 1/3 the allowed max heightlevel, to avoid funding cities somewhere up in the mountains.
Similar, the RiverBranchCityPlacer founds a city near the point where two or more rivers merge. The corresponding score is the higher the more equal-sized the rivers are, and the more flow they have.
The I introduced a two-step-behaviour where in the first step also 2/3 towns are created to avoid the effect that the cities occupy all the space suitable for them before any town is founded, which can lead to the effect that there are whole regions of map with only cities, but no towns at all.
In the current version, the configuration shown above is hardcoded. Also, you cannot yet disable city generation (if you really want to get rid of it, outcomment the respective call near the end of rivers_rainfall.cpp, and return false to notify the old city generator that it should do the job) In the end, this would probably need another configuration window similar to the one I introduced for the rivers. But this is nothing I can implement right now (for reasons of real-world-time-constraint). Also, before implementing such a window, probably some experience what config options are actually required would be useful.
For example, the above settings are tested on a rather mountainious heightmap with some big valley in the middle (see attached screenshot). If in constrast, the map contains a lot of ocean, then one might want to apply the CoastPlacer with a much higher probability, i.e. the probabilities will certainly be specific to the kind of map being generated to some extent (although of course a Placer that doesn´t find an appropriate place will do nothing after some computation attempts, and leave room for the next Placer).
Have fun.
City generation based on landscape.
The basic idea is, use the information the river generator collects anyway while it runs for positioning cities in a more real-world-like fashion than the old generator could. For this purpose, I first generate a bunch of scores (e.g. river_size_score, river_branch_score, flat_land_score) for each 16x16 grid section on the map.
Remember: In terms of town generation, the term "city" refers to big town that grows faster, and the term "town" to any other town.
Then, a bunch of so-called TownPlacers run with certain probabilities, and try to choose a tile that fits their particular requirement to a city. A short look into the source code:
Code: Select all
HugeRiverCityPlacer huge_river_city_placer;
RiverBranchCityPlacer river_branch_city_placer;
SmallRiverCityPlacer small_river_city_placer;
LakeCityPlacer lake_city_placer;
FlatLandPlacer flat_land_placer;
CoastPlacer coast_placer;
std::vector<TownPlacerWithProbability> city_placers = std::vector<TownPlacerWithProbability>();
city_placers.push_back(TownPlacerWithProbability(&huge_river_city_placer, 300));
city_placers.push_back(TownPlacerWithProbability(&river_branch_city_placer, 200));
city_placers.push_back(TownPlacerWithProbability(&small_river_city_placer, 200));
city_placers.push_back(TownPlacerWithProbability(&lake_city_placer, 50));
city_placers.push_back(TownPlacerWithProbability(&flat_land_placer, 200));
city_placers.push_back(TownPlacerWithProbability(&coast_placer, 50));
this->PlaceTowns(city_scores, cities_generated, number_of_cities, 333, towns_generated,
number_of_cities * 2, city_placers, townnameparts, town_names, do_continue);
DEBUG(misc, 0, "Finished city generation, generated %u cities and %u towns", cities_generated, towns_generated);
SmallRiverTownPlacer small_river_town_placer;
MountainTownPlacer mountain_town_placer;
ValleyTownPlacer valley_town_placer;
std::vector<TownPlacerWithProbability> town_placers = std::vector<TownPlacerWithProbability>();
town_placers.push_back(TownPlacerWithProbability(&small_river_town_placer, 400));
town_placers.push_back(TownPlacerWithProbability(&mountain_town_placer, 150));
town_placers.push_back(TownPlacerWithProbability(&flat_land_placer, 300));
town_placers.push_back(TownPlacerWithProbability(&coast_placer, 50));
town_placers.push_back(TownPlacerWithProbability(&valley_town_placer, 100));
this->PlaceTowns(city_scores, cities_generated, number_of_cities, 0, towns_generated,
number_of_towns, town_placers, townnameparts, town_names, do_continue);
In each of those two steps, iteratively call one out of the placers with the given probability. E.g. a HugeRiverCityPlacer is intended to place a city somewhere near a huge river. Its special implementation is rather straightforward:
Code: Select all
struct HugeRiverCityPlacer : public TownPlacer {
public:
virtual const char* ToString() { return "HugeRiverCityPlacer"; }
virtual bool PlaceInGridSection(CityGridIndex c, CityScore *score)
{
return score->river_size_score > 300
&& (score->flat_score > 400 || RandomRange(3) < 1);
}
virtual bool PlaceAtTile(CityGridIndex c, CityScore *score, TileIndex tile)
{
return TileHeight(tile) < _settings_game.construction.max_heightlevel / 3;
}
};
Similar, the RiverBranchCityPlacer founds a city near the point where two or more rivers merge. The corresponding score is the higher the more equal-sized the rivers are, and the more flow they have.
The I introduced a two-step-behaviour where in the first step also 2/3 towns are created to avoid the effect that the cities occupy all the space suitable for them before any town is founded, which can lead to the effect that there are whole regions of map with only cities, but no towns at all.
In the current version, the configuration shown above is hardcoded. Also, you cannot yet disable city generation (if you really want to get rid of it, outcomment the respective call near the end of rivers_rainfall.cpp, and return false to notify the old city generator that it should do the job) In the end, this would probably need another configuration window similar to the one I introduced for the rivers. But this is nothing I can implement right now (for reasons of real-world-time-constraint). Also, before implementing such a window, probably some experience what config options are actually required would be useful.
For example, the above settings are tested on a rather mountainious heightmap with some big valley in the middle (see attached screenshot). If in constrast, the map contains a lot of ocean, then one might want to apply the CoastPlacer with a much higher probability, i.e. the probabilities will certainly be specific to the kind of map being generated to some extent (although of course a Placer that doesn´t find an appropriate place will do nothing after some computation attempts, and leave room for the next Placer).
Have fun.
Last edited by ic111 on 13 Dec 2014 21:15, edited 1 time in total.
- te_lanus
- Transport Coordinator
- Posts: 326
- Joined: 19 Jul 2012 18:04
- Location: The Elizabeth Arkham Asylum for the Criminally Insane
Re: Patch: The Rainfall River Generator
Looks very interesting, would love to play it (just a shame I can't compile currently)ic111 wrote:This version has the last major feature I wanted to introduce:
City generation based on landscape.
Re: Patch: The Rainfall River Generator
Sorry, the version I released just two hours ago was broken. (forgotten hg qrefresh before the release...).
I replaced it with an updated zip. Now it hopefully works.
I replaced it with an updated zip. Now it hopefully works.
Re: Patch: The Rainfall River Generator
A small, but important bugfix: I forgot to propagate one cost.Failed() return value when I refactored the terraforming code in order to be able to execute it from map generation.
... one of the things you notice once you start playing a game yourself
[the result was that town expansion in the scenario editor pretty fast crashed with an assertion...]
... one of the things you notice once you start playing a game yourself
[the result was that town expansion in the scenario editor pretty fast crashed with an assertion...]
- Attachments
-
- rivers_v11.zip
- (198.3 KiB) Downloaded 106 times
-
- Tycoon
- Posts: 1283
- Joined: 23 Oct 2009 19:35
- Location: Here and there, sometime or another
Re: Patch: The Rainfall River Generator
I tried this, it causes much more aggressive terraforming than I would like. Large areas at similar low height levels are brought down to sea level, which is unaesthetic as well as impractical for later construction.ic111 wrote:Also, now there should actually be a path to realistic rivers and valleys on tgp-generated maps. Choose the settings
- flow consumed per lake volume = 0
- probability for outflow canyon = 1000
- probability for reducing a lake to its necessary tiles = 1000
Besides that, it would be nice to have the improved city placer available as a separate patch, or at least as much of it as practically possible.
--- Licenses: GNU LGPL, version 2 or newer, code and graphics. CC-By-SA, graphics, alternatively. If you're using any, I'd like to hear about it --- Call them "track types" ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
--- Mostly inactive developer for: NuTracks - Central European Train Set --- Running/compiling for: Linux (x86) - Android - Windows (32/64 bit) ---
--- Need a file packer? 7-Zip --- BOINC - use your computing power to benefit science --- Block trackers, not ads --- Unix in dispersible pellets, the formula for the future. ---
Re: Patch: The Rainfall River Generator
Yes, especially for wider rivers, the algorithm tends to lower a section of the river near the point where it flows into the ocean to height zero. This is a consequence of setting up a situation where rivers don´t flow upwards, and flow downwards properly with respect to the terrain.I tried this, it causes much more aggressive terraforming than I would like. Large areas at similar low height levels are brought down to sea level, which is unaesthetic as well as impractical for later construction.
At least, I suspect that this is your problem... Maybe also the wider valleys setting plays a role, it can lower additional terrain near the river to the river height. For further analysis, as always, a screenshot would be quite helpful...
I personally don´t mind if the last tiles of a river flowing into the ocean already descend to height zero, I recognize this just as being realistic. Think of the way rivers like the Rhine, or the Elbe flow into the North Sea.
Of course, if more than just a few tiles of length are lowered to height zero, I would also consider this a bug - and indeed, during development of the patch, I saw such effects on some occasions as result of (in the meantime fixed) bugs in the algorithm.
Of the criteria currently implemented, only four could work without the river generator:Besides that, it would be nice to have the improved city placer available as a separate patch, or at least as much of it as practically possible.
- FlatLandPlacer: Only consider flat terrain
- CoastPlacer: Only consider sections with a high amount of lake or ocean
- MountainTownPlacer: Only consider sections whose min height is at least max_height / 3
- ValleyTownPlacer: Only consider sections with a high difference between min and max height (inside the section), and choose a tile low in that section
The five other criteria only work with the data calculated by the Rainfall River Generator before.
IMHO, the more important TODO with respect to the city placer is adding a GUI to it, currently you have to recompile if you want to change anything regarding the criteria weights. Maybe, in the long term, I can arrange the river generator patch queue in a way that one can take the basic city placer patch and apply it on its own.
But don´t expect too much regarding this in the near future.
Re: Patch: The Rainfall River Generator
Looks great!
Now all we need for "realistic" gameplay with rivers, is a patch that forbids bulldozing them in a way that cuts them in two:
Maybe it could be implemented by having a check before performing a requested bulldozing operation on a water tile, to check if all neighboring water tiles could still find a path to each other without going over land.
Now all we need for "realistic" gameplay with rivers, is a patch that forbids bulldozing them in a way that cuts them in two:
Maybe it could be implemented by having a check before performing a requested bulldozing operation on a water tile, to check if all neighboring water tiles could still find a path to each other without going over land.
Re: Patch: The Rainfall River Generator
... and a short update to current trunk for the river generator.
- Attachments
-
- rivers_v12.zip
- Some small adaptions to current trunk.
- (198.29 KiB) Downloaded 90 times
Re: Patch: The Rainfall River Generator
I opened your manual and found the The patch queue, but there is no information regarding installation of a rather large number of patches to be considered. Are there any priorities? Intall order? Dependencies? I can appreciate the desire for modules for maintenance, but for the end user, that is quite a bundle for what is essentially one patch.
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
-
- Engineer
- Posts: 89
- Joined: 20 Nov 2003 15:20
Re: Patch: The Rainfall River Generator
Hi,
I think it would be a perfect idea to have a binary for this patch to download.
As far as I understand this, it doesn't affect savegame compatibility.
So as this excelent feature will be used mainly for scenario generating, even not-updated binary of current version would mean a great improvement for anyone, who wants to start his game with realistic rivers - he can always start scenario creation with this patch and than switch to up-to-date-nightly/stable version of OTTD for play.
So if you are not skilled enough for this patch to aply or you are somewhere on holiday without possibility to compile, it would be great to have a binary to prepare your land to play.
Many thanx in advance is someone does publish it..
I think it would be a perfect idea to have a binary for this patch to download.
As far as I understand this, it doesn't affect savegame compatibility.
So as this excelent feature will be used mainly for scenario generating, even not-updated binary of current version would mean a great improvement for anyone, who wants to start his game with realistic rivers - he can always start scenario creation with this patch and than switch to up-to-date-nightly/stable version of OTTD for play.
So if you are not skilled enough for this patch to aply or you are somewhere on holiday without possibility to compile, it would be great to have a binary to prepare your land to play.
Many thanx in advance is someone does publish it..
Re: Patch: The Rainfall River Generator
Wallyweb: Search for mercurial queues, mq. Under Linux, you want to do something like, copy the contents of the archive to .hg/patches, and use hg qpush -a. For a detailed explanation, I don´t have the time right now.
Those patches are for organizing the patch into smaller pieces of work.
MarkyParky: A binary would be indeed a good idea, but here the help of other people than me would be needed. Essentially, someone who can compile it under windows and provides a binary would be needed. My own attempts to crosscompile it weren´t successful in the past.
Unfortunately, this patch is *not* savegame-compatible. The reason are the newly introduced configuration options, which (at least as far as I know) forced me to introduce a new savegame version.
If anyone knows a way to configure things without loosing savegame compatibility this would be very good, but I doubt there is such a way. Conceptionally, one would probably need some more relaxed way of dealing with config options, something like "look wether you have such an option, if not, use a provided default value".
Those patches are for organizing the patch into smaller pieces of work.
MarkyParky: A binary would be indeed a good idea, but here the help of other people than me would be needed. Essentially, someone who can compile it under windows and provides a binary would be needed. My own attempts to crosscompile it weren´t successful in the past.
Unfortunately, this patch is *not* savegame-compatible. The reason are the newly introduced configuration options, which (at least as far as I know) forced me to introduce a new savegame version.
If anyone knows a way to configure things without loosing savegame compatibility this would be very good, but I doubt there is such a way. Conceptionally, one would probably need some more relaxed way of dealing with config options, something like "look wether you have such an option, if not, use a provided default value".
Re: Patch: The Rainfall River Generator
It's a standard Mercurial patch queue, by the looks of it. "series" contains the patches to apply (one per line, first line first, last line last.wallyweb wrote:I opened your manual and found the The patch queue, but there is no information regarding installation of a rather large number of patches to be considered.
"status" contains the currently applied patches, which should be 0 bytes, as you have nothing applied.
You can apply the patches manually, if you have a Mercurial clone of OpenTTD, you can just drop the "patches" folder in the ".hg" folder and say "hg qpush -a"
More reading https://mercurial.selenic.com/wiki/MqExtension wiki, or http://hgbook.red-bean.com/read/managin ... ueues.html book chapter
Being a retired OpenTTD developer does not mean I know what I am doing.
Re: Patch: The Rainfall River Generator
First of all, some disclaimers:
- I'll be 70 years old in two weeks. I am not adverse to learning new things. It's easy to keep your brain in good form. You just have to use the damn thing.
- Although I am familiar with Linux (I have a Linux box somewhere in this room), my current environment is Windows7 which came with the rather powerful laptop that I now use.
- I have MinGW installed and can clone a repo in my choice of src or git.
- I compile cirdan's New Map Features and JGR's tracerestrict-cirdan to Windows 32 bit binaries whenever they push a new repo.
- I am really impressed with the concept and potential of ic111's Rainfall River Generator patch(s) and would like to include it in my compile efforts.
My question is, until I get my mind wrapped around Mercurial, can I apply your patches using msys and, if yes, would I have to follow the number order explicitly?
My first attempt would be with OpenTTD trunk. Once I have that working, I would try it with cirdan's fork to see if there are any incompatibilities.
- I'll be 70 years old in two weeks. I am not adverse to learning new things. It's easy to keep your brain in good form. You just have to use the damn thing.
- Although I am familiar with Linux (I have a Linux box somewhere in this room), my current environment is Windows7 which came with the rather powerful laptop that I now use.
- I have MinGW installed and can clone a repo in my choice of src or git.
- I compile cirdan's New Map Features and JGR's tracerestrict-cirdan to Windows 32 bit binaries whenever they push a new repo.
- I am really impressed with the concept and potential of ic111's Rainfall River Generator patch(s) and would like to include it in my compile efforts.
Not to worry. Alberth was kind enough to post links to some reading material to get me started.ic111 wrote:Wallyweb: Search for mercurial queues, mq. Under Linux, you want to do something like, copy the contents of the archive to .hg/patches, and use hg qpush -a. For a detailed explanation, I don´t have the time right now.
I agree with your approach wholeheartedly ... much easier to manage.Those patches are for organizing the patch into smaller pieces of work.
My question is, until I get my mind wrapped around Mercurial, can I apply your patches using msys and, if yes, would I have to follow the number order explicitly?
My first attempt would be with OpenTTD trunk. Once I have that working, I would try it with cirdan's fork to see if there are any incompatibilities.
There is some recent discussion on this subject in cirdan's New Map Features topic.Unfortunately, this patch is *not* savegame-compatible. The reason are the newly introduced configuration options, which (at least as far as I know) forced me to introduce a new savegame version.
If anyone knows a way to configure things without loosing savegame compatibility this would be very good, but I doubt there is such a way. Conceptionally, one would probably need some more relaxed way of dealing with config options, something like "look wether you have such an option, if not, use a provided default value".
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Patch: The Rainfall River Generator
The patches in a mq patch series must be applied in the exact order as stated in the 'series' file. Any other order will likely fail at some point as the patches assume the code as modified by all previous patches - thus applying them to a repo without the preceeding patches will likely result in conflicts.wallyweb wrote: My question is, until I get my mind wrapped around Mercurial, can I apply your patches using msys and, if yes, would I have to follow the number order explicitly?
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Patch: The Rainfall River Generator
planetmaker wrote:The patches in a mq patch series must be applied in the exact order as stated in the 'series' file. Any other order will likely fail at some point as the patches assume the code as modified by all previous patches - thus applying them to a repo without the preceeding patches will likely result in conflicts.wallyweb wrote: My question is, until I get my mind wrapped around Mercurial, can I apply your patches using msys and, if yes, would I have to follow the number order explicitly?
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Re: Patch: The Rainfall River Generator
Yes, this is one thing which has bothered me in the past.ic111 wrote:If anyone knows a way to configure things without loosing savegame compatibility this would be very good, but I doubt there is such a way. Conceptionally, one would probably need some more relaxed way of dealing with config options, something like "look wether you have such an option, if not, use a provided default value".
I have a branch on github which amongst other things allows new config settings to be saved in a separate chunk which is tolerant of unexpected, missing or re-ordered settings. This is not much good for savegame compatibility with trunk, but it's useful for savegame compatibility between different patched versions. It's what I've used for almost all of the added settings in my patchpack.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Who is online
Users browsing this forum: No registered users and 0 guests