Opened 18 years ago
Last modified 18 months ago
#57 new task
[PATCH] Minimap — at Version 19
Reported by: | Stuart Walpole | Owned by: | wraitii |
---|---|---|---|
Priority: | Should Have | Milestone: | Work In Progress |
Component: | UI – In-game | Keywords: | beta patch |
Cc: | andy011973@… | Patch: |
Description (last modified by )
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.
Change History (20)
comment:1 by , 18 years ago
Description: | modified (diff) |
---|
comment:2 by , 18 years ago
Description: | modified (diff) |
---|
comment:3 by , 14 years ago
Milestone: | Multiplayer Demo |
---|
comment:4 by , 14 years ago
Milestone: | → Backlog |
---|---|
Owner: | set to |
comment:5 by , 14 years ago
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.)
comment:6 by , 13 years ago
Owner: | removed |
---|
comment:7 by , 10 years ago
Component: | Core engine → UI & Simulation |
---|---|
Description: | modified (diff) |
I think points 4 and 5 can be considered fixed.
comment:8 by , 8 years ago
Keywords: | beta added |
---|
comment:9 by , 8 years ago
Milestone: | Backlog → Alpha 22 |
---|
comment:10 by , 7 years ago
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?
comment:11 by , 7 years ago
Milestone: | Alpha 22 → Work In Progress |
---|
comment:12 by , 7 years ago
Keywords: | patch added |
---|---|
Summary: | Minimap → [PATCH] Minimap |
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 customstring
in thexml
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 theAddSetting
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?
comment:14 by , 7 years ago
Cc: | added |
---|
comment:15 by , 7 years ago
Is the feature mentioned in ticket:3491 covered by this ticket? I couldn't quite tell from the description.
comment:16 by , 5 years ago
Component: | UI & Simulation → In-game UI |
---|
Move tickets to In-game UI
as UI & Simulation
got some sub components.
comment:17 by , 3 years ago
Description: | modified (diff) |
---|---|
Owner: | set to |
comment:19 by , 3 years ago
Description: | modified (diff) |
---|
Milestone Multiplayer Demo deleted