News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Public rights of way

Started by jamespetts, January 17, 2021, 03:42:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

There has been discussion for some time regarding public rights of way. As is documented elsewhere, this feature was introduced in response to what was at the time the widespread practice of players severing road connexions between and within towns to build their networks (this was before the feature automatically connecting industries and attractions by road was introduced). It is intended to replicate real life public rights of way, which are a fundamentally important part of transport and without which the game would be significantly incomplete.

A number of players have expressed frustration at the way in which the public right of way system has been implemented, especially in relation to railway level crossings, but, in the past, nobody has been able to think of any better solution to the original problem, so no progress has been made. This has been compounded by the fact that I have had extreme difficulty in making any amendment to the code for cities building bridges, so I cannot find any way of forcing cities to build bridges over railways rather than using level crossings.

Some have suggested removing the restriction from the code and having a human-enforced rule, but this is unworkable: I do not have the time to dedicate to policing the server and this in practice would require me to check every road on the server every day, and, in respect of each alteration made by a player, carefully to consider whether or not it constitutes an unreasonable diversion. With 307 towns and thousands of industries, it will be readily apparent why this is not the right kind of solution on any possible view.
In any event, the problem is not so much one of outright trolling or deliberate vandalism: incidents of both are fortunately very rare in Simutrans-Extended due to its niche status. Rather, the problem is players optimising for the profit of their own network without considering externalities: a player building a railway between two towns has no reason to care if a road connexion between them be severed. In reality, profit making companies only consider such externalities in so far as rules force them to do so, and the game needs to replicate this element of reality. Thus, this is actually a fundamental gameplay balance issue rather than simply an issue of online gaming etiquette: a fundamental design goal of Simutrans-Extended is that players should be able to play according to incentives that are as close to reality as possible, and that they should be able to play using a style intended to maximise their in-game profits within the code-enforced rules without being able to do things (especially game breaking things such as severing arterial road connexions) which real transport companies would never in reality have been able to do. Thus, defining precisely the extent to which players can make detours in public rights of way for their own network is a significant gameplay feature and needs to be treated as balance critical. This means careful consideration of all the remote consequences of any change to this feature is necessary before implementing it.

Recently, in the Discord channel relating to the Bridgewater-Brunel server, Freahk has made an interesting suggestion which merits some careful consideration, viz. for cities to re-build road connexions automatically if the code detects that any have been severed.

This is not, when properly considered, a complete alternative to the public right of way system, but may simultaneously allow some relaxation of the current rules (in particular, increasing the diversion length) and also eliminating an exploit in which players may incrementally create an absurdly circuitous route by gradually compounding diversions, as the existing lightweight diversion code, which intentionally has a zero memory footprint when not actively in use, only looks at the diversion from the individual tile being deleted rather than looking at the route as a whole.
However, implementing such a system is likely to be highly complex, both from the perspective of coding a system that achieves this aim within reasonable parameters of performance and memory consumption and from the perspective of carefully calculating all of the remote consequences of this and avoiding any exploits, perverse incentives or adverse unintended consequences. Work on such a feature, including fixing bugs and adverse side effects reported after initial implementation, may take many months, and, if this were to be made a priority, work on all other features and fixes would be delayed by this amount of time.
A number of things need careful consideration. First of all, checking routes is extremely slow. This is currently done by the private car route finder: in the Bridgewater-Brunel server, when clients are connected, this takes many, many hours to check all the cities. It is faster now when no clients are connected, when this task can be given a higher priority and multi-threaded, but even then it takes circa 20 minutes. Thus, on a large map, there will be a very long lead time between a city detecting that a route has been removed and it being rebuilt. For this reason alone, this cannot be the sole protection for public rights of way and the existing system, albeit potentially with a more generous allowance for diversion and possibly different treatment of level crossings, will need to be retained.

