-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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(Scripts/Karazhan) Nightbane take off phase handling #18934
base: master
Are you sure you want to change the base?
fix(Scripts/Karazhan) Nightbane take off phase handling #18934
Conversation
use conditional schedule takeoff instead invincibility fix and timing no need to delay ScheduleGround
Not sure how it's implemented in this PR, but looking at the log commented in the linked issue, it does appear that the flight phases get queued when the HP thresholds are hit. Reading the issue implies the current flight phase should be interrupted and a new one started, which (again, to my perspective) contradicts the log. |
#18935 Language is hard to express my thoughts, so I've created a PR that I'll close later. |
From my understanding Nightbane cannot be killed until he completed 3 flight phases. Every 25% a flight phase is queue'd. From the log, for the first <50% Nightbane does not land. I'm not sure why this one skips the landing and the second <25% makes him land. I think the proper struct should be: once in the air there's a flight queue, once it's empty we do a landing. When an air phase is triggered while in the air, it gets queued. I suspect to do it like this requires more refactoring. Phase are awkward. It uses some bools _flying,_intro and hardcoded phase 1,2 and these are changed by scheduler, waypoints and updateAI Phases/Groups like in TC make more sense but I wanted to get the logic right first |
new inro lands attack flag is not removed.. cant attack :)
-- (172250, 8, -11130.677, -1891.4235, 107.89634, NULL, 0), | ||
-- (172250, 9, -11110.674, -1878.7712, 107.89686, NULL, 0); | ||
|
||
-- Intro |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice to see this. 👀
Changes Proposed:
This PR proposes changes to:
Issues Addressed:
SOURCE:
The changes have been validated through:
pathing, trigger air phase mid-air WCL https://classic.warcraftlogs.com/reports/7nrz98TtXqRkdAj1#view=replay&fight=21, mentioned in chromiecraft/chromiecraft#6919 (comment)
wrath classic, sniffs: https://www.youtube.com/watch?v=vSO2Ik_e69I%0A
Tests Performed:
This PR has been:
How to Test the Changes:
a.
.damage 1000000000
one shot on pull, see if 3 flight phases happen back to backb.
dmg5 dmg7
gm spells to reduce damage to 75% to trigger phase, deal more damage past 50% and/or 25% to skip next ground phasec. deal damage to 75% to trigger phase. do not reduce past 50% and observe Nightbane starts ground phase
Trigger flight phases at different times
a. during ground phase
b. before triggering landing_wp (after take off, during p2 air phase)
c. after triggering landing_wp, after he circles and is about to land
Resets
a. talk to urn then run away
b. talk to urn and
.gm on
c. reset during air phase
d. reset during ground phase
Urn
a. interact with urn after reset
Known Issues and TODO List:
intro_wp
west
tolanding_wp
POINT_INTRO_TAKE_OFF
instead of his actual point before doing his intro path. Taking off vertically sets his fly animation properly.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.