Hi everyone,
A small quality-of-life addition I would like your read on before doing anything more with it.
What it does
The stop information window gets one small button, "Show destination map", below the Happy / Unhappy / No route figures. Pressing it opens the existing minimap (map_frame), brings it to the front if it is already open, switches it to the passenger-destination overlay (PaxDest) and selects the town nearest to the stop. So from a stop you are looking at, one click shows where that town's passengers are trying to go, without hunting for the city window first.
One honest point on the semantics
Passenger destinations are recorded per city, not per stop. So the button deliberately shows the current-month destinations of the nearby town, and its tooltip makes that explicit ("Show current-month passenger destinations for the nearby city"). It does not claim to show only the passengers that failed at that specific stop, and it adds no per-stop storage.
How it fits the existing code
I tried to stay inside what already exists rather than add anything parallel:
- It reuses the real minimap: minimap_t::set_selected_city() plus the existing MAP_PAX_DEST overlay mode. MAP_PAX_DEST is an overlay flag, so it is OR-ed into the current base map mode rather than replacing it.
- The stop window does not touch the map frame's internals. There is one small public method, map_frame_t::show_pax_destinations(city), that selects the city, enables the mode and syncs the map's filter buttons. It does not reposition the minimap viewport.
- The one non-obvious detail: selecting a city records that city's current destination change-counter, so already-existing destinations would not repaint until a new one appeared. A small minimap_t::invalidate_pax_destinations() resets that counter so the destinations you already have show immediately.
- Nothing is serialised, the savegame format is unchanged, routing and the schedule are untouched, and the button disables itself when the world has no cities. The window opens/raises through the window registry (a create_win failure cannot leave a dangling pointer).
Validation
Builds clean on trunk (no new warnings in the touched files). The patch is small: 7 files, +61 lines, GUI only (halt_info, map_frame, minimap, two English translation pairs in en.tab). Screenshots attached: the button in the stop window, the destination map opening with the nearby town selected, and the switch from another map mode. In the screenshots the markers are magenta because the demonstration stop has no line yet, so every passenger is "no route" - that is expected, not a bug.
Deliberately out of scope for this first cut
No per-stop destinations, no "No route only" filter, no Current/Previous selector, no dedicated legend, no "next destination" button. I did not want to guess at those before hearing whether the basic shortcut is wanted and whether reusing the city-level PaxDest overlay is the right call.
What I would appreciate your view on
- whether a per-stop shortcut into the city-level destination overlay is a welcome addition;
- whether the small public method on map_frame_t is an acceptable seam, or you would prefer it exposed differently;
- and whether the wording keeps the per-city vs per-stop distinction clear enough for players.
Thanks for taking a look.
There is already such an overlay, just open the city window and select Destination on the minimap. However, the overlay was broken indeed. Fixed in r12103
With stops, I am not a great fan as this is very misleading since its not the origins or destinations of that stop. Also, there are stops in the middle of nowhere.
Thanks, that makes sense.
I tried to make the city-level semantics explicit in the tooltip, but I agree
that placing the action in the stop window still suggests that the displayed
destinations belong to that stop, especially for rural stops.
I have also reviewed r12103. It fixes the repaint problem and makes the city
window responsible for the minimap's selected city, so the additional minimap
invalidation and stop shortcut in my patch are no longer appropriate.
I will withdraw the current patch.
The original usability problem was understanding the "No route" count shown
at a stop. Addressing that accurately would require real stop-specific failed
destination information, which is a different and larger proposal. I will not
pursue that without discussing the data model first.
Thank you for reviewing it and for fixing the existing overlay.