[EPIC] UI: Routing Tool

[originalfoo]

This tool visually combines the features of the Lane Arrows and Lane Connectors tools.

Lane Arrows

Current implementation is floating panels with buttons for each direction. I find this a bit confusing to use, and clunky to work with. Maybe using arrow glyphs (rather than characters) on the buttons would be better, where only one button (and thus glyph) can be active at a time?

Also, it would be nice if we could add a few new arrows?

• Deflect = Driver should start moving in to adjacent lane
  • Used when a lane is closing (eg. road narrows) or some obstruction ahead (eg. roadworks)
• Merge = Driver must merge in to adjacent lane
  • Used when a lane cannot continue 'straight ahead'
• Diverge = Driver may diverge in to adjacent lane
  • Used when additional lanes become available, or when there's a slip road, etc.

Issue: Most roads don't have deflect, merge or diverge arrows. Some roads do, but only via supplemental lane marking asset packs. We'd need some way for user to choose which decals to use to represent the new arrows, possibly via integration with Find It! mod.

Two other things:

• H: Hide = Arrow takes effect, but does not appear on the road
  • There must be way to do this, as on normal nodes where two segments of same type connect there are no arrows
  • Would fix: Hide lane arrow VictorPhilipp/Cities-Skylines-Traffic-Manager-President-Edition#169
• X: Reset = Reset an arrow to game default
  • Removes any customisations; an arrow might still appear depending on what the game default is

The full list of arrows:

• L: Left
• LF: Left-Forward
• F: Forward
• LFR: Left-Forward-Right
• LR: Left-Right
• FR: Forward-Right
• R: Right
• DL: Deflect Left (new)
• DR: Deflect Right (new)
• ML: Merge Left (new)
• MR: Merge right (new)
• IL: Diverge left (new)
• IR: Diverge right (new)

They could be arranged in a grid, something like:

IL LF F FR IR
ML L LFR R MR
H  DL LR DR  X

With the exception of H (hide) and X (reset), all the arrows equate to lane connections. Depending on what's attached to the nearby node, some arrows would be unavailable. For example, at road junction, the diverge, deflect and merge arrows would not be applicable. Diverge and merge are only available when a road widens or narrows, respectively. Deflect only applicable on normal nodes where both segments are same number of lanes. Left turn only applicable if there is a left turn, and so on...

As inferred from the above, it's not just at junctions where the lane arrow tool is applicable; it's also useful at nodes where different types, or even same type, of road meet.

When hovering over an arrow button in the panel, the following happens:

• Source lane is highlighted (see UI: Highlight lane when hovering over icons associated with lane #33)
• Lane connectors are shown to clearly indicate what lanes it connects to
• Destination lanes are highlighted too

This way the user has zero doubt as to what effect the arrow will have if they choose it.

If any of that sounds feasible, let me know and I'll do a quick graphic mockup of the grid layout.

[originalfoo]

Lane Connectors

These could do with some visual enhancements.

First, better arcs that represent the actual path vehicles will take. See #3, and subsequently #4.

Second, using circles for both incoming and outgoing lanes is a bit confusing.

• Incoming lane should be a square
• Outgoing lane should be a triangle
  • The triangle points in direction of traffic, away from the node

This would make docs easier: Click a square to select the incoming lane, then click one or more triangles to select outgoing lanes.

Visually, the user is drawing arrows (line with a triangle at the end) from a square (incoming lane), thus depicting the flow of traffic through the junction.

Colours:

• Squares: Existing colour scheme (but not white)
• Triangles: White
• Default lane connections should be thin white lines
  • These are defined by either city road lane selection algorithm or highway rules according to old TMPE docs. Note that any lane arrow/connector customisations at a highway junction cause it to switch to the city road system to determine defaults for non-customised lanes.
• Custom lane connections would be the normal source-coloured lines

When user customises lane arrows, they are effectively making custom lane connectors for those lanes.

When hovering over a lane arrow (in floating panel), or a square or triangle (on the road), it's lane connectors should be normal width and the other lane connectors should shrink to thinner width. This will make it clear which lane connectors the user is currently interacting with.

[originalfoo]

Eraser tool

As per #38, there will be an eraser tool on the toolbar.

While the Lane tool is active, the user can click the eraser, then:

• Click a node = Reset all lane connections and arrows for segments connected to node
  • While a node is selected, pressing Delete or Backspace (current TM:PE features) has same effect
• Click a square = Reset that lane to default connections
• Click a lane arrow outline on the road = Reset that lane to default connections

[originalfoo]

Stay on lane feature

I had no idea that this feature, Shift+S, existed until now.

Would be nice if there was some UI (either in floating panel or some shape on a road?) to allow 'stay on lane' to be a) discoverable and b) can be applied via mouse.

Should this feature be disabled at junctions? It's main use seems to be normal nodes, and especially 'bend nodes'. EDIT: Yes, as per current TMPE implementation.

[originalfoo]

TMPE old docs state that reckless drivers may not ignore lane connections, but can ignore lane arrows... sounds odd?

EDIT: This is for detailing, to allow user to do roadworks, etc., within limitations of current system. In new system, with extra lane arrows, they could use deflect/merge/diverge arrows.

[originalfoo]

U-turns

As per #32, should U-turns tool be moved to this Lane Routing tool?

It could be icon in centre of road.

Either side, if applicable, could be icons for "Stay on lane" (one in each direction) feature.

If #51 is implemented, the buttons for u-turn and stay-in-lane would be besides the build bar (like where the curved roads buttons are on roads menu).

[originalfoo]

Pondering data structure

For lane arrows/routing, an 8-bit word of flags...

Bit:

• 0 - hidden - invisible lane arrow
• 1 - left - "you can turn left"
• 2 - forward - "you can go straight on"
• 3 - right - "you can turn right"
• 4 - deflect - "lane ahead will close; consider switching lanes"
• 5 - merge - "lane ahead now closed; switch lanes"
• 6 - diverge - "new lane ahead; you can use it if you want"
• 7 - custom - non-standard lane routing (also required for u-turns)

Deflect, merge and diverge relate to left/right. If there's no left/right flags then deflect/merge/diverge are not applicable.

The merge/diverge features can be used to create roadworks; even if there are lanes ahead, traffic can be told to merge in to adjacent lane. After the road works, user places a diverge allowing traffic back in to the lane.

Under the hood, all these things really just relate to lane connectors. Where we can determine standard lane connectors, it will save a lot of data in savegame if we just store the applicable lane arrow bitmask rather than a bunch of lane connection data.

[originalfoo]

UI Mockup

Please excuse the shit diagram ;)

Quite a lot of changes here, as you can see.

Less right-clicking

Now that we differentiate between incoming (square) and outgoing (triangle) nodes, there's no need to hide incoming nodes when routing a specific node.

Right click can still be used to deselect the current source node, however users can now simply click a different source node to route from that instead.

Squares:

• These are source nodes
• Colours:
  • White square = using standard lane arrow (see later) setting
  • Coloured square = custom lane connections
• Outline width:
  • Thick = the segment you are currently altering (in this case, user is altering the lower road)
  • Thin = all other segments
• Filled square indicates which source lane is currently selected
• Right-click a square (or eraser tool it) to reset its lane arrow and connections to default

Triangles:

Note: To further distinguish between squares and triangles, the squares could be flush with the end of the road segment (like bottom and right in the image above) and triangles could be offset from the road edge (like right segment in image above).

• These are destination nodes
• They appear when a source lane is selected (filled square)
  • Only valid outgoing lanes (for selected incoming lane) are shown
  • For example, you can't route a road lane to a bike lane
• Colours:
  • Yellow = same segment as source (eg. if you want u-turn, connect square to yellow triangle)
    • These could potentially have thinner width?
  • White = other segments
• Fill:
  • Filled = there's a route to it from the current source segment
  • Empty = there's no route from the current segment
  • This makes it really obvious if I've missed a connection
