marzent
commented
3 months ago Yeah this is indeed true, I was hoping that the new server time logic would compensate for that enough, but getting the original timestamp is cleaner... Unfortunately this means trampling over at least 1 of the hooks Deucalion uses and there can be many unintended side effects when both are running at the same time (i.e. hooking together, unhooking in a different order than hooking etc.) I am also not sure how well the rust hooking library used there handles multi-hook scenarios as well. Will try to see how its works and if it causes issues, maybe show a warning if Deucalion is detected and/or unload Deucalion.
jasonrm
Currently, IINACT appears to be generating its own timestamps for events. It would be preferable if the packet timestamps were used similarly to what ACT does. The current approach leads to a number of issues: 1) The packet timestamps have meaningful implications for log analysis (i.e. a NetworkBuff event and NetworkAbility event sharing a timestamp means the buff applied in time/a NetworkBuffRemove event and a NetworkAbility sharing a timestamp means the buff does not apply to that ability). 2) GCD estimation tools like https://gcdcalc.fly.dev/ and xivanalysis' GCD estimation rely on the original timestamps being in use. 3) FFLog's new method of detecting impossible weaves leans heavily on event timestamps and it's possible for IINACT to create situations that would lead to your log being invalidated when it wouldn't be on ACT. Consider these events recorded with IINACT: https://awau.moe/34L3Xxz.png The player in question had a 1.97 GCD ingame, and ACT logging the delay between two GCDs at that speed as anything below 1.90 would be an exceptionally rare outlier. IINACT logged the time difference as being as low as 1.821 seconds and if the player had successfully double weaved in between those GCDs the log would be flagged by FFLogs due to needing less than 1.83 seconds to double weave, when this wouldn't have happened with ACT.