Quick Links

The server runs at variable speeds.

Sometimes the game simply runs faster than others. I don't mean frame rates or ping times by that, either. At its most extreme, sometimes everything only happens at about 60% of the normal speed. That's running speed, attack speed, skill cooldowns, everything. Mobs move and attack slower, too, so it's not a huge gameplay disadvantage, though it is annoying.

Well, not quite everything: buff durations still last the normal length. So if you have a buff with a 40 second duration and a 30 second cooldown and the server is only running at 60% speed, the buff still lasts 40 seconds, but the cooldown is now 50 seconds so you can't maintain it indefinitely.

Usually it's not 60% speed. That seems to only happen right after patches. But a lot of times, it's about 90% speed. Today, it seems to be around 85% speed. And the speed at which the server runs seems to stay the same all day, not bounce around constantly.

I'm not sure if it's a bug or an intentional way for the server to cope with heavy loads. It would be bizarre as a bug, though. And if it's a way to cope with heavy loads, why is it still present at far off peak times (e.g., weekday mornings) when there is a light load on the servers?

Nearly everything is still kept in sync, including client-side approximations to what is going on. This doesn't cause any rubber-banding, for example.

The one thing that is out of sync is client-side approximations to remaining buff duration. For example, if the server is running at 60% speed and a buff is supposed to last 30 seconds, then the client-side approximation counts down at 60% speed, then the buff abruptly expires from 12 seconds left. I think the bug there is that the server-side tracking of buff duration doesn't adjust for the different running rate the way it adjusts for everything else.

Nearly everything is still kept in sync, including client-side approximations to what is going on. This doesn't cause any rubber-banding, for example.

The one thing that is out of sync is client-side approximations to remaining buff duration. For example, if the server is running at 60% speed and a buff is supposed to last 30 seconds, then the client-side approximation counts down at 60% speed, then the buff abruptly expires from 12 seconds left. I think the bug there is that the server-side tracking of buff duration doesn't adjust for the different running rate the way it adjusts for everything else.

Nearly everything is still kept in sync, including client-side approximations to what is going on. This doesn't cause any rubber-banding, for example.

The one thing that is out of sync is client-side approximations to remaining buff duration. For example, if the server is running at 60% speed and a buff is supposed to last 30 seconds, then the client-side approximation counts down at 60% speed, then the buff abruptly expires from 12 seconds left. I think the bug there is that the server-side tracking of buff duration doesn't adjust for the different running rate the way it adjusts for everything else.

So how long is the 30 second buff going? The 12 seconds bit sounds confusing. Are you saying the 30 second buff is saying 50 seconds and at 38 seconds the buff is removed? Can you give specific numbers rather than 12 seconds left. As in it removes at 18 seconds instead of 30.

It sounds to me like there are multiple things going on. You aren't getting rubber banding so I wonder if they really have a client side calculation going on. On the other hand, the buffs might be on a different box within the "server" which is getting out of sync, way out of sync.

Do they have any settings related to server side calculations only which you can set to see if anything changes?

Let's say it's a 40 second buff with a 30 second cooldown, with the server running at 60% speed. If you have time elapsed (in real time), remaining buff duration (displayed), and remaining cooldown (displayed), it looks like:

So both the remaining buff duration and the remaining cooldown time are slowed down. When the server thinks the buff expires, it resynchronizes with the client and the buff is gone. But that doesn't happen for the cooldown, which forces you to wait.

Also, if you teleport (mainly backspace to turn in a quest), it resynchronizes the remaining buff duration with the server. So if I teleported after 20 seconds, the remaining buff duration would change from 28 to 20, the real time that the server thinks it has left.

I love this game, but IMC (the developers) treats the international version as the ugly step child. They just keep it around for the child support.

IMC actually does not care at all about it's international version. It's especially apparent when you follow the Korean version.

They honest to god can't be bothered to fix major bugs in the international version, even when they have already fixed the same bugs for Korean Version. All they would have to do is just roll these fixes over to the international version.

If you want to make this more bizarre, I've now concluded that it's a client-side problem, not server-side. On two occasions, the game has crashed my computer and I've been forced to reboot, and it has changed the speed at which the game ran. This morning, I logged on and it was running slow, so I rebooted my computer to see if it would make a difference. It did. But logging out and back in without a reboot never changes the speed at which the game runs, even if several hours have passed.

Client side bugs are nothing new, of course. But this one affects things that should be server-side, such as skill cooldown lengths and mob movement and attack speeds. How is it even possible for a client-side bug to make mobs move and attack slower in an open world game? I have no idea, but that's how the game apparently works. You'd think that even if client-side approximations were slowed down, you'd take damage from phantom attacks when the server insists that some extra attacks landed, but that never happens. That's what previously convinced me that it was a server-side bug.

It's also interesting that the speed seems to be only one of several discrete steps. It's either running at about 65%, 80%, 90%, or slightly over 100% of the nominal speed. That it doesn't go far over 100% means it's not really an exploitable bug, either, unless it has consequences that I'm not aware of.