According to this thread...it's terribly wrong.

Any experts here to make more clear?

LOL.."i write MMO's for living"

..and i don't approve da code  ..

Here you find proper reply

Originally posted by DarthRaiden

LOL.."i write MMO's for living"

..and i don't approve da code  ..

 

Here you find proper reply

Coder Lingo 101:

Design Decision-  A term used when a person(team) cannot solve a problem.

The problem cannot be solved it will exist in every client - server application. The handling will be different .. 

I like how people who have never once even seen a snippet of Darkfall's coding try to comment on it, saying it's "wrong".....

Originally posted by DarthRaiden

Here you find proper reply

the linked poster above is correct.

in a nutshell:

when client<->server communication is interrupted, on the server side, you have 2 basic implementation choices: (1) allow the client (player) to continue along their last known course, or (2) treat the client as stopped or barely moving. DF does the latter, as do most FPSes. most MMOs do the former.

the problem with (2) is that to other people, the lagged out player just stops moving, which obviously sucks for them in combat. with (1), the player would just appear to continue moving in the same direction. examples of this in MMOs are, eg: someone disconnecting in a raid and ghosting into the boss/spawn up ahead, or DAOC "lag-casting".

the HUGE problem with (1) is that it's easy to exploit, by artificially making your client lag, which causes the server and other clients to see your character warping and rubberbanding all over the place. using (2), if you artificially try to lag your client, it's highly detrimental to you (because you just stand still -- easy target).

darkfall does it the best way, for its kind of gameplay (FPS). the OP in that post doesn't know what he's talking about. he's conflating lag with ping, when the 2 are handled very differently.

Movement prediction would not be a good thing for a game like this (Due to its combat nature), its best to leave it all on the server.

However, we do know that the server is the clients bitch in regards to movement and updates....or speedhacks wouldn't work.

The real problem is they implemented the server as the end all be all of movement (good) , however it doesn't seem to have any sanity checks (bad). Meaning the server accepts any data received as real.

Essentially, it's halfassed.

Originally posted by Mrbloodworth

 

Movement prediction would not be a good thing for a game like this (Due to its combat nature), its best to leave it all on the server.

 

However, we do know that the server is the clients bitch in regards to movement and updates....or speedhacks wouldn't work.

The real problem is they implemented the server as the end all be all of movement (good) , however it doesn't seem to have any sanity checks (bad). Meaning the server accepts any data received as real.

Essentially, it's halfassed.

 

I have seen speed hacks in most of the online games I have played, at one time or another. As this is the case, do all MMO's rely on similar architecture?

Originally posted by robertb

Originally posted by Mrbloodworth

 

Movement prediction would not be a good thing for a game like this (Due to its combat nature), its best to leave it all on the server.

 

However, we do know that the server is the clients bitch in regards to movement and updates....or speedhacks wouldn't work.

The real problem is they implemented the server as the end all be all of movement (good) , however it doesn't seem to have any sanity checks (bad). Meaning the server accepts any data received as real.

Essentially, it's halfassed.

 

 

I have seen speed hacks in most of the online games I have played, at one time or another. As this is the case, do all MMO's rely on similar architecture?

No, they don't, and speed hacks come in different flavors. Its more of a case of "How easy did you just make it for people to spoof the server or create speed/movement hacks".

Its all data, and all data can be manipulated, its a question of ease.

And no, i have not seen any of darkfalls code, im am purely speculating here. I am giving them the benefit of the doubt that they did not leave the client to report movement..... Even if i see things that give me pause to the contrary. Pun intended.

Originally posted by robertb

I have seen speed hacks in most of the online games I have played, at one time or another. As this is the case, do all MMO's rely on similar architecture?

all network games (not just MMOs) use the same basic principle of the server streaming information to the client, which the client then renders. in all modern games, the server dictates everything, essentially because the information the client sends cannot be trusted not to be manipulated. there are, however, various thorny issues with how network lag is handled, accordingly most network games use varying degrees of client side prediction (read: guesswork) when the stream of info between client & server are interrupted (due to lag/packetloss/disconnection).

deliberate manipulation of this network stream can produce various in-game effects, such as what we might call speedhacking, rubberbanding, etc (alternatively, speedhacks and the like may arise from exploitation of a plain old boring bug in the network stack - won't go into this here).

there is basically no real way of preventing this kind of abuse, without impacting performance in a big way. similarly, all client/server programs (not just games) are susceptible to other programs intercepting and manipulating the data stream between client/server, by the very nature of the client/server setup. as you said, the proof is in the pudding: basically every network game out there has speedhacks and/or aimbots.

lastly, it may simply not be possible to implement certain kinds of games without offloading *some* of the game logic onto the client, which obviously means introducing the potential for cheats. course, there is the possibility of doing thing like on the fly encryption/decryption of packets between client/server but the potential for figuring out a cheat is always going to be there.

Originally posted by Mrbloodworth

 

Essentially, it's halfassed.

 

Like many, many aspects of this game from the UI to the (lack of) real content.

I think it's quite crystal clear that 100% of the movement is handled client-side without sanity checks. That's probably for the sake of performance, because this kind of system is probably the fastest one.

In other words, they're NOT using time based movement at all, they're using another system (simpler & faster & less precise, if you wish).

With such an architecture, implementing the system the OP is talking about would be very hard and taxing performance-wise.

Originally posted by javac 

the HUGE problem with (1) is that it's easy to exploit, by artificially making your client lag, [..]

Oh dear !...  me  and javac agree on something. I have seen this problem in quake wars where attempts are made "average"  out latency. I have seen plenty of players almost unhittable and jerkily moving due there deliberate gimping of their connection. Of course on decent servers they get banned quickly. With regard to DF we don't know what the source code is like as we cannot see it.

However just to disagree with Javac (!) the combat is still too rudimentry and basic for my and many more refined FPS players tastes. Certainly not M&B like. At best the code is probably a very generic solution. No technological marvel here I am afriad. Very simple combat  actions/options so you can have much more people on screen. No real boundary has been broken. I can understand the pro and cons of various techinques and limitations but I cannot understand why DF combat is marked as revolutionary when it is simply not. it is simply 100 odd people (if that) running around and hitting left mouse button and right occasionally with little sequencing or fluidity or directional attacks/blocks. 

To put it another way AV won't be selling this piece of DF on as Tasos reuseable technology speech which he gave to attract funders. It is simply so so... 

Okay you will flame me but I will state something here, it harkens back to the days of yor, when rocks were soft and dirt was young and there was this game called EverQuest. The GM's there decided in the vasty world of pvp they would do something new and interesting, they would not make people that lagged out keep moving, or stop, if they were in combat. Nope if you smacked a lagged out person that person became one bad #%# npc that handed you your #$% without mercy and also handed the same #$% to anyone else that hit them. Call it what you will but short sighted codeing be short sighted codeing. If EQ did that some three to four years ago, they should be able to as well.

Originally posted by javac

Originally posted by DarthRaiden

Here you find proper reply

 

the linked poster above is correct.

 

in a nutshell:

when client<->server communication is interrupted, on the server side, you have 2 basic implementation choices: (1) allow the client (player) to continue along their last known course, or (2) treat the client as stopped or barely moving. DF does the latter, as do most FPSes. most MMOs do the former.

 

the problem with (2) is that to other people, the lagged out player just stops moving, which obviously sucks for them in combat. with (1), the player would just appear to continue moving in the same direction. examples of this in MMOs are, eg: someone disconnecting in a raid and ghosting into the boss/spawn up ahead, or DAOC "lag-casting".

 

the HUGE problem with (1) is that it's easy to exploit, by artificially making your client lag, which causes the server and other clients to see your character warping and rubberbanding all over the place. using (2), if you artificially try to lag your client, it's highly detrimental to you (because you just stand still -- easy target).

 

darkfall does it the best way, for its kind of gameplay (FPS). the OP in that post doesn't know what he's talking about. he's conflating lag with ping, when the 2 are handled very differently.

 

 

No, if you artificially generate lag in scenario 1, then you will warp on client side, since the server will update your correct position to the client when its connection re-establishes. The only difference is in 1) as you mentioned you will just keep doing the last action server recorded (EQ1 style: moving forward into lava pools, rotating around your axis, etc) and in 2) you will just stop. Why would client data be preferred over server data? It makes no sense.

Originally posted by jimmyman99

Originally posted by javac

Originally posted by DarthRaiden

Here you find proper reply

 

the linked poster above is correct.

 

in a nutshell:

when client<->server communication is interrupted, on the server side, you have 2 basic implementation choices: (1) allow the client (player) to continue along their last known course, or (2) treat the client as stopped or barely moving. DF does the latter, as do most FPSes. most MMOs do the former.

 

