Topic: Oneway Twoway Road Patch for the Extended

[Vladki]

I think the spaced arrows aren't very good at checking connectivity. Also, arrows do not support slopes or diagonals.

Oh indeed they do support slopes and are useful - you have to zoom out:

[Ranran]

I wanted to say that it is much less inferior to the one that has continuity because it lacks continuity. (´・ω・｀)

And the arrows arranged in a zigzag on the diagonal are strange and honestly speaking, I do not like it. 

If you look only at this, it looks like it is not connected.

[prissi]

This was the main point of not starting to integrate the oneway overtaking patch to standard, which otherwise I would have liked too. However, personally I thought of a single direction wayobj (which would also allow to make other ways single directing) and give at the same time visual clues. For instance a guard rails with signs or arrows at crossings and begin and end.

Unfortunately I never finished my patch. (Partly because I lost motivation, when it became clear, that the code was geared for experimental and there was no intention to work further on standard.)

[Vladki]

If you look only at this, it looks like it is not connected.

No, it does not look so. If disconnected there would be one arrow skipped. When looking for disconnections you have to zoom out, and look for irregularities. Then it does not matter if the road is one- or two-way, straigh, slope, or diagonal. You just look for irregularities.

[Ranran]

What I mean is that this is not the best way. Does it make sense to find the missing one of the four?
For example, if this is a connected line, or if the color differs depending on the type of constraint, it is obvious. Why do you force users to take unnecessary trouble?
I said it should be done if it makes sense to change it along with the problem mentioned above. First, the above issues are priorities. I'm not sticking to this arrow alone.

However, I think it is impossible to improve the identification method without changing this display method in some way.

[Ranran]

I have found that this feature can be used to freely destroy public or my own roads without providing alternative roads. (´・ω・｀)
Make sure that both the entrance and exit are one-way inward. That way, it's almost as if it was cut, so it can be destroyed.
Occasionally it fails to destroy the entrance, but in that case try another destruction of the inner tile.

[jamespetts]

I have found that this feature can be used to freely destroy public or my own roads without providing alternative roads. (´・ω・｀)
Make sure that both the entrance and exit are one-way inward. That way, it's almost as if it was cut, so it can be destroyed.
Occasionally it fails to destroy the entrance, but in that case try another destruction of the inner tile.

This suggests that it should not be possible to change the one way status on public roads, as there is no algorithm that can be implemented within a reasonable time to check whether one way statuses on these roads in combination make them impassible.

[Freahk]

Oh well, even more restrictions that will require killing many people.

[jamespetts]

Oh well, even more restrictions that will require killing many people.

Can you think of a workable alternative?

[Freahk]

Usually I just trust people not to be too disruptive, but I've just recently noticed some people intentionally seem to be disruptive :(

In any case, all these restrictions have the exact opposite effect: People are forced to be very disruptive to achieve rather small changes and not allowing any oneway changes of PROW ways will make the aspect of road traffic management just impossible, at least without destroying whole city quarters just to remove and rebuild some roads.

If I have built a country road I definitely want to be able to upgrade it to become a motorway later.
There currently is a (rather incomprehensible) system to check for diversary roads. Why can't that system be used when changing the oneway mode either?

Btw. is there a way to entirely disable those diversary route checks? it's the most annyoing feature extended has and not required in a community where people trust each other to not be disruptive. In fact, on my last servergame each player had

If people are intentionally disruptive,  all these current restrictions including the plan to disallow the use of oneway modes in most cases doesn't really solve the issue either. Routes can still be cut by not sharing access and replacing PROW ways by player owned diversary routes, as just happened on Bridgewater at Thurenton.
Further, people are free and sometimes forced to destruct whole city quarters due to these restrictions, as just happened at Bridgewater in Thurenton either.

Further, a system to allow for replacing ways by bridges without causing temporary disruption should be considered as this is the main reason forcing players to destroy buildings just to build a temporary diversion.

[jamespetts]

I do not think that the problem is solvable simply by trusting other players not to be disruptive. Firstly, there is always a risk that players will be malicious; but secondly and probably more importantly, there will always be cases where players might do things that, whilst not intentionally malicious, are nonetheless doing things which it breaks game play balance for players to be able to do, such as cut off private car routes to towns to prevent traffic congestion and force passengers to use their own transport. This is not malicious to any other individual player, but it breaks the game play realism and the game balance for everyone. There may even be cases where players do not realise that they are destroying the only route between two towns.

A public right of way system is necessary for gameplay balance.

[Freahk]

