Technical solution to eliminate desync in single-player sessions
Hola gente, acabo de crear una pagina en fb para los jugadores en latinoamerica. les agradeceria que se unan y empiecen a aportar lo que puedan. yo ayudare con la traduccion a mucha gente para poder hacer una comunidad mucho mas grande y ayudarnos entre nosotros a resolver dudas.
el link es
Hola gente, acabo de crear una pagina en fb para los jugadores en latinoamerica. les agradeceria que se unan y empiecen a aportar lo que puedan. yo ayudare con la traduccion a mucha gente para poder hacer una comunidad mucho mas grande y ayudarnos entre nosotros a resolver dudas.
el link es
Obviously this will change nothing but the desync problem will be the reason for me to stop playing this game until its fixed. Its so damn frustrating dying to a group of e.g. melee mobs although u are far away from them and in the next second you are standing right inside their middle. It wouldnt be that frustrating if you wouldnt loose 10% of your exp each time you die...
I promise that allowing the client to calculate combat is not a million dollar project. Hundred thousand dollar project, yes.
"
qwave wrote:
Even if the core game rules are tightly coupled with their server architecture, this sort of code is almost always extremely easy to move to the client. I'll leave it at that.
So you went from 'i promise' earlier on this page to 'almost always'. The number of times you have contradicted yourself in this thread is absurdly high. How can anyone who does this be taken seriously. It is a complete invalidation of your credibility.
qwave resorted to waffling long before this. I think the key point where he was hung out to dry by Rhys occurred in pages 53-55:
That was also where qwave tried to weasel out of my own skeptical appraisal of his scheme:
"
qwave wrote:
"
RogueMage wrote:
Your proposal would eliminate the crucial part of the system that keeps it both reliable and unhackable: client resychronization updates imposed by the server. Without that mechanism, the remaining options are to either trust the client, or abort any client game session whose results diverge from the server's.
Resync would occur in two situations:
- The client sends values that are not within the lenient range of the deterministic seed. This will generally only happen when the client is hacking.
- The client does not send a state hash within a lenient amount of time. This will happen if the client has huge latency / lag.
Note the weasel words I bolded above. Those were telltale signs of a hacker's approach to network security. Rhys pounced on this as well, and wasted little time in dismissing qwave's blithe handwaving:
"
Rhys wrote:
"
qwave wrote:
Actually Rhys, now that I think about it, you could just solve the floating point issue by providing leniency to the client on the precision. Just validate the state hash as acceptable if the math falls within a given range. Problem solved.
It's a hash. There is no room for leniency. This simply doesn't work. And if it did, it would allow cheating.
Also, the server cannot resync the client by sending a state hash. Doing this would make the client "rewind" back to that valid state, yes. But the simulation is still deterministic, so the client will just desync itself again at the same point in the same way. So you have to have the server run forward without the client to get it past the desync point.
The leniency was not meant to be applied to the hash itself but to the validation done by the server in a simulation using the hash, as far as I understood. The leniency was only one suggestion. The other popular one was to avoid floating-point issues altogether using different calculations. However Rhys dismissed this with the reasoning that skill calculations would be affected to this.
But Mark hinted that their efforts to reduce desync relies in adjusting the skills itself anyway. It is still questionable if it pays off seeing the amount of resources/time needed to get progress concerning desync until this point.
After Rhys expressing interest on some article and doubting the capability to actually execute the simulations as needed for this suggestion he basically went lurk again. This is as much as the leniency suggestion got dismissed. It is limited by the game engine as the calculations done are too complex to get rewinded with a hash in a fire-sure way.
Last edited by Nightmare90#4217 on Nov 21, 2013, 6:23:36 PM
The other popular one was to avoid floating-point issues altogether using different calculations. However Rhys dismissed this with the reasoning that skill calculations would be affected to this.
I can tell you have no idea how fixed point math works and you are also throwing up a smoke screen to obscure all the valid reasons your ideas have no merit in an existing game. If you think you have any talent why aren't you designing your own game?
The other popular one was to avoid floating-point issues altogether using different calculations. However Rhys dismissed this with the reasoning that skill calculations would be affected to this.
I can tell you have no idea how fixed point math works and you are also throwing up a smoke screen to obscure all the valid reasons your ideas have no merit in an existing game. If you think you have any talent why aren't you designing your own game?
I was barely trying to run down the following past statements
with my own words in the part you quoted:
Spoiler
"
Rhys wrote:
"
qwave wrote:
You don't need this much precision for the combat calculations, that's what im saying. Reduce your precision and you shouldn't have this problem.
If you mean "switch to integer-only math everywhere" then yeah, that's what I said in my first post. But there is lots of combat stuff that relies on angles and sin/cos etc. If you don't mean integer-only math, then no, that suggestion will not work, because even "simple" math can create devilish number pairs like the ones I posted. For example: 7 / 3 results in a number not able to be represented exactly by the IEEE floating point format. If that number is later multiplied by 3, the results is then NOT 7, but 7.0001 or 6.9999. And a similar case can be trivially made for numbers falling either side of the .5 boundary.[...]
I don't know where your unwarranted hostility comes from as I did not claim to fix anything nor that it was my idea in the first place (I think it was HellGauss ones). I even said that I am a layman, what the fuck are you talking about talent!?
Last edited by Nightmare90#4217 on Nov 21, 2013, 6:03:37 PM
The other popular one was to avoid floating-point issues altogether using different calculations. However Rhys dismissed this with the reasoning that skill calculations would be affected to this.
I can tell you have no idea how fixed point math works and you are also throwing up a smoke screen to obscure all the valid reasons your ideas have no merit in an existing game. If you think you have any talent why aren't you designing your own game?
I was barely trying to run down the following past statements
with my own words in the part you quoted:
Spoiler
"
Rhys wrote:
"
qwave wrote:
You don't need this much precision for the combat calculations, that's what im saying. Reduce your precision and you shouldn't have this problem.
If you mean "switch to integer-only math everywhere" then yeah, that's what I said in my first post. But there is lots of combat stuff that relies on angles and sin/cos etc. If you don't mean integer-only math, then no, that suggestion will not work, because even "simple" math can create devilish number pairs like the ones I posted. For example: 7 / 3 results in a number not able to be represented exactly by the IEEE floating point format. If that number is later multiplied by 3, the results is then NOT 7, but 7.0001 or 6.9999. And a similar case can be trivially made for numbers falling either side of the .5 boundary.[...]
I don't know where your unwarranted hostility comes from as I did not claim to fix anything nor that it was my idea in the first place (I think it was HellGauss ones). I even said that I am a layman, what the fuck are you talking about talent!?
My bad, apparently I understand fixed point better then quoting.
My bad, apparently I understand fixed point better then quoting.
It is okay, brah. People tend to jump each others throat in here quite heavily.
I should state in the first sentence that I have no idea
what I am talking about instead in the last one.
Would probably save some people a rage or two.
