raidboss: update ShB timelines #5592
Conversation
…nd add longer sync windows as appropriate; explanatory comments where needed
ui/raidboss/data/05-shb/raid/e6n.txt
Outdated
| 2.0 "--sync--" sync / 1[56]:[^:]*:Garuda:366:/ window 3,1 | ||
| 13.5 "Ferostorm" # sync / 1[56]:[^:]*:Garuda:4BD[DEF]:/ | ||
| 0.0 "--sync--" sync / 104:[^:]*:1($|:)/ window 0,1 | ||
| 13.5 "Ferostorm" # sync / 1[56]:[^:]*:Garuda:4BD[DEF]:/ window 14,7 |
There was a problem hiding this comment.
This sync is commented out so this will not work. I'm not sure why, I'd have to look at a log.
There was a problem hiding this comment.
This sync is commented out so this will not work. I'm not sure why, I'd have to look at a log.
Not sure. But there is still a long sync on the Superstorm right after, so it should still be okay?
There was a problem hiding this comment.
That sync has been commented out since the initial timeline was added in #1118; there's a comment about it in the initial PR.
There's also some massive drift here; on a test run I did today, the Ferostorm ability didn't come out until 31.0s, but the timeline has it at 13.5s. I don't have any saved logs from when this was current content to see if it's always been like that.
There was a problem hiding this comment.
So the drift I'm seeing appears to be a bug with make_timeline and/or test_timeline, here are the first few relevant lines from the combat log (trimmed for space):
260|2023-06-21T02:49:01.6800000-04:00|0|1|
21|2023-06-21T02:49:16.1460000-04:00|40011872|Garuda|4BDF|Ferostorm
21|2023-06-21T02:49:16.6350000-04:00|4001187B|Garuda|4BDD|Ferostorm
22|2023-06-21T02:49:23.2620000-04:00|40011872|Garuda|4BD7|Superstorm
And here is an excerpt of what make_timeline gave when I tested against this log:
0.0 "--sync--" sync / 104:[^:]*:1($|:)/ window 0,1
31.0 "Ferostorm" sync / 1[56]:[^:]*:Garuda:4BDF:/
31.4 "Ferostorm" sync / 1[56]:[^:]*:Garuda:4BDD:/
38.1 "Superstorm" sync / 1[56]:[^:]*:Garuda:4BD7:/
The time given between the combat start line and the Ferostorm line is much larger than the log timestamps.
There was a problem hiding this comment.
Yeah, I'm not sure what's going on with e6n here. Maybe we can break this out into a separate issue to try to figure what's going on (with the timeline or make_timeline?)
There was a problem hiding this comment.
New issue #5635 opened. I'll remove the comment-out on the sync, since it looks like from the log @xiashtra posted that the first Ferostorm is roughly around the time where the sync should occur in the timeline. Once I finish up with this PR, I'll try to find some time this weekend to dig in a little further on the bug.
EDIT: I spoke too soon. Given the back-to-back uses of Ferostorm (4BDF/4BDD) and the longer sync window on the following Superstorm, I think it's better to leave this commented-out for now and just rely on the Superstorm sync. Will leave this unchanged from the current commit (e.g. no window on the 13.5 Ferostorm.)
Just played p10s in games, and it seems the result is opposite, still need someone to take further testing.
Largely the issue here is that each timeline bar has an id, and the timeout to recolor a bar to be "soon" was looking by id. If the timeline ever got adjusted due to syncs or jumps, then the soon timer would end up firing for bars at different times. To fix this, instead have the soon timer refer to the html element directly rather than an indirect id. Track and clear this (to avoid outstanding useless timeouts) if the bar is ever removed. While we're here, also refactor the expiring timeout into the same structure. Fixes #627.
Signed-off-by: 柚木鉉 <GloomyGhost@foxmail.com>
Not sure if I did something dumb while rebasing or Visual Studio did, but it was a messy unwind, and doing a new PR was POLR. So I'm killing the old PR (#5580 ) and opening a new one. This includes all revisions incorporating feedback from the initial code review. Apologies for any added work.
Signed-off-by: 柚木鉉 <GloomyGhost@foxmail.com>
Add P12s Engravement 1 Tower triggers. > This trigger is based on part of the functionality of #5587 PR, and later merges may involve conflict merges, which I will resolve at that time. In Engravement 1 (Paradeigma 2), 2 players receive lightTower and 2 players receive darkTower, 2 players need to guide the light beam and 2 players need to guide the dark beam. The operator of the beam extends the beam directly from the outside. The beam is attenuated until the jagged line disappears. The people in the tower find the people who have the opposite attribute to the debuff and put them in four places. At NE NW SE SW as a # shape. The position of outside Anthropos is fixed by two situation. `{[97, 75], [125, 97], [103, 125], [75, 103]} and {[103, 75], [125, 103], [97, 125], [75, 97]}`. The Anthropos will cast 'Searing Radiance' for light beam and 'Shadowsear' for dark beam. We use those as a trigger for Tower players place the Tower. When debuffs expire and towers drop, their debuff changes to lightTilt or darkTilt (same as tower color). At the same time the towers drop, the 4 tethered players receive lightTilt or darkTilt depending on their tether color.  --------- Signed-off-by: 柚木鉉 <GloomyGhost@foxmail.com> Co-authored-by: Adrienne Walker <enne@quisquo.us>
Adds triggers for: - Clones north/south during Paradeigma 1 - Clone line cleaves (e.g. inside east/outside west) during Paradeigma 2 - Glaukopis tank cleaves/swap - Parthenos line cleave (during Superchain IIB)
Triggers were ok for this one, but there were changes to the boss timelines and a non-targetable actor name change. Bosses will now walk center when using certain actions, making it very easy to induce timeline drift by dragging the boss off-center. The first boss is particularly prone to timeline de-sync; however, most groups will likely not see it if they are not intentionally moving the boss more than necessary.
Co-authored-by: Adrienne Walker <enne@quisquo.us>
First boss had minor timeline changes. Second boss was completely revamped. Co-authored-by: Adrienne Walker <enne@quisquo.us>
Timeline changes, primarily to the second boss.
6.3/6.4日本語翻訳
Sorts the ignored combatants list in `make_timeline.ts` for easier future maintenance. No entries added or removed.
Has been tested in game and in emulator, but could use some additional validation and feedback, particularly on alert timings and collisions. One odd thing is that for the Sample Tiles combatants/triggers, the trigger works fine in game, but the emulator never return position data (via getCombatants) for the tiles.
Tested extensively against logs & vod, but could use some additional testing in game and validation on the timings. Right now, for classical2, it will display the initial position for 7 seconds as an infoText, and right about as that expires, it will then display the inverted (actual) position as an alertText. I left those as static values, but I'm undecided whether it would make more sense to add a config option to allow the user to specify when the alert should 'transition' from initial to actual. Admittedly, I made a stylistic choice to do a single output trigger that covers the output for classical1 as well as the initial and actual calls for classical2. It adds some trivial complexity around delay/duration, but the primary benefit I saw in this approach was a single set of customizable output strings, rather than multiple triggers users would separately need to modify. (It also removes the need for some duplicative code.) But I understand reasonable minds may differ on that choice.
…nd add longer sync windows as appropriate; explanatory comments where needed
|
Ugh. Wonky merge again. Will close this out and open a new PR. |
New PR (follows #5592 ) without borked merge history.
New PR (follows quisquous#5592 ) without borked merge history. 1dd2d4e
New PR (follows quisquous#5592 ) without borked merge history. 1dd2d4e
New PR (follows quisquous#5592 ) without borked merge history. 1dd2d4e
More work on #5440 - added InCombat lines, removed unnecessary Resets, removed initial autos and added sync windows to first abilities as needed. This PR includes everything in 05-shb.