[PATCH] Minimap

[Stuart Walpole]

• Right-click on minimap to give target to selection (cursor should update accordingly).

• Minimap customisation JS to set colour/visibility of blips and background ... toggle different object groups and background, set group colours, etc ... See Session GUI design).

• Can fire events which trigger a flash on the minimap if the camera doesn't have that event in view (eg ping on MiniMap when under attack or a new production is complete; can cycle through most recent ping locations eg Spacebar). (r25691)

• The minimap rectangle-thingy is still a little off from the real position of the camera and gets confused if one changes the camera view.

• Something significant can happen on the map (for example, units attacking the player somewhere other than the current camera view, or research of a technology is completed, or a new unit could be trained). This "alert" consists of a flash on the minimap at the location where the alert originated, and optionally some text (in the message window) and/or sound indicator. A signal flare is an example of an alert that is placed deliberately by a player. The position of the last few alerts are also stored in a list. Hitting the Spacebar cycles the camera through these notifications.

[(none)]

Milestone Multiplayer Demo deleted

[Erik Johansson]

I suggest using some other key than spacebar. At least to me I associate the spacebar with "center-on-selected-unit", mostly from playing AoK, but I think some other games use it as well, don't quote me on that though. In any case I think a central key like spacebar should be used for something more common than cycling through minimap events :) (AoK used Home for cycling through the last events - not on the minimap, but other important things - as far as I know.)

[Josh]

I think points 4 and 5 can be considered fixed.

[wraitii]

proof of concept

[wraitii]

Hacked together the above proof of concept for point 2: click in the upper-left part of the minimal and you'll open a small panel with checkboxes. Disabling those will disable rendering of the corresponding stuff on the minimap.

Some design decisions before going further:

-How many types of minimal object do we want? Right now we have 9 (defined in CCmpMinimap.cpp), which seems high. They also aren't used afaik. I would restrict it to "Resource", "Military", "Support", "Structure", and possibly throw in "Hero" separately.

-Regarding layers, I think we should have one per above type + territory (showing them or not).

-Where should the check go? Should gui/Minimap be in charge or CCmpMinimap?

-How should the setting be stored? I used the GUI setting thing, which worked well enough.

-Should this be dynamic/stored in a JSON/hardcoded? Given current design hardcoded is easiest. Possibly we should load possible types from a JSON/xml files? But then validation would be at startup unless I'm wrong. Also can the code add GUI elements dynamically?

-I planned on adding a "zoom/magnifying" option that would highlight only that setting. E.G. it would turn the terrain shades of gray, and show just the color of what you selected. Is that a good idea?

[elexis]

Question: Does anyone know why CCmpMinimap.cpp isn't a JS component?

Independent Feature Request: Team colors (one color for each team, all players of a team being assigned the same color).

Review: The approach of the patch heads in the right direction, but all the hardcoding in C++ must be replaced with a dynamic/agnostic approach (see below for that and the other points that match my questions when reading the patch).

New Requirement? We could think about units being part of multiple layers (for example an entity being a hero/military unit/structure and an objectives-relevant entity).

Answers:

How many types of minimal object do we want?

That's the modders decision.

For the public mod:

• Resources: Having one layer for each resource type seems useful, because players can hide fruit trees, forests and focus on mines. But technically this is a pita as we can't construct or extend the enum dynamically. Instead of we could allow specifying a custom string in the xml MiniMap schema to define layers. Some maps also have much stone but few metal.

• There should be a minimap layer to show objective-relevant entities (for example the wonder in wondergame mode, heroes in regicide mode, some settlements or characters in some hypothetical campaign)

• Traders would be nice to have, especially for those specializing in raiding trade.

They also aren't used afaik

Revive or amputate.

Where should the check go?

You mean the players decision which layers to show? GUI. The simulation only offers the choices (because the choices are used in the simulation templates).

How should the setting be stored? I used the GUI setting thing

GUI setting thing is good, but it shouldn't be hardcoded. Pass an array of strings of visible layers, or create the boolean options depending on the XML/JSON defined types (similar like COList.cpp passes the list_ arrays).

Should this be dynamic/stored in a JSON/hardcoded?

Exactly. XML or JSONfiles should define which layers can be shown in the GUI object.

So either we'd have to

• (a) derive the minimap choices from all available entity templates
• (b) add a new directory with a file for each valid minimap choice (simulation/data/minimap/?)

Either way, the choices have to be known

• in the ctor of source/gui/MiniMap.cpp (for the AddSetting calls)
• in session/*.js, to setup the labels and checkboxes dynamically
• if (b), in GetSchema source/simulation/CCmpMinimap.cpp (unless we drop XML validation checks for minimap types that aren't declared in the new files)

An implementation could resemble GetAllTechs of the DataTemplateManager.js' simulation component which is used from both JS and C++ (thus could be passed through the GUIInterface), or something in public/globalscripts/` whose functions are exposed to all GUI and simulation JS and C++.

Given current design hardcoded is easiest

In the end it might be more work to change and rebase C++ code when changing things for example/and account for #3934.

validation would be at startup

Option 1) We could validate that types is a string, like Identity.js checks for Classes and VisibleClasses (which are being used with MatchClassList). Option 2) A more precise check would resemble the behavoir of simulation/helpers/Resources.js, but that's JS, we need if in C++.

can the code add GUI elements dynamically?

The minimapDetailsPanel in minimap_panel.xml should use repeated to remove hardcoding in XML. That comes with a hardcoded upper limit (something like 15) which should correlate to the maximum number of entries that can be shown on 1024x768 and trigger an error if exceeded (using a .children.length check, see #3934 for example).

I planned on adding a "zoom/magnifying"

Isn't it more highlighting?

[elexis]

Refs #4404

[Andy Alt]

Is the feature mentioned in ticket:3491 covered by this ticket? I couldn't quite tell from the description.

[Imarok]

Move tickets to In-game UI as UI & Simulation got some sub components.

[Imarok]

In 25691:

Map flares

Add flaring on the map and resize the minimap buttons.
Target marker and button by Stan.
Reviewed/Commented by wraitii, elexis, vladislavbelov
Refs: #3491
Refs: #57

Differential Revision: ​https://code.wildfiregames.com/D1751

[phosit]

[27169] adds background to the minimap