Still, is it possible to disable this? Its current nature is causing more disruption than it solves.


Just to be clear: I am not against PROW ways or something simmilar as a mechanism to prevent players from cutting privatecar connections between towns, but I do not think it should be as restrictive (and annoying) as the current system is, as it's often forcing players to destroy houses in cases where this would not actually be required.
Further, that system should not try to prevent players from abtotaging others as it cannot do this anyway.


All it should do is
a) ensure that connected cities remain connected without huge detours
b) ensure that housings within a city can be reached.


To do so, when initially built, it should be remembered which (pairwise) towns were linked by PROW roads and how long that connection initially was.
Roads inside towns will always be PROW when built adjacent to a PROW way, otherwise they will be unowned, but not PROW (which can happen when cities expand across lakes or something like that)

When players do now attempt to remove or alter the oneway state of a PROW road, it will be checked if
a) The distance in between the affected cities does not exceed the initial distance plus the tolerance and
b) Within towns, all adjacent PROW roads remain connected to the townhall.

That's the only system I can think of to actually ensure what it ite meant to without being as annoying as the current system, which I'd still prefer to disable for that reason.

[jamespetts]

What is suggested would be a very, very substantial new feature, and would require extensive new memory structures to the extent that careful performance/memory consumption testing would be needed for very large games, as a great deal of new data would have to be stored in every road tile.

It is unlikely for it to be viable for me to work on such a feature before economic balancing has been achieved.

[freddyhayward]

Players will often intend to temporarily disrupt a route and immediately restore it in-place. In these situations it It would be useful to have a system where players may promise to do this and are held accountable if they fail to do so. I have plenty of spare time at the moment and would be happy to work on such a system.

[jamespetts]

Players will often intend to temporarily disrupt a route and immediately restore it in-place. In these situations it It would be useful to have a system where players may promise to do this and are held accountable if they fail to do so. I have plenty of spare time at the moment and would be happy to work on such a system.

May I ask how you envisage that this would actually work and what being held accountable would entail in practice? This would have to be something robust and effective at preventing players from actually ever succeeding in disrupting routes for more than a very short period; it would not suffice to fine players, since many players have large sums of money; it would not suffice to impose some sort of time limit on temporary disruption, since players could repeatedly remove and replace the road so that it is only in place for a very short proportion of the time. It is difficult to imagine what could work effectively.

[Freahk]

Is there a way to disable the current system entirely in simuconf?
Won't help me on Bridgewater, but will definitely help for future under-the-radar servers.

[Vladki]

Is there a way to disable the current system entirely in simuconf?

What I suspect is that there is a bug in the PROW check. As it often does not allow to break city road even if short diversion is available. Maybe if the check works as expected, it should be possible to effectively disable it by allowing quite long diversion.

[Freahk]

Maybe if the check works as expected, it should be possible to effectively disable it by allowing quite long diversion.

That doesn't work and will cause quite long diversary route searches.

[jamespetts]

If I recall correctly, there is no setting for disabling public rights of way. If there is a bug, I should be grateful if somebody could upload a reliable reproduction case.

[freddyhayward]

May I ask how you envisage that this would actually work and what being held accountable would entail in practice? This would have to be something robust and effective at preventing players from actually ever succeeding in disrupting routes for more than a very short period; it would not suffice to fine players, since many players have large sums of money; it would not suffice to impose some sort of time limit on temporary disruption, since players could repeatedly remove and replace the road so that it is only in place for a very short proportion of the time. It is difficult to imagine what could work effectively.

I don't have anything concrete in mind. I suppose that if there is enough interest to warrant implementing the feature, there will be enough interest to discuss its workings. One possible measure would be an increasing monthly fee for as long as the route is not restored. Even if players were to rebuild and destroy the route periodically to reset the fee, I can't see how this would be more desirable than simply rebuilding it once.

[Ranran]

Can you think of a workable alternative?

How about allowing a one-way traffic for public roads only if there is an alternative road?
That is, if it is not destructible, it rejects the player's request for one-way traffic.
In other words, if there is no other parallel road connecting in the city, one-way traffic will be refused.
At least the current unconditional ability to change all constraints is a big problem. Also, the player may unknowingly make one way when updating the road. To be honest, I think it's easier than accidentally pressing withdraw all. Because the person who builds the road with the shortcut key does not check the display written on the icon in most cases. (As I'm saying again and again, this design is really bad...) And the "s" on the street is easy for anyone to remember, moreover, it is a key that is easy to press as it is one of "WASD".
If you accidentally rewrite an alternative road as one-way, it won't cause much trouble. Without alternative roads, a major traffic disaster could occur.



