Lane routing tools now support onscreen display

[kvakvs]

Fixes #830
Fixes #587

Changes

• Added new interface to be supported by both LegacySubTool and new style TrafficManagerSubTool which requests keybinds for the current mode
• Lane Connectors tool now suggests Ctrl+S keybind for stay in lane, and cancel rclick/esc.
• Nodes are back to 0.4 alpha (bug: white nodes 1.13.0 lane connector does not highlight nodes correctly on-hover #830) and hover has alpha too
• Code style changes

[kvakvs]

One UX question

• Right click in the initial tool mode deactivates the tool (LaneArrows tool in my implementation)
• Or right click does nothing and you remain with the tool active? (all other tools)

I feel like my approach is less intrusive and its easier to leave tools by right clicking. But its not consistent with the other tools. If you agree that leaving tools with right click should be that easy, i'll add that cancel right click into every tool.

[originalfoo]

I like right-click to exit tool, but some users might find it confusing/annoying (especially if they have dodgey mouse button like lots of old logitech mice do).

IMO it would be great if all tools could allow right-clicking out of them, but maybe mod option to toggle whether tools can be exited with right click to keep users happy?

It would be great if we could get "most" of the tools updated with OSD and right-click exit for the 11.5.0 release.

The traffic light tools would have to wait probably, but stuff like speed limits, parking restrictions, vehicle restrictions, priority signs, junction restrictions, lane arrows/connectors... I don't know how much work it is per tool? Maybe we release 11.5.0 with just a couple of tools done, then 11.5.x releases update more tools? what do you think?

[originalfoo]

Also, is there a way - for lane connectors in particular - to make the right-click text even more specific to current selection mode?

• Exit tool (when nothing selected)
• Exit node (when node selected)
• Exit lane (when lane selected)

[kvakvs]

It is not much work, 1-3 hours per tool.
For smarter exit messages we can do for sure, just did not want to grow the translation keys pool and used a generic cancel message.

[originalfoo]

I think the strings could be re-used for those translation keys.

For example, 'exit node' could be used on junction restrictions, lane connectors, priority signs...

I think there might only be like 4 possible exit values - those three listed above, and also Exit segment (eg. for vehicle restrictions, lane arrows, etc).

[originalfoo]

@kianzarrin is there any way to determine if auto-lane connector (Ctrl+S) has multiple states for selected node? for example, could the tooltip indicate when user can repeat the shortcut?

For example, on a basic node on 2 way road, the tooltip could be:

Ctrl + S Auto-connect lanes (repeat for alternate connections)

On a one way road it might be just:

Ctrl + S Auto-connect lanes (repeat to toggle connections)

[kianzarrin]

Right click in the initial tool mode deactivates the tool (LaneArrows tool in my implementation)

Why would that be useful?

[kianzarrin]

Can you make + and | white like you did in lane arrow tool?

[kianzarrin]

On a one way road it might be just:
Ctrl + S Auto-connect lanes (repeat to toggle connections)

@aubergine10 the code is :

stayInLaneMode = !oneway ? StayInLaneMode.Both : StayInLaneMode.Forward;

So yes something like that. Although in a two lane road if there is only one lane in the backward direction that can stiil be confusing to the user.

[kvakvs]

Can you make + and | white like you did in lane arrow tool?

It comes from keybind code as a string, so this will need splitting into separate words and then labels need to be created of each colour. Possible but tedious.

[kvakvs]

@kianzarrin I am now making | for dual shortcuts to be white.
I would prefer + to be orange as it is a part of one shortcut and it works together, and for that i should probably revert + in Alt + Click shortcuts to also be orange.

There is no actual coloring markup in C:S (or is there?). I am actually creating those labels, its tedious and probably not necessary.

[originalfoo]

If anyone knows about coloring text it will likely be @klyte45 as he's done all kinds of UI stuff in his TLM and other mods.

[klyte45]

The UILabel class (and some other text components) have a bool processMarkup. When enabled, it will process some tags:

<Color #rrggbb>text</color>
<Sprite spriteName> (requires atlas property to be setted)
<Setting settingName> (retrieve value from settings file)

Only color requires close tag. Also colors tags can be stacked. See more details at UIDynamicFontRenderer on ColossalFramework.UI namespace.

(May something in this text can be not so accurate, I wrote this from my memory =V)

[kianzarrin]

I can confirm this works from user perspective.

[originalfoo]

The ? button has no tooltip to explain what it does.

Also, would it be worth hiding the ? button when there are no hints to display?

[originalfoo]

These are just random thoughts, I'm trying to picture myself as new user. It is certainly better than what we had before, but I wonder if a new user would fail to grasp that they could just click a segment or node (ie. not apply a shortcut of any kind) to manually edit something?

So, is there merit to including more basic interactions? For example:

Imagine being a new user confronted with the scene above. Would you know that you could just click a segment to edit it's lane arrows?

For that situation, would it be worth adding something like:

Click segment Manually edit the lane arrows

Obviously we don't want to teach grandma to suck eggs, so once a segment is highlighted we wouldn't mention stuff like "Click the buttons to toggle them" because the UI alone is obvious enough.

But when a tool is first opened, and user hasn't selected anything yet, it would perhaps be useful to at least state what they can select. Additionally, maybe an option somewhere to hide the very basic "you can click a node or segment to edit it" type stuff?

[originalfoo]

While a lane is selected, the Ctrl+S shortcut should be disabled (it should only work when we're in the 'selected node' state):

Also, right-click in that image above won't leave selected node, it will leave selected lane (ie. transition state machine back to 'selected node' state).

Also, it would be great to tell the user what to actually do once they've selected a lane (as a basic hint mentioned in my last comment), for example...

When they've selected a node:

Click incoming lane Select the lane you want to edit

When they've clicked incoming lane:

Click outgoing lane Toggle a connection from the incoming lane

[kvakvs]

I was thinking about something like current mode description in a separate line and different color (sky blue maybe). I would also like to display those actions you mention in a different way or text colour. Because "click segment" is not actually a keybind or mouse click, its a targeted click action.

Would you like to have that in this PR? Or rather add during the upcoming future PR's?

There's one catch though. The bigger we make the hints panel, the faster users will click it away and forget about it.

[originalfoo]

We should limit the number of colors shown; maybe yellow for state-specific stuff and brown for multi-state stuff? That stuff (and the 'basic hints' mentioned in my earlier comments) could come in later PRs if desired.

An alternate to things like "Click node or segment" hints would be to revive that stuff you had where the clickable stuff would gently pulse its opacity making it really obvious to user "you can click here to do stuff".

We could probably remove Escape shortcut hint - all game tools use that mechanism so users will at least be familiar with that pattern.

For Delete | Backspace - do we need to mention both keys? Would stating just one of those keys suffice? For example, on Macs it would be Backspace, on other platforms it would be Delete. Would help reduce the amount of text.

Another thing I'm thinking - definitely a separate PR at later date - is would there be any merit to introducing some alignment? If you look at boundary between brown and white text, it's jagged which makes it a little difficult to quickly scan with the eyes. Maybe if there was a way to determine longest brown text, then right-align all other brown text to it? That way all the white text would be left-justified; might make it a bit easier to read?

[kvakvs]

If you can guarantee that the text will be always 1 line, wrap keys in an invisible panel, and wrap texts in an invisible panel, and make them size to contents, and they'll align nicely.

[originalfoo]

I think we will always want to ensure text is short as possible (always one line) so yes, wrapping in panels would work.

[kvakvs]

Added the tooltip to the (?) button

Here's the ModeDescription text. It is white (no distinct colour), it is 80% opaque, it is not translated at the moment.

TODO

• OSD show/hide button should become visible when there are hints available, even if hints are hidden
• Align keybinds with their text? Requires some extra refactoring, maybe optional

[originalfoo]

Another idea for the ? button: If there are hints, but the hints are hidden, hovering over the button would show the hints.

Use case: I've memorised most of the hints, so have hidden them. Yet one time I'm doing something and I need a recap; I can just hover ? to see the hints then move away again - no need to toggle them on/off if I just want a quick recap.

[kvakvs]

That's possible, but since your mouse is already on the ? just click it.

[originalfoo]

Then I have to click again to hide it afterwards.

EDIT: Although having it appear on hover then adds an additional issue: Clicking to hide it will keep it visible due to mouse still hovering the button.

So yeah, scratch that idea. Just keep it as is.

[originalfoo]

LGTM 👍