State machine for separate turning lanes.

[kianzarrin]

In #537 I implemented lane arrow separator to allocate dedicated turning lanes. The lane distribution is according the the number of turning lanes in each of the directions⬅️ ⬆️ ➡️. A more preference is given to the left and less preference is given to the right.

Now when segment has two lanes you automatically separate lanes to(right hand traffic): ⬅️ + ⬆️ || ➡️. This is good for quick-setup of timed traffic lights.
I think it would be nice to be able to switch to ⬅️ || ⬆️ + ➡️ after another alt+click on (#538 (comment) ). This would be good for a different setup kind of timed traffic light .

because of a bug the LHD is the opposite way around (#564 (comment) ).

The state machine can also dictate how the lanes are distributed. should we give preference to left in one state and preference to forward in another state? should this be in options menu? or should we keep things simple?

[kvakvs]

State machine and example implementation of new Lane Arrows you can find here #391 . SM is just 1 module to drop into your TM:PE project.
The FSM (finite state machine) module is here https://github.com/kvakvs/Cities-Skylines-Traffic-Manager-President-Edition/blob/canvas-gui/TLM/TLM/Util/GenericFsm.cs
The usage is here https://github.com/kvakvs/Cities-Skylines-Traffic-Manager-President-Edition/blob/canvas-gui/TLM/TLM/UI/SubTools/LaneArrows/LaneArrowTool.cs

[kianzarrin]

State machine and example implementation of new Lane Arrows you can find here #391 .

Wow! That's so cool. In any case my FSM is mutually exclusive and is for the quick-edit feature.

[originalfoo]

A more preference is given to the left and less preference is given to the right.

Using terms "left" and "right" will cause confusion due to different sides traffic can drive on (LHT/RHT, or RHD/LHD). Elsewhere we came up with following driving-side agnostic terms:

• Nearside -- the left or right direction a vehicle can turn without crossing oncoming traffic
  • Example: The side you would exit on the highway
• Farside -- the opposite direction to near side

When applying state machine it might be useful to think in those terms, rather than driving side specific "left/right".

For example: On a map where vehicles drive on the left, the nearside lane would be the left lane. The most common turning lane will likely be the nearside lane. In UK that would be left lane, in US it would be right lane.

[kianzarrin]

from #671 :

From steam user adam.ruscoe:

Not seen this noted as an "issue" on the thread as yet...
I love the ctrl click set everything to one lane per action, but on a two lane each way section, with driving set to the right hand side the mod currently sets the right hand lane as turn right, with the left hand lane being turn left and straight on.
Given than on a RHD road where you have priority you may have to wait to turn left, but don't wait to turn right or go straight on this seems incongruous with how it is mostly laid out in real life (and how I always lay out my cities in game)
Admittedly I've literally just downloaded it and come across this so there may be a setting somewhere I've missed, but as a default I can see that causing more issues than less.

Issue reported for STABLE v11.0
I've asked for screenshots and any other infos to be posted here.

[kianzarrin]

1. When you are trying to open interlocking traffic jams its best to get as many cars out of the way as possible. turning right is easy so let's get rid of those cars first.
2. Argument can be made that turning left is hard and going straight or turning right is easy so its better to do that first. I admit this is how it normally works in the world so I should probably made this one the default.

Its hard to know what to do when you have only two lanes but three directions! We really need a state machine.

[originalfoo]

Generally with 2 lanes and 3 directions I'd have the turning lane go the way of the near-side turn.

Maybe an Alt key modifier that tells the applicator to use far-side lane instead?

[kianzarrin]

@aubergine10 so you didn't like the state-machine approach?

PS: now I remember why I made that decision! its particularly good for timed traffic lights to have extra right turn cycle.

[originalfoo]

I think a state machine is required, it will help keep code sensible.

[kianzarrin]

• if the number of source lanes is more than 3 and not multiple of 3, priority to have more lanes is: far turn, forward, near turn. (far turn is slowest so it gets more turn, in TTL near turn is green for 2 steps, so it needs less lanes)
• if there are 2 source lanes, I do the opposite: near turn gets dedicated lane. (to get extra turn at TTL)

The question is in the lane arrow tool how the step machine should work?
approach 1:
state 1: TTL recommended (2 lanes: naer-side priority | 3+ lane:s Far-side priority)
state 2: alternate TTL *(2 lanes far-side priority | 3+ lanes forward-priority)
Ignore this if number of lanes is multiple of 3 on all node segments.
step 3: clear all values to default (or undo #568)

• alternate TTL is when far turn gets a dedicated step, then straight and right are bundled together.

approach 2:
state 1: 2+ lanes => far side prioirty
state 2: 2 lanes => near side priority | priority 3+ lanes =>forward priority.
Ignore this if number of lanes is multiple of 3 on all node segments.
step 3: clear all values to default (or undo #568)

Approach 1 is more consistent if you have TTL while approach 2 is more consistent if you don't have TTL.

which one should I go for?

[originalfoo]

Can we let user cycle through options?

For exmaple, if user gets far side turning lane, but they wanted nearside, they just repeat the applicator to get it's alternate result?

Similar to how Shift+S on lane connectors will cycle a segment node through a) all lanes ahead only, b) one side ahead only, c) other side ahead only

So an applicator starts with what it thinks is best, but if there are alternatives user can just repeat it to cycle them. Or add an Alt modifier to the applicator to alter it's decision making.

[originalfoo]

Also, regarding the recent report linked above (#671) I don't think user was using TTL on that junction they were testing with.