[Patch] Contextual construction information: cost, length and modifier hints

[victor_18993]

I have been looking at a few of the UX issues discussed recently, especially cases where Simutrans already knows useful information but does not present it very clearly to the player.

This patch is a first small step in that direction. It combines two closely related changes:

A) Construction cost and length no longer depend on tooltips.

B) While a construction tool is active, the interface shows the modifier keys that actually affect that tool.



The goal is not to redesign the GUI or change construction behaviour. It is only to make information that already exists in the engine easier to see and discover.

The current construction cost/length information was sent through the static tooltip channel. This meant that it followed the cursor and also disappeared completely when tooltips were disabled.

Instead, the patch adds a small contextual band next to the status bar.

It shows, depending on the active tool:

- the construction tool;
- current length;
- estimated cost;
- the relevant Ctrl/Shift effects.

For example, the way builder can show effects such as:

[CTRL]: straight route
[CTRL]: replace existing ways
[SHIFT]: keep city roads



The duplicate Ctrl entry is intentional. Ctrl currently controls more than one independent behaviour in the way builder, and Shift can disable one of those behaviours without disabling the other. I preferred to expose the current behaviour accurately rather than hide that ambiguity behind a simplified description.

The patch does not change the meaning of Ctrl or Shift.

Bridges do not show an empty modifier row because the bridge builder does not use those modifiers during construction. Tunnels, electrification, etc. only show the effects they actually implement.

The contextual band uses the existing theme colours, spacing and font metrics. It does not reserve additional viewport space and does not modify the existing status bar, which already has its own width-degradation rules.

Some implementation details:

- Cost/length are pushed when the construction preview calculates them.
- Tool name and modifier hints are read from the active tool.
- The stored estimate also remembers which tool produced it, so data from an old tool is ignored automatically.
- The cost information has been moved out of the tooltip channel rather than duplicated, so there is no duplicate display.
- Modifier hints are defined per effect rather than per key.

Validation:

- baseline and patched build produce the same cost and length for the same construction gesture;
- tooltips ON: normal hover tooltips still work and construction information is visible;
- tooltips OFF: hover tooltips disappear, but construction cost/length remain visible;
- cancelling or changing tools clears stale information;
- tools without modifiers keep a single-line band;
- small-width degradation has been tested;
- SDL2 build passes;
- headless build passes;
- full test suite passes;
- no new compiler warnings;
- no measurable frame-time difference at the current 1 ms measurement resolution.

Current test result:
237/237 PASS before and after the change.

Diff:
6 files, +420 / -9.
No existing function has been substantially restructured.

There are a few pre-existing issues found while testing that I deliberately did not include in this patch:

- Ctrl currently has multiple meanings in the way builder.
- show_tooltips can effectively be forced back on by distributed themes.
- cost signs are not consistent between all construction tools.
- SDL2 did not refresh modifier state immediately on KEYUP.

The last one has been isolated into a separate, very small bugfix patch so it does not need to be mixed into this UX change.

I will attach the patch and screenshots showing:
- normal construction;
- tooltips enabled/disabled;
- Ctrl inactive/active;
- tunnel behaviour;
- bridge without modifier hints;
- small-screen behaviour.

This is intentionally an incremental change. I am interested in whether this kind of contextual information fits the direction people would like for the interface before extending the idea to other tools.

[Roboron]

Fantastic idea! This is the kind of change that users with less Simutrans experience will appreciate

Actually, I have thought about this in the past, so I have some ideas for improving it. I think the best approach would be to create a new build dialog* where the user could see that information and check/uncheck those options without the need of pressing keys, because that's not practical while playing in touch devices.

It would also be cool if it could show demolition costs as well.

But, as an initial approach this is much better than what we have currently, so for me this can go in.

* Similar to the one that appears when you ctrl+click the signal builder.

[prissi]

While I agree that more information is needed, the screen shot displays one problem: On small screen (Android) there is already very little space in the vertical direction.

Another problem with large screens: when dragging long ways, the information is always near the pointer position, while the bottom could be far away (for the eye).

Therefore, it should be optional to display the information at the bottom.

Moreover, the function of Control can be inverted in the settings. Not sure if the patch takes care of that.

For advanced construction, I agree with Roboron, a separate dialog would be best, with (image?) comboboxes for way, bridge and tunnel, and buttons for parallel building, straigt and replacement. It sounds sensible to add extended preview there too.

Overall, more information may be nice if screen diemnsions are reasonable. But I would not retire the tooltips, as they show the information where the focus is already.

[victor_18993]

