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

test_timelime issues with seal lines #5716

Open
quisquous opened this issue Jul 20, 2023 · 1 comment
Open

test_timelime issues with seal lines #5716

quisquous opened this issue Jul 20, 2023 · 1 comment
Labels

Comments

@quisquous
Copy link
Owner

test_timeline does not appear to start with this log and initial sync. If I add a sync to Glory Neverlasting, it works just fine. The seal message definitely appears in the log file. I haven't looked at why this is happening, just noting to get it fixed. (cc @JLGarber if you have any time or interest to look at this)

01-left_portal-left_path-showers-wrong_orb-close_case-MountRokkon_20230718_221704.834_28m.log

1000.0 "--sync--" sync / 00:0839::Last Glimpse will be sealed off/ window 10000,10000
1011.6 "Glory Neverlasting" sync / 1[56]:[^:]*:Yozakura the Fleeting:83A9:/
1021.6 "Art of the Windblossom" sync / 1[56]:[^:]*:Yozakura the Fleeting:8369:/
1030.7 "Oka Ranman" sync / 1[56]:[^:]*:Yozakura the Fleeting:836E:/
1035.8 "--middle--" sync / 1[56]:[^:]*:Yozakura the Fleeting:8612:/
1040.1 "Seal of the Fleeting" sync / 1[56]:[^:]*:Yozakura the Fleeting:8379:/
1040.3 "Seal of the Windblossom" sync / 1[56]:[^:]*:Yozakura the Fleeting:837B:/
1042.3 "Seal of the Rainblossom" sync / 1[56]:[^:]*:Yozakura the Fleeting:837D:/
1049.5 "Seal of Riotous Bloom" sync / 1[56]:[^:]*:Yozakura the Fleeting:8374:/
1052.7 "Seal of the Rainblossom" sync / 1[56]:[^:]*:Yozakura the Fleeting:8377:/
1052.7 "Seal of the Windblossom" sync / 1[56]:[^:]*:Yozakura the Fleeting:8376:/
1059.7 "--sync--" sync / 1[56]:[^:]*:Yozakura the Fleeting:8612:/
1065.9 "Bunshin" sync / 1[56]:[^:]*:Yozakura the Fleeting:837E:/
1075.0 "Shadowflight (cast)" sync / 1[56]:[^:]*:Yozakura the Fleeting:837F:/
1080.0 "Shadowflight" sync / 1[56]:[^:]*:Mirrored Yozakura:8380:/
1085.2 "Art of the Fireblossom" sync / 1[56]:[^:]*:Yozakura the Fleeting:8368:/
@quisquous quisquous added the bug label Jul 20, 2023
@quisquous
Copy link
Owner Author

quisquous commented Dec 16, 2023

The log from #6045 also has this issue (or something similar), as the in combat line doesn't start combat. If you modify it to be 0.0 "--sync--" InCombat { inGameCombat: "1" } window 1000000,10000000 then it hits at t=151. So I think something might be wrong with how test timeline imagines when an encounter starts.

cc @xiashtra

JLGarber pushed a commit to OverlayPlugin/cactbot that referenced this issue Dec 24, 2023
(sorry for the git bork/closed PR - one more time...)

This PR should address the encounter sync drift referenced in
quisquous#5635 and quisquous#6048, as well as the
missing zone-seal sync referenced in quisquous#5716.

There were a couple of separate but related issues that I found:

1. `encounter_tools` had not (yet) been updated to use `InCombat` lines
to start encounters, even though `make_timeline` is inserting an
`InCombat` sync at the start of a new timeline.
2. For fights that do not have zone seals, `encounter_tools` would fall
back on using `playerAttackingMob` or `mobAttackingPlayer` regex. While
this mostly still worked (with minor drift issues), it was also counting
faerie healing actions as the start of the fight. I confirmed this was
the case with the log in issue 6048. I don't have logs for the original
report from issue 5635, but I suspect a similar cause there, as I was
unable to repro in e6n when on non-pet classes.
3. I think there was a minor logic bug in `encounter_tools` re: pushing
the fight-starting log line into `logLines`. When encountering certain
log lines that should trigger a new fight encounter, `onStartFight()`
would reinitialize `this.currentFight` and set `.startTime`; but when
`storeStartLine()` was subsequently called, it would not push the
starting log line into `.logLines` because the fight already had a start
time set. This was causing make/test_timeline to sometimes not have
access to (and not be able to sync on) the log line that started the
encounter.

