Topic: Thoughts on map generation

[ras52]

I've been giving some thought to how map generation might be made a little bit more realistic, hopefully without adding too much complexity.  I don't think much has changed in these bits of code recently, but I'm using yesterday's nightly build of Simutrans extended and pak128.Britain-Ex.

More navigable rivers.  If I generate a 1024×1024 map, there are rarely more than a few short sections of navigable rivers and sometimes none.  At 8 tiles per km, a 1024×1024 map is an area roughly the size of Yorkshire.  Unless the map is mostly water, an area this size should really have multiple navigable rivers.  I haven't looked at the map generation code for a long time, but I'm fairly sure rivers effectively have a flow direction because they're generated from one end to the other, which means the direction of flow is known at the time of generation even if it is lost later on. Can we model the flow rate by starting it at 1 unit at the source and incrementing by 1 unit per tile as the river descends, picking up water from the surrounding water table, and summing the flow rates together when two rivers merge?  Then map flow rates to river types via some settings in simuconf.tab.  It's not perfect, but I think it could result in a more realistic number of large rivers.  (A more comprehensive model would look at precipitation between watersheds, and have separate flow and velocity values based on gradient, to distinguish fast flowing mountain streams from slow lowland rivers.  That might not be too hard to implement, but is probably overkill for Simutrans.)

Lakes should have outlets.  It's common to find inland lakes with no outlet in maps generated by Simutrans.  In temperate climates like Britain this is not realistic, and the outlet of a large lake will sometimes be a fairly large river that is quite possibly navigable.  If the surface of the lake is above sea level, then there should be a river out of it, continuing until it gets to a body of water at sea level.  If a flow based system is used for determining the type of river, as described in the previous paragraph, we'd want to take the total flow in, add an amount per unit area of the lake to represent the excess precipitation over evaporation, and use this as the flow at the outlet of the lake.  The amount to be added per unit area could be configurable in the climate settings.  A negative value could be used in arid climates to allow endorheic lakes.  A moderately large positive value should ensure there is a navigable river following out of every sizeable lake, which would add realism and improve game play.

Place cities on rivers.  Historically, most towns have been founded on a river or the coast of a lake or sea, with larger towns normally on navigable water.  Could the city placement code be made to do this?  One strategy would be to look for water without (say) 5 tiles of the city hall, and if there isn't, discard the location with (say) 90% probability.  By not discarding it unconditionally, it means there will be a few towns not on rivers, and if there are not enough suitable locations on rivers, other locations will eventually be selected.  As a further refinement, if the city is to be one of the largest generated, the code could require navigable water (i.e. a navigable river, lake or sea) within 5 tiles.

Bridges on inter-city roads.  At some start times, the inter-city road generation code is very reluctant to place any bridges, and will make extraordinary detours to avoid it.  This is particularly true before 1785, when inter-city roads are bridleways, and I think is caused by the cost ratio of inter-city roads and the preferred bridge.  This could probably be fixed by introducing a cheaper sort of bridge which doesn't allow wheel vehicles, much like the bridleway.  An alternative approach might be to introduce a ford, which can only cross small, unnavigable rivers with a very low speed limit.  But this problem is not restricted to the period before 1785, even though that is one of the worst, and perhaps the penalty for bridges in the code is too high as there is a public interest argument for wanting direct inter-city routes.  Another, perhaps more frivolous solution might be to designate some small proportion of roads as "Roman roads" and give them masonry bridges with no penalty, hopefully resulting in some good, direct routes.

[jamespetts]

Welcome back! Thank you for your thoughts.

In relation to lakes and rivers, I think that the lake algorithm is sub-optimal. I just attempted to generate a 1024x1024 map with 1024 rivers in the "climate settings" dialogue: with lakes disabled, a very large number of navigable rivers were generated. With the same map settings, but with lakes enabled, fewer navigable rivers were generated because the rivers were too early terminated in the lakes, which, as you point out, have no output. Lakes are a relatively new addition (from Standard) and I suspect that their interaction with river generation was not thought through as fully as it might have been. I recommend generating maps with lakes disabled until somebody has the time to write a better lake algorithm. (I am unlikely to be in a position to prioritise map generation for a very long time indeed given the queue of other tasks of higher priority).

The city placement code already has a weighting for being near rivers and the coastline (I am not sure whether it works with lakes). In the climate settings sub-dialogue of the new map dialogue, look for the "cities like water" setting. By default, it is at 60. If you increase this to a higher number, cities will have a stronger preference to be near water of some sort.

As to bridges and fords, there is a discussion here regarding fords: it is planned to implement fords at some point (there are already graphics for them), but this will have to wait until this becomes the highest priority item, which might be a while. I think (but am not sure) that only a relatively minor change is necessary to the code, so this may be able to be done within a few months, depending on other priorities, but this is not certain. Of course, if anyone else were to work on this, it could be implemented rather more quickly.

[ras52]

Thanks for the quick response, and for the welcome back!

Disabling lakes does result in far more navigable rivers, and obviously removes the problem of lakes without outlets.  Thanks. Lakes don't seem a high priority for getting a good simulation of British transportation, so disabling the feature is no great hardship.  And it's obviously perfectly understandable that a open source project like this might have some features that don't yet work perfectly.  However might I suggest disabling lakes by default?  I think it would be good if the default settings for map creation were a fairly a combination of safe features that work together well, as this will often be new players' first experience of the game.  Or, failing that, could the lakes setting beremembered, as other most settings are?  At the moment, you have to disable it afresh every time you restart the program. 

Thanks for drawing my attention to the "Cities like water" setting.  I've played a bit with a bit this morning, and on a map with a normal number of rivers, its effect is not obvious.  Reducing the number of rivers to zero makes the effect obvious, so it is clear working.  I suspect what is happening is that, when the map uses the default number of rivers, almost everywhere on the map is near a river or coast, so the setting has little effect.  I like maps with lots of small rivers, and the default value seems right to me.  But perhaps the "cities like water" setting should be changed to only consider navigable water (whether seas, lakes or rivers)?  Or more complicatedly, but perhaps more realistically, match the city size to the type of water – small villages would prefer any river, lake or sea; larger towns would like prefer a navigable river, lake or sea; while the biggest cities would prefer a large river or sea.

Reading the thread on fords, I can appreciate they' might not be trivial to implement, and a priority.   From the point of view of getting more realistic inter-city roads before 1785, the problem could probably be solved just as easily with a new "bridleway bridge" with a zero axel weight restriction, thus prohibiting carts and coaches, while allowing pack horses, post boys and drovers.  Graphically, it could be a narrower version of the trestle bridge, and it might be given a reduced maximum height and length.  Or simply tweaking the penalty for bridges in the inter-city road layout code could work too.

[jamespetts]

My apologies: I realise that I did not respond to this at the relevant time.

Outlets for lakes would indeed be splendid - it is just a matter of there being a developer somewhere with the ability to do this who thinks that this is a higher priority than anything else that can be done in that amount of time.

As to disabling lakes by default, I should be interested in others' views on that. I can see the merit to that, but if lakes, even with their implicit sink-holes, are very popular, this may need some more careful thought.

In relation to checking the navigability of rivers, the code already does check this by checking the maximum speed. However, I am just now implementing a small change so that it also checks the maximum weight: these must both now be a non-zero value for towns to treat the water as a reason to build in that vicinity.

The zero axle load bridleway bridge might as well be a ford; this would actually require more work to implement than the existing ford, as it would require new graphics.

In any event, thank you again for your feedback on this: it is much appreciated.

[Elemental]

While the lakes themselves are rather nice, the fact that large rivers can end in even the smallest of them is a problem. Another problem is that barges drawn by horse or tractor can move freely on them, leading to swimming horses. So at least for now, I am for disabling lakes by default.

[Freahk]

Another problem is that barges drawn by horse or tractor can move freely on them, leading to swimming horses.

It's a feature, called seahorses, don't remove it!

K, let's be serious.
I don't think this is an issue of map generation generating lakes but moreover a problem of what is considered a lake and what is not and how ships handle it.
Up to today I don't really know what is considered a lake and what is considered an ocean. My guess, which did not proof false yet, is any warter at the lowest level is considered an ocean, whilst any other kind of water is considered a lake.

I had not expected these seahorses to swim in lakes at all, so I didn't try it out until I saw a player on my server not knowing anything about constraints at all simply using them.
I expected this to be a bug but when I was just about to post it, I had noticed that seahorses cannot swim in the ocean, which is water at the lowest level of the map I guess?
Later on, I was about to use a small ship to cros a small part of the ocean and it did not find a route for this reason.

This behavior is kind of odd and to be honest, I would either expect any kind of small ships not being able to enter "normal" water at all, which would break some good points of gameplay, or being able to move along coasts up to a maximum distance.
Thus, we should consider replacing the "Must use: Waterway" constraint with a maximum_coast_distance in each dat.
That would allow us to let seahorses travel exactly along the coast, whilst allowing small non-horse-hauled ships to at least cross some rivers or even small sections of the ocean. Which is, I guess, much better to understand for players.
Also note, it would be nice to get a more preciese message than "can't find route" in case of any constraint violation. It is sometimes really hard to understand it's not working here, because the water level is one level lower than at a lake where it just worked.
It gets even worse for violated axle loads or overall weights and stuff like that.

Technically, I guess, we had to add a distance_to_land attribute to each water tile, at least up to some rather small distance, so it would definitely fit into a uint8.

I also thought about specifying this depening on the currenty already existing depth of the water, but then noticed that some lakes have the minimum water depth for quite a huge area, so it could again be crossed by seahorses.

Feature request incoming? Or is it considered a bad idea anyway?

[Matthew]

I think of seahorses as a graphical bug. In an ideal world, the seahorses would move around the edge of lakes. Just as trains would travel up slopes at 45º instead of each carriage jumping up a flight of stairs, horizontally. But after a while you don't think about it. IMHO this solution is a lot of work for a very minor problem. But 'one man's meat is another person's poison', so perhaps you may see it differently.

[Ranran]

Up to today I don't really know what is considered a lake and what is considered an ocean.

My guess is that there is a slope between the ocean and land, but not the lake.

[Vladki]

My guess is that there is a slope between the ocean and land, but not the lake.

No, definitely not. Lakes and oceans can have both type of shores. I'd like to hear a definitive answer on this topic. So far my wild guess was that any water that touches the edge of map is ocean, but i think that more probable is any water at water level defined when creating the game.

Allowing ships according to max-distance-to-shore would be very nice - allowing coastal traffic, or at least small ships getting from river/canal to nearby seaport to transfer goods. But I would consider this as low priority wishlist item. At the moment, seahorses are fun.

Allowing according to depth would be nice workaround, if considered easier than distance. The shallowest water could then be permissible for horses - they would really wade across the flooded plains, pulling barges... (more fun . Also a minimum depth could be specified, so that harbours for big ships have to be built at deep water (steep shore gradient). But that is even less important than navigation by shore distance

[wlindley]

Can we modify the Info box to show some difference between a lake and ocean, so we know where "Must Use: Waterway" vessels will function, and where not?  In the screenshot, a Norfolk Wherry will operate on the upper (lake) but not the lower (ocean).  Yet both info boxes say "Open water; water; water."  Constant frustration !

[jamespetts]

The sea-horses "feature" has been the subject of some consideration before. I think that the summary of the discussion was that it is reasonable for horses to be able to pull barges around the edge of lakes, but that coding to enforce this specifically would be very time consuming and was not considered a priority, so the current situation was thought the least worst option until such time as a system for ground-hauled boats in particular (but not other small boats that cannot use open seas) to use the edge of lakes could be devised.

[jamespetts]

I have implemented Freddy's lake disabling by default patch, but this does not seem to work as lakes are still enabled by default; I have not had time to investigate this at present. I wonder whether Freddy could look into this?

[ras52]

I think of seahorses as a graphical bug. In an ideal world, the seahorses would move around the edge of lakes.

I don't agree.  I don't think it's historically accurate to allow horses to draw barges on lakes at all.  In reality, you cannot simply take a sufficiently deep river and run a horse-drawn barge along it: you need to do enabling work to make it suitable first, typically by building a towpath and ensuring the river is deep enough at its edges.  This is because, the further out the boat, the less practical it is for a horse to tow it as it tends to drag into the bank where it will ground.  Simutrans doesn't model this.  It would be nice if it did, perhaps as an add-on to the river way similar to electrification on a railway line, but that's not important to this discussion.  In principle you probably could do the same enabling work to the banks of lakes.  Or, in shallow lakes, you could build a submerged towpath in through the lake, as happened in a very small number of rivers where the landowners on either side would not allow a towpath to be built.  But I cannot think of a single instance where either happened to a lake.  Certainly this didn't happen to Lochs Lochy, Oich and Ness in the Caledonian Canal, which is the most obvious example of a British canal incorporating lakes.  Many of the boats using this canal in early times were seaworthy ships, equipped with sails or, later on, powered by steam.  The sailing ships might well be pulled along the canalised sections by horses in a calm, or if the wind was in the wrong direction as only the smallest of sailing dingies can tack on a canal.  And there were certainly steam-powered tug boats on the lochs which could pull barges on that section. Simutrans doesn't allow a vehicle to reconfigure a convoy in transit – for example, by switching between cheap horses for the rivers and expensive steam-powered tugs for the lakes.  This too would be a nice feature, and it would be useful in other situations, e.g. trains changing from an electric locomotive to diesel, as happens currently on the Highland Caledonian Sleeper.  But I doubt this is a priority for anyone.  For historical accuracy and simplicity, I think I'd simply ban horses from lakes.

[jamespetts]

The idea of having a towpath way object for canals to allow horse (and diesel tractor) drawing is an interesting one, although it might take a considerable time before it can be implemented owing to developer time constraints. A question would be whether canals should be built with such a way object by default - if so, that would require a whole new mechanism in the game (including modified .dat files for every canal) to provide for this.

It is an interesting question as to whether there were any significant enabling works necessary in reality to allow horse-drawn barges along rivers. Is anyone aware of any data on this?

As to reconfiguring convoys in transit: this is planned, and work started on this a while ago, albeit was suspended owing to the need to prioritise bug fixing. Hopefully, work will resume on that this year: this is a very major project, however.

[ras52]

The idea of having a towpath way object for canals to allow horse (and diesel tractor) drawing is an interesting one [...]. A question would be whether canals should be built with such a way object by default

I would say not, especially if that makes it harder to implement.  It seems reasonable to allow canals to be built without towpaths, even if that wasn't commonly done.

It is an interesting question as to whether there were any significant enabling works necessary in reality to allow horse-drawn barges along rivers. Is anyone aware of any data on this?

You typically need to build a revetment wall along the bank with the towpath, because you want the river to get deep very quickly on that side so that you can have the horse (or tractor) and boat as close to being in a line as possible.

As to reconfiguring convoys in transit: this is planned, and work started on this a while ago, albeit was suspended owing to the need to prioritise bug fixing. Hopefully, work will resume on that this year: this is a very major project, however.

I'm not surprised you describe this as a very major project.  Have you got as far as working out how this will work?  In the simplest case we want to go from A via B to C, and back again, with a reconfiguration in B both ways.  Say we want to do A to B (and vice versa) by horse, but B to C (and vice versa) by steam.  Do we take any steps to ensure there will be a suitable "engine" (horse, tug or locomotive, etc. as applicable) waiting at B?  For example, do we ever sent engines back from C to B without load?  In more complex circular routes, this is likely to be needed.  And what do we do with waiting convoys?  In reality we'd need somewhere to park vehicles while they wait – possibly a long time – to be reconfigured.  On a railway, this means sidings.

[jamespetts]

There has been a detailed technical discussion about the implementation of a large set of features, including the convoy re-combination feature, here. Work has already started on coding this (mainly data structures and the UI, the latter of which is being worked on by Ves) on a separate branch, although that has not been updated for some time. I am hoping to return to continue this work this year.

[Vladki]

How about just a new permissive way constraint "towpath", that would be automatically present only on canals, but not on rivers. Horses and tractors would require this constraint (like electrification). So if you would want to use a river for towing, you would haveto canalise it first. Is that much different from real world practise?

[Ranran]

No, definitely not. Lakes and oceans can have both type of shores.

This is not correct.


Basically the ocean does not allow to create flat land next to it.
First you need to make a flat land in a remote place. This looks like a loophole in the system.



Lake ports can be created separately from marine ports, but pak128.Britain does not have such a lake port. But pak.nippon has.

[Freahk]

Flat shores are quite rare for oceans, maybe it's even a bug, but sometimes there are little flat islands on the ocean.
For lakes there doesn't seem to be a preference. Some shores are flat whilst others are sloped.

Also, when applied on lakes or oceans, the multi tile terrain alignment tool will create flat shores. One does not need that complicated approach for it.

[Ves]

How about just a new permissive way constraint "towpath", that would be automatically present only on canals, but not on rivers. Horses and tractors would require this constraint (like electrification). So if you would want to use a river for towing, you would haveto canalise it first. Is that much different from real world practise?

I was thinking exactly this!

[freddyhayward]

I have implemented Freddy's lake disabling by default patch, but this does not seem to work as lakes are still enabled by default; I have not had time to investigate this at present. I wonder whether Freddy could look into this?

Having just looked into this, the no_lakes setting needs to be changed in simutrans/config/simuconf.tab file in the simutrans-extended repository and config/simuconf.tab in the simutrans-pak128.britain repository.

[jamespetts]

I have now amended the pakset simuconf.tab for Pak128.Britain-Ex to disable lakes by default.