Explanation of Dead Reckoning in MMO's

[Vengeance]

We just had an interesting technical conversation (and lecture from me, so doubly interesting :-)) about Dead Reckoning on irc.  Why it is needed; what matters about it and what doesn't matter.  Someone suggested I post it here and so I have.  Slightly edited for on-topic-ness.

[17:03:24] <Serpentus> Well, the server treats mobs the same as characters, so what you really want is time synch between players, no?
[17:03:40] <Gothi[c]> right
[17:04:27] <Serpentus> One problem is that latency is never constant.
[17:04:39] <+Lanarel> also, iif clients would keep an estimate of their lag, the server could correct for what it receives, and the client could correct for what it gets from the server.
[17:04:42] <Serpentus> Another problem is that I type poorly.
[17:04:59] <Gothi[c]> Serpentus: right, that's why it would be better to have all clients+server agree on a common clock time
[17:05:24] <Serpentus> So you want us to host an atomic clock?
[17:05:40] * Serpentus grins.
[17:05:44] <Gothi[c]> well, that's something that i want to avoid
[17:05:51] <Serpentus> Vengeance: that's in the budget, right?
[17:06:01] <Gothi[c]> it's not for PS, don't worry
[17:06:05] <+weltall> ahhahaah
[17:06:09] <+Lanarel> Serpentus: that only works if everyone has such a clock
[17:07:06] <Serpentus> Gothi[c]: The simple fact is that it doesn't matter who is keeping time, you will always need to ask the clock what time it is. Even chipsets do not measure seconds accurately.
[17:07:28] <Gothi[c]> i guess i could implement something like Object->Translate(matrix,time,algorithm) where time is the time an object should change it's position/rotation in, and algorithm could be linear/logarithmic/whatever
[17:07:39] <Serpentus> If I leave my computer on for a month and do not sync it with a time server, I will inevetably lose a minute or two.
[17:08:01] <Gothi[c]> and then only send updates when needed, and pass them to that function
[17:08:27] <+Lanarel> I have been looking at pc time recently. I could see a jump in clock speed when it got a bit warmer, resulting in about 40 seconds difference a day
[17:08:52] <Serpentus> We can't really treat time as a variable.
[17:09:35] <Serpentus> I mean, we can use it in functions as an argument, but to have a "time server" that synchronizes data execution across disjoint groups of machines is a bit out of our reach technologically.
[17:09:59] <Serpentus> Unless you want to host an atomic clock.
[17:10:05] <Serpentus> Which I am all for.
[17:11:16] <Serpentus> And with that said, step 1 in the paper you pasted is inherently flawed.
[17:12:37] <Gothi[c]> heh
[17:12:49] <Vengeance> ok here
[17:13:27] <Vengeance> Gothi[c]: What kind of game are you making?
[17:13:47] <Gothi[c]> a couple
[17:13:55] <Gothi[c]> that's why i'm trying to keep things generic
[17:14:05] <Gothi[c]> right now it's just an engine
[17:14:31] <Vengeance> The issue is that different games require different levels of accuracy.
[17:15:07] <Gothi[c]> ok
[17:15:09] <Vengeance> FPS is a good example of needing a lot of accuracy.
[17:15:21] <Gothi[c]> well it wont' be for FPS games
[17:15:22] <Vengeance> Bullets and lasers go fast, and 1/2 second latency is a lot
[17:15:41] <Vengeance> if the enemy's mesh is off by 2 pixels, that might mean the diff between a hit and a miss
[17:15:43] <Gothi[c]> one idea was a space shooter mmo and the other was more something like PS
[17:15:54] <Gothi[c]> i guess the space shooter would have to be more accurate
[17:16:24] <Vengeance> In PS, we handled it the way every fantasy MMO handles it, which is to ignore it completely. 
[17:16:30] <Gothi[c]> right now i have a working server and client. clients can login and move around and see eachother. i'm just trying to implement a generic algorithm to smoothen the movements between net updates
[17:16:32] <@Khaki> in PS time sync is not needed
[17:16:37] <Vengeance> None of our spells or targeting or rules require pixel perfect accuracy
[17:16:45] <Vengeance> in fact, none depend on physical location at all
[17:17:18] <Vengeance> So if client A moves at 0 msec
[17:17:21] <Gothi[c]> well, i'm not even worrying about shooting and stuff yet
[17:17:32] <Gothi[c]> right now i just want my mobile objects to move smoothly between net updates
[17:17:33] <Vengeance> and client B and C are both 200 msec ping time with the server
[17:17:48] <Gothi[c]> and not jump as server sends a new position to the client
[17:17:55] <Vengeance> smooth movement is a different issue from world consistency between A, B and C
[17:18:06] <Gothi[c]> that's true
[17:18:12] <Vengeance> Smooth movement is what dead reckoning is for
[17:18:37] <Vengeance> you send vel updates, and ang vel
[17:18:51] <Vengeance> but you don't send them every frame, of course
[17:18:55] * Serpentus wants Vengeance to do a podcast on DR.
[17:19:04] <Vengeance> Serpentus: yeah I should.  we get lots of questions about it
[17:19:15] <Vengeance> Let's say you want to update from the network once a second
[17:19:22] <Vengeance> brb
[17:19:26] <Gothi[c]> ok
[17:20:37] <@Khaki> I don't see what's so hard about it
[17:21:32] <Serpentus> Khaki: Hard about what?
[17:22:18] <@Khaki> DR
[17:22:19] <+Lanarel> You need a smooth way of correcting wrong positions. PS just 'teleports' you. You could correct from current (wrong) position towards the correct one to keep it smoother
[17:23:07] <Serpentus> DR isn't hard, but it has pros and cons and knowing how PS implements it and for what functionality is no trivial matter.
[17:23:20] <@Khaki> Lanarel: for someone that is continuously running with varying lag and angular velocity, the errors will eventually build up to the point where the client is forced to teleport
[17:23:34] <+Lanarel> yes, there are limits
[17:24:37] <@Khaki> pixel perfect collisions in a fps still have to be done client side, that's why getting rid of cheating in a fps is so hard
[17:24:50] <@Khaki> maybe that's why there are so few open source FPSes
[17:25:15] <Gothi[c]> yeah
[17:25:21] <+Lanarel> hehe. I suggested that cheating was the reason it was done this way
[17:25:24] <Vengeance> b
[17:25:53] <Gothi[c]> a way to solve that is to do pixel perfect collision on the client, and on the server just check if the action is within the realm of possibility
[17:25:53] <Vengeance> Yes, so the issue is that for smooth movement you need updates every frame
[17:26:11] <Vengeance> The only way to do that is to extrapolate the movement from the last position and the last velocity
[17:26:31] <Vengeance> So now you do 200 updates in 200 frames in 1 second
[17:26:57] <Gothi[c]> yeah, but you're not always going to get 200 updates in a second
[17:27:06] <Gothi[c]> there may be a 1 second hickup
[17:27:09] <Vengeance> Gothi[c]: I'm saying 0 updates
[17:27:23] <Vengeance> Net update.  200 frames. Net update
[17:27:33] <Gothi[c]> oh ok
[17:27:35] <Vengeance> So now what are the possible errors here
[17:27:48] <Vengeance> If the person is going in a straight line at a constant speed, there is no error
[17:27:53] <Vengeance> the extrapolation is correct
[17:28:17] <Vengeance> If the person turns 1 frame after the first net update, you could be way off though
[17:28:33] <Vengeance> So you solve that by braeking your 1 net update/sec rule
[17:28:44] <Vengeance> and if the vel or ang vel changes, send the net update immediately
[17:29:27] <Vengeance> So now you are worried about the time lag between client A and B in that scenario
[17:29:33] <Gothi[c]> yes
[17:29:35] <Vengeance> But the time lag is invisible to both sides
[17:29:47] <Vengeance> Client A moves and controls his avatar directly so he has no lag
[17:30:00] <Vengeance> ok let me slow down
[17:30:05] <Vengeance> Let's say we have this sequence:
[17:30:14] <Vengeance> 0 msec: A starts moving
[17:30:27] <Vengeance> 500 msec: A stops moving.
[17:30:44] <Vengeance> Now with 200 msec of lag, here is what client B sees:
[17:30:51] <Vengeance> 0 msec: stationary
[17:30:59] <Vengeance> 200 msec: A starts moving
[17:31:07] <Vengeance> 700 msec: A stops moving
[17:31:20] <Vengeance> So it all happens late, but it happens consistently
[17:31:33] <Vengeance> and 200 msec isn't much unless you're shooting lasers
[17:31:50] <Vengeance> The hard part in all this isn't lag, but variable lag
[17:32:02] <Vengeance> Imagine if B sees this sequence:
[17:32:07] <Vengeance> 0 msec stationary
[17:32:13] <Vengeance> 200 msec: A starts moving
[17:32:32] <Vengeance> 800 msec: A stops moving and is now in the "700 msec" position
[17:32:51] <Vengeance> He was extrapolated for 600 msec but only actually moved for 500 msec
[17:33:02] <Vengeance> so when you "fix" his position, you have 100 msec of error
[17:33:15] <Vengeance> for a walking character at 2m/s, that's 200cm or 8 inches
[17:33:31] <Vengeance> Not enough to affect gameplay much, but enough to look jittery
[17:33:56] <Vengeance> In PS, we don't just instantly update the "fix" position though, and teleport him 8cm
[17:34:16] <Vengeance> we note the new "correct" position, and factor that into the next DR set
[17:34:24] <+Lanarel> ah, did not know that
[17:34:27] <Vengeance> so he slides gradually to the right spot over a second or so
[17:34:52] <Serpentus> crafty
[17:34:55] <Vengeance> This is harder than it sounds, because the stationary case is easy but the "running and turning plus error" case is trickier. 
[17:35:10] <Gothi[c]> right
[17:35:33] <Vengeance> You end up having to extrapolate A's current position on client B, plus extrapolate A's "correct" position on client B, and interpolate beetween those at the same time
[17:36:05] <Vengeance> So this is what we do
[17:36:17] <Vengeance> Yes it was a PITA to build
[17:36:35] <@kougaro> which explains why you sometimes see people jumping in a pit, and then "teleporting" back at the border
[17:36:40] <Vengeance> The error interpolation may have been disabled or changed since the iteration I'm talking about
[17:36:55] <Vengeance> so I would need to check it to be 100% sure, but this is how it is supposed to work.
[17:37:13] <+Lanarel> the jumps are only after server updates have not been received for a bit, kougaro
[17:37:19] <Vengeance> kougaro: Now factor in non-guaranteed UDP packet delivery and out of order delivery. 
[17:37:36] <@kougaro> Vengeance : no thanks, I will leave that to you
[17:37:46] <Serpentus> kougaro: I claim your scenario occurs because Klyros have wings.
[17:37:52] <@kougaro>
[17:38:03] <@kougaro> klyros are the cause of all evil, for sure
[17:38:09] <Gothi[c]> i need to digest this
[17:38:27] * Serpentus hides his wings.
[17:38:40] <Vengeance> Gothi[c]: If you run two PS clients at the same time and look at each other, you can see that the lag doesn't matter much quite easily.
[17:41:20] <Vengeance> Ok someone read all that out loud and record it and we'll call it a devcast. 

[Elvors]

Atomic clocks? "Out of reach technologically"? "Pretend it doesn't exist"?

No need for atomic clocks, technological reach, or pretending - you already have and use such a consistent time base, just by asking the OS for a time!
The OS synchronizes with clock sources from the Internet and achieves a typical accuracy of 10ms.
Well, for Windows that means "Windows XP and higher". No internet time for Win 9x, and no calibration (hence arbitrary imprecision) for Win2k.

So time base (the first third of the chat log) is not a problem.


Regarding lag, I have to contradict Vengeance - not about the technical facts but about the consequences.

First, Vengeance assumes a 200ms delay.
That's accurate when fighting NPCs; laanx.fragnetics.com has a ping of 400, and half of that is what you get as a delay.
However, when duelling other players, the other player's delay factors in as well, so you get a delay of 400ms.

Second, Vengeance assumes that exact timing does not matter when fighting in PS.
In practice, you have to be near your opponent when your weapon is ready to hit, and away when the opponent's weapon is ready to hit, so there's a decisive timing-related componentent in battle even without lasers.
And you can move quite a distance in 0.2 seconds, let alone 0.4 seconds!
The problem is well-known among duellers, too. There's even standard terminology for it: "lag kill".

Lag kill is simple to provoke:
Assume opponents at a distance that they can cover in 4 seconds. Each has a weapon with a 2-second hit delay.
T+0000: Both opponents start running towards each other.
T+0200: Server receives information from T+0000.
T+0400: Opponents start to see each other run. Experienced opponents will assume their opponents 400ms ahead of their actual position.
T+1890: Both opponents stop running.
T+2000: Weapon hit time is reached. Server checks if opponents are near enough to each other. Server didn't receive the "stop running" command yet, so it extrapolates their positions - since both opponents are just 10ms away from the point where they would meet, this is well within combat distance and a hit occurs.
T+2190: Server receives the "stop running" commands, and corrects the positions: opponents are now 0110ms worth of running distance from each other, way out of weapons' reach.
T+2200: Clients receive the "a hit occurred" message. One opponent goes down, the other wins.
T+2290: Clients receive the true position of the respective opponent. Opponent is moved back 0110 ms worth of running.

