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

fix [firststrike] special with apply_to=opponent crashes Wesnoth 1.17.x #6574

Merged

Conversation

newfrenchy83
Copy link
Contributor

like reported in forum in https://forums.wesnoth.org/viewtopic.php?p=672374#p672374
if unit with "last strike" ([firststrike] special with apply_to=opponent, on any of its attacks) is targeted by other unit for attack, wesnoth crashes,
and other problems exist also for other weapon specials like poisons, when apply_to=opponent used(id two user of this specials fight, one fighter only could be poisoned)

@github-actions github-actions bot added the Units Issues that involve unit definitions or their implementation in the engine. label Mar 22, 2022
@Wedge009 Wedge009 added the WML Issues involving the WML engine or WML APIs. label Mar 23, 2022
@newfrenchy83 newfrenchy83 force-pushed the fix_special_with_apply_to_opponent branch from 77222e6 to 93ddc19 Compare March 24, 2022 16:26
@newfrenchy83 newfrenchy83 reopened this Mar 24, 2022
@newfrenchy83
Copy link
Contributor Author

@Pentarctagon why the checking don't work?

@github-actions github-actions bot added the Unit Tests Issues involving Wesnoth's unit test suite. label Mar 24, 2022
@newfrenchy83
Copy link
Contributor Author

@Pentarctagon test added and validated here too.

@newfrenchy83 newfrenchy83 force-pushed the fix_special_with_apply_to_opponent branch from 7306a2f to 29cfe1b Compare March 26, 2022 17:10
like reported in forum in https://forums.wesnoth.org/viewtopic.php?p=672374#p672374
if unit with "last strike" ([firststrike] special with apply_to=opponent, on any of its attacks) is targeted by other unit for attack, wesnoth crashes,
and other problems exist also for other weapon specials like poisons, when apply_to=opponent used(id two user of this specials fight, one fighter only could be poisoned)
@newfrenchy83 newfrenchy83 force-pushed the fix_special_with_apply_to_opponent branch 2 times, most recently from f4f8d84 to abc4096 Compare April 1, 2022 11:27
src/units/abilities.cpp Outdated Show resolved Hide resolved
@newfrenchy83
Copy link
Contributor Author

@Pentarctagon don't forget this PRfor master branch

@Pentarctagon
Copy link
Member

@stevecotton should I look at this one as well, or did you only mean the 1.16 version of the PR?

src/units/abilities.cpp Outdated Show resolved Hide resolved
@newfrenchy83
Copy link
Contributor Author

@stevecotton should I look at this one as well, or did you only mean the 1.16 version of the PR?

Like i added @stevecotton test today, i could said yes, but i is my own opinion.

// True if "whom" corresponds to "self", false if "whom" is "other"
bool whom_is_self = ((whom == AFFECT_SELF) || ((whom == AFFECT_EITHER) && special_affects_self(special, is_attacker)));
unit_const_ptr whom_unit = whom_is_self ? other : self;
map_location whom_loc = whom_is_self ? other_loc : self_loc;
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I was confused when suggesting names. whom_unit would make sense for the unit that is whom, but the unit here is the opponent of whom. How about whom_is_self, them_unit and them_loc; alternatively whom_is_self, them, their_loc?

So the comment could be

// There are only two units involved in this logic, but three pairs of names for them: {self, other},
// {attacker, defender} and {whom, them}.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@stevecotton names changed, but i not added comment.

@stevecotton
Copy link
Contributor

@stevecotton should I look at this one as well, or did you only mean the 1.16 version of the PR?

I think it's good, except for the mixed-up names (sorry newfrenchy83, those were my fault). Comments would be welcome, but I think it'll be ready to merge once those names change.

It behaves as expected with the tests in PR #6582 - the ones that say "known bug in 1.16" fail and all the other pass. That's good, I'll open a PR with the 1.17 versions of those tests once this merges.

Copy link
Contributor

@stevecotton stevecotton left a comment

Choose a reason for hiding this comment

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

I'm sure the CI is going to pass, but will wait for it.

@stevecotton stevecotton merged commit 650f704 into wesnoth:master Apr 8, 2022
@newfrenchy83 newfrenchy83 deleted the fix_special_with_apply_to_opponent branch April 8, 2022 09:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unit Tests Issues involving Wesnoth's unit test suite. Units Issues that involve unit definitions or their implementation in the engine. WML Issues involving the WML engine or WML APIs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants