You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Classic region map does not systematically identify the buildings in the world. A town or region name may be visible, and some buildings have hover-only tooltip rectangles, but a player cannot tell what most buildings are without moving the pointer over them one at a time.
The screenshot and comment carried over from the original issue show the problem in Brynknot: “Add a small name or icon to the buildings here.” Brynknot is only a useful example of the problem; this issue must cover every building represented on the world region maps, not just Brynknot or Strakewood.
Reproduction
Enter any settled or explored part of the Classic world; Brynknot is one example.
Press R (or open the region map from the UI).
Look at the buildings at the default zoom without moving the mouse.
Hover the buildings one by one.
Actual:
Building identity is not consistently visible at a glance.
Where a tooltip exists, the useful name or description is only revealed after hovering.
Unique buildings and important NPC locations have no consistent compact map marker.
Expected:
Every building in the playable world has one persistent region-map marker: a generic icon when its function is recognizable, or a small concise label when it is a unique/non-generic building.
Common services are easy to recognize, including post offices, smithies/blacksmiths, shops, taverns/inns, banks, temples/priest buildings, libraries, and comparable building types.
Existing hover text remains available for the full description and is not replaced by the compact marker.
Markers obey the existing region-map fog-of-war behavior and do not reveal undiscovered areas.
Scope
Inventory all authored buildings that can appear on the world/region maps, including buildings in cities and villages, isolated structures, named manors, important NPC buildings, guild or quest locations, and other player-facing buildings. Do not make Brynknot the boundary of the work.
Use one marker per logical building. Repeated map objects that exist only to calculate an automatic tooltip rectangle must not create duplicate icons or labels. The inventory should record the source map, the building/category, the region-map anchor, the marker form, and the tooltip that remains associated with it.
Apply the following presentation rules:
Use one consistent icon for each common building category. At minimum, investigate icons for a post office/mail service, smithy/forge, general shop, magic shop, tavern/inn, bank, temple/church/priest, library, and equivalent categories found during the world inventory.
Use a small concise text label for a non-generic building that does not have a truthful reusable category icon, especially an important NPC, manor, guild, or quest building. Examples include Manor of Maplevale and other named locations.
Use an icon plus a short name only when the combination is necessary to distinguish an important location; do not fill the map with long descriptions.
Keep the current detailed hover tooltip, including its authored wording and automatic span behavior, unless a separate content correction is explicitly identified.
Existing implementation path
This should use the existing authored map metadata and text markup, not a new map-marker or tooltip system:
client_map_info already supports sub_type 1 for a persistent label and sub_type 2 for a hover tooltip. The server/world-maker generates the region-map definition from the authored map data; generated client-maps/*.def files must not be edited by hand.
The Classic client already renders region-map label text through text_show with TEXT_MARKUP | TEXT_OUTLINE. The existing markup supports [img=...] for a specific game face and [icon=...] for a game face or a named client texture. Therefore an icon can be carried by the existing label text, for example with the eventual equivalent of [icon=building_smithy 18 18 1], while a unique location can use a compact text label.
No new server/client protocol field or marker subsystem is expected. Adding or registering the selected image assets in the normal resource/content pipeline is part of this work, but it should not require new gameplay or networking code. The final choice between client textures and game-face assets must be made after checking how the selected pack can be distributed to Classic clients.
Selected icon pack
Use Resource and building icons (Unknown Horizons) as the primary and consistent visual source for the common building icons in this issue. This is no longer just a candidate or an optional fallback.
It is a 2D medieval/strategy GUI set intended specifically for resources and buildings.
The OpenGameArt page reports 40 building icons at approximately 46x46 px, plus 44 resource icons at 32x32 px, with transparent PNG previews.
The page declares the set as CC-BY-SA 3.0 and provides the source previews and attribution context.
The consistent size and transparent-background presentation make it suitable for small region-map markers.
Select the required building icons from this pack, register them with stable project asset names, and use them for recurring categories such as smithy, shop, tavern, bank, temple/priest, library, and post office/mail where the source has an appropriate symbol. Review the actual icon silhouettes and palette at the region-map scale before placement; the source pack must remain recognizable after any resize or transparent-padding cleanup.
The pack may not contain an exact symbol for every Atrinik service. If a required category is missing, create or commission a small matching addition based on the Unknown Horizons visual treatment, or adapt an existing Unknown Horizons building icon where that remains truthful. Do not silently mix in an unrelated icon pack. Record the source files, CC-BY-SA 3.0 license, attribution, transformations, any derived additions, and final asset names in the normal provenance/credits record before importing anything.
Work to do
Enumerate every world-map building and its existing tooltip/anchor data. Use Brynknot as the pilot area, including the current Tavern, Library, Bank, Post Office, Apartments, Temple of Elathiel, Jonaslen location, and Manor of Maplevale examples, then continue through the rest of the world.
Classify each building as a common reusable category or a unique named location. Identify buildings currently missing tooltip metadata as well as buildings that already have hover text.
Adopt the Unknown Horizons pack as the primary icon source. Review its actual files at the region-map scale, map its icons to the recurring building categories, and document any same-style additions required for missing categories. Confirm visual consistency, readability, transparent padding, asset dimensions, distribution rights, attribution, and stable asset names before adoption.
Add one client_map_info label entry (sub_type 1) at a reviewed anchor for each logical building. Put the selected icon markup in the entry for generic buildings and a concise small label in the entry for unique buildings. Keep the existing sub_type 2 tooltip entries and their descriptions.
Check label/icon placement across the supported zoom range. Prevent overlap with neighboring markers, town/region names, coastlines, important map geometry, and the icon itself; adjust anchors or shorten labels where necessary.
Regenerate the Classic region-map data and inspect representative regions, including Brynknot, every building category, and a region containing unique NPC buildings. Verify fog-of-war behavior and that missing/unloaded assets fail visibly during testing rather than being accepted silently.
Acceptance criteria
The scope and implementation cover all buildings in the playable world, not only Brynknot or one region.
Every inventoried logical building has exactly one persistent icon or concise label, with no duplicate marker from repeated tooltip-span objects.
Common categories use the Unknown Horizons pack as their primary, consistent icon source; the mapping covers post office/mail, smithy/forge, shops, tavern/inn, bank, temple/priest, library, and all other recurring categories found in the inventory.
Any missing category icon is added or adapted in a visually consistent, properly licensed way rather than silently pulled from an unrelated pack.
Non-generic important buildings, including named NPC/quest buildings, have a small readable label when no truthful generic icon exists.
Existing detailed hover tooltips remain available, including the current Brynknot descriptions, and are not replaced with labels.
Markers are readable at the default region-map zoom, do not materially overlap, and remain within the supported zoom range.
Fog of war still prevents markers and details from exposing undiscovered areas.
The Unknown Horizons pack and any derived additions are explicitly approved for distribution, with source, license, attribution, transformations, and final asset names recorded; no unreviewed download is committed.
No new server/client protocol or gameplay behavior is introduced; only the existing map metadata/markup path and normal asset registration are used.
Generated client-maps output is regenerated for validation but is not treated as authored source.
python3 tools/validate.py, the relevant Classic/content validation, git diff --check, and a visual Classic region-map inspection pass.
Release-line handling
This is an authored content and asset issue. Implement the canonical correction in atrinik/content@main, then carry the equivalent map metadata and approved Unknown Horizons-based assets into the v1.x release/backport source that the Classic deployment uses. Validate the main and v1.x results separately, because a fix that exists only in current content does not correct an already-published Classic v1.x package.
The repository’s current content governance treats the old v1.x content history as frozen release evidence rather than a second mutable authoring source. If there is no live remote 1.x branch at implementation time, use the established release/backport worktree or package process; do not create a new branch or make generated output authoritative merely to satisfy this issue. See the historical content release-line discussion.
Non-goals
Replacing the existing hover-tooltip system.
Adding a new network/protocol contract, gameplay interaction, or clickable map feature.
Limiting the solution to Brynknot, Strakewood, or only the buildings that already have tooltip records.
Revealing undiscovered buildings or changing gameplay names, NPCs, regions, or map connectivity.
Importing unrelated icon packs or unreviewed derived assets when the selected Unknown Horizons source or a matching addition can cover the category.
Problem
The Classic region map does not systematically identify the buildings in the world. A town or region name may be visible, and some buildings have hover-only tooltip rectangles, but a player cannot tell what most buildings are without moving the pointer over them one at a time.
The screenshot and comment carried over from the original issue show the problem in Brynknot: “Add a small name or icon to the buildings here.” Brynknot is only a useful example of the problem; this issue must cover every building represented on the world region maps, not just Brynknot or Strakewood.
Reproduction
R(or open the region map from the UI).Actual:
Expected:
Scope
Inventory all authored buildings that can appear on the world/region maps, including buildings in cities and villages, isolated structures, named manors, important NPC buildings, guild or quest locations, and other player-facing buildings. Do not make Brynknot the boundary of the work.
Use one marker per logical building. Repeated map objects that exist only to calculate an automatic tooltip rectangle must not create duplicate icons or labels. The inventory should record the source map, the building/category, the region-map anchor, the marker form, and the tooltip that remains associated with it.
Apply the following presentation rules:
Manor of Maplevaleand other named locations.Existing implementation path
This should use the existing authored map metadata and text markup, not a new map-marker or tooltip system:
client_map_infoalready supportssub_type 1for a persistent label andsub_type 2for a hover tooltip. The server/world-maker generates the region-map definition from the authored map data; generatedclient-maps/*.deffiles must not be edited by hand.text_showwithTEXT_MARKUP | TEXT_OUTLINE. The existing markup supports[img=...]for a specific game face and[icon=...]for a game face or a named client texture. Therefore an icon can be carried by the existing label text, for example with the eventual equivalent of[icon=building_smithy 18 18 1], while a unique location can use a compact text label.client_map_infoarchetype definition.No new server/client protocol field or marker subsystem is expected. Adding or registering the selected image assets in the normal resource/content pipeline is part of this work, but it should not require new gameplay or networking code. The final choice between client textures and game-face assets must be made after checking how the selected pack can be distributed to Classic clients.
Selected icon pack
Use Resource and building icons (Unknown Horizons) as the primary and consistent visual source for the common building icons in this issue. This is no longer just a candidate or an optional fallback.
Select the required building icons from this pack, register them with stable project asset names, and use them for recurring categories such as smithy, shop, tavern, bank, temple/priest, library, and post office/mail where the source has an appropriate symbol. Review the actual icon silhouettes and palette at the region-map scale before placement; the source pack must remain recognizable after any resize or transparent-padding cleanup.
The pack may not contain an exact symbol for every Atrinik service. If a required category is missing, create or commission a small matching addition based on the Unknown Horizons visual treatment, or adapt an existing Unknown Horizons building icon where that remains truthful. Do not silently mix in an unrelated icon pack. Record the source files, CC-BY-SA 3.0 license, attribution, transformations, any derived additions, and final asset names in the normal provenance/credits record before importing anything.
Work to do
client_map_infolabel entry (sub_type 1) at a reviewed anchor for each logical building. Put the selected icon markup in the entry for generic buildings and a concise small label in the entry for unique buildings. Keep the existingsub_type 2tooltip entries and their descriptions.Acceptance criteria
client-mapsoutput is regenerated for validation but is not treated as authored source.python3 tools/validate.py, the relevant Classic/content validation,git diff --check, and a visual Classic region-map inspection pass.Release-line handling
This is an authored content and asset issue. Implement the canonical correction in
atrinik/content@main, then carry the equivalent map metadata and approved Unknown Horizons-based assets into the v1.x release/backport source that the Classic deployment uses. Validate themainand v1.x results separately, because a fix that exists only in current content does not correct an already-published Classic v1.x package.The repository’s current content governance treats the old v1.x content history as frozen release evidence rather than a second mutable authoring source. If there is no live remote
1.xbranch at implementation time, use the established release/backport worktree or package process; do not create a new branch or make generated output authoritative merely to satisfy this issue. See the historical content release-line discussion.Non-goals