Suggestion - Improved Positional Telemetry

boatboat

Hi!

I am not super familiar with the FFXIV plugin ecosystem, so please let me know if I am saying something ignorant. 

Currently I'm maintaining an FFXIV puzzle game where you see a short positional replay of a raid and have to guess which fight it is from. The game is powered by FFLogs data, and shows player positions, ability casts, debuffs, etc.. For the most part the data is pretty good and easy to build off of. However, I find that reconstructing player movement is quite difficult due to the way that ACT tracks position. Position seems to be tracked as a side-effect of player actions like GCDs and ability usage, and other actions like players receiving damage. Consequently position event density is serviceable during fight uptime, for the most part. However, when it comes to downtime, whether that's forced downtime, a player dropping GCDs, or mechanic-related downtime like stuns, position event density becomes very sparse. This has been a fairly significant challenge for my game, since I have to filter out portions of certain raids due to a lack of event density, as this manifests as a buggy/laggy looking experience (pretty much the same concept as packet loss in a multiplayer game, can only interpolate/try to predict for the next frame/event). 

I don't mean to bring this up as an issue with the tool. Clearly, ACT serves as good telemetry and has supported FFLogs for many years. I'm sure that there are many considerations made that led to the current state of the tool, whether that be performance, maintainability, log size, or what have you. However, with the current state of the telemetry, there isn't a super solid foundation to build a replay tool off of. This is fairly evident in the FFLogs replay tool, which has a lot of the mentioned issues with apparent lag. 

I make this post as I am curious if there is any interest in extending the existing positional telemetry. I'm not sure what makes the most sense given the current architecture of the tracker, but some sort of polling system that guarantees a positional event per player every, say, 1-2 seconds would be a significant fidelity upgrade for replay tools and games like the one I am working on. However, I get that this is a big technical tradeoff considering the main purpose of logs is for damage telemetry which is already comprehensively covered. Just wanted to throw this out there and get thoughts on it. I'm also not sure how FFLogs factors into this, and whether FFLogs itself trims any data from ACT-generated logs before they make it to the service, so this might be completely out of scope for ACT developers. But anyway, thank you for your consideration and I definitely understand if this is not feasible/advisable.

EQAditu

My understanding is that, as you said, positional data is incidental.  It's part of other interesting network packets, so it is included in the lines that are already interesting.  

The FFXIV Parsing plugin that generates the logs ignores the standard movement packets as it would be an unacceptable amount of data.  Though a timed filter would solve this, as you suggested.

OverlayPlugin, when running, will decode these network packets (ActorMove & ActorSetPos).  However these log lines are out of the standard range and FFLogs may ignore them since they were not created by the parsing plugin.  Not every FFLogs user will be using OverlayPlugin.  According to the documentation, OverlayPlugin also seems to ignore player generated packets and only focuses on NPC position changes.  Their focus is clearly to predict raid encounter scripts rather than create replays.

For your purposes, ActorMove would probably need to be moved into the FFXIV Parsing plugin and FFLogs would need to also keep that data.  The OverlayPlugin devs have already done the work of decoding the correct packets and they are re-verified every patch.  Ravahn wouldn't have to do much work there except minimal verification each patch.  Ravahn would have to decide at what frequency the packets would be allowed and create that logic.

If FFLogs approached Ravahn about adding this data, it would probably be taken more seriously...  and it would guarantee that FFLogs wants this data.  Including the data does you no good if FFLogs strips it away.  FFLogs would likely not take data from OverlayPlugin seriously as it is optional.  But it would be easier to implement there since it is already there in some form.

Anyways, that's my take on the situation.  I don't really have any ability to implement these things myself.  And those who do don't really read these forums.  You would probably need to get some collaboration between Ravahn and FFLogs.