Improved lag compensation/prediction code - Suggestion

[Llewen]

Games like Half-Life are coded in a way that predicts where players will be to compensate for lag, so that even if my ping is 200+, if I shoot at another player, my bullets will generally hit. UO does this extremely poorly. It isn't obvious if you are using a ranged attack of some sort, including pets and summons, but if you try to close with a melee weapon on a moving player, unless your ping is extremely low, it can be almost impossible.

Now it could be there is a trick to this that I don't know about, but I really think this is an area of the code that could be radically improved. Now I'm guessing with UO's wonky z axis issues it might not be as simple as the 2D nature of UO would suggest that it should be, but still, if the devs ever get a minute or two to relax, this is something I'd like to see worked on.

 

[EnigmaMaitreya]

Everquest all but vanquished that form of lag.

You can (very very occasionally) see the mechanism.

You will, lets say, run forward , stop and rubber band back. This is caused when the Client has ... limited autonomy to do things and synch's up with the server. In EQ's case that is approximately a 6 second tick count (or in short EQ does thinks on 6 second intervals i.e. a tick). I believe UO is a 5 second tick.

What EQ did was to update the client with changes in a defined radius from the character (this is a generalization) rather than a complete check of that defined radius every 6 seconds.

UO does the same thing .... mostly, it allows the client to be ... some what autonomous, but no were near the level of EQ. So you cam move etc but the entire radius is being rechecked constantly, which of course is more data traffic and more compute work (server side).

I think I know the basic reason they continue to do this and if so, then a choice by OSI, that I may have had some influence on a long time ago may, in hindsight, have been a big mistake.

It would all have to do with duping and duping in EQ is 0.00000000001 of what appears to be in UO, based on the constant posts.

 

[drinkbeerallday]

it can be almost impossible.

so it is possible that it can be nearly impossible? that doesn't sound too bad.

 

[Llewen]

It would all have to do with duping and duping in EQ is 0.00000000001 of what appears to be in UO, based on the constant posts.

I'm not sure I understand how this specifically relates to duping? Although I guess I can fathom in a general way how it might be. I wouldn't know any of the specifics though, and obviously we shouldn't go into them here. I did have a personal attendant magically copy itself on me once.

I paged a gm about it, and the gm didn't seem to care...

 

[EnigmaMaitreya]

I'm not sure I understand how this specifically relates to duping? Although I guess I can fathom in a general way how it might be. I wouldn't know any of the specifics though, and obviously we shouldn't go into them here. I did have a personal attendant magically copy itself on me once.

I paged a gm about it, and the gm didn't seem to care...

One could ask a generalized question, "Should one consider ones datagram (the definition(s) of data packets) proprietary or should one let them be ... exposed (even if indirectly) to the community".

One could generalize that, the more the Datagram is exposed to the community, the less autonomous the client may need to be, to compensate for the ... (virtually) clear text. OR in short there may be a correlation between the availability of the Data Packet Definition(s) and the Autonomy of the Client.

 

[Eslake]

It doesn't relate to duping at all.

You can't effectively code that sort of thing into a game like UO. For targetting, it is irrelevant because you can target someone from the opposite end of the shard if you have targetted them already (or if one of you lags so you still see them there)

And applying predictive (or backtrack) methods to the game would destroy what there is left of PvP.

Target a player and get off screen, induce lag via 3rd party and while the client shows him sitting still you walk in and drop everything you have on him. Walk away then cut the induced lag.

What happens?
Does the game play catch-up with your client and show you've killed this guy (who had no chance to retaliate)?
Does it backtrack and say you're still standing where you started but are now out of mana (and did your weapon take damage)?
Or did the potential target come find you and kill you while you were faking the lag? - in which case again, what happens on your client?

Simply put, the only way to prevent any predictive measures from being abused would be to always assume anyone lagging is attempting an exploit and put them at the disadvantage.

 

[EnigmaMaitreya]

It doesn't relate to duping at all.

I disagree.

While EQ's PvP is a joke, that is NOT because of the client. It is because a Level based system inherently prevents quality PvP unless it is a Peer vs Peed.

UO core was the first one out there.

EQ's core was ... essentially a copy of UO's core with some modifications (mostly upgrades based on the learning curve of UO).

The Clients diverged considerably. EQ is a true 3D client and incorporates multiple camera angles/views. UO is a 2D representation of a 3D graphics data.

BUT

EQ has chosen to view its ... datagrams (network traffic) as proprietary. UO has chosen to view its datagrams as ... licensed property. EQ has almost NO duping, UO has lots of duping.

When one knows the Network Traffic, it is not hard to ... figure out exploits.

The only prevent in that scenario is to 100% be server side action (as in the Client is brain dead).

 

[Llewen]

And applying predictive (or backtrack) methods to the game would destroy what there is left of PvP.

Target a player and get off screen, induce lag via 3rd party and while the client shows him sitting still you walk in and drop everything you have on him. Walk away then cut the induced lag.

What happens?
Does the game play catch-up with your client and show you've killed this guy (who had no chance to retaliate)?
Does it backtrack and say you're still standing where you started but are now out of mana (and did your weapon take damage)?
Or did the potential target come find you and kill you while you were faking the lag? - in which case again, what happens on your client?

Simply put, the only way to prevent any predictive measures from being abused would be to always assume anyone lagging is attempting an exploit and put them at the disadvantage.

That sounds like a reasonable argument, but how do games like Half-Life prevent that sort of thing? They would be just as susceptible to what you have described as UO would be. I'm pretty sure this could be implemented without that being an issue.

It doesn't relate to duping at all.

I disagree.

