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

Remove player from attack list upon death (Fixes a yellow skull issue) #2072

Merged
merged 4 commits into from
Jan 11, 2017

Conversation

dbjorkholm
Copy link
Member

@dbjorkholm dbjorkholm commented Jan 9, 2017

This should eliminate the possibility of receiving a yellow skull after killing another player (if none of them has any skull).

if (Player* player = attacker->getPlayer()) {
Party* party = player->getParty();
if (Player* attackerPlayer = attacker->getPlayer()) {
if (targetPlayer && attackerPlayer->hasAttacked(targetPlayer)) {
Copy link
Member

Choose a reason for hiding this comment

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

Get the target player here instead of up above where it is long unneeded yet.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fine, I'll move it xD

return;
}

auto it = std::find(attackedSet.begin(), attackedSet.end(), attacked->guid);
Copy link
Member

@ranisalt ranisalt Jan 11, 2017

Choose a reason for hiding this comment

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

A set is implemented as a red-black tree and it's faster to traverse with attackedSet.find(attacked->guid) than the generic std::find.


auto it = std::find(attackedSet.begin(), attackedSet.end(), attacked->guid);
if (it == attackedSet.end()) {
return;
Copy link
Member

Choose a reason for hiding this comment

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

You can save a few lines if you use != attackedSet.end() and erase in here.

@ranisalt
Copy link
Member

Is there an issue reporting this bug?

@dbjorkholm
Copy link
Member Author

No, I don't think there is (I'm unable to find one at least).

return;
}

auto it = attackedSet.find(attacked->guid);
Copy link
Member

Choose a reason for hiding this comment

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

Note that hasAttacked that is called before this function already performs this check. You probably don't need to check hasAttacked then.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's better to be safe than sorry, as later it can be used in other context if need be

Copy link
Member

Choose a reason for hiding this comment

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

@gugahoa he doesn't need to check if hasAttacked prior to calling removeAttacked, not the other way around

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, sorry, I misunderstood your comment haha

Player* targetPlayer = getPlayer();
if (targetPlayer && attackerPlayer->hasAttacked(targetPlayer)) {
attackerPlayer->removeAttacked(targetPlayer);
}
Copy link
Member

Choose a reason for hiding this comment

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

See my comment below, I think those 4 lines above might be reduced to attackerPlayer->removeAttacked(getPlayer()), but please double check.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep! You are absolutely right, I didn't really pay attention to that.

@ranisalt
Copy link
Member

I think you just solved a dangling pointer issue :)

@ranisalt ranisalt merged commit 132aa7f into otland:master Jan 11, 2017
@ranisalt
Copy link
Member

Thanks!

@WibbenZ WibbenZ added this to the 1.3 milestone Dec 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants