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

Change [filter_weapon] to not depend on attack_type::weapon_specials #6501

Merged
merged 1 commit into from Feb 10, 2022

Conversation

stevecotton
Copy link
Contributor

This changes it to use the function that attack_type::get_value already uses,
thus removing a call to attack_type::weapon_specials. The latter is being
refactored by @newfrenchy83, and questions about the effect of that refactor on
this code delayed the review on his PR.

This code is part of the object used for [filter_weapon]formula=, however the
implementation of that filter creates exactly one attack_type_callable, so
doesn't trigger this code. For testing I called it via a debugger.

@stevecotton stevecotton added Enhancement Issues that are requests for new features or changes to existing ones. Units Issues that involve unit definitions or their implementation in the engine. labels Feb 9, 2022
@stevecotton stevecotton self-assigned this Feb 9, 2022
@github-actions github-actions bot added the WFL Issues involving the Wesnoth Formula Language engine and APIs. label Feb 9, 2022
@stevecotton
Copy link
Contributor Author

@newfrenchy83 sorry it's taking so long to review that PR, but it hasn't been forgotten.

I'm expecting the CI build to fail on flatpak, which is waiting for a new version of an SDK to be uploaded to dockerhub.

@newfrenchy83
Copy link
Contributor

@stevecotton i commited 27429f5 for resolve that.

@stevecotton
Copy link
Contributor Author

Thanks, but my motivation for writing this was to get rid of the only_active argument from attack_type::weapon_specials; I think this is the only place that called it with only_active set to false.

@newfrenchy83
Copy link
Contributor

Thanks, but my motivation for writing this was to get rid of the only_active argument from attack_type::weapon_specials; I think this is the only place that called it with only_active set to false.

when this PR will be merged, i remove only_active argument in my PR

const auto& s = self_specials[i].cfg["id"];
const auto& o = other_specials[i].cfg["id"];
if(s != o) {
return s.str() < o.str() ? -1 : 1;
Copy link
Member

Choose a reason for hiding this comment

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

Any reason not to just return s.compare(o)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will change to s.str().compare(o.str()), thanks. They're both config_attribute_value objects, so there isn't a direct compare(), but I forgot to look again for a compare() function after realising that I needed to convert them to strings.

Copy link
Member

Choose a reason for hiding this comment

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

I realize this is a bit late now that it's merged, but you could also do:

auto result = s.str().compare(o.str());
if(result != 0) return result;

That way you compare it only once instead of potentially twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea, I'll remember that next time. However, for the backport I think it's good to keep the code the same as this already-merged version.

@CelticMinstrel
Copy link
Member

This seems fine to me.

This changes it to use the function that attack_type::get_value already uses,
thus removing a call to attack_type::weapon_specials. The latter is being
refactored by newfrenchy83, and questions about the effect of that refactor on
this code delayed the review on his PR.

This code is part of the object used for [filter_weapon]formula=, however the
implementation of that filter creates exactly one attack_type_callable, so
doesn't trigger this code. For testing I called it via a debugger.
@stevecotton stevecotton merged commit 6ccac5a into wesnoth:master Feb 10, 2022
@stevecotton stevecotton deleted the wfl_compare_weapon_specials branch February 10, 2022 05:40
knyghtmare pushed a commit to knyghtmare/wesnoth that referenced this pull request Feb 15, 2022
Fixes the currently suspected root cause of wesnoth#5108, but requires further testing
to confirm that it fixes that issue.

Closes wesnoth#6501 (the question of how to test the mapgen filter).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Issues that are requests for new features or changes to existing ones. Units Issues that involve unit definitions or their implementation in the engine. WFL Issues involving the Wesnoth Formula Language engine and APIs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants