| Pages: 1 2 [3] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 3 post(s) |
Ein Spiegel
   |
Posted - 2008.09.22 17:22:00 -
[61]
Desync doesn't always mean YOU lose a ship either. Sometimes it means you can kill someone horribly without them ever knowing you were there. I lost a rapier to behavior which I suspect may be linked to a desync... it's only suspicion, of course, because the player that killed me didn't see anything wrong and of course the logs show nothing.
(Scenario: I'm in a fight that is 2v2, becomes 2v3 but the third ship never appears in space or on overview. In fact, the third ship is only shown in the combatlog. The error message when trying to warp out when not scrambled only says "External factors are preventing...")
/FIX DESYNC PREASE
|
Reptar Dragon
THE FINAL STAND
|
Posted - 2008.09.22 21:48:00 -
[62]
/SIGNED
I've been desync'd and lagged to oblivion with only 6 people in a system, it's not an obvious server capacity problem. CCP, please force us to petition for things that really don't show up in logs, and not for things that do, but apparently don't anyways.
|
Beltantis Torrence
|
Posted - 2008.09.22 22:23:00 -
[63]
Honestly I won't take CCP's "we're very serious about performance" stance seriously until lag and desync's at the very least show up on the known issues list. I won't bother helping out with bug testing/etc free of cost when I know that serious bugs don't even get tracked unless the fall into the "easy to fix and not terribly nasty sounding" category.
|
Strill
|
Posted - 2008.09.23 00:07:00 -
[64]
 Originally by: Praesus Lecti
This poses an interesting situation that to me, isn't logical. Say that you are desynced and you know it. You are sitting at a static location, not moving. If you zoom out on your camera and launch some drones, the drones will appear in space at the coordinates the server says you are at. If you then return the drones to your dronebay, they will proceed to fly to the location the client says you are at. Deploy them again and they appear back at the other location. Why are the deploy and return locations allowed to be different? How can the server, which knows full well where you are truly located, tell the drones to proceed to a totally different location in order to return to your drone bay?
This is my understanding of how it works.
>Client's ship location is desynced.
>Client tells server "I'm deploying drones"
>Server tells client that drones are deployed at location X.
>Drones appear at location X for the client, which is far away from the ship.
>Client tells server "I'm telling my drones to return to the drone bay"
>Server tells client: "the drones are moving towards your ship"
The client and server then move their drones towards the player's ship. Since the client's ship location is desynced, it sees them moving for quite a while. The server, however, doesn't see the drones move at all because they're already at the player's ship.
>The drones reach the player's ship from the client's perspective
>Client tells server: "ok scoop all my drones to the drone bay"
Even though the server sees the drones at a completely different location than the client, it scoops them anyway because they're close enough.
>Server tells client "Drones have been scooped"
Basically the problem is that the server doesn't scoop the drones until the client tells it to, regardless of what the server sees. This also causes all sorts of other problems.
For example, let's say the server sees the drones as being within scoop range, but the client doesn't. If the user tries to scoop their drones, that command will be stopped at the client since the client doesn't think the drones are in scoop range, even though the command would have succeeded if it had been sent to the server.
|
Fenix Zealot
Caldari
Aeon Of Strife
|
Posted - 2008.09.23 17:41:00 -
[65]
I recall once a month or 2 back when i was on the test server flying a wyvern around that someone had loaned me, i had become desynced and restarted my client to correct this. AFter logging back in i noticed a CCP player in local and i convoed that individual (i have since forgotten the name). I asked that CCP individual if they knew why ships get desynced so often. The response i got was one of confusion. "what do you mean desynced?" was the answer i got. When i proceeded to say that its when the server and client see the same ship in different locations the response i got essentially went along the lines of "that doesn't happen"
It does seem as if everyone has seen fit to stick their heads into the sand as certain animals do when they are afraid of a threat. (devs and players and GMs are all at fault for ignoring this problem to some extent) It is about time that a form of outcry has finally come up here on the forums about it again. The general community has spoken, it is time for a kind of official response from the devs/gms to come to light about this problem. Even if the devs/gms decide not to fix this problem, acknowledgement of it would be more than appreciated.
The next time i talk to a BH or ISD BH or CCP on the test server, or anywhere, rather than meet confusion and ignorance about this obvious problem, at the very leased i would expect some tips, or guidelines, or reccomendations about how to avoid it, or fix it quickly, even if there is no easy solution for the whole problem.
Anyone who has spent 5 minutes in the capital FFA on singularity, or anyone who has ever flown a capital anywhere for more than 5 minutes will notice this desync problem regularly. I have never personally witnessed it in a sub capital myself, but i know of plenty of people who have had it get them killed while flying sub capitals... some more than once.
It is also good to note that in addition to bumping of any kind, lag, and problems while warping, desyncs also happen between any ships that engage in refitting while in space via use of a carrier/mothership or ship maintenance bay at a POS. When i engage in combat using my carrier, i carry minor refitting equipment with me for not only myself, but some of my fleet mates as well. depending on circumstances, this has the potential to allow extreemly violent strategy changes during combat that without question can and will change the outcome in my/our favor. This advantage in preparation and tactical thinking is made less meaningful if everyone that participates gets desynced by sometimes as much as 10+km... Tactical thinking and versitile and adaptive strategies should never get a fleet killed by a fault or glitch in the game engine.
To allow such a fault/glitch to eliminate the advantage of using ones critical thinking skills in favor of cookie-cutter gank n tank type mindlessness is a direct insult and a stab in the back to the utter brilliance that represents all the hard work and dedication that has gone into making this game the greatest MMO out there.
/signed a trillion times over.
please we beg you to consider this problem and find a way to fix it.
En Taro Adun! |
Reptzo
Channel 4 News Team
|
Posted - 2008.09.23 21:27:00 -
[66]
where did the other 2 pages go in this thread???? or are there 2 threads with the same name??
|
|
CCP Casqade
|
Posted - 2008.09.23 22:32:00 -
[67]
Hi.
I just cleaned out the nonconstructive and forum rule breaking "/signed" posts adding nothing but noise to this otherwise somewhat constructive thread. I was hoping that I would have time to write a proper response to the questions raised in this thread, but I didn't have time for it.
Please keep this thread clean of personal attacks and speculation presented as facts. I'm hoping to find time to supply you with some answers for the questions in the near future.
|
|
Tiger Kior
Minmatar
Pator Tech School
|
Posted - 2008.09.24 22:24:00 -
[68]
Originally by: CCP Casqade
Hi.
I just cleaned out the nonconstructive and forum rule breaking "/signed" posts adding nothing but noise to this otherwise somewhat constructive thread. I was hoping that I would have time to write a proper response to the questions raised in this thread, but I didn't have time for it.
Please keep this thread clean of personal attacks and speculation presented as facts. I'm hoping to find time to supply you with some answers for the questions in the near future.
However condescending you just came off as, we do all look forward to hearing from you.
|
|
CCP Casqade
|
Posted - 2008.09.24 23:13:00 -
[69]
Coming through as condescending was not my intention. I am sorry if I did.
|
|
Seth Ruin
Minmatar
Ominous Corp
Ethereal Dawn
|
Posted - 2008.09.24 23:26:00 -
[70]
On a somewhat related note, this could also be an avenue to explore for kicking idle players. The server should not be sending data to clients who are, for all intents and purposes, "dead."
This is, of course, assuming the amount of data sent to an idle client (or multiple idle clients, such as in Jita) is substantial enough to cause unnecessary load on the server.
|
|
|
Reptzo
Channel 4 News Team
|
Posted - 2008.09.24 23:36:00 -
[71]
Originally by: CCP Casqade
Coming through as condescending was not my intention. I am sorry if I did.
I did not feel you were being condescending. I thought it was cool that you were cleaning up the thread and that you planned on responding.
|
Tiger Kior
Minmatar
Pator Tech School
|
Posted - 2008.09.25 06:06:00 -
[72]
Edited by: Tiger Kior on 25/09/2008 06:07:02
Originally by: Seth Ruin
On a somewhat related note, this could also be an avenue to explore for kicking idle players. The server should not be sending data to clients who are, for all intents and purposes, "dead."
This is, of course, assuming the amount of data sent to an idle client (or multiple idle clients, such as in Jita) is substantial enough to cause unnecessary load on the server.
Perhaps if a client meets certain criteria for an idle kick, such as the following logic:
1) node has >X users
2) user has been idle for >X minutes
3) user is one of docked, cloaked, inside a force field
If the above criteria is met then an idle disconnect is imposed on the user. Although this is not directly related in of itself to the desync topic, it is nevertheless by extension of the overall issue of fleet fights a related idea and does have merit for consideration in my opinion.
|
Azuse
Brotherhood of Suicidal Priests
Pure.
|
Posted - 2008.09.28 10:36:00 -
[73]
I'd like to add something witty, or intuitive, but the reality is i cannot add anything other than the client not forcibly updating with the server is just sloppy, either that or it is but the packets are getting lost en rout which i doubt.
The new networking layer has made my eve smoother it's true (and welcome) but the other week we lost a dread who logged in at a ss then warped to a pos, at least he activated warp but on his screen never moved, and preceded to be ganked by a fleet which he saw on his overview 9au away. People in the pos saw him on their overviews 9au away therefore no one could do anything and of course, he petition like so many others comes back as log showing nothing wrong which, ironically, is probably true. The only constant was the server, therefore the logs, could agree that the dread was indeed at the pod and being shot, unfortunately every client involved agreed that it was 9au away.
Which begs the question if the server is running the game, and the client is drawing its data from the server running the game, why can clients interact with each other when the data they are using is clearly different from the servers?
-------------------------
|
Imhothar Xarodit
Minmatar
Wolverine Solutions
|
Posted - 2008.09.28 16:19:00 -
[74]
What I know about desyncs...
It somehow has a high tendency on affecting capital, meaning large and slow ships.
And as far as I have experienced it now it always happened after a bump. My client didn't get the "bump move" but the server did, meaning on the client side it looked like I hadn/t bumped or the bump was just a really small one, but the server has you on the "bumped away" destination.
So far it happened very often when warping the carrier into a fleet (bumping on warp drop-off in general is a good candidate) and boarding a carrier from inside a ship maint array when too close to the structure. It's a chance based thing really, and yes I did provide bug reports.
Would really be good to get some feedback.
The whole bumping thing in EVE is broken anyway, the physics engine needs a redesign, it is ridiculous that a ship with 100m/s top speed manages to "emergency drive" from an imminent collision at 500m/s and then takes 10 minutes to get back down to normal speed (and hence controllable again).
One big step would be to make the "Approach" command slow down and stop at the collision edge and not ramming the object at full speed. Would make a big difference and bumping more difficult to be exploited.
|
Kazuo Ishiguro
House of Marbles
Zzz
|
Posted - 2008.09.28 17:44:00 -
[75]
Originally by: Imhothar Xarodit
The whole bumping thing in EVE is broken anyway, the physics engine needs a redesign, it is ridiculous that a ship with 100m/s top speed manages to "emergency drive" from an imminent collision at 500m/s and then takes 10 minutes to get back down to normal speed (and hence controllable again).
One big step would be to make the "Approach" command slow down and stop at the collision edge and not ramming the object at full speed. Would make a big difference and bumping more difficult to be exploited.
At the moment we have more or less perfect elastic collision between ships. If the coefficient of restitution was reduced, people wouldn't travel quite so fast after being bumped, which would help reduce the load spike from a 'causality bubble ' calculation point of view. |
Imhothar Xarodit
Minmatar
Wolverine Solutions
|
Posted - 2008.09.29 22:22:00 -
[76]
Edited by: Imhothar Xarodit on 29/09/2008 22:24:03
Originally by: Kazuo Ishiguro
At the moment we have more or less perfect elastic collision between ships. If the coefficient of restitution was reduced, people wouldn't travel quite so fast after being bumped, which would help reduce the load spike from a 'causality bubble ' calculation point of view.
Thanks for not contributing to the topic.
I know physics and know the math behind collisions. And it stil doesn't expolain how a shuttle at 500m\s manages to bump a Raven in the opposite direction if colliding head-to-head. The point is that "collisions" in Eve aren't real collisions but (as has been stated by several devs already) a means of the ship computer to escape the real collisions. Did you ever wonder why the ship turns around after a bump? Because the ship can only fly in the direction it is pointing (aka there is no drift), but that might be more a limitation of the physics engine.
Anyway, the Eve physics are not part of this topic. I mentioned bumping because I only experience desyncs after being bumped in a capital. Reducing the possibilities of bumping also reduces the possibilities of desyncs. Changing the way approach works is a step. I mean, if I want to approach somebody, I don't want to RAM him at max speed but rather stop in front of him. The only other intent is bumping and seems connected to desyncs somehow... |
Kazuo Ishiguro
House of Marbles
Zzz
|
Posted - 2008.09.30 12:20:00 -
[77]
Originally by: Imhothar Xarodit
I know physics and know the math behind collisions. And it stil doesn't explain how a shuttle at 500m\s manages to bump a Raven in the opposite direction if colliding head-to-head.
This is still possible in cases where the raven is moving slowly, but certainly not at full speed.
Quote:
Did you ever wonder why the ship turns around after a bump? Because the ship can only fly in the direction it is pointing (aka there is no drift), but that might be more a limitation of the physics engine.
I think ship orientation is a purely client-side graphical feature, possibly tied to align time but not having any effect on anything.
Quote:
Reducing the possibilities of bumping also reduces the possibilities of desyncs. Changing the way approach works is a step. I mean, if I want to approach somebody, I don't want to RAM him at max speed but rather stop in front of him. The only other intent is bumping and seems connected to desyncs somehow...
I doubt whether that would actually save much work - you're just replacing the bump calculations with the task of calculating the required speed changes. This is not trivial, especially when the target is constantly moving and changing direction. It might even be worse than the current situation.
Besides, we already have the 'keep at range' option, which usually avoids collisions, at least with one target at a time, not to mention the option of manually slowing down or warping within 0km.
---
DIY copying in Liekuri
20:1 mineral compression
Eve Online folding@home team |
|
|
| |
|
| Pages: 1 2 [3] :: one page |
| First page | Previous page | Next page | Last page |