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?

I can't comment on Darkfall since I haven't played it, but here's a professional programmer point of view on the code that has been posted: it's horrible.

The OP criticizes the non-existing use of elapsed time in the client and posts pseudo-code to show how it's supposed to be. The only problem is that none of the time variables set in "UpdateTime" are used in his "Agent_Move" function, so really, either he seriously typo-ed his code, either he doesn't know what he's talking about.

Originally posted by Rytif

 

Quoted by the Darkfall Forum:

==========================================================================================

public static void UpdateTime()
{
// you do this to actually get the time that's elapsed for example using the api calls for QueryPerformanceCounter
QueryPerformanceCounter(out m_lCurrentTime);

m_fElapsedTime = (float)((double)(m_lCurrentTime - m_lLastTime) / (double)m_lTimerFrequency);
m_dTime += m_fElapsedTime;
m_lLastTime = m_lCurrentTime;
}
So when you would account for movement it would be something like:

public void Agent_Move()
{
Vector3 ActorDir = Vector3.Normalize(Vector3.Subtract(new Vector3(_AgentGointToPosition.x, _AgentGointToPosition.y, _AgentGointToPosition.z), new Vector3(_AgentPosition.x, _AgentPosition.y, _AgentPosition.z)));
Vector3 ActorPosition = Vector3.Add(new Vector3(_AgentPosition.x, _AgentPosition.y, _AgentPosition.z), Vector3.Scale(ActorDir, _AgentCurrentSpeed));
_AgentLastGoodPosition = _AgentPosition;
_AgentPosition = new TV_3DVECTOR(ActorPosition.X,ActorPositio n.Y,ActorP osition.Z);//new TV_3DVECTOR(ActorPosition.X, World.Landscape.GetHeight(ActorPosition. X, ActorPosition.Z), ActorPosition.Z);
//_AgentPosition = slide(_AgentLastGoodPosition, _AgentPosition);
_AgentPosition = Agent_Collide(_AgentLastGoodPosition, _AgentPosition);
Agent_SetLookAt(new TV_3DVECTOR(_AgentGointToPosition.x, _AgentPosition.y, _AgentGointToPosition.z));
if (_AgentOwnerStyle == AgentOwnerEnum.Mesh)
World.MeshManager.Mesh[_AgentOwnerName].Position = _AgentPosition;
else
World.ActorManager.Actors[_AgentOwnerName].Position = _AgentPosition;
}
=============================================================================================

 /end qoute

 

BLAHAHAHAHAHA! That code was exactly copied from Truevision3D.com and was qouted to describe to the developers on how to program their engine. It was also insisted by the other DFers to hire this individual because he'll create better code.... that is not his nor from a custom engine... mind you I'm positive it's also not c++ (it's C#). It goes to show that there is nothing but script kiddies over there in that community.

It's just so basic and has absolutely no indication of network movement (dead walking?)... because it was from a Truevision3D tutorial.. blahahaha!

I dont know much bout program languages but I thought dot net have taken over c++?

---

Originally posted by PapaB34R
I dont know much bout program languages but I thought dot net have taken over c++?

---

If by "dot net" you mean C#, then the answer is no. Utility programs can be written in a managed code base like C#. But if you want high degrees of efficiency it is usually better to use an unmanaged code base like C++ to ensure better access directly to machine instructions.

There is a hell of alot of stuff you just can't do in .NET either.   Well some of that could, but by the time you wrote the code to do what you wanted it would be a total waste of time.  You would be better off writing a dll and accessing some stuff that way.

The thing that really pisses me off about .NET is technologies that came out after .NET was established, you still have to do in C/C++.  It is like Microsoft only supports their framework when it is convenient for them.