I'm wary about unintentional breakage, given the various different
events that should (or should not) start a timeline. cc: @xiashtra and
@JLGarber, would appreciate an extra set of eyes.
github-actions bot pushed a commit to OverlayPlugin/cactbot that referenced this issue Dec 24, 2023
…cripts (#15)

(sorry for the git bork/closed PR - one more time...)

This PR should address the encounter sync drift referenced in
quisquous#5635 and quisquous#6048, as well as the
missing zone-seal sync referenced in quisquous#5716.

There were a couple of separate but related issues that I found:

1. `encounter_tools` had not (yet) been updated to use `InCombat` lines
to start encounters, even though `make_timeline` is inserting an
`InCombat` sync at the start of a new timeline.
2. For fights that do not have zone seals, `encounter_tools` would fall
back on using `playerAttackingMob` or `mobAttackingPlayer` regex. While
this mostly still worked (with minor drift issues), it was also counting
faerie healing actions as the start of the fight. I confirmed this was
the case with the log in issue 6048. I don't have logs for the original
report from issue 5635, but I suspect a similar cause there, as I was
unable to repro in e6n when on non-pet classes.
3. I think there was a minor logic bug in `encounter_tools` re: pushing
the fight-starting log line into `logLines`. When encountering certain
log lines that should trigger a new fight encounter, `onStartFight()`
would reinitialize `this.currentFight` and set `.startTime`; but when
`storeStartLine()` was subsequently called, it would not push the
starting log line into `.logLines` because the fight already had a start
time set. This was causing make/test_timeline to sometimes not have
access to (and not be able to sync on) the log line that started the
encounter.

I'm wary about unintentional breakage, given the various different
events that should (or should not) start a timeline. cc: @xiashtra and
@JLGarber, would appreciate an extra set of eyes. eab4545
SiliconExarch pushed a commit to SiliconExarch/cactbot that referenced this issue Jan 5, 2024
…s#15)

(sorry for the git bork/closed PR - one more time...)

This PR should address the encounter sync drift referenced in
quisquous#5635 and quisquous#6048, as well as the
missing zone-seal sync referenced in quisquous#5716.

There were a couple of separate but related issues that I found:

1. `encounter_tools` had not (yet) been updated to use `InCombat` lines
to start encounters, even though `make_timeline` is inserting an
`InCombat` sync at the start of a new timeline.
2. For fights that do not have zone seals, `encounter_tools` would fall
back on using `playerAttackingMob` or `mobAttackingPlayer` regex. While
this mostly still worked (with minor drift issues), it was also counting
faerie healing actions as the start of the fight. I confirmed this was
the case with the log in issue 6048. I don't have logs for the original
report from issue 5635, but I suspect a similar cause there, as I was
unable to repro in e6n when on non-pet classes.
3. I think there was a minor logic bug in `encounter_tools` re: pushing
the fight-starting log line into `logLines`. When encountering certain
log lines that should trigger a new fight encounter, `onStartFight()`
would reinitialize `this.currentFight` and set `.startTime`; but when
`storeStartLine()` was subsequently called, it would not push the
starting log line into `.logLines` because the fight already had a start
time set. This was causing make/test_timeline to sometimes not have
access to (and not be able to sync on) the log line that started the
encounter.

I'm wary about unintentional breakage, given the various different
events that should (or should not) start a timeline. cc: @xiashtra and
@JLGarber, would appreciate an extra set of eyes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant