(Not recommended to read when you don’t care about tilesets XD)
Okay this is going to be a hard to understand one because there is a lot of variables but I will try my best to share my insights…
TL;DR: The timestamps of the archer in the combat log are relative to the “number” showing up on the target. But it should be relative to the “hit sparkle” on the target (or number should be consistent delay, probably better solution). And the second conclusion is, there is no client side way to tell if you will get a ‘Z’ tile or not. This should also be relative in time from the “hit sparkle” (and also from the combat log)
So this is what we did. We shot 11 arrows at a dummy with all arrows above 90% (0.9 seconds) charge to get max damage. This was done as close as possible to the dummy to reduce the difference in travel time to the dummy. From there we used the video footage and the combat log of both players to determine what was triggering the “Z” tile and what wasn’t triggering it. This test was done on the Simple (WebSocket) connection type. (we are aware it triggers relative in time between hits of a target. Not release of an arrow or other projectile)
So we measured multiple things to find a pattern that was sadly not consistent on any of the things we tried. I will go through them from left to right (See table on bottom of post)
One of the tests we did (Column B) showed the timing between arrows measured from astragt’s video. The time spot used was the “Hit” itself. The first image below shows how the “hit” itself looks like. The key in understanding if the data is incorrect is looking if there is a time where ‘Z’ tile is triggered that is lower then a time where no tile is triggered. This seemed promising until the 9th and 11th row proved this wrong. So we conclude that this method can not tell you if you will trigger the ‘Z’ tile or not. (it comes the closest to accurate of all methods though)
Now the next step was doing the same for when the “Damage number” shows up (Column C). What we found out is that the “Damage number” has a significant inconsistent delay of 0.2-0.3 seconds relative to the “hit” itself (See column H). This is a problem because it is inconsistent and out of the control of the Ranger itself. The “hit” on the other hand has a relative consistent delay from actually releasing the arrow (Column I) which is neglect-able because that is 1 frame that can be missed on the video. The conclusion from measuring the difference between the distance of two “hits” is way more inconsistent. A “Z” gets triggered on 0.867 seconds and nothing gets triggered on 0.950 seconds… (photo of measure on hit below)
So we also measured the difference in time that the combat log shows us (Column D). Where we noticed a pattern that the difference in time matches up with the difference in time of the “Damage numbers”. So that means they are linked together. But the Archer uses the hit sparkle as visual to know how fast you hit something… So the combat log should really use that as timestamp and not the damage number itself. Unless the damage number can become consistent timing too. Which it currently isn’t.
Then we compared the combat.log of both view and saw there was also a difference in timing between two clients. This is not a big problem as long as the archer that Shouts itself has the accurate time to know the tiles. Which is not the case…
So all methods of measuring how much time there are between arrows did not give us an accurate timing of knowing when the “Z” tile triggers and when not. This is a problem because we clearly release the arrow past 0.9 seconds every time (always max damage and bar on astragt’s video). But still the “Z” tile doesn’t always trigger, and we can not see why because the timings are not representing the timings of the tile detection code. So I am guessing the moments are send to the server and there separately viewed for time between hits. I really think the client should also be able to see if a tile will get triggered or not by either a visual or the combat log. Because currently this is not the case.
(This is probably too heavy and time consuming to be taking action on ATM but just wanted to share this for now )
Astragt’s view (to prove timings):
Scott’s view (to prove tiles and any other timing indications):
Table used for conclusions: