Shortcut for fixing all round about rules in one click

[kianzarrin]

people use a lot of roundabouts in their cities. the vanilla roundabout can get a massive boost if pimped by traffic manager. while the roundabout mod automatically adds TMPE rules when creating them, I still want to be able to add traffic rules after creating roundabouts for example because I might modify my roundabout or I am trying to fix other peoples cities.
I am planning to add a simple shortcut to fix all the traffic rules for a roundabout with one click.
I prefer to avoid adding a roundabout tool to traffic manager. I think its best to use the already existing junction priority tool. select the tool and then press alt+shift+click on a round about to do all of the following:

• give way entering the roundabout
• enter blocked junctions if you are already on the roundabout
• enter blocked junctions if you are entering the roundabout
• separate turning lanes on the roundabout
• choose lanes when entering the roundabout in cases where highway rules apply.
• no lane changing in the nodes in the roundabout (using lane connection tool).
• etc
  I also wish to add options so that people can individually choose any of these features.

[kianzarrin]

please assign to me.

[kianzarrin]

I am thinking that I can write code that auto detects a roundabout when we use priority tool>shift+click

[krzychu124]

I am thinking that I can write code that auto detects a roundabout

That will be the hardest part :)

[originalfoo]

Random thoughts:

• Assuming roundabouts are always 1-way roads, that could help filter out some segments at junctions?
• There is also the curvature of roundabouts - given a starting segment, and knowing which side traffic drives on, you could perhaps use that to help identify segments that are part of roundabout?
• Not all roundabouts are round; some have strange shapes such as being more oval, etc.
• I've seen several instances - both in-game and in real life - where two roundabouts connect to each other. In real life, good examples can be found by googling "magic roundabout road".
• Sometimes nodes on roundabouts can have traffic lights on some or all of the entrances to roundabout.

As an example of something that might prove difficult to detect, take this concoction from a city I'm currently making:

It started out as two roundabouts (one around the train station, and one around the park) which were merged together, sharing a straight section of road (between park and station). I've since changed some of the road around station to two-way to make traffic more fluid, but the 'oval-about' around the park is still one-way and acts as roundabout.

In cases where roundabouts can be detected, it would be good if the segments could be highlighted to give some visual confirmation to user as to which part of their road network will be affected.

However, it might also be beneficial to have an option to allow users to define which segments comprise the roundabout. For example, here I've used routes tool to turn the roundabout in to a named route:

As for what happens at the junctions:

• I assume you mean "yield" when entering the roundabout (ie. if no oncoming traffic the vehicle doesn't have to wait, unless there is a traffic light without an active 'turn on red').
  • It would be worth checking that the 'Yield' sign interacts properly with 'enter blocked junctions' in this scenario
• For junctions with traffic lights, could possibly have two mod options in an "At roundabouts" section on the Policies tab in mod options:
  • Vehicles leaving the roundabout can turn on red
  • Vehicles entering the roundabout can turn on red
• Separate turning lanes are good, but there also needs to be opportunities for vehicles to change lanes within the roundabout (depending on size and complexity, and whether there are nodes between junctions, etc).
  • Could possibly just limit to 1 lane change per node? (in other words: vehicle can move in to adjacent lane if desired)

Possibly related issues:

Tagging #472 , #73 , #424 , #41 (comment)

[kianzarrin]

@krzychu124 @aubergine10
Guys take it easy! TMPE already can find a roundabout! look:

[kianzarrin]

@aubergine10
The objective of this issue is to setup traffic rules for common roundabouts with one click and save time. I will be using already existing features of TMPE. Adding more features to TMPE should be under a different issue. rare and exceptional situations can always use manual tweaking of traffic rules using TMPE. That said I am all for adding cool features. but it should be done under different issue.

It would be worth checking that the 'Yield' sign interacts properly with 'enter blocked junctions' in this scenario

I use a lot of roundabouts with the rules I have suggested so I am certain yeild +enter blocked junctions works just fine in this scenario. :)

For junctions with traffic lights, could possibly have two mod options in an "At roundabouts" section on the Policies tab in mod options:
Vehicles leaving the roundabout can turn on red
Vehicles entering the roundabout can turn on red

I don't think adding traffic lights to roundabout is a good idea. In any case I think you might have misunderstood me. What I intend to do is to shift+click on the round about to setup common traffic rules for a normal roundabout. Why should it add a traffic light? You can of course add traffic light manually using TMPE. TMPE junction restriction tool can allow you to do right turn on red if you like.

Separate turning lanes are good, but there also needs to be opportunities for vehicles to change lanes within the roundabout (depending on size and complexity, and whether there are nodes between junctions, etc).
Could possibly just limit to 1 lane change per node? (in other words: vehicle can move in to adjacent lane if desired)

In options you can define which one of these rules you like and which one you don't like. I personally don't like changing lanes in roundabout in this game. I don't think cars change more than one lane anyway. Just to be clear I am taking about changing lane on nodes without junctions and two segments with same number of lanes. and I intend to achieve it by using the lane connection tool.

[kianzarrin]

@aubergine10

it might also be beneficial to have an option to allow users to define which segments comprise the roundabout.
Wow that's a good idea. Never though of that. This is what TMPE does already.

Not what you wanted. I will raise another issue to fix this. I prefer to keep my changes small.

[kianzarrin]

@aubergine10 Before raising the issue about road segments I need to give this some though. But if you like you can go ahead and do the honors :)

Edit: created #542

[kianzarrin]

@aubergine10

it might also be beneficial to have an option to allow users to define which segments comprise the roundabout.

By the way its possible to use #541 #537 on a roundabout to setup rules for each junction individually and that mostly does the job :)

[kianzarrin]

#7 is also related to this

[kianzarrin]

A bit of progress on the roundabout rules.


TODO:

• highways chose lanes when joining highway roundabout.
• provide user options.
• only traverse oneway paths.
• roundabout detection

My code is here: https://github.com/kianzarrin/TMPE-kian/tree/PriorityRoad

[kianzarrin]

only traverse oneway paths.
roundabout detection

For these features I may need to modify the traverse function to use one more input and output variable.

I wonder how hard is it going to be to write a breadth-first traversal functions that trims path that don't form a loop.

[kianzarrin]

I wonder how hard is it going to be to write a breadth-first traversal functions that trims path that don't form a loop.

Its just going to be like breadth first search of binary search tree. I just have too keep pointers to parent.

[kianzarrin]

Ok I have arrived at a dilemma:
Traverse all one directional roots that form a loop and:
A) prefer shortest path (Red Paths)
B) prefer straight path (Grean Paths)
C) Only go straight ( works with a normal roundabout but none of the ones bellow ).

What should I do? choose option C which is full proof but not inclusive leaving strange roundabouts to issue #542 ? or choose option A or B that are more inclusive but may suggest strange paths that the user can see by looking at the highlight?

I personally prefer option A. But I need other peoples opinions before I can progress with this.

[kvakvs]

How about a shortest loop of the same road type. If the user changes road type to a smaller or larger road and breaks the loop, its on them to fix it manually. In your top picture, there is no roundabout with a single road type, so it should not be detected as such.

[kianzarrin]

@kvakvs
The problem with the same road type restriction is that in many cases people reasonably change the number of lanes in the round about like bellow:

[kianzarrin]

after giving it some though I changed my opinion (lol I cannot make up my mind!) to option "B) prefer straight path (Grean Paths)".
If the user ALT-clicks over specific part of the roundabout that he wants to be covered it will work in all cases above. There will be super weird cases in which it won't work but that's on the user.
besides TMPE already gets confused in exceptional cases:

Option C has the advantage of making the code much shorter though.

[kvakvs]

B makes no sense at all, it extends onto the highway, i do not want highway be modified, if i am only doing a roundabout. Just prefer the same type road. Also maybe you can also query the Game Engine and get the road assigned the same street name somehow.

[originalfoo]

I created mass edit options tab

We can't add more tabs. Some languages (*cough* German, Polish...) have long words. We already had to simplify tab names to make everything fit so adding another tab is a non-starter IMO.

We should instead make tabs scrollable so they can fit more options. (Look at code for mod compatibility checker to see how to do scroll panels).

The options depicted ( #539 (comment) ) all look like they belong on Policies tab, in an "At roundabouts:" section maybe?

[originalfoo]

Some more thoughts:

• Mod options shouldn't "negate" (it's confusing in some cultures if activating an option has the effect of deactivating something). If I turn an option on, something should be turned on, not off.
• When mass changes are being made via user interaction, we need visual feedback to show where (or, ideally, what) changes are being made:
  • At simplest level this could be highlighting the segments (and nodes?) on the 'route' that will be affected
  • Better still, would be show relevant overlays depicting the end result
  • Visualising what will happen before user applies it gives user confidence to apply it
  • In cases where it gets route wrong (for whatever reason) I might still choose to apply and then make some manual corrective adjustments
  • Visualisation will help with any future bug fixing and enhancement work
• In terms of visualising the roundabout customisations, which comprise multiple TM:PE tools, there are, I think, two viable approaches:
  1. Just turn on the relevant persistent overlays - less work, but they will show customisations for everything on screen, which could be confusing to users. However, this could cause some lag because we've not fully optimised those overlays yet. Each overlay builds a list of all segments/nodes on the map (as applicable to the overlay), then filters that list to stuff that's currently within camera view, then checks if any of that stuff has customisations that differ from defaults, then renders it.
  2. Considering we know specifically which segments/nodes will be affected, maybe we could refactor the overlays so they get passed in a list of segments/nodes (as applicable) to process. This would cut out all the "scan whole map, work out what's on screen" stuff, and potentially lay some foundations for future optimisation (namely: caching) of what's in camera view for the normal use of overlays?
• If TM:PE gets this new feature, configurable in mod options, we should provide an API for "Roundabout Builder" mod to use
  • Roundabout builder can provide a list of segment id's that comprise the main roundabout (so TM:PE does not need to guess the route)
  • TM:PE then applies the user-configured roundabout settings to those segments, the nodes between them and any entry/exit segments (Roundabout Builder no longer needs to worry about all the minutiae of the different TM:PE features, it just says "here's a roundabout, work your magic")

[kianzarrin]

@aubergine10 I already turn on relavant overlays. if you hold ctrl then relavant overlays are turned on. Also ofcourse the round about is highlighted when holding shift. My code is in github so you can take a look.i upload my latest version tomorrow.

[kianzarrin]

Wow look at this cool implementation of magic roundabout:

and another type of roundabout: https://www.google.co.uk/maps/@51.8845308,0.9327983,122m/data=!3m1!1e3

I will see how my roundabout mass edit feature works out here.

[originalfoo]

I think there are some of those in workshop. Here, try some of these ready made intersection assets :)

• https://steamcommunity.com/sharedfiles/filedetails/?id=1910302061
• https://steamcommunity.com/sharedfiles/filedetails/?id=1910417290
• https://steamcommunity.com/sharedfiles/filedetails/?id=705074476
• https://steamcommunity.com/sharedfiles/filedetails/?id=877114598
• https://steamcommunity.com/sharedfiles/filedetails/?id=884787937 - bidirectional roundabout lol
• https://steamcommunity.com/sharedfiles/filedetails/?id=1266280103
• https://steamcommunity.com/sharedfiles/filedetails/?id=622616395
• https://steamcommunity.com/sharedfiles/filedetails/?id=561554476 - requires NExt2
• https://steamcommunity.com/sharedfiles/filedetails/?id=852984562
• https://steamcommunity.com/sharedfiles/filedetails/?id=829552245
• https://steamcommunity.com/sharedfiles/filedetails/?id=1907883944
• https://steamcommunity.com/sharedfiles/filedetails/?id=1908121926 - I think this is the one from your google earth image! Requires several mods/assets to use.
• https://steamcommunity.com/sharedfiles/filedetails/?id=596679166
• https://steamcommunity.com/sharedfiles/filedetails/?id=643466950
• https://steamcommunity.com/sharedfiles/filedetails/?id=535467797
• https://steamcommunity.com/sharedfiles/filedetails/?id=779009510
• https://steamcommunity.com/sharedfiles/filedetails/?id=878101221 - requires NExt2
• https://steamcommunity.com/sharedfiles/filedetails/?id=1329382648 - requires NExt2

