|
Author |
Thread Statistics | Show CCP posts - 8 post(s) |
|
CCP GingerDude
|
Posted - 2010.11.15 13:52:00 -
[1]
Originally by: Taedrin
Originally by: TriadSte Edited by: TriadSte on 15/11/2010 11:02:19 Happens to me in every single C3 sleeper site. Also when i release my drones they will happen to be anything from 1000 meters upto 90 KILOMETERS behind me.
Ive filed 1 petition and 2 bug reports about these issues but alas low and behold, CCP have not got back to me at all on both counts.
As normal they're understandably super busy putting even more content onto something which currently is not running properly.
Ya know, the normal CCP way
Giggety giggety, giggety goo!
18 months, amirite?
Just because CCP doesn't answer your calls doesn't mean that they didn't get the message. Also, just because you are affected by the bug doesn't mean that CCP is going to ignore them.
The last time we had desynch, CCP spent a LOONG LOOONNG time trying to figure out how to fix it.
We're on the motha.... ;)
|
|
|
CCP Atropos
|
Posted - 2010.11.15 23:08:00 -
[2]
Originally by: TriadSte I would have thought desync to be a "minor" problem for a good programmer/expert. Considering how difficult it is to create patchs, additional content etc.
I hope you're basing your presumption on the difficulty of the task on actual knowledge of the inner workings of the system and not on a gut feeling and assumptions. Otherwise that would be bad
Software Engineer Core Engineering |
|
|
CCP GingerDude
|
Posted - 2010.11.16 13:40:00 -
[3]
Originally by: Urgg Boolean Ya know that odd phenomenon when invoking a tractor beam? At first, the numbers in dicate the target is many times farther away than it is supposed to be. Then it clears and behaves normally. Is this related to the desync problem ?
No, the tractor beam snapping is unrelated but since you mention it, it got fixed last week in the dev branch. Also rubberbanding when dropping out of warp is also mostly fixed. I'm debugging the desync issue right now. Expect a client patch soon...
|
|
|
CCP GingerDude
|
Posted - 2010.11.16 20:42:00 -
[4]
Originally by: ceaon
Originally by: CCP GingerDude
No, the tractor beam snapping is unrelated but since you mention it, it got fixed last week in the dev branch. Also rubberbanding when dropping out of warp is also mostly fixed. I'm debugging the desync issue right now. Expect a client patch soon...
btw the problem whit ejecting 50 titans from the cargo hold is fixed ? i really want to do that on TQ for Christmas
Ah, nice reference there ;)
But desync problem found and fixed locally. It has to do with different number of bits between client and server when you orbit something...involves trigonometry and stuff. Deployment of fix (requires client patch) will be sometime within the next two weeks.
|
|
|
CCP Habakuk
|
Posted - 2010.11.17 11:59:00 -
[5]
Originally by: ceaon btw the problem whit ejecting 50 titans from the cargo hold is fixed ? i really want to do that on TQ for Christmas
This was actually my first test, when trying to reproduce this desync problem - but the titans behaved very well. It got more interesting when checking NPCs, which were orbiting other objects (and colliding with something while orbiting)... |
|
|
CCP Explorer
|
Posted - 2010.11.18 08:35:00 -
[6]
Originally by: Pan Crastus
Originally by: Siiee How would a precision error cause the server and client simulations to diverge?
Actually if you want to watch precision errors in action just "look at" another ship while warping away (I don't remember exactly how to make the look stick, you might have to use the advanced camera) The points jittering around and model breaking up just before the camera snaps back to your own ship is a classic example of FP precision.
I guess that's "kinda" confirmed now. The server probably uses full precision while the client gets a reduced number of bits over the network and ends up with a wrong/different result when performing the same calculation, or something like that. At least that's how I interpret the CCP answer. Might be even worse than a floating point issue if they use fixed point in network traffic.
The issue is slightly different. Both the client and the server are using full precision but obviously the client is using 32 bit math libraries and the server is using 64 bit math libraries (we are using the built-in math libraries in Windows).
It turned out that when operating on 32 bit numbers then the results were almost the same (more on that later) but when operating on 64 bit numbers then some calculations (in particular sin() and cos()) would diverge noticeably quickly. After 64 Bit Inventory then item identifiers can be true 64 bit numbers, in particular the item ID's for NPC's are up in that range.
So, a new problem you may ask? No, this has in fact been a problem since we moved the EVE Server to 64 bit in Quantum Rise. That's when the server starting using different 64 bit math libraries from the 32 bit math libraries that the client uses. The difference, however, was small enough when operating on small numbers (that is while the item identifiers were still 32 bit) that it was not really noticeable. We actually came up with a reproduction case this week for the 32 bit scenario but it requires more than 30 minutes of orbiting while constantly getting bumped.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
CCP Explorer
|
Posted - 2010.11.19 23:05:00 -
[7]
Originally by: Mag's So any chance we get a 64bit client option soon, so we can choose to completely avoid these issues?
A lot of the the middleware we use in the client is only available in a 32 bit version.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
CCP Explorer
|
Posted - 2010.11.19 23:08:00 -
[8]
Originally by: Pesadel0 Is the Fix going to be implemented in the new patch?
Yes, in the next full client patch on 30 Nov.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
|
|