1 second delay and archer attacking problem (also potential problem for other classes)


(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 :man_shrugging: )

Astragt’s view (to prove timings):

Scott’s view (to prove tiles and any other timing indications):

Table used for conclusions:


The explanation for this is pretty straightforward if I’m understanding your post. The re-working of the hit and networking code shifted a lot of things to the client to make it “feel” more responsive to the player. Nearly all games do this. So when you fire an arrow, you see it hit the target and your client goes “I hit that!” and shows the hit effect. However, obviously since this is an MMO and we can’t trust your client, the hit does not actually count until it is confirmed by the server. The damage number shows up when the server has confirmed the hit and sent back to you “yes, I agree that you did hit that and here is how much damage you did.” That is also when all tileset calculations are performed.

The discrepancy you are seeing between how long it takes for the number to show up from the time you see the sparkle is just the latency between your client and the server, which is not going to be a constant, it varies.

Nothing about tilesets has changed from this perspective from original Orbus. The only difference is that in the old game, you wouldn’t see the sparkle until the hit was confirmed on the server, and now you see it sooner than that.

Are you saying that’s leading to some kind of unintended consequence where it’s harder to get timing down for tilsets? Or?


No this problem was already the case in original Orbus and I already addressed it before. But the timing of that post wasn’t really a good moment (Reborn in the heavy works back then) and we didn’t do that precise calculations/measurements back then. I waited for reborn so maybe the combat log would have give me a more accurate answer but it didn’t. It gives more confusion. The key problem is that you as a player can in theory hit the dummy every 0.99999 seconds and still don’t get the Z tile all the times. But sometimes releasing it at 0.9 seconds will give you the Z tile. I know the problem is with the server not trusting the client and doing their own calculations, but sadly the difference in latency between messages apparently proves that the server can not be accurate enough to always give the player a “Z” tile triggered even though the player is certainly not doing anything wrong timing based.

The travel time to the dummy is consistent, the arrow release point is always 0.9+ seconds and still Z does not trigger sometimes and sometimes it does. And it is unreliable enough that sometimes you can get Z every single hit for minutes. And other times it will never show up… (two extremes of course)

The important examples proving this problem were:
(For measuring time between the client side hits)
The 0.933 seconds time between two arrows triggered a Z tile
But 0.950 seconds time between two arrows did NOT trigger a Z tile.

(For measure between the “Numbers” showing up which was from server confirmation)
The 0.867 seconds gap between arrows triggered a Z tile
But 0.950 seconds gap between arrows did NOT trigger a Z tile.

In other situations it was right though. Z tile should trigger when the gap time between two arrow hits is long enough. But it seems to contradict itself. But I can only see the client side :man_shrugging:But apparently using the “Number” gap difference it is very likely the server and client can be about 0.1 seconds off sync in deciding things.

The client though is THE human factor and the server has a lot of variable lagg of apparently 0.1 seconds in it that is not controllable by the player. So the player can never guarantee the Z tile even if it is a robot.

I was also thinking about a solution for this problem. It seems that the server can be wrong about this in an error margin of about 0.1 seconds. So a potential solution would be to let the client sent their timestamps, and if the difference in timestamps between the server and client are more then 0.1 seconds then you can not trust the difference in time. The client timestamps are just for syncing up the timings of things and making it more accurate. I understand that you want to confirm the hit first but before it is confirmed you can already remember that timestamp and then when it is confirmed use it.

So the key problem is a human or even robot can not always get the system to know it is shooting 0.9 seconds atm because it seems to use server only timestamps. Using client to narrow down accuracy would help a lot.

(Note: the difference is probably more like 0.05 latency because it is also bouncing back to the client again, but I just want to be on the safe side here and made it double)


It is great to hear that the spark is now more precise on the client side in Reborn btw. Thnx for that. :slight_smile:

Now only hoping the tilesets timing for this can also be addressed. :sweat_smile: I have seen many archers complain they can not guarantee their tilesets to trigger. The Z tile is just an example. This seems to also happen when charging an arrow and getting the “I” looking tile instead of the “Z” looking tile half of the times (while their client side timing is correct).


