Topic: Bug: Ship canal not buildable above certain altitudes?

[AP]

In my latest game, the Ship Canal refuses to build above contour -3 (sea level being -8), even though there are large rivers at much higher altitudes. Is this deliberate behaviour? It will happily build on the lower terrain.

This is on flat open countryside with a solvent company.

[Rollmaterial]

The behaviour is intended to simulate canals needing a source of water. Thus the higher the altitude, the smaller the canal can be.

[AP]

In which case,  it doesn't work, and should be scrapped.  It's too crude a method if it doesn't analyse the map. And building a better method of restriction is probably quite hard.

My map has numerous large rivers nearby at higher altitudes,  which ships can already use,  and which I quite reasonably want to join together and build branches and shipyards on. And this prevents me from doing so.

I also have an enormous high altitude inland sea I want to connect to the actual sea.

Lack of water not an issue in either case.

River width is, as has been noted elsewhere, simply derived from rivers joining together, not length or altitude.  So if 4 mountain streams join near the top of a mountain,  you get an epic width river all the way down the mountain.

[jamespetts]

This is indeed intentional as Rollmaterial points out: see this video for details.

It is realistic that larger canals cannot easily be built at higher altitudes because of the difficulty in getting water to those altitudes: larger canals were not in fact built at higher altitudes. This is one of the reasons that Cornwall, a hilly part of the country, had so many very small tub-boat canals. It is necessary to have a mechanism in the game that provides a realistic incentive to build the smaller canals.

It does not fundamentally undermine this basic reason that there are some circumstances in which specific river generation settings combined with the specific permutations of the random number generator occasionally produce large rivers at high altitudes. In any event, it is somewhat doubtful in reality that it would be realistically possible to harness such high altitude rivers as a reliable source of water for a large canal. If there is something that needs remedying, it is the prevalence of large rivers at higher altitudes, not the prohibition of canals at such altitudes, but it is unlikely that spending much time on such a feature will be worthwhile in the short term as having large rivers at higher altitudes occasionally does not of itself seriously unbalance the game and changing this would take a lot of time that could more profitably be deployed on more pressing features.

[AP]

Not sure this is the right answer, this breaks water transportation at present.

The middle third of my map is an enormous inland lake, fed by multiple rivers the size of the Thames. And the excuse is "lack of water"...?!  It'd be like saying you couldn't build the Caledonian Canal, plenty of altitude gain on that, look at the locks at Banavie.

It's an arbitrary restriction. How is it coded, as a %  of map terrain range? Why not link it to the highest tiles of medium river instead?

Worth also being mindful that what is considered "high"  altitude should probably be as defined in the Climate settings at map creation e.g. as Mountains. Which this definitely wasn't. Now we have doubleslopes it's easy to get through quite a lot of contours but that doesn't mean you are actually in the alps.


I think it's the construction costs and maintenance that should encouraguh e different sized canals,  tbh. Land being expensive

[DrSuperGood]

The only reason larger canals did not exist at high altitudes is due to there generally being less running water at high altitudes, not that the altitude itself was limiting. Limiting by altitude results in the problem AP is describing, where there is an enormous high altitude lake due to geography but one cannot build cannals from it.

I would suggest making the maximum canal altitude a configurable map setting so it can be tailored on a per map basis to be realistic to the geography of that map. In the future maybe some water model could be created that limits canals to run from inland lakes or other water sources and their size is restricted by the flow potential of that source.

[jamespetts]

Thank you both for your feedback.

The way in which the maximum canal height is coded is using the max_altitude setting in each canal's .dat file. This defines a number of tiles above sea level beyond which the canal cannot be built.

The most straightforward solution, until there is somebody with the time and experience to build a full water/terrain model as Dr. Supergood suggests, is likely to be to apply a maximum altitude restriction to rivers and lakes, too (so that joining rivers do not create larger rivers if the larger river would be above the maximum altitude for that type and that lakes do not form above a certain altitude). As large rivers and lakes are less common at high altitudes in reality, then, absent a fully detailed water/terrain model, this would seem to be the most sensible way of resolving the anomaly described.

I should note that this is not currently a high priority issue in light of the other features/issues currently in progress.

[AP]

The way in which the maximum canal height is coded is using the max_altitude setting in each canal's .dat file. This defines a number of tiles above sea level beyond which the canal cannot be built.

The most straightforward solution, until there is somebody with the time and experience to build a full water/terrain model as Dr. Supergood suggests, is likely to be to apply a maximum altitude restriction to rivers and lakes, too (so that joining rivers do not create larger rivers if the larger river would be above the maximum altitude for that type and that lakes do not form above a certain altitude). As large rivers and lakes are less common at high altitudes in reality, then, absent a fully detailed water/terrain model, this would seem to be the most sensible way of resolving the anomaly described.

Without knowing how the code works at all - could you not simply make the canal builder check for an adjacent water tile of equal-or-greater width, when building?  That would ensure all canals start from an adequate source of water.

You could augment that with a second check that the water tile should be at equal-or-greater height as well, if you wished (perhaps only doing this prior to the date pumping stations become available*).

This would also give players an incentive not to create 'desert' maps, and avoid restricting the map generator which could have adverse effects.

*1793 for the Kennet & Avon canal, but there may be earlier examples.

If we were being really graphically swish, I suppose we could have canals build "dry" until the water tile is connected, rather than refuse to build at all, but even to me that sounds like a lot of work!

[jamespetts]

Thank you for the suggestion and apologies for the delay in relying: I have recently returned from holiday.

The idea is an interesting one, but a difficulty is that there is no representation of width as such in the code. Instead, there are abstract way constraints of one of two types: either permissive or prohibitive. Permissive constraints permit vehicles that have a matching constraint to travel upon them (ways without a matching constraint cannot be traversed by the vehicle). Prohibitive constraints prohibit all but vehicles with matching constraints from travelling upon them (vehicles without a matching constraint cannot traverse the way).

For waterways, we have quite a large set of constraints. Waterways generally have a single permissive "waterway" constraint, which allows boats that are not capable of travelling on the open ocean to travel on them. Waterways (be they rivers or canals) also have a series of prohibitive constraints:

(1) tub boat canal;
(2) narrowboat canal;
(3) barge canal; and
(4) ship canal.

All of the boats with the "tub boat canal" constraints are also coded with "narrowboat canal", "barge canal" and "ship canal" constraints; all of the boats with "narrowboat canal" are also coded with "barge canal" and "ship canal" constraints, and all of the boats with "barge canal" are also coded with "ship canal" constraints. This establishes in practice a hierarchy of canal/river sizes, so that smaller boats can travel on larger canals/rivers, but not vice versa.

However, this hierarchy is implemented entirely at pakset level and cannot unpicked on the fly (at least, not without some fantastically complex and probably very unreliable code, as the game would have to infer the hierarchy of ways by comparing the constraints of different vehicles). All that the code sees is a series of constraints. It would not be too hard to allow a canal to be built next to a river with an identical matching set of constraints, but the code would not know that "ship canal" ranks higher than "barge canal", and, whilst the boats have multiple constraints, the rivers/canals have only one constraint. Thus, a small canal could not be built next to a large river, which would be arbitrary and less comprehensible to players than the current system.

[AP]

Hi James

I've been doing some more reading on canals recently, and realised the waterway width thing is a complete red herring. You just need to check for any adjacent water tile* when building.

Canals are basically static bodies of water, they don't flow like rivers, and are constructed to hold water well. They lose a negligable amount to evaporation.  Once built and filled (which can take as long as required), their water consumption is only really defined by whether there are any locks. Locks are installed in series, so the number of locks is irrelevant, the water loss is the same whether there is 1 lock on a canal or 100. 

The only thing that influences the volume of water loss from the locks on the canal, is how often the lock gates are opened and closed. And clearly that's not something we're ever going to calculate or simulate. 

But basically, so long as you can get some water from somewhere to the canal summit, the canal will work. The smallest spring can fill the largest ship canal, given enough time.  You just use a summit reservoir to make up the disparity in supply and demand. And ultimately have a transit limit through your locks which I suggest we ignore.

*So we should just make canal tiles check for any adjacent water tile of equal or greater altitude when building, job done. Surely that is an easy code fix?

We could introduce a non-navigable "feeder aquaduct" waytype and bridge if you wanted to encourage proper hydraulic engineering.

[jamespetts]

May I ask what the source for that is? I recall reading that tub boat canals were chosen in Cornwall specifically because of the difficulty in getting enough water for a larger canal to higher altitudes.

[AP]

I've been reading a variety of websites and such. Much of it is simple physics. Lock gates leak slightly but lock volume is known and far greater. Evaporation from a given surface area is known.  Lock volume is lost at a rate directly related to the number of boats traversing the canal.

The important thing is that "higher altitudes" is subjective. Ultimately if you want to take a canal above the local water table, yes there will be issues.  But that is inherently a matter of understanding local geography - finding the highest suitable watercourse and going no higher. And that depends on the map in question.

See https://en.wikipedia.org/wiki/Summit-level_canal

The wikipedia article on the Canal Du Midi is interesting because it had exactly that problem. Lots of people thought it a good idea but it took ages before someone with the right knowledge was able to find a route that allowed a water source to the summit.
https://en.wikipedia.org/wiki/Canal_du_Midi#Study_of_the_project

I think giving players the same puzzle could be entertaining.

[jamespetts]

Thank you - I will have to study that carefully when I have time.

However, changing this system would create a serious problem: the existing tutorial video about waterways expressly states that canals need a source of water and that smaller canals can be built at higher altitudes than larger canals. Changing this would be a huge amount of work. Deleting it would involve destroying a huge amount of work already undertaken, much of which would still be useful. Retaining it would involve confusing players with outdated and misleading information.

[AP]

That's a nuisance, yes. Possibly it may be worth keeping tutorials in written form only, going forward, until more playtesting has been done? 

[jamespetts]

The trouble is that there is no end to how much more play testing can be done (meaning that there will never be any video tutorials if one were to adopt that view), and people find the video tutorials extremely helpful.

[AP]

I think allowing the tutorial videos existance to dicate or restrict the form of the game, risks following a rather regressive form of logic, which will not be to the benefit of the game's development.

If it's been decided that videos are required early -before the game is finished, tested, or balanced- then it must surely also have been accepted that those videos will have to be amended to suit any subsequent developments?

I very much doubt it was expected the game would be "perfect" first time.

[jamespetts]

It is not so much the case that something in a video tutorial will never change come what may; but rather that the fact that it is in a tutorial greatly increases the cost of changing it, which must be weighed carefully when considering: (1) how that cost balances against the benefits of any such change (which would need to be considered with great care and in great detail); and (2) the relative priority of any such change compared with any other work that needs to be done, of which there is currently a huge queue of things that are fundamental to balance, which, in turn, is fundamental to Simutrans-Extended being a fully formed game.

The amount of work necessary even to assess whether this change is worthwhile is so great that it is a long way down the queue compared to a very long list of other important tasks.

The more people who contribute to the development of Simutrans-Extended, the faster that the queue can be processed (and the more time that I will have to make videos), so the imperative as always is increasing the number of active developers (for which my current strategy is to get the game to balance as soon as possible in order to attract more players, a fraction of whom in turn may well become developers).

[Vladki]

I just would like to point out that some barge canals in the demo game are above the allowed altitude. They work, but cannot be upgraded, rebuilt, etc...

[zook2]

It might be off-topic, but some canals were built without waterproofing and lost vast amounts of water. For example:

https://en.wikipedia.org/wiki/Aral_Sea#Irrigation_canals
"The construction of irrigation canals began on a large scale in the 1940s.[clarification needed] Many of the canals were poorly built, allowing water to leak or evaporate. From the Qaraqum Canal, the largest in Central Asia, perhaps 30 to 75% of the water went to waste.[citation needed] Today,[when?] only 12% of Uzbekistan's irrigation canal length is waterproofed. Of the 47,750 km of interfarm irrigation channels in the basin, only 28% have anti-infiltration linings. Only 77% of farm intakes have flow gauges, and of the 268,500 km of onfarm channels, only 21% have anti-infiltration linings, which retain on average 15% more water than unlined channels."

I don't know whether canals in Cornwall in the 18th century were built to a higher standard than canals in Usbekistan in the 20th.

[merry]

I have to say that the arbitrary canal height restriction is really quite crazy, and really doesn't fit into Extended's aim to be 'realistic'.
As it stands, it it were true, many important UK canals woudl probably not have been built, let along the others round the world built in central continental areas.
I doubt the Huddersfield narrow, nor the Leeds & Liverpool, nor the Llangllen, ot name a few in the UK, would have been possible for starters. And certainly, it makes the early game very difficult to play unless the terrain is near flat, as water is the only way to move bulk economically, or anything over long distances, at that point in the timeline.

Have to say, to assertion at one point in the discussion that that a video tutorial being rendered inaccurate by a change makes the change undesirable, it seems a whole level of daft beyond...OK, you get the idea. A case of the tail wagging the dog.
Anyway, video tutorials are really quite annoying. Sequential-access data? IN a random access world? Much as video is good eye-candy, give me a text & illustration information I can hop through & search as needed any day.

[prissi]

The is also the Rhine-Danube channel, which is built for large ships and goes to 406 m altitude (175 m) and 75 m down:
https://en.wikipedia.org/wiki/Rhine%E2%80%93Main%E2%80%93Danube_Canal

The Erie canal also goes up 175 m. Of course there is even the Erie-lake.

Since there is a maximum lake height parameter (at least in standard) a revision may be needed. Otherwise when building a new canal tile, one must start at a navigable river. That would also enforce a automatically sensible restriction.

[jamespetts]

I think that the answer to this issue is likely to lie in adding variations on the existing canal types that are concrete lined. Already, the large ship canal type has had its maximum altitude removed, as this represents a type that was concrete lined from the start.

Early canals were not concrete lined, and they had to be at or below the altitude of a water source of sufficient volume to keep them replenished as they would otherwise dry up. Later concrete lined canals did not do this.

If anyone has any data on the introduction dates of concrete lined canals, that would be helpful.

Incidentally, I am moving this to the pakset section, as this is a discussion about how to configure a pakset feature, rather than any issue with the code.