Secondly, the existing private car route finder does not store a table of route distances between cities: only time per tile values (the highest possible value indicating no connexion at all). The time per tile value can be affected by congestion or the speed of current era private cars, which slowly changes with time, so the current system could not be used without significant modification (the performance and memory consumption consequences of which would need very detailed consideration) to check whether an unreasonably long diversion has been created.

Thirdly, a system that allowed a player actually to sever or even divert a public right of way and for the game to rebuild it could be used as an exploit to force the game to provide an upgrade to the road for free to the player: the current way building algorithm simply finds the lowest cost route (normally the shortest) between the origin and destination (the townhall road tiles of the two cities), so there could be no algorithm that just found the place where the connexion had been severed without a huge amount of additional work creating a fundamentally new algorithm to do this, and it is not clear whether there is a workable algorithm that can do this reliably in any event, at least not within reasonable parameters of coding time/effort/skill and performance when running.

That third issue might be addressed in part by disallowing severance using the existing system, albeit with more generous diversion requirements, and making it more expensive for players to create such diversions than simply to upgrade the road themselves, but I do not know (and would not be able to know without some very intensive and extremely time-consuming work) whether or not this can be done within realistic overall costing parameters.

Fourthly, a system that allowed players to sever rights of way for them to be rebuilt later only works if there is in fact the space in which to rebuild them later. A player erasing a road from a narrow causeway to replace it with a railway line would be able by so doing completely to circumvent the system. Indeed, a system that allowed destruction on the footing of later rebuilding would be one that gave railway companies the power to take the best alignments from existing established roads for their railways, forcing roads to use much more circuitous or hilly routes, which would fundamentally unbalance the game.

As for railway level crossings, the best solution is likely to be simply to prevent the roads connecting industries to build level crossings, and treat railways in the same way as they treat rivers, viz. forcing them to build a bridge if they are to connect at all. This at least prevents players' existing assets from being interfered with, which is a reasonable and realistic solution.

As should be apparent from the above, the issues relating to public rights of way do not admit of a simple solution that does not cause at least as many problems of its own for game balance. Careful and detailed thought may well provide refinements to the system that will limit players' frustration whilst maintaining the balance critical fundamentals that require the feature in the first place.

Edit: I have now implemented a feature preventing automatically built industry roads from building level crossings over existing railways, which should alleviate the issues caused by these crossings.

Edit 2: Another suggestion that I see on the Discord channel that merits some consideration is measuring the diversion from the nearest intersection each side of the tile to be deleted; as ever, this will need detailed evaluation before it can be determined whether implementing this is sensible in the circumstances.
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

#1
I see one big conceptual issues with the current approach resulting in most of the diverse problems caused by this system.
PROW routes are not a local thing! What actually matters is the route in between two points on the map, usually in between cities, attractions and industries.
If the old route runs ove rthe hills and a player builds a short route through the mountain using a tunnel, that route will effectively obsolete the old one, but any local PROW system won't accept this new route as a replacement.

There are two ideas how this could be solved, the first one being a slight, still rather local improvement of the current system, the other one being a system that actually takes care of the generated PROW routes as a whole.



Idea 1 - measure the diversion in between the related intersections.

When deleting a road, currently routes in between the adjacent tiles are calculated. If one of these routes will be longer than max_diversion_tiles, that attempt is denied.
The example image is a quite common situation, where there is a diversion that is actually better for everyone, or at least not that much worse, but it won't be accepted.
Jump to the related intersection (the blue circles), then calculate the routes in between those intersections and compare their length against the old route.

That should improve the situation in a quite common scenario, but it will still fail in more complex situations.



Idea 2 - Introduce a PROW route concept and ensure that those routes will never become longer than their initial length.
We need to remember which PROW routes use a specific road tile. To do so, we maintain a list of PROW routes in those road tiles.
Additionally, for each PROW route, we need to know (origin, destination, length).
Now we can, whenever deleting a PROW road, recalculate the related PROW routes and check if the new route is within the tolerable limits.
If not, reject the destruction, otherwise delete the old related PROW routes from the road tiles and write the new ones.