the problem with (2) is that to other people, the lagged out player just stops moving, which obviously sucks for them in combat. with (1), the player would just appear to continue moving in the same direction. examples of this in MMOs are, eg: someone disconnecting in a raid and ghosting into the boss/spawn up ahead, or DAOC "lag-casting".

 

the HUGE problem with (1) is that it's easy to exploit, by artificially making your client lag, which causes the server and other clients to see your character warping and rubberbanding all over the place. using (2), if you artificially try to lag your client, it's highly detrimental to you (because you just stand still -- easy target).

 

darkfall does it the best way, for its kind of gameplay (FPS). the OP in that post doesn't know what he's talking about. he's conflating lag with ping, when the 2 are handled very differently.

 

 

No, if you artificially generate lag in scenario 1, then you will warp on client side, since the server will update your correct position to the client when its connection re-establishes. The only difference is in 1) as you mentioned you will just keep doing the last action server recorded (EQ1 style: moving forward into lava pools, rotating around your axis, etc) and in 2) you will just stop. Why would client data be preferred over server data? It makes no sense.

there is usually some resyncing of where the client & server think you should be, since while packets were lost, the server was only guessing what you *might* have been doing were packets not lost.

in any case it's clear DF doesn't do movement on the client.

Originally posted by javac

Originally posted by jimmyman99

Originally posted by javac

Originally posted by DarthRaiden

Here you find proper reply

 

the linked poster above is correct.

 

in a nutshell:

when client<->server communication is interrupted, on the server side, you have 2 basic implementation choices: (1) allow the client (player) to continue along their last known course, or (2) treat the client as stopped or barely moving. DF does the latter, as do most FPSes. most MMOs do the former.

 

the problem with (2) is that to other people, the lagged out player just stops moving, which obviously sucks for them in combat. with (1), the player would just appear to continue moving in the same direction. examples of this in MMOs are, eg: someone disconnecting in a raid and ghosting into the boss/spawn up ahead, or DAOC "lag-casting".

 

the HUGE problem with (1) is that it's easy to exploit, by artificially making your client lag, which causes the server and other clients to see your character warping and rubberbanding all over the place. using (2), if you artificially try to lag your client, it's highly detrimental to you (because you just stand still -- easy target).

 

darkfall does it the best way, for its kind of gameplay (FPS). the OP in that post doesn't know what he's talking about. he's conflating lag with ping, when the 2 are handled very differently.

 

 

No, if you artificially generate lag in scenario 1, then you will warp on client side, since the server will update your correct position to the client when its connection re-establishes. The only difference is in 1) as you mentioned you will just keep doing the last action server recorded (EQ1 style: moving forward into lava pools, rotating around your axis, etc) and in 2) you will just stop. Why would client data be preferred over server data? It makes no sense.

 

there is usually some resyncing of where the client & server think you should be, since while packets were lost, the server was only guessing what you *might* have been doing were packets not lost.

 

in any case it's clear DF doesn't do movement on the client.

Thought a quick glance of you tube shows some wonderful speed hacks with no rubber banding or latency effects you would normally see. I think the speed of the movement may actually be .. client side?

Come on Javac post some links to you tube vids of hacks and discuss with comparison to other speed hacks in other games:)

Originally posted by tombear81

Thought a quick glance of you tube shows some wonderful speed hacks with no rubber banding or latency effects you would normally see. I think the speed of the movement may actually be .. client side?

Come on Javac post some links to you tube vids of hacks and discuss with comparison to other speed hacks in other games:)

I think you are right. If client movements were processed on server, then there would be no speedhacking, since the server adjusts your location. If this work is done on client side, though, then the client can be "hacked" and simply update server with movement distances 10 times more then usual.

If that is the case, wouldn't there be some checks whether client reports abnormal movement (after compensating for sprinting/riding)? I've done some work with client/server communications, but never in a game, so maybe I am missing something?

Originally posted by javac

there is usually some resyncing of where the client & server think you should be, since while packets were lost, the server was only guessing what you *might* have been doing were packets not lost

in any case it's clear DF doesn't do movement on the client.

Actually the opposite is quite clear. The movement is quite clearly almost completely client side, and I'm willing to bet that the client sends <X, Y> packets to the server, rather than <DeltaX, DeltaY> packets.
 

IMHO they did not even implement sanity checks.

I think the only serverside movement-related feature is collision detection (there are no pass-through-walls hacks as of now AFAIK).

Originally posted by Galadourn

According to this thread...it's terribly wrong.

 

Any experts here to make more clear?

is this an 1april joke or is it really that bad?