Gracias, Roboron y Prissi. Estoy de acuerdo con ambos puntos, especialmente en lo que respecta a las pantallas pequeñas/táctiles.
La información de construcción contextual ahora está integrada en r12194 . El comportamiento actual se divide deliberadamente entre lo que es universal y lo que depende de un teclado físico:

• Coste, duración y motivo de rechazo: ordenador de sobremesa + Android
• Sugerencias de modificadores Ctrl/Shift: por ahora solo para escritorio.
• Semántica de construcción, enrutamiento y costos: sin cambios

El conjunto de regresión está en verde en 292/292 , incluidos los casos RHT/LHT. La ruta específica de Android se verificó mediante compilación con

Code Select Expand

__ANDROID__Todavía no he realizado una prueba real con Android NDK/dispositivo, así que no quiero afirmar que se haya realizado una validación de Android en tiempo de ejecución que aún no se ha producido.
También revisé el punto sobre la configuración de Ctrl. La implementación actual toma

Code Select Expand

straight_way_without_controlen cuenta, por lo que no anuncia Ctrl para el comportamiento de ruta recta cuando la construcción recta ya está forzada por la configuración.
Creo que el siguiente paso más importante es la dirección que ambos sugieren: en lugar de intentar reproducir las teclas modificadoras del teclado en dispositivos táctiles, hacer que las opciones de construcción sean explícitas e independientes del tipo de entrada.
El modelo que estoy investigando ahora es aproximadamente:
Teclado / táctil / entrada futura → opciones de construcción semántica → herramienta de construcción existente
Así, Ctrl y Shift seguirían siendo atajos de teclado rápidos, pero los conceptos que mostraría la interfaz serían, por ejemplo, Recto, Paralelo y Reemplazar , en lugar de "Ctrl" y "Shift". Por lo tanto, un usuario táctil nunca necesitaría abrir un teclado virtual ni saber qué tecla modificadora corresponde a cada acción.
También estoy analizando detenidamente el diálogo de espaciado de señales existente como precedente en el juego. El primer objetivo es un pequeño diálogo de construcción avanzada que se pueda abrir sin teclado y que configure la herramienta de construcción ya seleccionada, sin duplicar la lógica de enrutamiento/construcción.
En cuanto al tamaño de la pantalla, creo que la separación útil es:
Cerca del puntero: mantenga la información concisa que sea inmediatamente relevante para la acción actual: coste, duración, motivo del rechazo y el comportamiento actual de la información sobre herramientas.
Diálogo avanzado: opciones de construcción persistentes y, posteriormente, si resulta práctico, selección de vía/puente/túnel y una vista previa más detallada.
Eso debería evitar los dos problemas opuestos que mencionaste: en pantallas pequeñas no llenamos el espacio vertical con información permanente, mientras que en pantallas grandes la información relacionada con la construcción actual no termina muy lejos del puntero.
I will test the design at desktop resolutions and constrained Android-like resolutions before proposing an implementation. The intention is for the same semantic construction UI to work on desktop, Android, Windows/Linux touch screens and Android devices with a physical keyboard, rather than creating an Android-specific version of the construction tools.
One transparency note about r12194: the integrated version also contains two refinements developed after the patch originally posted in this thread, so it is somewhat larger than the version reviewed here. They were regression-tested together, but those later refinements were not part of the originally posted patch.
There is also one small observable scripting detail: some rejected

Code Select Expand

command_x paths that previously propagated an empty string can now preserve the actual rejection text. The accept/reject decision, route, cost and resulting world state are unchanged, but a third-party scenario explicitly checking

Code Select Expand

err == "" could observe that difference.
I will keep the advanced-construction work separate from r12194 and bring back a small, reviewable proposal with screenshots before considering any further integration.

[victor_18993]

Thanks for the feedback. I have now made the contextual construction information optional in r12195.
There is a new Show contextual construction information option in the display settings. It is enabled by default, so the current behaviour does not change unless the user disables it. On small screens this recovers the space used by the extra information band, while normal tooltips remain unchanged.
Android/touch behaviour is also unchanged: cost, length and rejection information can still be shown, but keyboard-only Ctrl/Shift hints remain suppressed.
I also tested the advanced construction dialog idea. The existing signal-spacing dialog is a good architectural precedent, and semantic controls such as Straight and Replace can be connected to the existing construction behaviour without duplicating the builder logic.

There are two points I would like to clarify before going further:

• What would be the preferred touch/mouse-accessible way to open the advanced construction dialog?
• When you mentioned a parallel option, did you mean a new explicit user-selectable mode? At the moment
  
  Code Select Expand
  prefer_parallel is derived internally from map geometry rather than being an existing player option.

One small limitation of r12195: the GUI toggle works immediately, but persistence through

Code Select Expand