End result: a hit occurred though both opponents never moved near enough to each other to ever hit.
And, yes, you can cover a great deal of distance in 0.2 seconds. Since both are running towards each other, the effective lag hit distance is double of what one can cover in 0.2 seconds. I'd estimate that this distance is roughly five to eight times the diameter of the target marker in PS.

[Vannaka]

@Elvors:
If you know that's how it works, why not take advantage of it to hit your opponents without ever going near them?
What an idea... wish I'd thought of that. 

[Mythryndel]

Because the lag is not absolutely set at 200ms or 400ms as in the example... it varies significantly and can't be counted on to work reliably.

[Lanarel]

Atomic clocks? "Out of reach technologically"? "Pretend it doesn't exist"?

No need for atomic clocks, technological reach, or pretending - you already have and use such a consistent time base, just by asking the OS for a time!
The OS synchronizes with clock sources from the Internet and achieves a typical accuracy of 10ms.

First of all, if you ask your OS for the time, and your OS is windows, you only get a 15 ms resolution (or sometimes 10 I think, depending on hardware). Also, the time synchronization it has build in is for getting time accurate enough for some encryption to work, and (for earlier versions) they say it cannot be guaranteed to be accurate within a few seconds. Later versions may be better, but it is still not a full implementation of the ntp protocol, and will be less accurate. WIth ntp servers on windows machines in a lan (gigabit) I could get around 10ms accuracy. Getting this over internet is nonsense.
The ntp time synchronization assumes the pc clock is constant enough over the period that time is not checked (which may be about 15 minutes). I have seen pc time accelerate from one second to another by so much, that time would deviate several seconds an hour. Until the ntp server notices (by checking again), you may be a large part of a second off.

About lag in PvP. You are right that this is different from fighting an NPC. Assuming no lag for the NPC, this is what happens in the server:
you are standing still, and start moving. 200ms (or whatever lag later) the server notices. At some point the server decides it is time for an attack. It will compare positions, which to you would be your position of 200ms ago, but the NPC position at the correct moment. It will then tell you you attacked, which you will see when you moved another 200ms, and the npc may have moved 200 ms as well. So the attack happened at a situation (relative position) that you never saw.
In PvP, assuming you both have 200ms lag, this would happen: you two are running, with the server keeping track of your positions 200ms late. At some point it decides there is a hit and it checks relative positions. Both fighters see the result 200 ms later, at a position that seems wrong. But with both the same lag, the server did use a position that did happen. SO the result is more 'true' than with the npc.
Of course this only matters if you see how combat is implemented as a representation of something real (and not just a computer trying to get a result that is conforming character skills on average), and try to use player skill where it was not intended.

[Elvors]

Atomic clocks? "Out of reach technologically"? "Pretend it doesn't exist"?

No need for atomic clocks, technological reach, or pretending - you already have and use such a consistent time base, just by asking the OS for a time!
The OS synchronizes with clock sources from the Internet and achieves a typical accuracy of 10ms.

First of all, if you ask your OS for the time, and your OS is windows, you only get a 15 ms resolution (or sometimes 10 I think, depending on hardware).

10ms if you use GetSystemTimeAsFileTime on Windows (it pretends a better precision, but lower-order bits are filled with garbage).
1 micro(!)second if you use ntp_adjtime() on Linux.

