Opened 12 years ago
Closed 8 years ago
#1646 closed enhancement (fixed)
[PATCH] Show unmet requirements in technology icon tooltips
Reported by: | zoot | Owned by: | |
---|---|---|---|
Priority: | Nice to Have | Milestone: | Alpha 22 |
Component: | UI & Simulation | Keywords: | patch |
Cc: | Patch: |
Description
Show unmet requirements in technology icon tooltips.
See this thread for discussion.
Attachments (1)
Change History (12)
by , 12 years ago
Attachment: | techtiphack3.diff added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|---|
Component: | Core engine → UI & Simulation |
Milestone: | Backlog → Alpha 12 |
comment:2 by , 12 years ago
Cc: | removed |
---|---|
Keywords: | patch review added |
follow-up: 5 comment:3 by , 12 years ago
Keywords: | review removed |
---|
comment:4 by , 12 years ago
Milestone: | Alpha 12 → Alpha 13 |
---|---|
Priority: | Should Have → Nice to Have |
Moved to the next release as further work is required.
comment:5 by , 12 years ago
Sorry, I seem to have missed the last comments here.
Replying to historic_bruno:
- We should probably go ahead and plan on handling multiple requirements per tech, which may need a recursive design of the tooltip string building function.
Would it not be better to do that when multiple requirements are implemented? Then we will know how the format will look.
- The required count appears red, as if it's an unmet requirement. It will remain red even when the count is satisfied, which is an inconsistency in the UI. The logic would only grow messier to solve that with conditional colors or visibility.
This is not strictly true. When the count is satisfied, the check on unit_commands.js:673 will fail, and the string won't be shown in the tooltip.
- I think the logic in
GetRequirementsVars()
should be combined withgetFormattedRequirementsTooltip()
GetRequirementsVars()
is really just a glorified getter, modelled on the structure of CheckTechnologyRequirements()
. The idea being that all the logic for parsing technology requirements should be contained in the component to which it is native.
I can copy it over if you insist, but then the logic has to be maintained in two different files. Alternatively, I could try to find a way to combine GetRequirementsVars()
and CheckTechnologyRequirements()
(or at least have one call the other)?
comment:6 by , 12 years ago
Milestone: | Alpha 13 → Alpha 14 |
---|
comment:7 by , 11 years ago
Milestone: | Alpha 14 → Alpha 15 |
---|
comment:8 by , 11 years ago
Milestone: | Alpha 15 → Alpha 16 |
---|
comment:9 by , 10 years ago
Milestone: | Alpha 16 → Backlog |
---|
comment:10 by , 10 years ago
It'd be nice to indicate which structures actually count as village/town phase structures on their individual structure tooltips for newer players.
comment:11 by , 8 years ago
Milestone: | Backlog → Alpha 22 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
In r19120 by fatherbushido:
Merge different logics of technology requirements and fix the related bugs. Create a global script which derive the technology requirements objects in a form usable for structure tree, gui, simulation and AI. Reviewed by mimo (for AI) and fatherbushido. Fixes #3993, #1646, #4263, #4217. Refs #4108.
In r19121 by fatherbushido:
Add a simulation test to the previous commit of s0600204's patch. Refs #4263.
Some comments from looking at the patch:
GetRequirementsVars()
should be combined withgetFormattedRequirementsTooltip()
I guess the question is: do we want to keep this as simple as possible and only handle the case of a single class requirement per tech (which could be easily special-cased), or do we want to make it super flexible and handle all possibilities? The former would certainly be a simpler, neater solution. I don't know if we plan any techs that require a more complicated solution.