settings.xml is currently behind the existing 124.6 settings-version gate while the current save version is 124.5. I left that untouched rather than changing the format version just for this option.

[Roboron]

Android/touch behaviour is also unchanged: cost, length and rejection information can still be shown, but keyboard-only Ctrl/Shift hints remain suppressed.

I could play on Android devices with a physical keyboard and big screens. And I have played on Linux (non-Android) phones without keyboard.

I don't know if we can detect if the user is playing with a physical keyboard, but that would be the best option. Second best is to show this information based on screen size. But definitely not based on OS.

What would be the preferred touch/mouse-accessible way to open the advanced construction dialog?

Currently this is done on Android by first pressing the "Ctrl" tool on the toolbar. I don't like it.

Another approach that comes to my mind: pressing the tool a second time to open the advanced construction dialog. Not sure how viable that is, and how that state should reflect on the toolbar.

[victor_18993]

Thanks, Roboron. 

I agree that detecting the presence of a physical keyboard would be preferable to making the decision based on the operating system. Screen size also sounds like a better fallback than an OS-specific rule.

The second-click idea is interesting too. If clicking an already selected construction tool does not currently have an important meaning, using the second click/tap to open the advanced construction dialog could provide a common mouse/touch-accessible solution without introducing an Android-specific workflow.

I'll look into whether that interaction can be implemented cleanly and how it could be reflected in the toolbar state.

[makie]

The second-click idea is interesting too. If clicking an already selected construction tool does not currently have an important meaning, using the second click/tap to open the advanced construction dialog could provide a common mouse/touch-accessible solution without introducing an Android-specific workflow.

The second click deselects the tool—effectively selecting the magnifying glass instead. You can disable this behavior in the settings.

I like the solution where the second click opens the settings.

I often accidentally deselect a tool by clicking on it a second time—usually because I forget to press Ctrl.

[prissi]

One could add one special construction tool, and there select all three components (way, bridge, tunnel). Maybe even in the main menubar, with tabs for the separate waytypes. That could clear up a lot of screen estate for paksets with compact menu bars and keep the screen clear of tools bars (only one window needed). Not relying on hidden modifier keys.

[victor_18993]

A small update on what we are currently working on.
One of the areas we are focusing on now is improving how Simutrans presents information to the player during construction and normal interaction.
The attached preview shows the direction we are exploring for the interface:

The goal is not to redesign Simutrans into a different game, but to make the existing depth easier to understand and use.
Recent work has already been moving in this direction by making construction feedback more explicit: showing what the active tool is doing, the expected length and cost, and, when something cannot be built, giving the player a useful reason instead of a generic failure.
We are now looking at how to extend that idea further so that important information is available where it is needed, without forcing the player to search through several windows or documentation pages.
The main principles we are trying to preserve are:

• keep the existing simulation and gameplay depth;
• reduce unnecessary ambiguity in the interface;
• make construction tools easier to understand;
• provide clearer contextual feedback;
• improve usability on different screen sizes and input methods;
• avoid platform-specific solutions where a common interaction can work for desktop and touch devices.

This is still work in progress, so the preview should not be taken as a final interface design. The intention is to test the ideas incrementally and keep only the changes that genuinely improve usability without getting in the way of experienced players.
Feedback is very welcome, especially about what information you would find useful to have immediately available while building or managing a network.

[makie]

@ victor_18993
Please do not use postimg.cc or similar services to upload and embed images. We have no control over those links. When I click on your linked image to view a larger version, I get delight with porn. Also, such images often disappear suddenly or eventually start linking to something else what doesn't make us happy.

I have already asked pumuckl999 not to do this—without success—but I'm giving it another try anyway. He argued that it's easy and doesn't require registration, but his screenshot thread looks absolutely terrible now after time:
https://forum.simutrans.com/index.php/topic,9594.0.html
or in the German forum:
https://www.simutrans-forum.de/mybb/showthread.php?tid=3061&page=216

If you don't use the forum, there is this option:
https://simutrans-germany.com/ --> Dateiaustausch

Or via the translator, you may not expect this.
You are Co-Maintainer of "Base texts" and as such you can go to "Manage Objects" there is "File upload" choose destination directory "victor_18993" (yes it exists) there you can store nearly unlimited.
The link to this files is "https://simutrans.net/victor_18993/filename.anything"
And if anything not work at your wish, then ask me (makie) i can find a solution as maintainer of this translator.

Example:

[victor_18993]

Sorry about that, Makie. I was using Postimg because the forum is still not allowing me to upload images or attachments properly, so I used it as a workaround.

I take note of what you said and I won't use that service again.

Thank you very much for pointing me to the SimuTranslator upload option and explaining how to use it. That should solve the problem for me while the forum uploads are still not working.