News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Rivers with public right of way cannot be upgraded to canals

Started by Matthew, July 14, 2021, 06:21:58 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Matthew

Certain rivers cannot be upgraded to canals. I think this is because those tiles have public right of way (PROW).

Steps to reproduce:

1. Create a new map.
2. Find a long, large river generated by the game at low altitude (≤4). Observe that it has PROW on navigable tiles.
3. Switch to public player.
4. Manually place a long, large river (with all the different river sizes down to brook) next to the generated river. Observe that there is no PROW.


Savegame with steps 1-4

5. Switch to default player (use the Player dialog, as the keyboard shortcut will crash the client).
6. Try to upgrade both rivers to ship canals throughout their lengths.

Expected behaviour:

Both rivers can upgraded to ship canal throughout their length by Ctrl+LMB.

Actual behaviour:

The manually placed river can be upgraded throughout. But the generated river can only be upgraded to a canal on non-navigable tiles. The canalization fails without an explanation on navigable tiles with PROW.


Savegame with actual behaviour
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

freddyhayward

Can you compare the canal and PROW river speeds? If the river is faster, this isn't a bug.

wlindley

How would this best be patched:  Railways and canals built by 'Public player" should be 'grey' but rivers and roads should be 'orange'?  Should all roads so built be 'orange' or would highways be 'grey' and if so what's the dividing point? I'd like to write code to make this work as we expect, but -- what exactly would that be

Mariculous

What exactly do you mean?
Do you refer to the difference in between "unowned" (orange) and public player owned (grey) ?

wlindley

Exactly. The expectation is to be able to switch to public player as a "map editor mode" when creating or moving rivers and ordinary roads that should be "unowned" just like all the other program-created ones.

Mariculous

I am not sure about that distinction.
Currently, the line is drawn in between automatically generated (unowned) and objects created by player interaction ((public) company owned) objects.

To be honest, I'd consequently distinguish in between natural-or-private objects (private as in natural person) and other objects, but there might be a reason no to do so.
Natural objects and Private objects, both are always unowned because Simutrans does not maintain the bank accounts of private persons nor the bank account of Gaia.
Anything else, which includes all ways except from natural waterways, should be owned by the company (including the public company) which built it.


Edit: Anyways, I guess object ownership is not the point of this bugreport!
Might we split this topic?

jamespetts

Thank you for your report. Matthew - can you confirm whether the canal to which you seek to upgrade the river has at least as good a top speed, maximum weight and at least as permissive a set of way constraints as the river that it is replacing? If not, then this is intended behaviour, as players using the river being replaced may find themselves unable to use the new canal in the same way as the old river.

As to ownership, this is unrelated, and I am doubtful that anything in particular needs to be done about this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Matthew

Quote from: freddyhayward on July 15, 2021, 03:36:45 AM
Can you compare the canal and PROW river speeds? If the river is faster, this isn't a bug.

Quote from: jamespetts on July 18, 2021, 10:59:32 AM
Thank you for your report. Matthew - can you confirm whether the canal to which you seek to upgrade the river has at least as good a top speed, maximum weight and at least as permissive a set of way constraints as the river that it is replacing? If not, then this is intended behaviour, as players using the river being replaced may find themselves unable to use the new canal in the same way as the old river.

Thank you for correcting my error: this is indeed caused by the canal having a lower speed than the river that it is attempting to replace. This is a sensible and easy to understand limitation, but I never knew about it.

Firstly, is this the same behaviour as Standard? If not, then perhaps it should be mentioned in the features overview. Because otherwise the attempted upgrade fails without explanation or warning.

Secondly, at least with the values used in pak128.Britain-Ex, this sensible limitation seems to me to have surprising results. The small rivers (both upstream and downstream) have a speed limit of 10km/h and a barge canal/small river restriction. If you want to enlarge them to create a waterway than take the smallest oceangoing craft, then you would expect to use the ship canal, which has a medium river restriction. But it only has a speed limit of 9 km/h, so you can't do it.

I know that these kind of things have usually been thought through carefully in Sim-Ex/128-Ex, so I wonder whether this is an accident or intended to have some historical purpose.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

Mariculous

I found an interessting source about this.
Not a British one but it indicates that speed limits on canals and rivers is mich more complicated than a hard speed limit.
Though it also mentions that speed limits on river sections are usually greater than speed limits on canal sections - at least in France.

https://www.french-waterways.com/practicalities/cruising-regulations/


This leaves out a common practice though: instead of canalising rivers, those are sometimes straightened or enhanced to carry larger ships without installing canal walls and watergates.
Might that be a sensible workaround for this issue?

jamespetts

Standard does not have a public right of way feature, so this is not present there. I will have to review the feature overview at some point, as it may need updating more generally.

In relation to speed limits for canals, etc., this is a very complex topic. The original work to add much detail and realism to canals, including adding multiple types of canal with different restrictions and multiple types of canal boat that fit into different canal widths and that are introduced at different points in history was undertaken in 2012. Since 9 years have now passed since then, I do not recall in detail the reason for each individual value of, e.g., speed limit.

