Oneway Twoway Road Patch for the Extended

[jamespetts]

Thank you for your work on this: this is interesting. On one level, it looks better than the current system; on another level, however, it is not as obvious from the colours what system is in use as there is no pre-existing association between these colours and these behaviours.

Freakh's suggestions have some merit in this regard; I wonder what other people's views are on this?

[Ranran(retired)]

however, it is not as obvious from the colours what system is in use as there is no pre-existing association between these colours and these behaviours.

There are some changes I haven't posted yet.
1) The color of the icon text changes depending on the mode
2) Arrows will be displayed in the preview of the construction plan in case of one-way mode

1) has already been pushed to the branch.
As for 2), it is not possible to handle correctly when using shortcut keys and when roads and bridges are separated at the moment, so it is necessary to deal with it. So I haven't pushed yet.

[Mariculous]

Again an improvement, as there is an ingame association to the tool constructing the road, which is kind of on on-the-fly help page.
Still, I don't think those colors can easily be remembered (and there are already too many colors to remember in Simutrans elsewhere), so players will have to look them up. Either in the "real" hel page or by using the construction menu.

[Ranran(retired)]

What matters more is what "H" and "L" represent. Normal players can't look it up. (you may get its hint from the code). And it is not related to the word displayed in the "set overtaking mode" menu. Therefore, it is more difficult to remember than to remember colors. (In a sense, the menu description is misleading.)

Also, as I have already explained, bus stop mode selection should not be here, so we plan to separate the list. That is more intuitive.

And I wonder if Overtake stationary only mode is necessary. As already mentioned, if this can be done for free, there is no reason not to set it at a bus stop on a two way road. It just forces the player to waste extra effort. It also works as an overtaking prohibition except on tiles with bus stops as I said above.
Road vehicles will automatically be able to overtake if you meet the conditions for overtaking at the busstop.
On the contrary, if this is not set, the bus stopped at the bus stop will not be overtaken. On ordinary roads, road vehicle can overtake if it meet the conditions at where not a bus stop, but unless player set it, it will be limited. Here is the ambiguity of the specification.
When overtaking is impossible at the bus stop, I think that overtaking is prohibited. So we can remove this nonsensical mode by disabling  overtaking a stoping bus only if overtaking is set.
In that case, memorizing what the green tile and "L" represent is no longer necessary.

I may not have properly understood your request.
What you guys are saying is adding a symbol to the tool icon (and "set overtaking mode" menu)?
It's not too difficult. On the other hand, displaying symbols on the main game screen is just problematic as it is not possible to recognize the shape of the arrow when zoomed out.

[Mariculous]

On the other hand, displaying symbols on the main game screen is just problematic as it is not possible to recognize the shape of the arrow when zoomed out.

Use the same highlight color for all special road modes, so players will know "there is something special" even on high zoom levels.

Use icons to indicate the exact type of roads mode, so people can see the important information without searching the help pages.
Those icons might be hidden at high zoom levels if it turns out to be rather confusing than helpful on high zoom levels.

Instead of those letters, a mini version of these icons could be shown on the button.

[Ranran(retired)]

Those icons might be hidden at high zoom levels if it turns out to be rather confusing than helpful on high zoom levels.

As I have already explained, the reason such a method is not suitable is that it also depends on the size of the pakset. It also depends on the person who designed it. The small pakset is no longer visible after zooming a little. Large paksets may use a finer grained design to allow more design options. As a result, it is not always correct that a particular zoom becomes a boundary value.
And it must be a design that takes direction and continuity into consideration. I can't think of such a design.
For example, consider that there are 10 tiles of the icon that means overtaking prohibited. There is no reason to do so unless it is a good design that is more visible and intuitive than colored tiles. It's very bad if it just displays the same icon in 10 tiles in a row. And if it's invisible when zoomed out all the way, I think colored tiles are better.

[Ranran(retired)]

I'm afraid but what is the purpose of inverted lane mode? 

I have a question: what is the purpose of the "Inverted lane" option?  I know what it does mechanically, but what sort of real life situation is it meant to simulate, or what problem in the game is it meant to solve?  The other road types I get, but I'm scratching my head with this one.

This question has been asked by Andyh before, but it seems that no answer is available.
This mode creates an unrealistic situation by ignoring the position of the bus door, ie the relationship with the bus stop. And if we don't have this mode, we can reduce the variation of colored tiles to two. It eliminates one of the incomprehensible colors that Freahk points out.


Next, another new issue:
I noticed the following GUI display.

It is a check button of "Left" "Right" at the bottom. 

The ribi-arrow can be called from the display settings window.
Some fixes around vehicle movement.
Flags for road. "citycars do not enter" and "avoid becoming cityroad" feature.
Improvement of citycars. Citycars follows lane affinity signs and the lane yielding rule.

I guess it is one of the features in this list (perhaps last one I guess) but currently at least this switch seems not working. And this button can also be changed regardless of the owner. (´・ω・｀)

And that
1) the other features mentioned above don't seem to be implemented at least in the current extended (Looking at your previous answers, it's possible you're confusing that you implemented a feature that doesn't exist in extended.)

Are these changes acceptable for simutrans extended?

2) You just made a suggestion to Extended but haven't responded afterwards

Thinking from these two, only the switch for the feature that was planned to be implemented I suspect that is mixed in with the GUI.
@THLeaderH - I would appreciate it if you could explain about these. 


In addition to the above, I think there are some omissions of explanation.
I was looking at the code and noticed that I could set the helpfile to Overtaking mode. The help file is not currently available in extended.
I do not speak English, but you can provide a help file.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/blob/fix-overtaking-patch-issues/simutrans/text/en/overtaking_mode_frame.txt
I generated a file that was almost empty. You guys can edit it. 

2) Arrows will be displayed in the preview of the construction plan in case of one-way mode

I completed this work and pushed it to the branch.

I wonder if Overtake stationary only mode is necessary.

I integrated some modes as suggested yesterday and removed overtake stationary only mode.
Before:

mode	can overtake at busstop	can overtake at road
Two way(default)	NO	YES
Overtake stationary only	YES	NO
Overtaking prohibited	NO	NO

As already explained, there was a problem because Overtake stationary only mode works as Overtaking prohibited on tiles without a bus stop.
Therefore the green tint of the tile is actually orange. So we had to fix this somehow. So I changed it like this:


After:

mode	can overtake at busstop	can overtake at road
Two way(default)	YES	YES
Overtaking prohibited	NO	NO

This change reduces the coloring of the tile by one, reducing the need to remember colors.
I think that it will reduce the troublesome operation for the player, and the rules on the road will be simple and easy to understand.

Ideally, the ability to overtake at the bus stop is limited by the width of the road, the width of the car, the shape of the bus stop, etc. The width of the road and the cost of the bus stop affect the cost and can be linked to the economy. But I think it's a different story. I don't think there is an advantage to limiting if there is no such link to the economy. Therefore, it is better to be able to overtake by default because it does not force the player to bother.
However, it is important to note that convoy cannot overtake unless it meet multiple overtaking conditions. No oncoming convoy, no intersection near, no convoy at the overtaking point. So don't overestimate it. If there is an intersection nearby, it is the same as overtaking prohibited.

[freddyhayward]

- Two-way mode does currently allow overtaking at bus stops, subject to the usual overtaking conditions.
- I don't think realism concerning road width and bus doors are relevant, because the road can be any arbitrary width, 125m in 128.britain.
- Overtaking conditions should be as simple and generous as possible, because of this limitation.
- I agree that overtake stationary only and inverted mode should be removed because they add unnecessary comlpexity.

[Mariculous]

Inverted lane can be useful in some cases to build special types of motorway exists, though, these cases are pretty rare and I can only remember once using it, so it might just be removed.

That "left" and"right" checkboxes are a feature of the so called lane affinity sign. It does not work for private cars at all, at least that's the information I got half a year ago or something like that.
In any case, the GUI is confusing, though I don't know how to improve it.

I agree with the changes to the overtaking modes.

[Ves]

Throwing myself into the discussion, I agree that it might actually be too complex and fiddly with the "overtake stationary" and "inverted lane" (Inverted lane means that the vehicles drive at the oposite side of the road than what they usually do). At least I have never come to use them, although I could imagine they could be usefull for some people.

Regarding coloring the road tiles, I do think that coloring the way has some merit. Highlighting objects with colors is something that is well established in Simutrans, so I think this could indeed be usefull in this case as well. The colors needs to be established somewhere, though, and I think just coloring the very tiny letter (which is easily oversighted) is not enough. I would suggest that you create a color square (like you have done in the factory window), so that the player is always looking at the colors when choosing which mode to build. I do not agree with the concerns that the coloring of ways would clash with the reservation coloring, as these two display modes should not be used at the same time! Already the color red is used in multiple modes (block reservations, schedule stops, factories), so this should be no problem IMO.

I agree with the problem of the directional modes. I read in the thread that it was compared to the directional reservation made by trains, but I dont think it is a fair comparasion: Directional reservations will always be the same direction throughout the entire blue field, and the direction can be seen by clicking on the tile. The overtaking mode, however, can have two tiles next to each other, with opposite directions, and this would be very cumbersome to check EVERY tile for its correct direction. Therefore I agree that there preferably should be *something* that tells us wether we have the correct orientation, and I do have a slight experimental suggestion which features only the colors and no icons:

The default color for oneway is, say, blue or yellow.
I dont know how way tiles  with three and four directions are handled with the one way mode. Either the one way constraint affects only the entry of the tile, the exit of the tile, or both entry and exit. If the latter, it is pretty useless for three and four directional way tiles.
In either way, whenever two tiles with with the one way modes set, and the one way modes of the two tiles are incompatible, those two tiles are highlighted in red.

This way of displaying the tiles would not give you the direction of the one-way, however, this should be printed in the info window of the waytile. And with this approach, you are guaranteed that all blue (or yellow) waytiles connected to this tile, are also set in the correct direction.
If you find a red area of tiles, this means that something is messed up, and you will have to fix it. You would probably anyway resolve it by rebuild the entire stretch, instead of turning the direction of each individual wrong direction tile, hence the indidual directions are not really necesary.

[Mariculous]

This way of displaying the tiles would not give you the direction of the one-way

Please no!
Don't do the same issue as was done with directional reservations. This requires ye another unneccessary click and due to the perspective of the map, it is not clear if for example right-up is north or east.
For sue an experienced player knows it's North, any anyone else could have a look on the minimap to know this, but why shouldn't we keep things intuitive if we can?

I do not see any problem with showing arrows in addition to colors (just as I don't see any issue with showing icons in addition to colors for any other mode)

[Vladki]

For the letters and colors - just show them next to the check box like:

• - (T) two-way
  
• - (O) one-way
  
• - (H) halt/stop only overtaking
  etc. 
  Color can be either only on the letter (T,O,H,...) or as background for the whole translated text

[Ranran(retired)]

Thank you for your feedback. I have made some changes.

- Removed inverted lane mode
If we still need it, you can restore it by reverting commit number 3d0c4a63a0c7205229756f6498388ab0ae2ee138.

- Prevented changing the overtaking mode of roads owned by other player

- Players cannot change the overtaking mode of a non-destructible public or without adequate diversionary routes road.
Previously, one-way signs had similar rules. However, THLeaderH added a specification that ignored that specification. First of all, the existing sign and overtaking modes exist independently, which is somewhat difficult. Now the change to One-way mode will be subject to the same rules as one-way sign placement.
(As a known issue resulting from this issue of my patch, the road arrow and one way sign are not currently linked correctly.)

I tried to display an error when setting the overtaking mode failed, but it was too annoying and the implementation is postponed. (´・ω・｀)

Next, another new issue:
I noticed the following GUI display.

It is a check button of "Left" "Right" at the bottom. 

I delved into the behavior of this. As I guessed, this is obviously an unfinished work and just a papier-mache.
The lane_affinity flag of the sign is only called in here, there is no actual condition and there is only a comment.

Code Select Expand


// If there is one-way sign, calc lane_affinity. This should not be calculated in can_enter_tile().
if(  roadsign_t* rs = gr->find<roadsign_t>()  ) {
if(  rs->get_desc()->is_single_way()  ) {
if(  cnv->calc_lane_affinity(rs->get_lane_affinity())  ) {
// write debug code here.
}
}
}

Some variables may be rewritten in calc_lane_affinity, but at least for the moment I haven't seen this working.
calc_lane_affinity() is also used here only, but I'm wondering if it's working properly.
From the commit history, it seems difficult to identify only the part related to this. So I'm not sure how much such a thing exists, but I would appreciate any comments on this.



About review of system design:
I suspect the intersection may not need restrictions and arrows. The display of the arrow and tile coloring at the intersection is somewhat incorrect.
Coloring the intersection has no meaning. Convoy can't stop there in parallel, and of course overtaking.

- Two-way mode does currently allow overtaking at bus stops, subject to the usual overtaking conditions.

Then I can't understand why Overtake stationary only existed. (´・ω・｀)
I think the features that players expect are the ones in "Road stop improvements" here.
At first I thought that the width of the road was wide enough to reproduce a bus stop with a side road.

- I don't think realism concerning road width and bus doors are relevant, because the road can be any arbitrary width, 125m in 128.britain.

Yes, lining up two roads means occupying 250m, destroying a large number of houses, driving out residents, and occupying the city.
Regarding door issues, I just wanted to know if inverted mode makes sense.

- Overtaking conditions should be as simple and generous as possible, because of this limitation.

I agree. It is very unrealistic to be able to overtake unless there are only two cars on a few tiles, a few hundred meters oncoming cars, and only a few hundred meters. There is a horse running in the opposite direction 375m ahead, then we cannot overtake the slow horse in front. So I think the current overtaking constraint is too strict even on intercity roads. Especially in the age of carriages. There are many intersections in the city and it is almost impossible to overtaking. And as mentioned above, a four-lane road requires a great deal of sacrifice.

The colors needs to be established somewhere, though, and I think just coloring the very tiny letter (which is easily oversighted) is not enough. I would suggest that you create a color square (like you have done in the factory window), so that the player is always looking at the colors when choosing which mode to build.

For the letters and colors - just show them next to the check box like:

the very tiny letter (which is easily oversighted) is not enough - yes. It's just better than nothing. I don't like the one-letter English display. It is hard to understand the meaning. As I said before, it's not good for Japanese people, it's not universal design. (I think there are many such languages, Simutrans supports multiple languages...)
As I have already pointed out, there is a flaw in that when you select it in shortcut mode it is not visible. So displaying colored boxes there is likewise pointless. Therefore, the display is for associating the color with the display and is not always displayed and is not important. However the current characters aren't good, so I think it's a good idea to replace them with something other than characters. It may be good to have a dedicated symbol.
So I suggested showing it in preview or cursor. I have successfully added only the preview arrow.
Unfortunately, there are currently no prospects for anything else. Coloring the tiles in the preview messes up the preview because its looks is hard to see.
Displaying symbols is a burden for pakset authors. Note that the tile cursor size depends on the pakset size.  Note that the symbol for GUI is not available on the cursor or main game screen. It is best for the GUI to be close to the character size. The appropriate size of the main game screen changes depending on the zoom ratio. The tile has a width of 256px at 256size.
I think parallel stop mode can be abolished from this list because it is a bus stop mode only. It works as a one-way street only for tiles other than bus stops. So it can be moved to the bus stop icon. In that case, the mode is reduced to three - default/one way/overtaking prohibited. Then, all we need is to solve the overtaking prohibited mode display issue.
In that case, preparing a overtaking prohibited cursor may not be so difficult. For example, in Japan, the sign of overtaking prohibited is like this.

I'm sure most countries have something similar. So we add one such picture to this.

Also note that it is necessary to add a mode other than the above three that does not overwrite the mode. When laying a new one, lay it in two ways. This should be the default.

I do not agree with the concerns that the coloring of ways would clash with the reservation coloring, as these two display modes should not be used at the same time! Already the color red is used in multiple modes (block reservations, schedule stops, factories), so this should be no problem IMO.

At least red should not be used. Because it's used in the schedule as you point out.

I believe competing for it only creates a problem and has no advantage.
I often check this red display to see where the bus line is set to use on the bus terminal. When checking it, it is more convenient to be able to check at the same time what restrictions are set on the bus terminal.

Therefore I agree that there preferably should be *something* that tells us wether we have the correct orientation, and I do have a slight experimental suggestion which features only the colors and no icons:

I think you may be misunderstanding my opinion. I don't recommend erasing arrows from directional ones.
However, as already pointed out some issues, there are issues with the existing arrows, also does not match the somewhat new spec, so I am considering redesign. I'll post about this later.

[Ranran(retired)]

Also note that it is necessary to add a mode other than the above three that does not overwrite the mode. When laying a new one, lay it in two ways. This should be the default.

I added this feature and pushed it to my branch.
Currently this mode is labeled "default". We need to modify it to a proper expression together with "two way (default)".
That is, "two way (default)" is no longer default. The default value for road laying is two way, but overwrite mode is not the default.
The "two way (default)" designation in the mode select window looks strange and dishonest.
I would appreciate any feedback on this.

[Mariculous]

Wouldn't it make more sense to select the construction mode "override" or "retain" independantly of the road mode?
In principle it could be useful with any of the road lane modes.

In fact, I wouldn't expect the construction of new roads to change the mode, except if I am force-building.
That means, it might be an option to couple this behavior to ctrl-build.

I'm sure most countries have something similar. So we add one such picture to this.

Overtaking prohibited is an a real-world roadsign either, so we could use that sign.

That's the UK version of it, which is roughly the same all over Europe.

[jamespetts]

Thank you for all your work on this: this is very helpful. I agree with removing the inverted lane mode - there is only one road in the UK where driving on the right is the standard, and that is the very short road forming the entrance to the Savoy Hotel in London. I do not think that we need to replicate this in Simutrans-Extended. The removal of the overtaking stationary only mode is also sensible as it is not clear what problem that this solved.

The fixes to prevent players altering the one way status on other players' roads are definitely helpful - thank you for these.

As to the UI, it is definitely better to have the arrows displayed only on one way roads: this is much clearer, and makes one way roads much easier to find. It is also helpful to use the pink and orange to demarcate the special settings of parallel stop mode and overtaking prohibited mode. It would further be helpful to have the suggested icon in use here at the cursor (and possibly on the road itself over the orange) to designate that overtaking is prohibited.

One thing that I notice that will need to be changed is that there are two separate entries for the two way mode: one marked as "Two way (default)" and the other marked as "default". It is not clear why this should be and I suggest simply removing "default".

I am also not a fan of the letter, although the letter with a colour is better than the letter without a colour. Ideally, one would have a symbol (1) on the cursor; (2) in the set overtaking mode menu; (3) on the individual road tiles when the overtaking mode overlay is enabled ; and (4) on the active road icon for each type of mode bar the default two way mode, for but I can understand if this is too much work. Because these symbols would be cross-referenced to text describing their meaning in the only place where one can invoke the display of this symbol on one's own roads, there should be no danger of players coming across this symbol and not understanding what it is.

As to the actual mechanics for overtaking, it would be better to separate the discussion of that from the discussion of the UI, or else it will be very hard to follow the thread. I wonder whether we should separate the UI discussion into its own thread?

As to directional reservations on railways, it would certainly be a nice feature to have arrows in addition to the blue colouring, but I do not consider this as a priority at present as it is less important for players to know the current directional reservation of railway track than to know the permanent setting of a one way road, as the former is automated whereas the latter is player controlled.

In any event, thank you very much for your work on this, Ranran - it is much appreciated.

[Ranran(retired)]

One thing that I notice that will need to be changed is that there are two separate entries for the two way mode: one marked as "Two way (default)" and the other marked as "default". It is not clear why this should be and I suggest simply removing "default".

The reason for adding this is as described in above post.

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.

Also note that it is necessary to add a mode other than the above three that does not overwrite the mode. When laying a new one, lay it in two ways. This should be the default.

I added this feature and pushed it to my branch.
Currently this mode is labeled "default". We need to modify it to a proper expression together with "two way (default)".
That is, "two way (default)" is no longer default. The default value for road laying is two way, but overwrite mode is not the default.

"default" is a temporary name. It needs to be changed. In this mode, settings are not actually overwritten. It is troublesome to set the mode again when upgrading the road. This mode is selected by default, and if you are laying a new road, it will be laid in two way mode. Select an existing two way mode if you want to overwrite the road with two ways.

"override" or "retain"

Freahk made the above suggestion about this mode name.

[jamespetts]

Ahh, I understand - the name "default" was misleading. I suggest a different type of control for this, since it does something different to the others. What we want is a control that keeps whatever is the existing one-way mode when upgrading, but uses whatever of the others is selected for new roads. The name of this additional control should be "do not change the mode for existing ways".

[Ranran(retired)]

Fixed the mode name as suggested by James.
I think this solves some of the many problems. I'm going to break fixing work. All other changes are complex and time consuming. As mentioned above, the size of symbols/icons is different for GUI and cursor, one is scalable.
Treatment of non-functioning GUI and code-There are many unknowns without waiting for THLeaderH's reply.

I hope that those who want to solve other problems can solve them.

[jamespetts]

Excellent, thank you very much. Now incorporated.

[Mariculous]

I like the patch, but it was very bad timing to combine it with the restriction to change the overtaking mode of existing ways.
The patch caused or pointed out many places where the mode is set wrongly and we cannot fix those places, because of the new restriction.
I'd kindly ask to remove that restriction, at least for some time, so those places can be fixed.

Another thing I'd like to mention is that the diversionary tiles should be increased pretty much, otherwise cut-and-cover constructions will be effectively impossible, but I guess that's not related to this patch.

[jamespetts]

May I ask for more detail as to the issue as to the problem with the overtaking mode on existing ways? Is this in the Stephenson-Seimens server?

[Mariculous]

No, it's in Bridgewater.
There are non default road modes in many places where these do not belong.
For example, in Telbourne there is a oneway road bridge that should be twoway, in Fleckwater at the dock, there had been a mistaken "Parallel stop mode" road tile, which caused "no route" to all vehicles using the staging inn and the only way to fix this involved killing the inhabitants of the houses at the coast.

Independantly of this, the lack to remove most PROW ways will now cause the need to kill many further people.
I would really appreciate a much higher max diversion value until a better solution is implemented.
It will still ensure its key purpose, which is ensuring that players do not cut the connection between two towns.

Edit: The inability to update the mode of roads will cause significiant issues with the automatic road connection feature of industries!
New industries will simply destroy motorways and players won't be able to fix it.

Please undo this restriction until we have a proper solution for those two major issues. I cannot imagine anyone will be interessted in maintaining motorways in the future under these circumstances. Well, at least I am not.

[jamespetts]

The problem is that there are equally bad consequences to removing the restriction, as players can then block public rights of way. As to motorways, these are generally not public rights of way; do these end up being taken over by industries and converted to public rights of way? If so, this is an exceedingly complex issue, and no simple solution is likely to make things any better overall.

[Mariculous]

Trying this out, I have noticed that road connections are not built at all with a new industry, so this is not an issue anyway.
Though, I am wondering why that was disabled?
Checking stephenson-Siemens, where player roads were obstructed by industry generation in the past, the afected stretches of road had been converted to PROW with roads mode being changed to bidirectional.
We had fixed this as it was still posible, but with the new restrictions, we will effectively get broken motorways that nobody can fix anymore.

The likely easiest soltion to this is using the "keep mode for existing ways" when building those automatic roads to prevent the AI from being obstructive.
This might lead to situations where the newly built road cannot be used on stretches, but this can be fixed by players whilst the former cannot be fixed.
Alternatively, I guess it's the better solution, disallow the AI to connect to anything other than "Two way (default)".

The "please provide an adequate diversary route" issue can be fixed by simply setting the max diversion tiles to a higher number. It will then still protect connections in between towns from being cut entirely.
That's an interims solution, though until there is a proper solution adjust existing roads without cutting them.

The situation as-is prevents players from being obstructive, which they usually are not anyway, whilst adding automatic very obstroctive behavior to the program code.
That is really a much worse experience imho.

[jamespetts]

I am afraid that I cannot reproduce the failure of newly built industries to build roads. I should be grateful if you could post a new thread with a reliable reproduction case of this error, as this is a separate thing to the matters discussed on this thread. Thank you.

[Mariculous]

I'm afraid I can't.
All i did was creating a new game with one city and placing new industries using the "increase industry density button". New industries spawned, but they were not connected.
So I loaded a stephenson-siemens save and did the same with the same results.
I did nothing special, so if it works for you, I have no idea what's going on.

[jamespetts]

I am afraid that I have not been able to reproduce this: virtually all of the industries that spawned when I tested this were in towns and immediately adjacent to existing roads. The one occasion when an industry out of town spawned triggered a crash in unrelated code which I believe that I have now fixed, but I have been unable to test this since no industries other than those in towns and connected immediately to existing roads have been spawned since the first test run.

When I tested with a freshly generated map in 1750, however, new industries routinely appeared outside towns and were connected automatically by road. That was how I tested the change of preserving the one way mode of underlying ways as now implemented.

[freddyhayward]

The problem is that there are equally bad consequences to removing the restriction

These consequences are not equally bad: without, players had the ability to obstruct others, but almost never chose to use it, and could be easily reverted. Now, anomalies are frequently obstructing players, and players cannot do anything about it. The latter is far worse.

[freddyhayward]

The restriction introduced is highly flawed: it uses the existing public right of way system that checks whether a road could be deleted. It does not check whether the route would be altered more than the acceptable diversion length, nor whether it would be altered at all. This creates a perverse situation where improving a route by changing one-way roads to two-way is prohibited.

[freddyhayward]

I am experiencing guaranteed desyncs on bridgewater-brunel after a vehicle departs through a road after its overtaking mode has been changed since this patch.

[Phystam]

I also observed probably the same desync issue on my server. When I change overtaking mode (using public player), desync occurs after a while. Re-joining after the desync, the overwritten overtaking mode has not been applied.

[Ranran(retired)]

I think some points are incorrect. Many "illegal" one ways can be removed with one way. It has a problem with intersection handling, but this is a problem with the original patch.
So in this example, the intersection is eliminated first.


You may find that there are unnatural one ways here and there. But it may be working like a two way. That too is an original issue.
And, as I have already pointed out, the arrow design is flawed.

1) You can remove the arrow from the one way tile in some case.
It is possible to create many examples where the arrow is not displayed on the tile even though it is one way.
2) I don't know if the arrow is two or one
For example, something like this could be created before my patch. My patch just made it easier to identify.


This means that it is virtually impossible to enter this intersection. But so far this was recognized as a 2-way display.
The way it should be is that the two arrows pointing to the two lanes face outward.

The opposite - you can also remove the arrow from the intersection.

This suggests that it may be better to color the tiles, even the usual one way. (At least until the arrow becomes sane)

And note that the problems that are currently pointed out to have created the situation by ignoring the limits in most cases with loose limits. I wonder if we can create the same situation again.
In other words, in order to create a new one way that cannot return one way to two, it may not be easy to create under the current specifications. But at least there are big problems at intersections.
I'm in favor of being able to turn one way back into two ways. In that case, the owner's check is sufficient.

Re-joining after the desync, the overwritten overtaking mode has not been applied.

I think this is a big clue, but I'm not sure.

[freddyhayward]

I figured out exactly why: you put the player checking logic in strasse_t, a class that does not and should not know which player is trying to edit it - this logic should be handled by way_builder_t which has access to player_builder. You used welt->get_active_player(), which returns a different result for every client, leading to desync.
edit: I hope I didn't project a harsh tone. It is not your fault for being tangled in the existing spaghetti code.

[jamespetts]

In relation to the restriction, I had stated in a different thread (it is rather difficult to manage when the same issue is discussed in multiple threads) that I have now prevented roads built by industries from altering the underlying overtaking mode, which should deal with those concerns.