This might come with an additional two click admin tool: "make PROW route", which initialises a new PROW route in between the two locations.
The current "make public" tool won't work well with this PROW concept.

The advantage of this solution is clearly that it cannot be exploited by repeated lengthening, given we always store the initial length of a PROW route, not the length of the current revision and ensure that this route can only be lengthened by a slight amount.
Further, it will also work in more complex situations, for example replacing a curvy mountain pass with many intersections by a straight motorway.
The disadvantage clearly is the coding effort needed.
Memory consumption and computing time shouldn't be a big deal. PROW routes are not a quite global thing, so there shouldn't be many of these stored on a single road tile.

jamespetts

Thank you for your thoughts. I do not have time to respond in length now, but it would help me if you could consider the possible implications of the first system of players' ability to build intersections with public rights of way at any arbitrary point.

Incidentally, in reality, public rights of way are local in the sense that the actual specific route is the thing that is protected by law, not the abstract ability to go by road from one place to another, but the ability to do so by a particular route.

The diversion system is intended to replicate the ability that governments have by legislation (in the UK, what are termed "private" Acts of Parliament) to modify a right of way by simulating in an approximate sort of way the sort of diversion that a Parliamentary committee might authorise.
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.

Vladki

I do not know how the laws regarding PROW work in any country, and I suspect they will vary quite a lot. Also describing "what a Parliamentary committee might authorise" in algorithmic way is impossible, yes Mr. Minister?
So what should be considered is that PROW ways are there to connect inhabited places. So, we could use that as an option to allow longer (or just any) diversion if there are no buildings next to the road being removed and along the whole diversion path. Otherwise the current rule will apply. This would keep the current rule in cities, and allow any diversions in countryside.

jamespetts

I do not know of any other model of rights of way that is fundamentally different to that used in the UK - is anyone aware of any specific different way of doing it?

It is certainly possible in principle to have an algorithm that generates a simplified version of what a committee might decide; we already have algorithms in the game that are simplified models of what passengers or town planners might decide, so this is no different in principle.

The idea of a route between places in the abstract is a long, long way from what a public right of way actually is, and I think that I described in a great deal of detail in the original post why this cannot be a substitute for the existing system, but might in theory be used alongside a version of it with a higher permitted diversion length to minimise the exploits that might be caused by this, although the coding effort for this would be truly enormous, and I note that nobody has volunteered for this at this stage.

The between intersections idea is a more interesting one, although there is still the possibility that a between intersections route could end up being more stringent than the current requirements in some instances. I have still not had time to examine all the possible cases in detail, but it would help if anyone were to address the issue relating to the ability for players (not necessarily the ones wanting to build the diversion) to place intersections at any arbitrary point so that we can examine carefully the consequences of this alternative.
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

I had hoped to have had some more contributions apropos the intersection algorithm here, but, since that has not happened, I will set out my own thoughts so far.

First of all, it is difficult to see any major drawbacks from the perspective of the original purpose of the public rights of way algorithm to implementing a system based on measuring the distance between the next intersections. One possible issue might be that, if there are intersections very close to the intended diversion, this algorithm might be less generous to the player than the current algorithm. I am not sure how often that this will arise.

One thing to consider is whether to continue to allow the diversionary route to be longer using the existing max_diversion_tiles setting or to require it to be the same length. It is probably better simply to deploy the existing max_diversion_tiles setting to give the maximum greater length of the route from the existing route between adjacent intersections or else there will be many circumstances where the intersection algorithm is less generous than the current algorithm.

One complexity is what to do when the tile sought to be deleted is itself an intersection. One possibility is to use the existing algorithm in such a case; indeed, to use the existing algorithm in all cases, but also check the new intersection based algorithm in all cases where the tile that the player wishes to delete is not itself an intersection, meaning that the player will be able to delete the tile whenever either the existing or the proposed algorithm permits it.

