-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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(Script/BlackTemple) Illidan won't double up on his script actions #21277
Conversation
Were you able to reproduce it after the latest changes done to the HealthCheck scheduler? |
Honestly applied my fix and just tested that... Let me try before so can be sure lol |
The issue (If still there) isn't in the boss script but a race condition in the healthcheck implementation |
Interesting, maybe then this fix is irrelevant |
Illidan continues to have problems, but this particular problem I have not seen in months (and I fight Illidan every week). |
Yeah same thing with original script... So what I did adds nothing I think? Though guess with the bool it would make sure for sure... But that's a bit "hackish" if so |
Probably fixed then from healthcheck fix? |
Maybe....Maybe not. This bug is not easy to reproduce, so I cannot confirm that it has been fixed. |
Either way if there is an issue it is preferrable if its fixed in the source rather than every boss script that uses healthchecks, thanks for the PR tho 👍 |
Ok cool, I'll close the PR then |
Changes Proposed:
This PR proposes changes to:
Issues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.