I'm still searching for another very unique roundabout from some years back, but the list above should give you some nightmares for now :)

[originalfoo]

Still searching for that other roundabout but found this on my travels which might be worth trying out in-game:

[originalfoo]

Still not found the one I'm looking for, but another to test:

https://steamcommunity.com/sharedfiles/filedetails/?id=662904182

Lots of very short roads between junctions, will likely cause problems with UI or even the various tools.

[originalfoo]

This is the crazy roundabout I was trying to find: https://steamcommunity.com/sharedfiles/filedetails/?id=467233288

[originalfoo]

Sp3ctre18 is doing some interesting roundabout designs which can be found in this collection:

https://steamcommunity.com/workshop/filedetails/?id=1762964190

[kianzarrin]

@aubergine10
My roundabout detection algorithms works with most of those crazy roundabouts.
In every case my roundabout detection algorithm is successful, All the traffic rules are setup properly.

As said in #539 (comment) I prefer to upgrade the roundabout finding algorithm in second phase of this issue (or should I open a new issue?). @brunoais I can see now that there is certainly a demand for it. #542 is an alternative solution to the problem.Regardless I prefer to make the roundabout traversal algorithm more clever.

Here are some screenshots:

[kianzarrin]

@kvakvs Do I need unit tests here?

[originalfoo]

I notice there's some cases where there's only one entry road to a junction, and the entry is given priority.

Does this incur performance impact over just leaving the junction as vanilla setup?

[kvakvs]

@kianzarrin You don't need them to release this work, but if you find a way to test this in some reasonable non-complicated way, absolutely do it.

[krzychu124]

Does this incur performance impact over just leaving the junction as vanilla setup?

@aubergine10 It shouldn't but I'm curious why is this even possible?

[kianzarrin]

Does this incur performance
@krzychu124 It shouldn't but I'm curious why is this even possible?

It's what the code does. To avoid it we can check for node onewayout flag

[originalfoo]

It's what the code does. To avoid it we can check for node onewayout flag

Well, priority signs are about entrance to junction, not leaving junction.

So, specifically, we should ideally disable priority sings on junctions that have one way IN, as that one way in has no competition (and thus no need for priorities to be set).

[originalfoo]

Just a random thought: Looking at some of the glitches identified in the test images (great work btw!!) would it be worth having something that classifies as segment as "clockwise, anti-clockwise, or bidirectional"?

That way, if the starting segment is clockwise travel direction (such as roundabout on LHT cities), for example, it would make it easier to filter adjacent segments if, in relation to previous segment, they are going clockwise.

If starting segment is bi-directional, then pick a direction relevant to city setup: LHT = clockwise, RHT = anti-clockwise, and follow that curve?

Rough mockup: based on direction of traffic (on current segment) entering a node, and knowing if clockwise vs. anti-clockwise, could something like this work?

Example above would be for clockwise travel. So one line is "straight ahead", the other is at some angle of tolerance, and any outgoing segment in between would be considered candidate for "continuation of the road in the (anti)clockwise direction".

[kianzarrin]

Just a random thought: Looking at some of the glitches identified in the test images (great work btw!!) would it be worth having something that classifies as segment as "clockwise, anti-clockwise, or bidirectional"?

I can't see how to implement the clockwise direction thing since the code is not aware of the bigger picture when its focusing on one segment. I have some simple ideas to fix it

• currently i check if currentSegment =! initaialSegment && segmentList.constains(currentSegment) then its not a roundabout. A better check would be if nodeList.Contains(CurrentSegment.headNode)
• Instead of following a preferred direction (forward) follow all possible paths in all directions. if the path is not a roundabout then discard it. among the paths that are roundabout I choose the one that has the list amount of left/right turns within the roundabout. if the number of turns are equal then choose the shortest paths

[kianzarrin]

I now check for nodeList.Contains(CurrentSegment.headNode) instead of segmentList.constains(currentSegment) Didn't solve the problem but made it a little bit better. No more zig zags.

before

After