• If no incoming lane is selected, the triangles disappear. However, if there are any outgoing lanes that have no connections at all (from any source) their triangles could show (when there's no active source lane selection). This would alert me that one of my lanes is inaccessible at the junction/node.

As I add custom lane routes, the source lane arrows are updated accordingly to best match the connections.

Lane arrows

I need to spend some time pondering the interaction model of this, but initial ideas jotted below...

When a source (filled square) is selected, the lane arrows palette appears, filtered to valid arrows for that source lane.

• Hover over a lane arrow (in palette) to see what change will be (this takes account of any key modifiers pressed)
• Click: Clear existing connections from that source and apply those associated with the lane arrow
• Shift+Click: Add lane arrow connections to existing connections
• Alt+Click: Subtract lane arrow connections from existing connections

In any case where current connections for a lane match a standard lane arrow, the connection lines go thin white to indicate a standard set of connections. This is on a lane by lane basis. It makes it easy to see which lanes are using normal road/highway rules (those with thin white line connectors) and which are using customised rules (thick coloured lines).

[originalfoo]

Roundabout automation

Doing lane connections or arrows for roundabouts is tedious. Is there some way we can automate?

Specifically, this would be a "conflict mitigation" approach (see #4) where things like automatic filter lanes would be added to the segments of the roundabout.

The key problem is detecting a roundabout, although we could just let the user select the segments or junctions manually as an interim measure.

Note: @joaofarias was working on a roundabout detection algorithm back in the days of T++. I don't know if he ever uploaded it to github, but it might be lurking in a branch or tag of https://github.com/joaofarias/csl-traffic

[originalfoo]

Copy and paste

A tool to copy/paste lane routing/arrows from one junction to any matching junctions.

Some nightmares here from code perspective, in that we'd need to deal with junctions facing different angles, making sure the number of lanes match, etc. Could potentially be simplified by looking at road names, priority routes, etc., of the copied junction? But what about pasting to junctions on other routes - icky.

[kvakvs]

The lane connector tool (where you drag colored curves) has a function (even now in TM:PE 10.20) called "Stay in Lane" (keyboard Shift+S) which connects all incoming lanes on a segment to all lanes on another segment. But from what i know it is simplistic and only works on nodes where there are exactly 2 road segments with same amount of in/out lanes.

What you want is probably just smarter and improved Stay in lane behaviour, where it would assign each outgoing lane say clockwise to each corresponding incoming lane counter-clockwise, even if more than two segments are present. That's exactly the situation with roundabout exits and highway exits/ramps, i.e. there are 3 segments and regular Stay in lane won't work.

[originalfoo]

There were some ideas going in that direction in this issue: #325 - There could be several 'helper' shortcuts that would achieve common lane usage patterns.

• Shift + S = Straight ahead only
• Shift + L = Limited (single lane change)
• Shift + U = U-turn (only at junctions, maybe also at some transitions?)
• Shift + D = Default (whatever vanilla would do)

So the roundabout situation, for example, would be Shift + R or something like that. Remember that sometimes people would use one pattern or another as a starting point for further manual customisations.

[kvakvs]

When setting lane connectors or lane arrows, we can highlight possible routes from there for a few segments, this will help people see if their lane connector is what they mean it to be and is not sending traffic entering a road straight into a next exit (For example) because there isn't a node to change lane

[originalfoo]

#638, #632 have implemented Reset button and Delete key shortcut for resetting Lane Arrows.

[kianzarrin]

I have made the following lane connection.

routings seem a bit odd.

The selected target lane is white.

• The segment that joins the roundabout does not go to that lane at all. considering that the innermost lane is already connected, I would expect the remaining lanes to be connected together.
• SOS(yellow) can go to the selected lane from the exit lane of the roundabout but not the right-forward lane in the round about!

tagging @aubergine10 @krzychu124

[originalfoo]

I'm assuming image above is via routing diagnostic tool? If so which lane is mouse over in that second image?

Also, what do you mean "SOS(yellow)"? Is the color of small lane end circles indicating vehicle restrictions or something?

[kianzarrin]

@aubergine10 The white lane is the selected target lane. I have not hovered over any lane.
the circles show all backward transitions from other lanes to the selected target lane. yellow is relaxed transition which is used by SOS vehicles.
you can try it!

[originalfoo]

So in the image above, I assume there shuold be blue lane end circle between the other two (because vehicles can go straight ahead due to lane arrows) and the road entering from bottom should also have a lane end circle on its outer lane? At least that's what I'd assume would be happening as an end user based on the lane arrows/connector setup at that junction.

But in reality the outer lane of bottom road will only connect to the outer lane of roundabout (the inner lane of bottom road would normally connect to middle and inner lane of roundabout but it's been limited to just the inner lane due to lane connector). Is that correct? And I still don't get why the middle lane of roundabout on left doesn't connect to middle lane of roundabout on right.

[kianzarrin]

No the middle lane of the round about should go to the outer lane of the roundabout.
I think there should be a yellow circle in the middle lane of the roundabout.
as for the connecting road, there should be a blue circle on the outermost lane but that might be hard to calculate.

[kianzarrin]

I think this is partly because sometimes routings do not want to go to a lane that already has routings. this is because in the past lane connections used to be bidirectional and I wanted to stay backward compatible with train station connections.