Displaced lane support in traffic lights

[Elesbaan70]

I have been working on how to add displaced lane support to timed traffic lights. There is code in my fork, but I plan to abandon the current branch and start fresh with the knowledge I've gained so far. Before doing that, I'd like to share what I have so far and get feedback to incorporate into the final version.

This first message will just cover the functionality I have in mind. I'll get into the implementation in later messages.

I have two use cases for displaced lanes. If anyone has more, let me know!

Use Case 1: Displaced Left Turn

Also known as a Continuous Flow Intersection

Use Case 2: Turnaround Lane

A slip lane that connects pairs of one-way roads to facilitate U-turns

Not a Use Case: Diverging Diamond Interchange

The current traffic light code already supports the diverging diamond interchange, because it does not mix standard and displaced lanes on a single segment.

Functionality Needed

Entry into and exit from displaced lanes needs separate traffic light regulation for these scenarios:

• In advance of a Continuous Flow Intersection, traffic crossing over into the displaced left turn lane needs separate control from traffic remaining in standard lanes. This divides forward-moving traffic among multiple lights.
• After a Continuous Flow Intersection, traffic going straight starts out displaced and crosses back to the standard side, for which it needs separate control from the right-turn slip lane. This divides forward-moving traffic among multiple lights.
• At an intersection with a turnaround lane, the left turns into and out of the displaced (turnaround) lane need separate control from the standard left turns. This divides left-turning traffic among multiple lights.

A theoretical condition exists where right-turning traffic turns into or out of a displaced lane. I have not found a useful example of this, but support will probably come naturally since we have to support left-hand traffic.

Proposed Timed Traffic Light Enhancements

Modes

The following modes are currently supported:

• Simple - All directions are controlled together.
• SingleLeft - Left is controlled separately.
• SingleRight - Right is controlled separately.
• All - All relative compass directions (ArrowDirection) are controlled separately.

The proposal is to add the following modes:

• DisplacedTurn - In addition to all relative compass directions, displaced left and right turns are controlled separately.
• Crossover - In addition to all relative compass directions, forward-moving crossovers (but not displaced turns) are controlled separately.

DisplacedTurn Mode

A displaced turn is a left or right turn which either leaves or enters a displaced lane.

In DisplacedTurn mode, the following lights can be controlled. Note that the lights are ordered differently depending on driving direction.

Right-Hand Traffic	Left-Hand Traffic
DisplacedLeft	Left
Left	DisplacedLeft?
Forward	Forward
DisplacedRight?	Right
Right	DisplacedRight

Displaced turns in the direction that is normally a near turn are a questionable use case. On the other hand, there seems to be no reason to omit it, other than to simplify the UI.

Crossover Mode

• A crossover is when traffic enters, leaves, or continues in a displaced lane without turning.
• A left crossover, in right-hand traffic, is when traffic enters or continues in a displaced lane.
• A right crossover, in right-hand traffic, is when traffic leaves a displaced lane.

For left-hand traffic, the definitions of left and right crossover are reversed.

In Crossover mode, the following lights can be controlled. Note that the lights are ordered differently depending on driving direction.

Right-Hand Traffic	Left-Hand Traffic
Left	Left
LeftCrossover	Forward
RightCrossover	LeftCrossover
Forward	RightCrossover
Right	Right

Mode and Light Availability

Availability of the new modes and lights in the UI would be based on the presence of displaced lanes in the involved segments.

Additional Notes

This enhancement affects only the operation of timed traffic lights. It is intentionally limited in scope, and does not impact any other aspects of TMPE's operations except when necessary to facilitate traffic light operation.

[Elesbaan70]

ArrowDirection vs. LaneDirection

The basic change that will make displaced lane support possible is to create a new LaneDirection enumeration, which will replace ArrowDirection in traffic light code. This will allow the traffic light code to understand traffic movements other than simple directionality.

    public enum LaneDirection {
        None = 0,
        Left = 1,
        Forward = 2,
        Right = 3,
        Turn = 4,
        DisplacedLeft = 5,
        LeftCrossover = 6,
        RightCrossover = 7,
        DisplacedRight = 8,
    }

I have already performed a trial run of creating and using such an enumeration, and in my testing it worked well. It should allow all code not concerned with traffic lights to operate just as it always has.

Traffic Light related API and internal methods that calculate this value will need to accept source and target lane indices. The affected code already has this information. Most Traffic Light APIs that use ArrowDirection will be replaced and deprecated. Edit: Existing API methods will not be affected unless a new mode is used, in which case they will interact with it the best that their limitations allow.

[Elesbaan70]

Would flags be better apporach?

I thought about a flags-based approach, but it doesn't fit as well as you might think. For example, I think that in your approach a left crossover would be expressed as Left|Crossover, but this is an invalid representation because a left crossover is actually a forward movement, not a left turn.

My initial run at this even had displacement and crossover as flags overlaid on the directional values; but it got weird and messy, so I intend to abandon that idea. Also, having sequential numbers will facilitate putting the light states in an array instead of having a proliferation of properties in CustomSegmentLight that have to be managed individually.

    TurnOnRed = 1 << 7,
    Box = 1 << 8, // only enter junction if exit lane is clear/flowing

LaneDirection is about what movement is occurring to get from the source segment/lane to the target segment/lane. Things like TurnOnRed and apparently Box (which I'm not familiar with) are rules governing those movements, so including them here would be mixing separate concerns.

[originalfoo]

good points, thanks for elaborating

[Elesbaan70]

    Box = 1 << 8, // only enter junction if exit lane is clear/flowing

It just hit me what this is for. The Turnaround Lane use case could benefit from this rule, for when vehicles are exiting the turnaround lane. Basically, my plan was for the displaced left in that case to always be green, but really it should be in a state where vehicles only turn if the lane they're entering is clear.

[originalfoo]

Yup.

With the work @krzychu124 is doing on junction traffic management ( see plethora of videos starting from this comment: #1229 (comment) ) the Enter Blocked Junction feature is pretty much obsolete (really it exists only as a hack to deal with the existing bad junction management).

It could likely be replaced (or converted to) something akin to "box junction" ( see: https://en.wikipedia.org/wiki/Box_junction ) and/or "wait in junction" ( see: #46 ).

[Elesbaan70]

This also starts to get into the whole matter that at least in America, there are more traffic light states than just red and green. But that's a whole other topic.

[Elesbaan70]

Okay, I'm back on this now, after getting tied up with some other things and distracted for a bit. So I had talked earlier about the LaneDirection enum. Of course this impacts CustomSegmentLight pretty significantly.

As I've thought about it the past week, it's occurred to me that I'll already be doing a lot of the work required for lane-based traffic light control, so that's something to keep in mind. When looking at what I want to do to CustomSegmentLight, I think it's worth asking whether the LaneDirection enum really makes sense, or are we better off avoiding the complexity it adds and just going fully lane-based?

Here are the highlights of how the class would be revised:

• The light states would be stored in an array indexed by LaneDirection.
• The existing LightLeft, LightMain, and LightRight properties would come accessors to this array, and marked [Obsolete].
• Also marked [Obsolete] would be IsLeftGreen(), IsRightGreen(), IsLeftRed(), etc. These methods would all be replaced by equivalents that accept a LaneDirection.
• New overloads of GetLightState() would be added, and the existing overloads marked [Obsolete]:

RoadBaseAI.TrafficLightState GetLightState(byte fromLaneIndex, ushort toSegmentId, byte toLaneIndex);
RoadBaseAI.TrafficLightState GetLightState(LaneDirection dir);

• A new overload of SetStates() would accept states for all LaneDirection values.

Originally, I avoided thinking in terms of controlling traffic lights by lane because @krzychu124 described it as a complete rewrite of the traffic light code. Certainly, it would be a near rewrite of CustomSegmentLight, but my plan already involves tracking lane indices and managing signals by index, so at this point I'm not sure the LaneDirection concept is really buying me anything.

[originalfoo]

I would definitely like to see rewrite of traffic light stuff to make it lane based; that would also facilitate a massively improved UI (current UI is based as if user is driver on the road, but in reality user is "eye in the sky" looking down from above)... I was looking at an intersection asset earlier today where the creator had overlaid some "lane connector lines" to illustrate the traffic light sequence, for example:

show image

Speaking of lane direction / indexes... We have a GetSortedLanes() method that might be of some use. Also, there's lots of weird stuff in road assets - eg. lanes with both direction (often used for turning lanes), overlapping lanes (one going forward, the other backward), and of course there's stuff like tram tracks, monorail, bus lanes, parking lanes, and even train tracks (as in a road with an acutal train track on top of a road lane), etc.

[Elesbaan70]

Yeah, I already accounted for the weird lane directionalities, including the "Avoid" directions and overlapping lanes. The definitions of Forward/Backward and Standard/Displaced lanes in #1392 were designed to account for all this. I knew about GetSortedLanes(), but I was not relying on lane order. I walked all the lanes recording the minimum/maximum position values by direction, and cached the results.

I am going to explore the lane-based approach some more and see if I run into unexpected challenges.

Regarding UI, when you zoom in close enough, each lane should just have a single light painted over it that's either red or green. It could also have the arrows to make it more clear what's going on. I think this would work even without individual lane control; you'd just have to render each lane's light according to what directions are allowed from that lane.

[Elesbaan70]

@krzychu124 @aubergine10

I am an idiot. This was ridiculously easy.

stoplights.by.lane.sd.mp4

• Might want to consider a separate UI. No need for the user to know that it's just a special kind of vehicle restriction.
• This proof of concept has one special flag vehicle type. I think there should be two. That allows for up to four lane groupings per segment end, which is plenty.
• Maybe when the the only difference in the vehicle restrictions is the special flag, that should be the only infosign shown in the Timed Traffic Light UI. At that point, the other ones just add confusion.

[Elesbaan70]

This new approach to the problem was based on a user showing me yesterday how he is using vehicle restrictions as a hack for per-lane traffic lights. He usually just needs one extra grouping of lanes, so he gets it by banning emergency vehicles, since they'll still have other lanes to work with and can basically do whatever they want.

So I was just building from his hack, making a kind of "vehicle restriction" that's really just an arbitrary lane grouping. But.....

if you can detect that case like we already detecting lanes with special vehicle types it will be the best option IMO.

In this case, maybe there is no reason to hack it into vehicle restrictions at all. Instead, make the CustomLights dictionary be keyed on a struct of both ExtVehicleType and a new enumeration, something like this:

public enum LaneDisplacement
{
    None = 0,
    CrossLeft = 1,
    CrossRight = 2,
    TurnOutOfDisplaced = 4,
    TurnIntoDisplaced = 8,
};

CrossLeft, CrossRight:

TurnOutOfDisplaced, TurnIntoDisplaced (RHT):

TurnOutOfDisplaced, TurnIntoDisplaced (LHT):

I have still not identified a sensible use case for a displaced turn in the direction that is a near turn by default.

[Elesbaan70]

On the other hand, maybe we actually want this to be fully configurable rather than forcing the player into categories that we define. What if the player wants to create a stoplight like this one?

[Elesbaan70]

Here is a video of the hack that inspired this solution. Note that if we go with automated groupings, it will not solve this use case.

https://streamable.com/ls6590

[originalfoo]

Could displaced turns maybe facilitate something like this?

[Elesbaan70]

Hmmm, interesting. It's not lane displacement. In fact, I think the traffic light code as it stands now would support this just fine. But I suspect pedestrian pathfinding wouldn't know what to do with this, so you'd just end up with pedestrians walking through the fences instead of walking along the middle pedestrian lane.

EDIT: Also, I was picturing this as two nodes and a really, really short segment. If this were all in one node, there would be no way to define that middle lane as a place for pedestrians to walk. It just doesn't work that way.

[Elesbaan70]

Okay, here is a new plan for grouping displaced lanes separately in CustomSegmentLights.

1. Create a new enumeration of lane flags to be autodetected according to the definition of displaced lanes established earlier. This enumeration could gain user-configurable flags as a future enhancement.

public enum LaneConfiguration
{
  None = 0,
  CrossLeft = 1,
  CrossRight = 2,
  TurnOutOfDisplaced = 4,
  TurnIntoDisplaced = 8,
  ForwardDisplaced = 16,
}

2. Autodetect lane configuration according to lane connections. I believe that this is an acceptable requirement because this feature by its nature requires intentional lane connections rather than the magic that happens by default. But in the future this could be automated in the lane connector tool, so the player can see what is happening and make adjustments as necessary.

3. Revise CustomSegmentLights to use a new collection of lights with the following key (apparently the syntax coloring doesn't know about records):

public record struct VehicleLaneConfiguration(LaneConfiguration laneConfiguration, ExtVehicleType vehicleType)
{
}

4. When a light's ExtVehicleType matches the main light, and the only difference is in the LaneConfiguration, hide the vehicle info signs so it is clear that the light's purpose is to handle a lane configuration.

5. For compatibility, write an adapter class that gives the CustomLights collection access to the new collection. This can be fully backward compatible when all LaneConfiguration values are None, but it would be blind to any lanes with a different configuration.

That's the high-level view. Here are my proposed info signs:

CrossLeft, CrossRight

TurnOutOfDisplaced (RHT, LHT)

TurnIntoDisplaced (RHT, LHT)

ForwardDisplaced (RHT, LHT)

[krzychu124]

Sounds good 👍

Notice that record struct is not supported (we use C# 9.0 and only partially) a lot of C# 9.0 features can cause unexpected and weird bugs, including game crashes for no apparent reason.

[Elesbaan70]

I just realized that this is actually a Lane End Configuration. Or maybe these are Lane Connection Flags. Either way, it's even more closely tied to lane connections than I first suspected. Certainly, it requires a pairing of lane/node, or lane/isStart.

[Elesbaan70]

What is y'all's take on this commit? Elesbaan70@86054e8

Basically, the idea is for LaneConnectionManager to directly manage an object that contains not only the array of connected lanes, but also other information about the lane's connections, such as these new flags. Custom lane grouping for advanced/unconventional stoplight configurations could also be managed through here.

[Elesbaan70]

Here is a first look at Displaced Lanes. There is still work to do.

https://youtu.be/-p5AF1n3nF8

[Elesbaan70]

@krzychu124 I am not completely happy with the UI here:

Especially the segment coming from the right, the fact that it's a crossover makes it confusing. Here's what I'm thinking as a potential solution:

1. For lights other than the main light or, only for lights that govern displaced movements, only present directions that are actually possible for that light. In the above example, the cross-right light would not present the rightward direction, because no right turn is possible for that light. Likewise, the turn-into-displaced light for the top segment would not present the rightward direction, because it is left-only.
2. For lights that govern displaced movements, if only one direction is possible, default the mode to All.

The net effect of these changes is that in scenarios like the one shown above, the lights governing displaced movements would be in All mode by default so that the user will see the directional arrow on the light. The right segment's displaced light would show forward arrows, and the top segment's displaced light would show left arrows.

It could be argued that the cross-right movement in this example is really a standard movement, but it is a transition from a displaced to a standard lane. The only way to classify it differently would be through a very complex evaluation and comparison of all the lane connections.

[Elesbaan70]

Option 2 for this UI issue: I wonder if CustomSegmentLights can evaluate the lane arrows of each lane grouping, and eliminate distinct displacement groupings whose arrows don't conflict with the standard grouping/main light? Hmmm......

[edit] Yes, the Housekeeping() method should be able to take care of this.

[Elesbaan70]

This UI issue is resolved. Displaced lanes only get separate traffic lights if they have the same lane arrows as standard lanes.

[Elesbaan70]

Here are the lane configurations I have designed for. Blue lanes are standard, red lanes are displaced. I suppose information like this could go in a wiki eventually.

Standard lanes:

Inverted lanes (not displaced, just backwards):

Displaced inside lanes (required for standard CFI):

Displaced outside lanes (required for turnaround lane, used in some modified CFI designs):

TMUnitTest.Util.Extensions.NetInfoExtensions.DisplacedLanesTest verifies this behavior.

My code does not account for more than four directional lane groups on one prefab. It won't blow up or anything, but the results probably won't be very useful.

[Elesbaan70]

My apologies if this seems spammy. I wanted to catch everyone who's participated in conversations on this.

How does this look? Did I miss anything?

@krzychu124 @aubergine10 @kvakvs @chameleon-tbn @kianzarrin

Done so far

1. Displaced lane detection by extension methods on NetInfo and NetInfo.Lane.
2. LaneConnectionManager enhancements:
   1. Raise an event when connections on a lane end change.
   2. Raise an event when the lane connection feature is enabled/disabled.
3. Identification and flagging of lane connections involving displaced lanes, in LaneEndManager.
   • Also listens for LaneConnectionManager events to reset its cached data.
4. Removal of unmaintainable and unused public traffic light API.
   • This needs a rollout plan in case there are unknown/surprise dependencies.
5. CustomSegmentLights groups lights by both ExtVehicleInfo and NetLaneFlags.
   • Displacement-based groupings are folded into the main group if they don't conflict.
6. Tool enhancements:
   1. Show infosigns for displaced lane connections
   2. When displaced lane lights have the same vehicle types as the main light, hide the vehicle type infosigns.
7. Load/Save
   1. In Configuration.CustomSegmentLights, a new collection replaces the obsolete one that was based on the old ExtVehicleType.
   2. The old collection must still be written for at least one version, so that alpha users can revert to stable.
   3. Because of the way LaneConnectionManager works combined with how late the options are loaded, when lane connections are found in a savefile, LaneConnectionManager now operates as if enabled for the duration of the load. If its saved setting is disabled, that is applied once loading is complete.

To Do

1. TTL Copy/Paste
2. Lane Connector stay-in-lane feature
   • On mismatched lane count, account for displaced lanes in a way that makes sense.
3. TTL Quick Setup
   1. Continuous Flow Intersection
      • Two-way node with inner displaced lanes on one segment
      • Three- or four-way node with inner displaced lanes on one or more segments
   2. Contraflow Interchange
      • Four-way node with one-way traffic entering/exiting on opposing segments, and inner displaced lanes on one of the remaining segments
   3. Diamond Interchange with Turnaround Lane
      • Four-way node with one-way traffic entering/exiting on opposing segments, and outer displaced lanes on one of the remaining segments

[krzychu124]

do we need lane end manger? can't you just add Start/End structs to NetlaneExt?

LaneEnd Start, End

What is NetlaneExt?? There is no "extended" version for NetLane

[Elesbaan70]

do we need lane end manger?

I must confess that I'm puzzled by your antipathy toward lane ends. The concept is already baked into TMPE. It should have already had a manager, but people just keep putting lane ends things in other places.

Why are lane ends bad?

[Elesbaan70]

What is NetlaneExt?? There is no "extended" version for NetLane

I think he's talking about the new ExtLaneManager, which currently serves only the purpose of converting lane id to segment and index.

[kianzarrin]

I must confess that I'm puzzled by your antipathy toward lane ends

Anti-pathy? I like lane ends. Whether we create a separate lane end manager than ExtLaneManager or we just merge them together is an implementation detail.

[Elesbaan70]

I just want to make sure I'm not missing something. I want to understand your concern.

LaneEndManager is where this belongs because it is specific to the lane end in a way that is analogous to segment ends. I'm just making a program architecture that fits its function.

This decision doesn't need to affect how the flags would be incorporated into AN. Since two-way vehicle lanes aren't supported by the game anyway, asset creators will be fine seeing them as flags on the lane itself like arrows. I've been thinking about that and I think I have a simple algorithm. If this is ever merged, I will create a PR on AN to add the flags there.

We might not be so lucky with future lane end flags, but that will be true whether there is a lane end manager or not.

[kianzarrin]

I don't understand why do we have so many network managers. we have SegmentEndManager and ExtSegmentEndManager. I think both can merge into ExtSegmentManager. |CS manages all network related stuff inside a single NetManger.
To me it does not make sense to separate them since they are intimately related.

In any case I don't have a strong opinion on this. Both implementations are equal. Do it the way you like it.

[kianzarrin]

BTW which LaneEnd is Start and which one is End? is it simply based on StartNode of the segment and has nothing to do with the direction of the lane?

[Elesbaan70]

Yes, it is based on StartNode, just like for the segment ends and for the lane connections (which are really a lane end feature). It is "start" and "end" according to the direction in which the player drew the road. It has nothing to do with lane direction.

[kianzarrin]

Do you plan to create several small PRs or one very big PR?

[kianzarrin]

There might be some use for lane manager.

[Elesbaan70]

ExtLaneManager was intentionally made so it could be its own PR. I might need to make a branch and cherry-pick it, but that's easy enough that I could do it at any time if it's wanted for something.

In general, whether I do incremental PRs depends on @krzychu124's preference.

[kvakvs]

Incremental are better for multiple reasons. I delivered several huge PR in the past and every time its been pain.

[Elesbaan70]

Incremental are better for multiple reasons. I delivered several huge PR in the past and every time its been pain.

In principle I agree with this.

Merges that only partially implement the feature could get weird. But at the very least, large scale refactoring and foundational code changes should probably be merged separately from the feature itself.

[Elesbaan70]

Regarding the remaining to-do items:

TTL Copy/Paste - This is basic traffic light functionality that must be included in the initial rollout of this feature.
Lane Connector stay-in-lane - This needs its own issue and has commonalities with the old median detection problem.
TTL Quick Setup - This is an advanced feature that needs its own issue, maybe even separate issues for different types of intersections to be recognized and supported.

[Elesbaan70]

#1392 has been rewritten based on this discussion and related development work.

[kianzarrin]

if you have any code ready for review its better to put it sooner rather than later. reviews might take a while.

[Elesbaan70]

if you have any code ready for review its better to put it sooner rather than later. reviews might take a while.

Yes, indeed. I think especially, the nuking of the traffic light API needs to be thoroughly vetted, and a decision made on it. If it is rejected, that will create a lot of additional work for displaced lanes, and raise all kinds of questions about future features such as per-lane traffic lights.

[Elesbaan70]

I will do my own line-by-line review (I started that, but never finished), then create a PR.

[Elesbaan70]

RoutingManager is going to need some work for this. When Can Cross Lanes is disabled, it needs to prevent lane changes that cross oncoming traffic.

[Elesbaan70]

@krzychu124 The more I play with this feature in practice, the more I'm convinced RoutingManager will need to directly account for displaced lanes. I'm going to need some help understanding what bits of that code are relevant to this, and what they're actually doing.

Unfortunately, I've only barely looked at RoutingManager so far. Here are the use cases that need to be accounted for:

1. Entering displaced configuration, two-segment node
   Applies to: Entering a CFI
2. Leaving displaced configuration, two-segment node
   Applies to: Leaving a CFI
3. Turning into a displaced configuration
   Applies to: Turning in a half CFI, entering a turnaround lane
4. Turning out of a displaced configuration
   Applies to: Turning in a half CFI, leaving a turnaround lane
5. Turning within a displaced configuration
   Applies to: Turning in a full CFI

As an example, here is the alternate logic that would apply when use case 1 is detected:

graph TD

    Start(Enter Displaced Configuration)
    Start-->HowManyIncoming

    HowManyIncoming{How many<br/>incoming lanes?}
    HowManyIncoming -->|1| Fallback
    HowManyIncoming -->|More than 1| LaneCountCheck

    LaneCountCheck{Check lane counts}
    LaneCountCheck-->|More incoming<br/>than outgoing| Fallback
    LaneCountCheck-->|Same incoming<br/>and outgoing| AllDirect
    LaneCountCheck-->|More outgoing<br/>than incoming| Allocate

    Fallback[Give up and revert</br>to default routing]
    Fallback-->End

    AllDirect[Make direct crossover<br/>and forward transitions]
    AllDirect-->ForwardLaneChanges

    Allocate[Allocate crossover and forward lanes<br/>so that orphaned outgoing lanes<br/>of both types are equal]
    Allocate-->AllocateDirect

    AllocateDirect[Make direct transitions as allocated,<br/>to the innermost lanes]
    AllocateDirect-->NewLanes

    NewLanes[Make lane-changing transitions<br/>from outermost incoming lanes<br/>to orphaned outgoing lanes]
    NewLanes-->ForwardLaneChanges

    ForwardLaneChanges[Make lane-changing<br/>forward transitions]
    ForwardLaneChanges-->End

    End(Done)

[Elesbaan70]

Use case 2:

graph TD

    Start(Leave Displaced Configuration)
    Start-->LaneCountCheck

    LaneCountCheck{Check lane counts}
    LaneCountCheck-->|More incoming<br/>standard <i>or</i> displaced<br/>than outgoing|Fallback
    LaneCountCheck-->|More total<br/>incoming than outgoing| Conflicting
    LaneCountCheck-->|Same total <br/>incoming and outgoing| AllDirect
    LaneCountCheck-->|More total<br/>outgoing than incoming| Allocate

    Fallback[Give up and revert</br>to default routing]
    Fallback-->End

    Conflicting[Make conflicting crossover<br/>and forward transitions]
    Conflicting-->End

    AllDirect[Make direct crossover<br/>and forward transitions]
    AllDirect-->ForwardLaneChanges

    Allocate[Make direct crossover<br/>and forward transitions,<br/>leaving outermost lanes on the<br/>standard driving side orphaned]
    Allocate-->NewLanes

    NewLanes[Make lane-changing transitions<br/>to orphaned outgoing lanes]
    NewLanes-->ForwardLaneChanges

    ForwardLaneChanges[Make lane-changing<br/>forward transitions]
    ForwardLaneChanges-->End

    End(Done)

[krzychu124]

hmm, if you have Airports DLC there is a wide cargo road with "displaced" lanes. Will it work correctly with your idea?

[Elesbaan70]

I think use cases 3-5 are actually a lot simpler. Maybe as simple as this:

3. Turning into a displaced configuration
   • For an incoming turn lane, never provide transitions into both displaced and standard lanes. Always pick one or the other.
   • On inside turns, give preference to standard lanes.
   • On outside turns, give preference to displaced lanes.
4. Turning out of a displaced configuration
   • Does this really need any special logic at all?
5. Turning within a displaced configuration
   • For an incoming turn lane, never provide transitions into both displaced and standard lanes. Always pick one or the other.
   • For an incoming displaced turning lane, give preference to displaced lanes.
   • For an incoming standard turning lane, give preference to standard lanes.

[Elesbaan70]

hmm, if you have Airports DLC there is a wide cargo road with "displaced" lanes. Will it work correctly with your idea?

Short answer is: Yes.

Long answer is: Should someone be looking at the vanilla traffic AI to see if they're handling medians better now, since this is an obvious case where the routing would be problematic?