Also display issues:
Talking about arrow thing, I pointed out the imprecise restrictions that are being imposed, but a display that clearly indicates that a player is impassable will make things more clear. For example mothbold road, tiles that are not allowed access.

[jamespetts]

Ranran's suggestion seems sensible, as there is already code for checking this. For the reasons given in my previous post, however, I do not think that a monetary disincentive as suggested by Freddy is sufficient.

[Freahk]

I agree with Ranran, changing the oneway mode should use a mechanism to validate that there is a diversary route available.
This is essentially the idea of the above, though with a local point of view, using the existing (hard to understand) mechanism of diversary routes. It's still much better than generally disallowing such changes.

Although, the main issue is that there are many cases in which it is required to temporarily cut routes, and the rules to cut such routes are very restrictive, often forcing players to "temporarily" remove houses.
There are two possible solutions essentially different approaches to solve this:
1. Use much losser restrictions ensuring routes to not get cut or
2. Allow players to do such modifications without the need for temporary routes.

The first is described above, although I do still think it's a good idea to actually ensure what we want to ensure instead of using a quite local model that can always be circumvented, it is as mentioned a rather huge overhaul, though I do not think it requires extensive new memory structures, most of the data required is already available at some time and does only need to be remembered.

About the second, we had a brainstorming on the ingame chat yesterday. What came out is a mechnism to allow most conversions of ways in between plain way, bridge, tunnel (and elevated way) without temporarily cutting the route.

Freddy will have a more detailled post about this soon.

[jamespetts]

One complexity with Ranran's suggestion that occurs to me is that, as soon as the diversionary route is confirmed, the diverted route is marked as a public right of way. This may or may not be desirable behaviour in this context, although it may well be better than the current behaviour.

I shall look forward to the details of the proposed amended system arising from the discussions yesterday.

[Freahk]

This may or may not be desirable behaviour in this context, although it may well be better than the current behaviour.

As long as players are always allowed to "downgrade" from oneway to twoway mode, I don't see an issue here.
Downgrading would then still keep both as PROW, but as there then is a diversary route, one of those can simply be removed.
Both directions of a motorway being PROW is actually what I would expect.

[Ranran]

I found an additional issue.
A tunnel porter can be created by pressing with ctrl key, but this feature conflicts with its behavior.
It is annoying because it opens the settings window meaninglessly every time you build it.

[Ranran]

I found a further drawback of this feature.

One of the unkindness of this feature is that it doesn't consider road upgrades.


When you update the road, it will be overwritten with the newly set limit. So, it is necessary to set the original restriction again. It's like having to re-install signs and signals.
And, as I've explained so far, the arrows only give us a rough idea of what restrictions roads have. The restrictions that show double-headed arrows are likely to be overlooked. So you have to rely on your memory or click on each tile in advance to check the restriction.

I think we need a mode that doesn't overwrite the original settings.

[Ranran]

I made a change to remove the arrow when it's not one way. (Pull request #212)
I would appreciate if you guys could tell your thoughts on this.

As for Vladki's point of view of road connectivity, I'm reaffirming that this isn't suitable for it.
I've run into a situation where the roads aren't connected on the server several times but it didn't help at all.
1) When zoomed out, the arrow can hardly recognize the direction. (This may have a bad arrow design. However, I think that it is not suitable if it wants to check "continuity" but is itself discontinuous. I mean, the arrow is not connected to the next tile.)
2) Arrows are hidden by buildings, bridges, tunnels and terrain.



EDIT:
I'm currently looking at these codes a bit. I won't fix it now because it's a tedious task, but I'll leave a small note.

You should pass player information to set_overtaking_mode(overtaking_mode_t o) to prevent others from changing the road restriction (and add the process of comparing the owner and the executor). Or judge before calling the function.
Note that this is in many places and there are five similar functions.
And when rewriting this, please also consider the case where you do not change it as in my previous post.

[Ranran]

I made a display improvement change like I suggested before.
Please check this:


I would appreciate if you guys could tell your thoughts on this.


EDIT:
Additional note Further problem with Oneway Twoway Road Patch:
Please note that "overtake stationary only" works as "Overtaking prohibited" in places where there is not the bus stop.
So we need to reconsider this feature and its behavior and processing.

[Freahk]

Much better than what we currently have