EQ has chosen to view its ... datagrams (network traffic) as proprietary. UO has chosen to view its datagrams as ... licensed property. EQ has almost NO duping, UO has lots of duping.

When one knows the Network Traffic, it is not hard to ... figure out exploits.

The only prevent in that scenario is to 100% be server side action (as in the Client is brain dead).

There is no question, but this really isn't the issue here, that one of the reasons the 2D client has the problems it does with third party apps is that the packets are not encrypted, so third party apps are able to intercept and modify packets relatively easily. It is also true that Valve (the developer for the Half-Life franchise) has fairly effective anti-cheat functionality in it's VAC program, something that UO desperately requires.

And yes, the ability to modify packets easily would make prediction code susceptible to exploitation. So, once again, we are back to good ideas being impractical due to the fact that the use of third party apps with the 2D client is completely uncontrolled. Every time this topic rears it's ugly head, I start to get angry, so I guess I'll just drink my coffee and go do something else...

 

[Gildar]

First... lets tackle the easy one.
Allowing the client to be considered as "trustworthy" in any way, shape, or form, is asking for massive amounts of cheating. The only thing that should decide if a spell was successful, or damage was dealt, or you were close enough to take a swing (or fire an arrow) is the server.
The client's job is only to say "I want to perform action X", and to display the results that the server calculates back to the player.


Allowing the client to predict what it will get from the server for other objects could be beneficial, but it can also be a hindrance, depending on how people think and how people act in different situations. You definitely can't predict for very lengthy periods of time in UO because it's so fast paced. Two seconds and somebody can be a more than a full screen away.
Predicting one or two steps, however, might be enough to give some people a better sense of what is going on.

If such prediction capabilities were given to the client, it should have a user-facing sliding scale for how far ahead it will predict, with the lowest option being how it currently works (not predicting at all). Personally... I'd almost definitely keep it off - I've got enough experience to predict where people might run to, and know how far I need to aim in front of the person to actually be where they are in different situations.

edit:: Even with encryption, a client can't be trusted. If the program doing the encryption is in the hands of the enemies, they can (relatively) easily adjust what gets sent through the encryption algorithm.

 

[Llewen]

I believe in Half-Live there is a cvar for lag compensation, so you can turn it off and on, and I'm pretty sure all the actual hit and miss calculations are made server side, but the prediction code allows those whose connections may not be perfect to compete. I have no idea how it works exactly, but I would think any coder in the industry would know what I am talking about and have some idea at least how it works.

 

[Herc]

Stop overthinking it. What happens every time the encryption changes after a publish? Most of the cheaters disappear. Hrmm.

Script a little encryption change at server up every 3 days and you've killed half the cheaters out there. Hard core cheaters will be the hardest to kill, but the passive cheaters will be crippled heavily. Half is a good number.

 

[Nexus]

Stop overthinking it. What happens every time the encryption changes after a publish? Most of the cheaters disappear. Hrmm.

Script a little encryption change at server up every 3 days and you've killed half the cheaters out there. Hard core cheaters will be the hardest to kill, but the passive cheaters will be crippled heavily. Half is a good number.

Script in a litte Encryption change ever 3 days and 30 minutes after server up the cheaters will be at it again.

The people developing the programs folks use to cheat in this game are very good at what they do. They know how the game's client works and what it's restrictions are. The Only thing that limits how long before people start cheating again is how long it takes for the developers of these programs to upload a new version, and how long it takes for the cheaters to download it.

 

[Eslake]

The people developing the programs folks use to cheat in this game are very good at what they do. They know how the game's client works and what it's restrictions are. The Only thing that limits how long before people start cheating again is how long it takes for the developers of these programs to upload a new version, and how long it takes for the cheaters to download it.

But it usually takes 2 days for them to get it all put together and back in the game.
I love it just after a patch, I can go mining and when I meet someone else mining, they actually *gasp* SPEAK!

Those who think people still run on 2D because it can be scripted on, are not thinking very clearly.

If they dropped 2D today and forced us all onto KR in the morning, the script programs would be rebuilt to run in KR by the end of the week, and just updated as needed after that.

2D <> Scripting. The client used is irrelevant.

That sounds like a reasonable argument, but how do games like Half-Life prevent that sort of thing? They would be just as susceptible to what you have described as UO would be. I'm pretty sure this could be implemented without that being an issue.

They don't. At least not in the way it would have to be done on UO.
It is entirely another matter for UO than it is on a game where the only prediction needed is whether or not someone's aim is accurate after compensating for lag.

That sort of 'pointing' doesn't exist in UO. Here it is about unique actions taken, not relative positions.

A good example is the way casting NPCs work now. They "Predict" their casting sequence and it hits you even on the other end of the world if you manage to recall away.
Imagine the damage of applying that same design concept to players.

 

[Llewen]

That sort of 'pointing' doesn't exist in UO. Here it is about unique actions taken, not relative positions.

That is true for the majority of combat actions, with the exception of melee combat, which was the point of this whole thread. For melee actions relative positions are important, and if you have a ping of over 40 or so, you are at an extreme disadvantage when trying to attack any player character that is in motion. That is the specific situation which I am addressing here, which could, in my opinion, use some work.

Some things could be done server side that might not be being done at this time, to improve the accuracy of the display of relative positions, such as raising the process priority of the UO server software. And I expect that substantial improvements could also be made to the net code, both on the server and client side, but no matter how much those things are improved, there will still be lag that will need to be compensated for when it comes to situations, such as close melee combat, where relative positioning is important.

I'm not suggesting by the way that the technical mechanics of the relative positioning code are the same when comparing a game like Half-Life to UO, obviously they aren't. However, I do expect that some of the same principles or general concepts used to address the issue in one, might be applied in some way to the other.