Okay…well as long as it’s not something that was introduced in Reborn, then I will take it under advisement for a future update. I’m not sure it’s really possible to change the behaviour on this without trusting the client too much, but I will give it some thought.

At any rate, unless you have a connection to the server that is very unreliable, even if you have high latency it doesn’t matter, because the messages may be delayed but they would arrive spaced apart the same to trigger the tiles. What is causing the behaviour you are describing is not server lag, it is a latency spike where the message sent by the client doesn’t reach the server until 200ms longer than normal, after it is sent or something like that, which throws off the timing. E.g. 0.9, 0.9, 0.9, 0.9, 1.1 (due to 200ms spike), 0.7, 0.9, 0.9, 0.9. Like that.


Yeah you right. I didn’t mean it like having a bad connection but more like you are describing having a latency spike. Sadly I do notice some players having this latency problem very consistent. Something to battle that problem like my suggestion or something else would be really appreciated. It is a frustrating problem for many archers.

Maybe shifting the “delay tile” trigger another 0.1 second itself. So Z triggers every 0.8 > and I every 1.8. Would be a cheap fast fix though where big latency spikes would still make you suffer. Or archers being able to release on 1.1 seconds would be another one.

Thinking about those “latency spikes” more makes me also realize this is probably a bigger problem in Europe then America because those spikes have a bigger number on average.

(Ooh also this problem of giving the wrong “delay tile” would definitely start to show up for Shamans, Scoundrels and maybe even Bards :thinking: )


Not controllable by riley but actually pathing issues. The timestamp idea could work to get a timing difference between last spell cast.

I can imagine this issue is more prevalent for EU players as the connection has to path further. More path connections = more chance of variability in latency.


Okay before I :zipper_mouth_face: one more thing. I would like to note that Column H of the table (Hit to number delay) shows how much delay there is between client and server messages. But mostly how much it seems to vary. It goes between 0.2 to 0.33 and all values in between are not uncommon. Which means those so called “latency spikes” are not a rare one time thing but basically happen in various amounts every single shot.

Also having 0.9 seconds as the moment the archer gets max damage and also having 0.9 seconds as border for “Z” tile is also part of the problem. Because it is so close together, having a latency of 0.001 is enough for punishment :confused: So I definately think the Z tile trigger should be more like 0.8 seconds and above. Or in the future use client side stamps and then 0.88 is probably also acceptable.


Changing it to 0.8 would cause the same problem for those of us shooting every 0.8 seconds.

1 Like

Shooting every 0.8 seconds means you are losing dps???.. (Not talking about tilesets)

(Need to check that :sweat_smile:)


Losing damage per shot, but gaining dps.

1 Like

OMG I thought max dps was always on 0.9 or higher :scream: Not 0.8 - 0.9 (because of the rumble?)

Well remove the whole argument of having that Z tile exactly on 0.9 with the max damage. That is not needed anymore. Need to look at everything from a 0.8 perspective now… :sweat_smile:


The difference is very small. 1.25% actually. 0.8 is just a lot easier to do consistently because of the rumble.


1.25% is enough to always choose 0.8 seconds :man_shrugging: Definitely now the ‘M’ tile will start to trigger more often. Which makes the optimal archer tilesets slightly different.


That is what I’m using. It still doesn’t proc consistently.


Yeah your tiles still don’t consistently trigger because of another underlying problems which directly relate to the latency problem:

  • A “latency spike” will bring a 0.85 second spacing between hits above the 0.9 mark where it will make it a “Z” tile instead of “M”.
  • And another thing breaking it is a “latency spike” on the charge shot itself. Which will make the “Z” tile of the charge an “I” tile. (Tileset ZFM)
  • Or even more interesting it will cramp the two hits closer to your third normal arrow hit which will make from the “M” tile in the end of the charge an “N” tile. Which will also prevent you from triggering your tilesets.

And don’t let me start on talking about the “hits per second” tiles themself. They will in the future be their own topic which I have to do research on again, because those are also broken for sure XD. I addressed that problem before on the forums too. It all breaks the archers already weak tilesets lol.

closed #17

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.