Some thoughts:
The colors are easy to see, but these are comletely unintuitive.
Wouldn't it be better to draw an icon on top?
Draw nothing in case of "Two way (default)" is fine.
Drawing the arrows in case of oneway is fine either, but might better be the oneway sign.
Not exactly sure about Parallel stop mode, but it might be an adaption of the oneway sign.
Overtaking prohibited is an a real-world roadsign either, so we could use that sign.
About "overtake stationary only" I'm not sure either.
About opposite lane driving I'm not sure if such a roadsign exists. It might simply be two arrows in opposite lanes direction.

It would be quite awesome if that layer highlighted dead ends in general. It is very hard to find unconnected ways, especially on slopes, as there does not exist a dead-end way graphic.

[Vladki]

Yes, drawing nothing in default mode is good. One way mode too.
I do not like the colored background. We already use that for reservations and player ownership.

For the other modes, how about these:
parallel stop mode - show two parallel arrows
no overtaking - show solid centre line
overtaking only stopped vehicles - show dashed or dotted centre line
opposite lane, show red arrows in respective lane and direction.
dead end, show colored line at the tile border opposite the tile's exit

[Ranran]

Thank you for your thoughts.

Wouldn't it be better to draw an icon on top?
Draw nothing in case of "Two way (default)" is fine.
Drawing the arrows in case of oneway is fine either, but might better be the oneway sign.

As already pointed out, it is the same as the existing arrow design is bad.
I think that one of the factors that should be considered is the visibility when zoomed out.
The three-dimensional like drawing reduces the visibility during zoom out. Simple image is better than complex picture.

no overtaking - show solid centre line
overtaking only stopped vehicles - show dashed or dotted centre line
opposite lane, show red arrows in respective lane and direction.
dead end, show colored line at the tile border opposite the tile's exit

I think this kind of simple expression is better, but even then, the visibility when zoomed out may not be good and I think it still requires some work.
Coloring tiles is a minimal change that uses existing code. There are many priority issues that must be resolved for this feature...
Anyway, improved visibility will make it easier to find errors.

The colors are easy to see, but these are comletely unintuitive.

Do you think the color of block reservation is intuitive? I think it's the same. Also, the idea of coloring tiles may be consistent throughout the game.

About color
1) Color that does not conflict with Block reservation
2) the constraint should be near red, otherwise blue or green


To judge from the image:
Yellow-green is similar to the station color and may have poor visibility.
Pink may be slightly hard to see. Could a darker color be better?
Please note that these two are basically used only for bus stops.

I don't know what inverted is for.
Bus stop restrictions are only required for bus stops. There is no reason to set this to anything other than a bus stop. It's just confusing. And, as explained above, stationary only means no overtaking on tiles other than bus stops. I think a lot of work is required to change this, such as rewriting set_overtaking_mode above.
Regarding the drawing of arrows, there is currently no prospect of what to do. However, as a temporary change, I think that measures such as making the shape simple and changing the color may be possible. It should be considered in conjunction with the tile constraint colors.

We already use that for reservations and player ownership.

The problem is not so different in any way, and I think that tile coloring may be the best.


Finally I hope you understand that this is a simple fix. I'm not familiar with these codes so I may not be able to do any further.
I wondered if I could color the tiles with, for example, "no entry sign" or "mothbold", but it seemed complicated. Coloring in overtaking mode was easy.

[Freahk]

Do you think the color of block reservation is intuitive?

Yes, it's unintuitive either and on top of it does not show most important information of a directional reservation, which is it's direction.
I do think these should be highlighted in the same way as usual reservations but with an additional arrow to show the direction. That's another issue though.

[Vladki]

Coloring tiles is a minimal change that uses existing code. There are many priority issues that must be resolved for this feature...

OK, if it makes things simpler, I'm fine with it. Much better than arrows everywhere.

[Ranran]

Yes, it's unintuitive either and on top of it does not show most important information of a directional reservation, which is it's direction.

Certainly, I agree that a blue directional reservation needs a directional indicator.
But I don't think it is easy to display it properly and properly in the current system.
1) It is necessary to properly deal with zoom out.
2) It is necessary to deal with slopes and diagonals.
3) It is necessary to support different pakset sizes.
4) It is necessary to properly deal with intersections.

If we could create a system to draw it, it could be used on both roads and tracks.


Tips:
If you find it difficult to see the road restrictions, try reducing the brightness in the display settings. The restrictions will be easier to see.


Currently, the arrow won't light up, but it will be fixed as THLeaderH said he would fix it.



I think that blue is better for the one-way arrow (A little closer to light blue to avoid overlapping with block reservation). The one-way sign in Japan is also blue.
Therefore, I chose a tile color that is not close to it.