Technical solution to eliminate desync in single-player sessions

It seems to me that between OP and the GGG responder a lot of time could be better spent solving the problem rather than arguing over merits. It's not like this problem is costing GGG money and players... oh wait.

Thanks Rhys! Wonderful response!

"

The server must validate the snapshots in real-time, not once the client leaves the instance.

You are already doing this to ensure the player is not cheating. So that should not need to change. The snapshot is just the player's input and hash.

"

Also also, you need to be able to save the player's data at a moment's notice to prevent item dupes with trading.

This system ive proposed only applies to combat/pathing. It does not apply to trading or crafting.

"

Floating-point calculations will still cause desync.

You are right on this one, I was surprised nobody brought it up to challenge me. Does the game not use the IEEE754 standard for binary floating-point arithmetic? If Path of Exile is programmed in C++, you can set the floating-point behavior with the /fp compiler flag as long as none of the libraries are compiled with -ffast-math.

"

The client would effectively have the ability to see into the future.

The future would change each time a new roll occurs, which would make it virtually impossible to predict. Even a seasoned bot would not have the computational power to benefit from this.

"

Using (say) 1000 Fusings to try for a 6-link would take forever (you couldn't spam shift+right-click).

Again, this solution does not apply to crafting.

"

Now, you suddenly need the ability to effectively "rewind time" as far as the simulation is concerned.

This has been brought up several times. I indicated that the game would need a delay on town portal / logout of 2-3 seconds. As long as the snapshots are very frequent (a second or less), then you could not reliably prevent death.

"

This entire system breaks down completely as soon as you have more than one player.

Yes, ive said this. This system is designed specifically for single-player sessions.

"

Maphack would be even easier, and better, because it could show all the monsters and chests and items on the map, too.

The server would still retain the map/items/monster spawning.

Whatever

Also Rhys, can you comment on the possibility of fixing Path of Exile's rampant desync issues? I still whole-heartedly believe that desync is a significant issue due to the client having no ability to process portions of the game's calculations.

Honestly, the problem here is that GGG used a shit networking model for the game. They should have designed PoE so the client is just an interface to the server side game.

Trying to maintain to states to eliminate lag for a fast paced game all goes down the toilet when you put desyncs into the equation, because I die due to desyncs all the time, and PoE can't do anything about sync issues with their current system

Well, Rhys didn't say they can't do anything. He pointed out some realistic problems, but it can be overcome. I would definitely love to hear the approach they are taking to mitigate desync in the long run though.

"

SkyCore wrote:

"

qwave wrote:

"

Your use of absolutes detracts from your credibility. There is no 100% guarantee of anything, and the only way for the server to obtain information of user interaction is susceptible to automated manipulations.

A mob cannot be out of sync because the server and client are using the same key. It is a 100% guarantee because there is no 'sync'. I can use absolutes because it IS absolute. There is nothing more absolute than a shared key.

Wrong wrong wrong. User interaction CANNOT be anticipated by the server. <--period Thus there is no guarantee.
Your lack of knowledge about this most fundamental aspect leads me to believe you are not near as competent as you claim to be.

I must admit i was wrong here. Wrong in how i phrased things. When you say there is no 'sync' , i see that there is still a syn. Its implicit in the fact that both the server and the client are keeping track of the same states.(which arent the same and thus not synched because ANY user interaction causes a temporary difference between the two) Its a matter of semantics. And i think i would lose in a court of law to determine the precise definition of synch.

"

When you say there is no 'sync' there is still a sync. Its implicit in the fact that both the server and the client are keep track of states.

I will also admit to being very bad at explaining things. =)

These are very complicated topics, and it's great to see GGG involved in these types of discussions. Now, if only they can fix it. ;-)

"

Rhys wrote:

A whole bunch of shit that totally makes perfect sense
Just my 2c.

"

qwave wrote:

Yes, but the most important thing is that both the client and server use these values to simulate the game state and entropy, including mob pathing.

And this seed that is sent to the client is in no danger of being figured out? This seed needs to go into the PRNG unencrypted to get the process started, no?

"

qwave wrote:

The mob is guaranteed to be in sync 100% of the time if both the client and server are running the exact same deterministic simulation. So if the client clicks the mob, then he clicks the mob.

At first you said snapshots are sent in 1 second intervals, meaning the client could only store snapshots in 1 second intervals, else the random number generators will get out of sync.
I'll come back to this.

"

qwave wrote:

The mobs will be moving during each snapshot based on the entropy produced from the seed. Therefore, both the client and server will know the locations of mobs because they are sharing the same seed and thus the mobs are traveling in the same spots.

I'm sorry, but this just isn't possible. If mob movement is based on a seed value, then the player can have no affect on the mob. If the player can influence mob position, then no seed value can be used to determine mob position. In which case a calculation based on player position and mob position needs to be made.

Let me put it another way, a seed value can determine the starting position of a mob, type of mob, and other variables, but a seed cannot determine where the player will go. Hence a seed, and only a seed as you propose cannot contain that information. Either the client or the server or both will have to do that math.

Again, at first you said snapshots would be sent once a second, and verified at the end, meaning more then one action per snapshot, meaning the server couldn't make any determinations until the player left the area, meaning a whole lot of calculations to figure out where everything is/was, meaning no possible way to determine these things after the fact.

So now we're streaming this snapshot every millisecond, and the server is verifying each snapshot as it comes in. Where does prediction come in? I remember a time when PoE didn't have prediction, or different prediction algorithm then they do today, it was a vastly different game. Is the client trusted to predict the movement of mobs based on the client trusting the position of the player. Can you see no way this can be tampered with?

"

qwave wrote:

Your game client is creating the snapshots 100% of the time and streaming them to the server. This is the same way the game is currently doing it, that doesn't change at all. The difference is that the client is able to accurately run the 'simulation' without having to receive responses from the server.

I get what your try to say here, but you can't have a simulation on one side the trusts the user, and another simulation on the other side that trusts the users client. It just can't work like that. If I can manipulate the snapshot being sent or the client itself, the server has no choice but to trust me.

"

qwave wrote:

The client must adhere to the deterministic seed. The seed runs against the game engine, so if the mob hits you, that has to be part of the snapshot. If you send a snapshot without the mob hitting you, the server will compare the snapshot to it's own simulation and validate that you hacked the system. The client cannot forge a snapshot because the server is running the same simulation.

You continue to leave out player movement and actions, which is NOT part of the servers 'deterministic' seed. How and when are interactions between mobs and players calculated. Who does the calculation? If the server does, how is it any different from what we have now, if the client does it, how can we trust the client.

"

qwave wrote:

The validation can occur anytime that GGG wants. I only recommended the end of the session because it's the most efficient way to do it. The server does not 'persist' (save your new state to the database) until it has validated your snapshot. However, it CAN save the snapshot so that it can be restored/validated in the event of crashes/disconnects/etc.

You started of saying verification could be done at the end of the session. Clearly it cannot be. You said one second snapshot shots could be made and sent, then said the client would be streaming 100% of the time to the server. You claimed seed values could represent entire game states, I'm 100% positive that they cannot, because calculations for player/mob interactions will have to be made at some point. Prediction needs to be made based on player position and movement vector, and this prediction will have to be made by an untrusted client, or a server that is forced to trust the client. You outline no way to prevent players losing everything because your system only allows for a true/false response.

On my last note, from what little I've read today, it's seems that having the RNG in the hands of the enemy (the user) would allow them to watch/record all the numbers generated from it. Does having a possibly VERY large sample set of numbers generated not allow for ways to figure out what the seed is or possibly the next number in the sequence? I'm sure that's not the case in every algorithm, but I am sure that every RNG algorithm should stay out of the hands of the enemy.

Look, I'm tired, and uneducated in programming, but I'm pragmatic and willing to learn, but maybe this isn't the right time or place though.