(Examples lifted from http://search.cpan.org/~zefram/Time-UTC-Now-0.007/lib/Time/UTC/Now.pm#OS-SPECIFIC_NOTES. Not sure about OS X, might be as in FreeBSD.)

Also, the time synchronization it has build in is for getting time accurate enough for some encryption to work, and (for earlier versions) they say it cannot be guaranteed to be accurate within a few seconds.

Whoever "they" are, they are mistaken. The NTP protocol combined with the NTP algorithms give you 10ms or better precision.

The one caveat is Win2k, which uses SNTP: same protocol but dumb algorithms. It can't be worse than the current situation though.

Later versions may be better, but it is still not a full implementation of the ntp protocol, and will be less accurate.

Windows XP is said to have a full implementation of NTP.

WIth ntp servers on windows machines in a lan (gigabit) I could get around 10ms accuracy. Getting this over internet is nonsense.

Sorry, but this statement is far too broad. If there are problems with NTP time, they are related to local issues (such as not having a real-time operating system, see below), not to the internet as such - the NTP algorithms are pretty smart about detecting and factoring in systematic errors and jitter.

The 10ms accuracy is what you get at stratum 4 (end-user PCs behind a router, acting purely as clients). Stratum-2 servers tend to have sub-millisecond accuracy, and they get their time over the internet exclusively.

The ntp time synchronization assumes the pc clock is constant enough over the period that time is not checked (which may be about 15 minutes).

I suppose NTP is smart enough to detect a sub-15-minute jitter. The published claims about NTP wouldn't make sense if PC hardware were that unstable.

I have seen pc time accelerate from one second to another by so much, that time would deviate several seconds an hour. Until the ntp server notices (by checking again), you may be a large part of a second off.

Are you 100% sure you were measuring NTP jitter?
It might have been OS timeslice jitter.

In PvP, assuming you both have 200ms lag, this would happen: you two are running, with the server keeping track of your positions 200ms late. At some point it decides there is a hit and it checks relative positions. Both fighters see the result 200 ms later, at a position that seems wrong. But with both the same lag, the server did use a position that did happen.

If the player stops moving, the server will still extrapolate for ~200ms, assuming positions that were never true.

Of course this only matters if you see how combat is implemented as a representation of something real (and not just a computer trying to get a result that is conforming character skills on average), and try to use player skill where it was not intended.

In that case, the game shouldn't allow players to move around until the fight is over...

[Lanarel]

10ms if you use GetSystemTimeAsFileTime on Windows (it pretends a better precision, but lower-order bits are filled with garbage).
1 micro(!)second if you use ntp_adjtime() on Linux.

It says 10ms everywhere, I always see 15ms on different windows system . I know linux does better.

Also, the time synchronization it has build in is for getting time accurate enough for some encryption to work, and (for earlier versions) they say it cannot be guaranteed to be accurate within a few seconds.

Whoever "they" are, they are mistaken. The NTP protocol combined with the NTP algorithms give you 10ms or better precision.

They are microsoft (cannot quickly find it again), and they may not say that of more recent versions of windows. However on http://technet.microsoft.com/en-us/library/cc749145.aspx they do say for Vista: "Within a workgroup, the default setting for the time synchronization frequency is set to "once per week,"", so accuracy definitely is not their concern.

WIth ntp servers on windows machines in a lan (gigabit) I could get around 10ms accuracy. Getting this over internet is nonsense.

Sorry, but this statement is far too broad. If there are problems with NTP time, they are related to local issues (such as not having a real-time operating system, see below), not to the internet as such - the NTP algorithms are pretty smart about detecting and factoring in systematic errors and jitter.

The 10ms accuracy is what you get at stratum 4 (end-user PCs behind a router, acting purely as clients). Stratum-2 servers tend to have sub-millisecond accuracy, and they get their time over the internet exclusively.

Ok, let me rephrase that then (or turn it around and say your statement is too broad ): based on my experience with time on windows pcs, this is not for all PCs. So unless you make them really stratum 4 (fiddle with windows time server to actually use the ntp protocol not only once a week) and give everyone a decent internet connection, it will just not make everyone running planeshift with common time within 10 ms . I think you are being very optimistic.

I have seen pc time accelerate from one second to another by so much, that time would deviate several seconds an hour. Until the ntp server notices (by checking again), you may be a large part of a second off.

Are you 100% sure you were measuring NTP jitter?
It might have been OS timeslice jitter.

This was without ntp (on xp) comparing times from the pc clock (at 15ms resolution) with the highperformancecounter (cpu clock). This cpu had no variable clockspeed, and the change between the two was from one fairly constant speed to another, which was the same when trying again an hour or so later (so timeslicing seems very improbable). ntp may notice such a change (by doing the same as I did). If it does not, and things were so stable that update is not frequent, there may be some error (which is then slowly reduced).

Anyway, I do not intend to tell you time synchornization sucks, just that I do not think this is feasible to have solved for everyone running PS

Of course this only matters if you see how combat is implemented as a representation of something real (and not just a computer trying to get a result that is conforming character skills on average), and try to use player skill where it was not intended.

In that case, the game shouldn't allow players to move around until the fight is over...

It was intended to have fights depend on character skill. You can disagree with that. Not my problem, and intentions may change. You could show some dice rolling instead of the chars moving around. I prefer the way it looks now, even if system messages occur at times the chars are back to back

[Zontick]

 

 I've got a background in making things communicate in 'different versions of real time', so I'll toss my hat into the ring.

Man, you folks can make things seem pretty complicated when, given certain assumptions, they are not.

These assumptions are:

(1) That an advantage should not be given to someone because they happen to have the lesser ping time in PVP. Failure to meet that assumption - which is usually done by game designers, unfortunately - means that the people who have longer ping times are at a disadvantage and thus their experience is greatly diminished. This could be seen as helpfully self limiting from a game designer perspective such that they don't have to worry about the game experience while churning on stuff that they would prefer to do. "Blame the Internet" == Poor Answer.

(2) To make things fair in PvP, one can synchronize to assure fairness.


Pretty simple, really. And the answer is - at least for PvP - use the LCD. This is 'relative time'. The combat happens at the rate at which the lesser connection is running and can be done by testing ping on both PVP candidates and only allowing them to interact at the speed of the lesser ping.

As far as NPCs go - this could also be done but would be done more simply since there would be no ping comparison.

Group battles work on the LCD.

Yeah, I know, this is unpopular with the people with the faster connections to the server (and thus unfair advantage) - but if the intent is fairness, that would be how it would be done.

Yes, you could say that alot of other games ignore this and you would be right. And if the point is to be 'only as good as other games', that is the right answer as well. Diving into the infinitesmall details of an instantiation of the same iimplementation is just rearranging cookies on the plate. And we all know Ernie eats all the cookies and Bert gets none because Ernie's ping time to the plate is less. 

[Elvors]

Hm. I hear that there's clock drift. From elsewhere I hear that NTP works, even under Windows (XP+), which would exclude clock drift.
I'm not quite sure what to make out of this.
My initial point stands - it's a Solved Problem, and it Does Not Call for Atomic Clocks. It's possible that solutions aren't available under Windows. MS is MS

It was intended to have fights depend on character skill. You can disagree with that. Not my problem, and intentions may change. You could show some dice rolling instead of the chars moving around. I prefer the way it looks now, even if system messages occur at times the chars are back to back

Personally, I could well live with a scheme where only character skills matter as soon as it comes to combat,
However, it would make PvP tournaments relatively uninteresting - there are too many players with identical relevant stats&skills.

If PS 1.0 offers enough ways to vary charactes so that no two characters have exactly the same combat-relevant stats&skills, this might be interesting again.

[enderandrew]

I think magic needs to be balanced, ranged weapons need to be implemented, shield/weapon needs to balanced versus weapon/weapon, various weapons need to be balanced for speed and damage, and on top of that I'd like to see races get different racial maximums.  I think that will provide enough variables to make PvP different for different characters.

[Elvors]

Yeah, that would help.

There's yet another way: have maximums over multiple stats/skill.
E.g. make it so that the max for the sum of all stats is 1000. If you max all mental stats to 200, this leaves just 400 points for the physical stats.
A similar limitation could be imposed on skills. E.g., say, introduce a rule that only one of the magic ways or combat skills can be maxed, and limit everything else to a considerably lower level. So players have to choose what to max: Red Way? Sword? Heavy Armor? Shield? What max as a secondary skill?
That gives lots and lots of variation.

[enderandrew]

Ultima Online had maximum stat and skill limits so you couldn't max everything.  The problem with that is that most people then just maxed combat attributes and skills, and refused to touch say Musical Instruments because it hurt their ability to do PvP.  So I'm not so sure about that.

The other alternative that some MMOs use is a branching skill path, where you must make choices.  But usually in those systems, you aren't giving up Musical Instruments, you give up one combat skill for another.

[Elvors]

To allow Musical Instrument etc., just don't have it count against the Combat/Magic max.

I think a max on just the sum of all skill would be too simple.

[Vengeance]

I guess you totally missed the point of the big irc discussion I posted.  I will try to summarize:

1) It is impossible to synchronize times across machines.  Even with the NTP and the drift compensation, etc., you cannot trust data from a client due to hacks and cheats.  So why bother.

2) You don't need the times synchronized anyway, so spending time addressing point #1 is a waste.

You are right that right now PVP combat is overly dependent on exact timing, so there could be some advantages or tactics that leverage a slow or a fast pingtime.  But that is a design issue in our combat setup which we will be addressing in a future release of combat, not something that makes us attempt the impossible problem of net-wide time sync.

[Lanarel]

What Venge said