Another complexity is what to do if towns, industries or attractions are closer to the tile to be deleted than the next intersection in any given direction. For towns, this probably is not an issue as towns have so many intersections that this will make no practical difference in almost all cases. For industries/attractions outside towns, however, it is possible that a public right of way passes by one of these rather than ending at one of these and therefore that a diversion will cut off an industry or attraction. For that reason, the algorithm will need to stop at a point before the next intersection in any given direction if it finds a tile of road connected to an industry/attraction. It might be the case that this imposes more restriction than necessary if the industry/attraction has multiple roads connected to it, but this is rare outside towns and is likely to take a very high level of complexity to deal with in a sensible way.

Allowing the most generous of the two algorithms in any given case to decide whether a player can delete a tile will thus prevent this algorithm from being able to solve the incremental diversion exploit. However, anything that can practically solve this problem is likely to require an order of magnitude more complexity than simply implementing the intersection based algorithm. I will have to monitor the game over the coming months to determine whether that level of effort is likely to be worthwhile to prevent an exploit which so far appears to have been used only in protest at an issue which hopefully the intersection algorithm, combined with the new prohibition on industry roads building level crossings over players' railways, will address.

Before I start work on implementing this, I should be grateful for any feedback as to the above, and in particular whether there is any significant issue or possible problem that anyone thinks that I might have missed.

Thank you to all who have contributed to this discussion and especially to Freahk for having suggested the intersection algorithm.
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

Quote from: jamespetts on January 19, 2021, 11:12:02 PMOne thing to consider is whether to continue to allow the diversionary route to be longer using the existing max_diversion_tiles setting or to require it to be the same length.
It should permit the route to be longer, otherwise we will get many situations that cannot be solved, but the max_diversion_tiles setting might be set to a lower number.

Quote from: jamespetts on January 19, 2021, 11:12:02 PMOne complexity is what to do when the tile sought to be deleted is itself an intersection.
I don't see any issue here. It's indeed a special case as there can be more than two related intersections in that case, but apart from that, it's the same: Jump to the related intersections and calculate the new routes in between those up to 4 intersections.

Quote from: jamespetts on January 19, 2021, 11:12:02 PMAnother complexity is what to do if towns, industries or attractions are closer to the tile to be deleted than the next intersection in any given direction
That is indeed a difficult thing, which had been briefly discussed before.
Industries should in any case always be considered in the same way as intersections because disconnecting industries is not an option. By the way, currently disconnecting industries is accepted.
Town buildings are more difficult. Strictly, we have to consider adjacent town buildings because the road connection of those will become worse.
On the other hand, ensuring that buildings are always connected by a road might already do the job. A very badly connected town will suffer jams anyways.

Quote from: jamespetts on January 19, 2021, 11:12:02 PMAllowing the most generous of the two algorithms in any given case to decide whether a player can delete a tile will thus prevent this algorithm from being able to solve the incremental diversion exploit.
The existing algorithm is a subset of the new one with the "jump to intersection" modification. The new one can only solve the incremental diversion exploit if max_diversion_tiles is set to 0, which is not a good idea.
The rather simple modification does not target this issue. A more complex approach is needed if that's what we are aiming for.
As you said, the diversion exploit does not seem to be abused actively, so it's mos tlikely not worth the effort of implementing such. There are definitely ways to ensure this, but in ay case this will require us to remember some data about the original route, otherwise incremental modifications will always be possible.

jamespetts

I have now implemented the intersection based diversion feature. I should be grateful if people could test to see how this works with to-morrow's nightly build.
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: jamespetts on January 22, 2021, 12:37:30 AM
I have now implemented the intersection based diversion feature. I should be grateful if people could test to see how this works with to-morrow's nightly build.

James, thank you for taking the time to respond to player concerns. Two thoughts.

Firstly, this should only be tested in single player, as deleting roads in multiplayer frequently crashes the client and/or server.

Secondly, I not yet convinced this implementation is an improvement, but I am still gathering data.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

I should note that this feature is implemented in such a way as will always allow players to delete roads when the old algorithm would do so and will additionally allow players to delete roads in new situations.
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.