OverlayPlugin / cactbot

FFXIV TypeScript Raiding Overlay
Apache License 2.0
85 stars 34 forks source link

KOREA sever - Some ACT features do not work properly. #328

Closed shs1300 closed 1 month ago

shs1300 commented 1 month ago

Description

tank → Taunts, avoidance, and one-on-one duels notifications do not work. Since the setup is complete, it is expected to be a code error.

Additional Details / Steps to Reproduce

I set it to "Text and Sound" but it doesn't work.

Cactbot Module

Raidboss (alerts & timelines)

Configuration Info

Plugin Name - Status - Version - Path
FFXIV_ACT_Plugin.dll - Enabled - 2.4.3.2 - C:\Advanced Combat Tracker\Plugins\FFXIV_ACT_Plugin_KR\FFXIV_ACT_Plugin.dll
OverlayPlugin.dll - Enabled - 0.19.34 - C:\Advanced Combat Tracker\Plugins\OverlayPlugin\OverlayPlugin.dll
CactbotOverlay.dll - Enabled - 0.32.5.0 - C:\Advanced Combat Tracker\Plugins\cactbot\CactbotOverlay.dll

Overlay Name - URL
MopiMopi - https://haeruhaeru.github.io/mopimopi/?HOST_PORT=ws://127.0.0.1/fake/
Test - https://quisquous.github.io/cactbot/ui/test/test.html
Raidboss : Alerts Only - https://overlayplugin.github.io/cactbot/ui/raidboss/raidboss.html?timeline=0&alerts=1

Various Settings - Value
Plugin Language - Korean
Machina Region - Korean
Game Version - 2024.07.02.0000.0000
Screen Mode - Borderless Windowed
ACT Process Elevation - Elevated (Admin)
FFXIV Process Elevation - Elevated (Admin)
Inject and use Deucalion for network data - True
Hide Chat Log (for privacy) - False
Use WinPCap-compatible library for network data - False
Disable high-performance network filter - False
Disable Combine Pets with Owner - True
Disable Damage Shield estimates - False
(DEBUG) Enable Debug Options - False
Cactbot User Dir - C:\Advanced Combat Tracker\Plugins\cactbot\user

Log & Screenshots

No response

Confirmation

Amahamiuu commented 1 month ago

I think you just need to simply untick the 'Raidboss' box in the cacbot page then tick and reset it. It works for me :)

n0bi1 commented 1 month ago

All triggers with type: 'Ability' are not working. Here are the Type 21 logs in ACT:

Current 21|2024-08-08T06:45:01.8660000+09:00|---Deleted ID---|---Deleted Name---|1D6D|도발|4000049C|나무인형|18|DA100000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|44|44|0|10000|||-185.00|-123.90|32.09|0.79|118276|118276|10000|10000|||-176.06|-113.15|30.02|-2.40|00000BCC|0|1|66ad31f668da5dfe

Previous 21|2024-07-24T05:21:11.8080000+09:00|---Deleted ID---|---Deleted Name---|1D6D|도발|4000348D|콩나무|18|856A0000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|240509|255126|10000|10000|||80.00|100.00|0.00|1.57|26173|30167|10000|10000|||95.14|92.30|0.00|1.01|00001BB2|0|1|f8213dedb8b32d7e

There doesn't seem to be any difference in the ACT logs, but I'm wondering if there is an issue with the global and Korean servers not matching during the global 7.0 support process.

Echoring commented 1 month ago

Seems a change with Type 21/22 log was made recently: #315 (though I'm not sure whether it is due to this change, may some one have a check)

MaikoTan commented 1 month ago

Confirmed, it is related to #315 which added more fields that didn't in the log above posted by @n0bi1 So if the trigger is declared without a capture: false flag, the full regex would be generated, which cannot capture the log without those new fields.

Here's what I tried:

import NetRegexes from './resources/netregexes.ts'

const regex = NetRegexes.ability({ id: '1D6D', capture: false })
const regexCapture = NetRegexes.ability({ id: '1D6D' })

const str = '21|2024-08-08T06:45:01.8660000+09:00|---Deleted ID---|---Deleted Name---|1D6D|도발|4000049C|나무인형|18|DA100000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|44|44|0|10000|||-185.00|-123.90|32.09|0.79|118276|118276|10000|10000|||-176.06|-113.15|30.02|-2.40|00000BCC|0|1|66ad31f668da5dfe'

console.log(regex.test(str)) // => true
console.log(regexCapture.test(str)) // => false
wexxlee commented 1 month ago

Confirmed, it is related to #315 which added more fields that didn't in the log above posted by @n0bi1 So if the trigger is declared without a capture: false flag, the full regex would be generated, which cannot capture the log without those new fields.

This issue was encountered previously when targetCount was added to 0x15/0x16 lines. It was discussed in https://github.com/quisquous/cactbot/issues/4165, and @valarnin made some fixes in https://github.com/quisquous/cactbot/pull/4188 to support logdef versioning for exactly this sort of situation.

I'm tied up for a few days and won't be able to look at it or PR anything, but if someone wanted to PR a fix to use a different logdef version for KR FFXIV, that would probably be ideal. Alternatively, for a quick fix, someone could update the firstOptionalField property in netlog_defs for those lines so that any field indexes >= to that number are excluded from capture regex.

The second solution is less ideal, since it will effectively disable those fields from being used until turned back on. But I don't think anything in cactbot is using them currently (?), and I seem to recall that 7.0 releases in Korea in late September, so it's probably a reasonable stopgap if no one has time to unpack a proper fix.

n0bi1 commented 1 month ago

If #315 was the cause, why doesn't the trigger work properly in older versions like 0.32.4.0?

Here is the regex for General Provoke in 0.32.4.0:

/^(?<type>2[12])\|(?<timestamp>[^|]*)\|(?<sourceId>[^|]*)\|(?<source>[^|]*)\|(?<id>1D6D)\|(?<ability>[^|]*)\|(?<targetId>[^|]*)\|(?<target>[^|]*)\|(? <flags>[^|]*)\|(?<damage>[^|]*)\|(?:[^|]*\|){14}(?<targetCurrentHp>[^|]*)\|(?<targetMaxHp>[^|]*)\|(?<targetCurrentMp>[^|]*)\|(?<targetMaxMp>[^|]*)\|(? :[^|]*\|){2}(?<targetX>[^|]*)\|(?<targetY>[^|]*)\|(?<targetZ>[^|]*)\|(?<targetHeading>[^|]*)\|(?<currentHp>[^|]*)\|(?<maxHp>[^|]*)\|(?<currentMp>[^|]*)\|(? <maxMp>[^|]*)\|(?:[^|]*\|){2}(?<x>[^|]*)\|(?<y>[^|]*)\|(?<z>[^|]*)\|(?<heading>[^|]*)\|(?<sequence>[^|]*)\|(?<targetIndex>[^|]*)\|(?<targetCount>[^|]*)\|/i

(I apologize if my phrasing is awkward, as I am using a translation tool. Thank you for your understanding.)

valarnin commented 1 month ago

Setting firstOptionalField on the netlog_defs.ts entry for Ability to 47 should fix this I believe? Leave a TODO comment above it to re-assess once CN/KR are on 7.0/Ravahn backports the new fields to the older versions?