I believe that Freahk is correct that canals tend to have lower speed limits than rivers, which was what was intended to be simulated; certainly, there is no inconsistency between the speed limits of different canals:

Tub boat: 5km/h
Narrow boat: 6km/h
Barge: 9km/h
Ship: 9km/h
Large ship: 11km/h

I believe that the speed limits of all of the canals aside from the tub boat, whose maximum speed is marked as being guessed, were based on research, and likewise that of the rivers. Of course, anything other than a hard speed limit in a way would require drastic, highly complex and far-reaching changes to the whole way in which speed limits work, which would be a very major coding project, consume huge amounts of coding resources and greatly increase complexity for players, so is not likely to be a viable solution to a relatively marginal problem such as this.

Likewise, simulating the difference between canalising a river and enhancing its navigability without canalising it would require whole new abstraction layers to be implemented in relation to ways, which would have far-reaching consequences and require a major coding project. At present, rivers and canals are simply ways. Rivers are a special type of way that are built automatically on map creation and are unbuildable by players because the tool to build them is only accessible from a menu available only to the public player. In all other respects, they are treated as standard ways of the water type and can be upgraded by players to another way of the water type (canals) in the same manner as any other way. Any way that a player could use to upgrade a river to a better sort of river could also be built on virgin terrain by that player.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

I have now observed something simmilar.
I couldn't upgrade an existing small river (small river/barge canal constraint) to a ship canal (medium river/sip canal constraint) but I could upgrade the same river to a barge canal.

I suspect that is due to the constraint system not being well suited for the subset nature of canal constraints.
When it comes to which ships can run on a river/canal with a specific constraint, the structure is:
tub ⊂ narrow ⊂ barge ⊂ ship ⊂ large ship
Currently, there is no such relation at all between constraints.

To solve this issue, it might be easier to introduce a "way level" / "loading gauge" attribute to ways, identified by a single number:
If vehicles loading gauge is lower than or equal to that of the ways, the vehicle cann pass. Otherwise it can't.
That mechanism could further replace the light rail and tube constraints as well as being used on potential light rail tracks to reflect lower construction costs due to less space needed.

jamespetts

Quote from: Sirius on February 19, 2022, 02:31:55 PM
I have now observed something simmilar.
I couldn't upgrade an existing small river (small river/barge canal constraint) to a ship canal (medium river/sip canal constraint) but I could upgrade the same river to a barge canal.

I suspect that is due to the constraint system not being well suited for the subset nature of canal constraints.
When it comes to which ships can run on a river/canal with a specific constraint, the structure is:
tub ⊂ narrow ⊂ barge ⊂ ship ⊂ large ship
Currently, there is no such relation at all between constraints.

To solve this issue, it might be easier to introduce a "way level" / "loading gauge" attribute to ways, identified by a single number:
If vehicles loading gauge is lower than or equal to that of the ways, the vehicle cann pass. Otherwise it can't.
That mechanism could further replace the light rail and tube constraints as well as being used on potential light rail tracks to reflect lower construction costs due to less space needed.

I do not think that there is any need to reinvent the constraint system in order to deal with the upgrading issue: much simpler would be to add a feature that allows one way to be specified as upgradable to another without passing any better than or equal to checks if it is a public right of way.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

This issue has been discussed on the Discord server in relation to the recent bug-fix in relation to rapids. First of all, it is possible to upgrade rapids (and the underlying rivers) without a diversion: just make sure that the canal that you are using to upgrade has the same way constraint type as the underlying river. For example, a small river can be upgraded to a barge canal.

In due course, it would be worthwhile to have a system to allow upgrades in specified cases without the better than checks in relation to some specific constraints as discussed above, but new features will have to wait until higher priority, balance critical features have been implemented. For the present, players can always upgrade rivers to a canal of the same constraint type.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

neroden

I remember discussing this years ago.

At this point I actually lean, long-term, towards replacing the current system of constraints for rivers and canals with a width limit constraint in addition to the existing speed limit and weight limit, because I realized *it would be useful for roads and railways too* (loading gauge!).  This would be capable of replacing most of the special constraints coding for barges and canals, though not the "must use waterway" requirement or the one about bridge heights, which would remain.  But it would also allow for width-limited road and railway types, including tunnels and bridges... could be very useful as a future general pak feature.

Mariculous

Quote from: Sirius on February 19, 2022, 02:31:55 PMTo solve this issue, it might be easier to introduce a "way level" / "loading gauge" attribute to ways, identified by a single number:
If vehicles loading gauge is lower than or equal to that of the ways, the vehicle cann pass. Otherwise it can't.
Quote from: jamespetts on February 19, 2022, 03:47:42 PMI do not think that there is any need to reinvent the constraint system in order to deal with the upgrading issue: much simpler would be to add a feature that allows one way to be specified as upgradable to another without passing any better than or equal to checks if it is a public right of way.

wlindley

Another desirable feature would allowing small boats like the Norfolk Wherry to hug a coast by sailing on tiles adjacent to land; surely that is prototypical for "waterway" vessels?