Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add tooltip to unit_attack dialogs #6462

Merged
merged 9 commits into from May 18, 2022

Conversation

newfrenchy83
Copy link
Contributor

@newfrenchy83 newfrenchy83 commented Jan 25, 2022

in tooltip, the special and weapon_abilities are listed by stats (damage, attacks and chance to hit) and owner of each is specified.
replace #6399 for readibility purpose.

@github-actions github-actions bot added UI User interface issues, including both back-end and front-end issues. Units Issues that involve unit definitions or their implementation in the engine. labels Jan 25, 2022
@newfrenchy83 newfrenchy83 force-pushed the unit_attack_gui_tooltip branch 3 times, most recently from 5deadf3 to b261276 Compare January 25, 2022 17:39
src/units/abilities.cpp Outdated Show resolved Hide resolved
src/units/abilities.cpp Show resolved Hide resolved
src/units/abilities.cpp Outdated Show resolved Hide resolved
for (const config::any_child sp : specials_.all_children_range()) {
if((checking_tags.count(sp.key) != 0)){
const bool active = special_active(sp.cfg, AFFECT_SELF, sp.key);
add_name(weapon_abilities, active, sp.cfg["name"].str(), checking_name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't follow the logic of this function - it seems that weapon_abilities is a temporary string that's used for assembling parts of other strings called self_abilities etc, and if that's what it is then I don't see why weapon_abilities is in scope for the whole function. I also can't see why it's an input parameter to the weapon_specials_*_self functions, as it seems to be an output from those.

However, this line uses it purely as an output, and IIUC the value set here would be discarded, were it not for the first weapon_specials_impl_self call taking it as an input, and then possibly concatenating other values to it before copying it to self_abilities. However, that happens in a conditional block that only happens if self_ is non-null (which might always be true, but then why is there a conditional block)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weapon_abilities used mike reference,in add_name, i cannot put other stinrg in input or i put the code itself. I will try ths option.

@newfrenchy83 newfrenchy83 force-pushed the unit_attack_gui_tooltip branch 2 times, most recently from 1b2551a to ea7bcc0 Compare January 27, 2022 17:12
@newfrenchy83
Copy link
Contributor Author

@stevecotton i removed only_active argument to attack_type::weapon_specials()

@newfrenchy83 newfrenchy83 force-pushed the unit_attack_gui_tooltip branch 2 times, most recently from 6fd19cd to 4857bcd Compare February 11, 2022 11:35
@newfrenchy83
Copy link
Contributor Author

@stevecotton PR rebased

in tooltip, the special and weapon_abilities are listed by stats (damage, attacks and chance to hit) and owner of each is specified.
"Self: " replaced by "Owned: ", #Teachers: " by #Teached: " and "Opponent: " by "Inflicted (by opponent): "
@newfrenchy83
Copy link
Contributor Author

@stevecotton it is long time what PR not reviewed.

@newfrenchy83
Copy link
Contributor Author

@Vultraz it is a long time what this PR not reviewed, could you give an advice, see what this PR is a UI work.

@Pentarctagon
Copy link
Member

Can you post a screenshot of what it looks like with this PR's change applied?

@newfrenchy83
Copy link
Contributor Author

Can you post a screenshot of what it looks like with this PR's change applied?

teached: (cantor encoded in Elvish Captain and leadership)
tooltip_teached

teached by an enemy(diversion ability)
tooltip_teachedenemy

used by opponent(formation ability)
tooltip_usedopponent

@newfrenchy83
Copy link
Contributor Author

@Pentarctagon @Vultraz , i have a question, with abilities/specials showed in tooltip, show the weapon teached by enemy or used by opponent in attack prediction windows is useful, or must i show in tooltip only for not give heavy the window itself, and show in window weapon owned or teached by allies?

@Pentarctagon
Copy link
Member

I'd say to keep it just in the tooltip for now. Given how long this PR has already been open already, let's not add more to it.

@newfrenchy83
Copy link
Contributor Author

I'd say to keep it just in the tooltip for now. Given how long this PR has already been open already, let's not add more to it.

except what 'diversion' and formation both in window in this PR, must becommit a remove of that or don't commit anymore?

@newfrenchy83
Copy link
Contributor Author

@Pentarctagon i reformulate my question: 'diversion' and 'formation' name must appear in window(without mention of origin) or not? And if not, must commit that in this PR or i another PR after merging in master?

@Pentarctagon
Copy link
Member

I think it'd be best to see what vultraz says first.

Just as far as wording goes though, for correctness:

  • "teached" should be changed to "taught" in the above screenshots.
  • "enemy" is misspelled as "ennemy".
  • "others aspect" should be "other aspects".

@newfrenchy83
Copy link
Contributor Author

I think it'd be best to see what vultraz says first.

Just as far as wording goes though, for correctness:

* "teached" should be changed to "taught" in the above screenshots.

* "enemy" is misspelled as "ennemy".

* "others aspect" should be "other aspects".

i post screenshot of modification in done in my local:
taught(leadership and cantor)
tooltip_taught

taught by enemy(divesion in tooltip only):

tooltip_teachedenemy_no_window

used by opponent(formation):

tooltip_usedopponent_no_window

if @Vultraz is ok, then i commit change, or changes acceptable.

@newfrenchy83
Copy link
Contributor Author

@Pentarctagon excuse my lack of patience but i would post remording in PR, and i let what weapon owned or taught by allies in window.

@stevecotton
Copy link
Contributor

I apologise for how long it's taken me to review this, and thank @Vultraz for reviewing the UI.

My plan is to merge this evening, unless anyone has more to say. If I have any more ideas about possible refactoring, I'll create a new PR on top of this instead of blocking this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UI User interface issues, including both back-end and front-end issues. Units Issues that involve unit definitions or their implementation in the engine.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants