Pages: 1 2 3 :: [one page] |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.25 03:07:00 -
[1]
Just an idea to throw out here. First of all, its got to clear two phases (Is it posssible? If so, is it a viable idea?)
Currently lag and system loading are a problem, this is going to become doubly so after the Deep Safe nerf prevents loading the system from a safe point.
The proposal is to have ships, when they are jumping through a system (And possibly cyno bridging) to be first removed from the system they are in (as it currently is) but instead of appearing in the next system and waiting for the client to load (Aka sitting duck) to have the ship removed to another place, a holding point that one is not able to travel to, so that the client can load the server before it appears in the next system (Would not even appear in local until it is finished loading).
So basically, in a system where there is heavy traffic, a ship would jump, be deposited in another limbo system, then when it has finished loading the system it is going to is transported to that system.
|
Twilight Runner
|
Posted - 2010.04.26 02:15:00 -
[2]
Edited by: Twilight Runner on 26/04/2010 02:16:37 That would be too easy, this is ccp after all :)
perhaps there should be a fleet jump, and noone decloaks until all have loaded in the fleet.
|
Misanthra
|
Posted - 2010.04.26 02:51:00 -
[3]
Way you drop in does needs some fixing. Coding to have grid pulled for sure before spawn would be nice.
I'd just wish they'd fix coding for corpse generation at the bare minimum. Kind of sucks when you see your corpse floating next to you...at least give me the false hope spamming warp does something lol. See your corpse and its like...damn, guess I am stuck here till server catches up :( .
|
Torothanax
|
Posted - 2010.04.26 06:26:00 -
[4]
I LOVE massive fleet lag. But don't we all? One of the reasons I ditched null. Being a mindless drone of some super power was another, but off topic.
If the idea worked, great! I can't see anyone having issues with a better grid loading experiance.
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.26 19:05:00 -
[5]
Originally by: Twilight Runner Edited by: Twilight Runner on 26/04/2010 02:16:37 That would be too easy, this is ccp after all :)
I'm thinking the only reason CCP doesn't want to do it is because it would NOT be easy...or...they just don't really think about alternatives too much.
I imagine it would take a lot of code writing to script players into a Jump Limbo and then the system they are heading.
|
Misanthra
|
Posted - 2010.04.26 22:55:00 -
[6]
CCP won't do it cause it likes certain sides in the big war going and wants them to have turkety shoots on the gates lol. Depends who lost the battle and which chestbeaters/whiners post in caod who ccp likes
|
cBOLTSON
Caldari Shadow Legion. Talos Coalition
|
Posted - 2010.04.26 23:43:00 -
[7]
Originally by: Torothanax I LOVE massive fleet lag. But don't we all? One of the reasons I ditched null. Being a mindless drone of some super power was another, but off topic.
If the idea worked, great! I can't see anyone having issues with a better grid loading experiance.
LOL
Also, if you were being a midless drone then you have only yourself to blame.
|
Torothanax
|
Posted - 2010.04.27 03:59:00 -
[8]
Off topic much? If you like null, have at it. Wanna be a "dig-it" for some super power? All you. I may get bored of quick, cheap, easy pvp at some point and give it another shot, but for now I don't want anything to do with null other then the occasional romp through it.
It amuses me that find your play style superior to everyone else's in a sandbox game. Arrogant much?
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.28 08:40:00 -
[9]
How is the limbo system going to be better than the target system?
The game lags because it has to move ships around. An additional move into a limbo system will double the lag. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.28 17:22:00 -
[10]
Originally by: Whitehound How is the limbo system going to be better than the target system?
It's not suppose to be. It's just simply a placeholder.
Quote: The game lags because it has to move ships around. An additional move into a limbo system will double the lag.
For who? Even if the lag is doubled it would have no effect, the client would load the limbo system, which albiet would not take much considering it would be empty. Then load the target system, once it is done be transfered.
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.28 22:06:00 -
[11]
Edited by: Whitehound on 28/04/2010 22:07:53
Originally by: Jerid Verges For who? Even if the lag is doubled it would have no effect, the client would load the limbo system, which albiet would not take much considering it would be empty. Then load the target system, once it is done be transfered.
For whom? For all. For those in the source and for those in the destination system. Think about this: what happens if a client disconnects while its ship is being moved? And what happens to the rest of the fleet, what to do with to the disconnected client? Think it through and you will see that it creates more overhead than it currently needs. It is best to move each ship on its own from one system to another. Any logic to gather a group of ships will need to add more delay than necessary, causes either the fleet to lag or causes lags for other players in these systems, and it just would not be fair for all any more. Therefore is a ship moved when the player presses the button.
The problem is not the clients nor the servers but the Internet. Therefore is any additional move you make a potential source for another lag. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.28 23:18:00 -
[12]
Originally by: Whitehound Edited by: Whitehound on 28/04/2010 22:07:53
Originally by: Jerid Verges For who? Even if the lag is doubled it would have no effect, the client would load the limbo system, which albiet would not take much considering it would be empty. Then load the target system, once it is done be transfered.
For whom? For all. For those in the source and for those in the destination system.
Wrong. When a person goes from system A to B system C is not affected, likewise from C to B system A is not affected. So when transitioning, there is no extra load on anyone in the system except the effect already being experienced currently, since there is no difference between jumping from system A into system B, or jumping from system C (the limbo system) to system B. The only difference anywhere is the client going from system A to B will now go from A to C to B.
In otherwords, if I am in system A going to system B, under the current system I would go directly to B. On a modified network. I would go to C first, which would be empty so nothing to load there. I would then I would load system B. Then I would go to B. It's no different on B if I come from A or C.
It doesn't change any mechanics. Except that the player remains in C whilst B is being loaded before being set into B.
Of course, this is not even the real proposal. It is just a proposed mechanic to create the solution of the proposal (Which is that players jumping from system A to B are not in system B with nobody at the controls) CCP might come up with something better. I think it is a good idea even if it does require more resources.
Quote: Think about this: what happens if a client disconnects while its ship is being moved? And what happens to the rest of the fleet, what to do with to the disconnected client?
The client could do two things. Either 1) Go back to system A and perform an emergency warp. or 2) Go to system B and perform an emergency warp.
It would really be no different then if you disconnected during a jump right now.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.28 23:43:00 -
[13]
Originally by: Jerid Verges Wrong.
No. The time it takes to move something from A to B takes less than to move it from A to AB, then to B. One move is less than two moves. You imagine that by going to an intermediate system that you would gain something, but you do not.
If you still think that you are right then explain how you save time by adding a second move. Where does the time saving come from?
There is no time saving. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.28 23:55:00 -
[14]
Originally by: Whitehound
Originally by: Jerid Verges Wrong.
No. The time it takes to move something from A to B takes less than to move it from A to AB, then to B. One move is less than two moves. You imagine that by going to an intermediate system that you would gain something, but you do not.
If you still think that you are right then explain how you save time by adding a second move. Where does the time saving come from?
There is no time saving.
What are you talking about? This proposal has nothing to do with "Time Saving" this proposal has everything to do with reducing clientside lag when entering B system from A system. Or in the case of the proposal, from C system.
A revised system of "Two moves" taking "More time" with "Less lag" is a much, much more preferred system then a current system of "One move" "Quicker travel" "Frozen client sitting duck at gate"
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 00:25:00 -
[15]
Edited by: Whitehound on 29/04/2010 00:27:17
Originally by: Jerid Verges What are you talking about?
You do not understand where the lag is coming from but want to see it fixed on the server. The lag is neither coming from the client nor is it coming from the server. It is the latency between client and server. There is no fix for it. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 00:33:00 -
[16]
Edited by: Jerid Verges on 29/04/2010 00:34:42
Originally by: Whitehound Edited by: Whitehound on 29/04/2010 00:27:17
Originally by: Jerid Verges What are you talking about?
You do not understand where the lag is coming from but want to see it fixed on the server. The lag is neither coming from the client nor is it coming from the server. It is the latency between client and server. There is no fix for it.
And you do not understand what the proposal is. The point is to make the ship invulnerable to being destroyed whilst the client loads the server.
There is less lag for people in system because they have the benefit of having it preloaded. Whilst people jumping into a system have a great deal more to load. This causes the client to freeze or lag even though the ship appears perfectly fine from server side and is perfectly fine from perspective of the other players..
And a perfectly fine ship sitting perfectly still because the player can't control it is a perfectly great target.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 01:15:00 -
[17]
Originally by: Jerid Verges And you do not understand what the proposal is. The point is to make the ship invulnerable to being destroyed whilst the client loads the server.
There is less lag for people in system because they have the benefit of having it preloaded. Whilst people jumping into a system have a great deal more to load. This causes the client to freeze or lag even though the ship appears perfectly fine from server side and is perfectly fine from perspective of the other players..
And a perfectly fine ship sitting perfectly still because the player can't control it is a perfectly great target.
I do understand your proposal, but there is no such thing as a perfectly working system. You can imagine it as much as you like but each client responds in its own time and there is nothing the server can do to change this. You can make an entire fleet wait for 5 minutes and you will still see ships arriving at different times. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 01:57:00 -
[18]
Originally by: Whitehound
Originally by: Jerid Verges And you do not understand what the proposal is. The point is to make the ship invulnerable to being destroyed whilst the client loads the server.
There is less lag for people in system because they have the benefit of having it preloaded. Whilst people jumping into a system have a great deal more to load. This causes the client to freeze or lag even though the ship appears perfectly fine from server side and is perfectly fine from perspective of the other players..
And a perfectly fine ship sitting perfectly still because the player can't control it is a perfectly great target.
I do understand your proposal, but there is no such thing as a perfectly working system. You can imagine it as much as you like but each client responds in its own time and there is nothing the server can do to change this. You can make an entire fleet wait for 5 minutes and you will still see ships arriving at different times.
And what's worse about ships of a fleet arriving at different times? Better then an entire fleet arriving with nobody at the controls. At least this way players stand a chance.
First you said this proposal would just lag the client more. Then you said the proposal would lag the system server more. Then you said this proposal was all about making server loading faster.
So it appears to me you don't understand.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 02:00:00 -
[19]
Originally by: Jerid Verges And what's worse about ships of a fleet arriving at different times? Better then an entire fleet arriving with nobody at the controls. At least this way players stand a chance.
First you said this proposal would just lag the client more. Then you said the proposal would lag the system server more. Then you said this proposal was all about making server loading faster.
So it appears to me you don't understand.
That is not what I said. Read again, please. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 02:16:00 -
[20]
Yes you did.
Quote: The game lags
There is you saying the player will lag.
Quote: causes lags for other players in these systems
There is you saying the server will lag. (Since only performance issues serverside will affect multiple players when other people join in)
Quote: Where does the time saving come from?
There is you assuming this proposal has something to do with saving load time.
Not to mention. You keep avoiding my rebuffs when I point out you're wrong (About the game, about the server, about the 'time')
What the heck are you trying to drive at?
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 03:17:00 -
[21]
Edited by: Whitehound on 29/04/2010 03:23:24
Originally by: Jerid Verges What the heck are you trying to drive at?
That your proposal will not work. By moving an entire fleet into a temporary system do you increase the number of problems rather than to reduce them.
Let's assume you are right and one can move an entire fleet perfectly from one system to another. Then the slowest client will define when the entire fleetarrives, or, the slow clients will have to get kicked out of the fleet in order for a majority to arrive in time.
This means that you have two problems to deal with when the size of a fleet increases. Either the fleet jump takes longer and longer as the probability for a slow client increases with the number of clients, or, the size of a fleet reaches a limit because more and more clients need to get kicked out to guarantee a time limit.
There is a simple solution to this problem: one handles each client separately (players jump when they want to) instead of trying to jump an entire fleet.
This is one example of how your proposal will introduce problems. It does not say how to make all ships appear at the same time in one system nor how to make it appear for every player at the same time. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 03:32:00 -
[22]
Originally by: Whitehound the slow clients will have to get kicked out of the fleet in order for a majority to arrive in time.
We both know that that would never be implimented. Don't talk nonsense.
Quote: This means that you have two problems to deal with when the size of a fleet increases. Either the fleet jump takes longer and longer as the probability for a slow client increases with the number of clients
Go post a thread in General Discussion right now and take a poll. Or better yet, go to COAD since they are all people who live in Nullsec.
You ask them if they would prefer having to endure a longer server loading time during jumps/bridges but get immunity during that loading time. What do you think they would prefer.
Quote: There is a simple solution to this problem: one handles each client separately instead of trying to jump an entire fleet.
Well technically, under the current mechanics the system already handles each ship jumping on an individual basis (Although, when each player can start interfacing with their client lag free would be different for each)
Except. I'm not even sure what you're saying here.
Quote: This is one example of how your proposal will introduce problems. It does not say how to make all ships appear at the same time in one system nor how to make it appear for every player at the same time.
Because I never said that this proposal was about synchronizing the jump of a fleet between system A and B?
There you go again. Creating another fictatious problem that my proposal would present (When it doesn't) I can probably imagine that unless there were a program that determined if all the ships in the fleet were preloaded before sending them to system B that they would just enter the system once they finish loading regardless of the fleet. (Though, unless there are signifigant differences in machine performance or internet connection, a synchronized jump should have everyone through a system on a somewhat similar timeframe)
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 04:02:00 -
[23]
Originally by: Jerid Verges (Though, unless there are signifigant differences in machine performance or internet connection, a synchronized jump should have everyone through a system on a somewhat similar timeframe)
And there is the problem of the fairness for others. A fleet jump will require to perform many database transactions at once. This will likely cause a short freeze / pause for everyone, even when they are not part of the fleet and just happen to be in one of the systems, making fleet jumps an annoying game experience. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 04:16:00 -
[24]
Originally by: Whitehound
Originally by: Jerid Verges (Though, unless there are signifigant differences in machine performance or internet connection, a synchronized jump should have everyone through a system on a somewhat similar timeframe)
And there is the problem of the fairness for others. A fleet jump will require to perform many database transactions at once. This will likely cause a short freeze / pause for everyone, even when they are not part of the fleet and just happen to be in one of the systems, making fleet jumps an annoying game experience.
Which, of course. You are again wrong about. What happens between database transactions between system A and system C will not affect system B. Never. It doesn't happen in the current game AT ALL.
Whatever system B experiences will be the same no matter how an enemy fleet jumps in. Except that, the invading force will now have the grid preloaded before they are in B system.
If anything, this has the ability to IMPROVE server performance in B system by having the force that is jumping into the system preload the grid, that LESSENS the strain on resources of the server at that particular moment.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 09:21:00 -
[25]
Edited by: Whitehound on 29/04/2010 10:33:17
Originally by: Jerid Verges Which, of course. You are again wrong about. What happens between database transactions between system A and system C will not affect system B. Never. It doesn't happen in the current game AT ALL.
Just keep wishing that I am wrong . I want you to understand the problems that your proposal will create. If you continue to take my comments as flames then no one will care about your proposal anyway. You cannot take criticism!
On the topic, the problem with the fairness is that the server processes each request on a first come, first serve-basis and for each player/client, without giving anyone precedence. By creating a fleet jump operation will you indirectly give a fleet of players precedence over a single, non-fleeted player. In systems where you have a lot of fleets travelling through will the game experience for the single player begin to suck, because a fleet of players is processed as if it was a request made by a single player.
Originally by: Jerid Verges If anything, this has the ability to IMPROVE server performance in B system by having the force that is jumping into the system preload the grid, that LESSENS the strain on resources of the server at that particular moment. Rolling Eyes
It has the ability to improve the performance? I wish you had the balls to write that it DOES improve the performance. ... Fact is that you do not know. Unless CCP are noobs will their code already work very efficiently and all you do is to add something extra, and thereby reduce the performance. It will not improve the performance.
I am starting to think that your computer is just very slow and that your Internet connection sucks. Perhaps a faulty wireless connection. And now you want everyone else to wait for your ship to arrive and at the same time as others, by making everyone else wait for you. Admit it! --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 16:14:00 -
[26]
Originally by: Whitehound You cannot take criticism!
You are not making very good criticism. You keep switching your arguements around because I keep defeating them.
Quote: because a fleet of players is processed as if it was a request made by a single player.
Where does it say ANYWHERE that Eve servers process fleet ops as request made by a single player?
Quote: It has the ability to improve the performance? I wish you had the balls to write that it DOES improve the performance. ... Fact is that you do not know. Unless CCP are noobs will their code already work very efficiently and all you do is to add something extra, and thereby reduce the performance. It will not improve the performance.
I do not think you understand server load very well. If players have the grid preloaded before they are on it then that means the strain on the server when they are actually jumped through is LESS because less of the server's resources are devoted to grid loading for these clients (Since they are already loaded).
By spreading out the stress on the server when a single massive fleet jumps through instead of suddenly piling on a *****load of stress when the fleet clicks the "Jump" button you can reduce the lag everybody is recieving.
At least, in theory that is. Your theory of "Adding more programming makes the server slower" is a lot of hot air.
Quote: their code already work very efficiently and all you do is to add something extra
Well they do seem to be noobs since lag was not so bad a problem before Dominion (Oops?)
Quote: I am starting to think that your computer is just very slow and that your Internet connection sucks.
Haha! My connection is actually better then most! You know how I can tell? Because my ping on FPS servers is less then 100. It can go from 60-100 depending on the performance of my machine, the server, and my connection. The point is is that it is on average lower then other players.
You see, other players with poor ping affect MY performance on the server by causing an additionally strong load on the server due to their poor connection. If the load is too much the server begins to lag everybody regardless of connectivity.
Quote: And now you want everyone else to wait for your ship to arrive and at the same time as others, by making everyone else wait for you. Admit it!
You are frankly starting to grasp at straws. I have never encountered lag at all in Eve. I have on occasion been disconnected.
Your little theory that "I want everybody to wait for me" is frankly...childish. It is no secret that when people jump on grid into laging systems like Jita that their client can be frozen until the grid loads.
Everybody "Arrives" at the same time regardless. Different people get their client's unstuck at different times (Hint, the people camping the gate have their clients unstuck faster).
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 17:31:00 -
[27]
Originally by: Jerid Verges Your little theory that "I want everybody to wait for me" is frankly...childish.
It is accurate and you got caught. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.29 22:34:00 -
[28]
Originally by: Whitehound Edited by: Whitehound on 29/04/2010 17:44:57
Originally by: Jerid Verges Where does it say ANYWHERE that Eve servers process fleet ops as request made by a single player?
How does your fleet jump work then? Is it not initiated by the commander?
I don't know WHERE you found "Fleet Jump" but I assure you it does not exist. To be fair, I cannot speak of Cyno Bridging. But I have FCed before and there is no "Jump Fleet through X Stargate" option. Every individual member of a fleet must MUST press "Jump" on their own accord.
Quote:
Quote: ... is LESS because less of the server's resources are devoted to grid loading for these clients (Since they are already loaded).
And it will suck for others who are not members of the fleet. That was my point.
Quote: By spreading out the stress on the server when a single massive fleet jumps through instead of suddenly piling on a *****load of stress when the fleet clicks the "Jump" button you can reduce the lag everybody is recieving.
And that is how it is now when everyone jumps all by themselves.
Now you are just backpeddling away from "Fleets" and going to "Individual Members" when in fact there is no difference. Even if an individual jumps through a stargate or a large amount of individuals do, the server still has to load the client with all the stuff in the next system. This creates a huge lag spike for the client trying to load the server, (Which also ripples and effects ships on the server as more server resources are diverted to accomodate the new ships).
Preloading the grid allows this "spike" to be softened.
Originally by: Jerid Verges Your little theory that "I want everybody to wait for me" is frankly...childish.
It is accurate and you got caught.
It is not accurate at all, as I have said, I do not get lag on Eve.
And lol. You are still not even trying to address the REAL proposal here. Which is basically "Invulnerability while loading grid" Jump limbo is just one means to an end.
|
Captain Futur3
|
Posted - 2010.04.30 00:49:00 -
[29]
Just to make it clear that i got the point of this discussion:
OP wants to fix the problem, that when you jump a fleet(or group) in a new system, that when the group is big enough, the group lags that much, that they cant do anything while the enemy who is already in the system is able to attack them and kill them before they can give orders. Is that right?
If yes, i do think that the A->C->B solution would work, but only if the jump from system C to system B is not a common jump. More some kind of "loading screen" where the group members are loading the system informations. The server is then transferring the group datas into the system and then when everyone has loaded the stuff, the ships will jump into the system. But lag in general will not be fixed, nor will it run any faster.
(at least thats what i got when i read this thread) But i dont have any fleet fight lag experience, so this is just theory.
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.30 02:25:00 -
[30]
Originally by: Captain Futur3
OP wants to fix the problem, that when you jump a fleet(or group) in a new system, that when the group is big enough, the group lags that much, that they cant do anything while the enemy who is already in the system is able to attack them and kill them before they can give orders. Is that right?
That is the problem yes.
Quote: If yes, i do think that the A->C->B solution would work, but only if the jump from system C to system B is not a common jump. More some kind of "loading screen" where the group members are loading the system informations. The server is then transferring the group datas into the system and then when everyone has loaded the stuff, the ships will jump into the system.
This is exactly the proposal yes. (Well sort of, this is just the means to the end, which is to stop the problem)
Quote: But lag in general will not be fixed, nor will it run any faster.
Of course, this is not a "Fix lag" suggestion.
The only thing I am not 100% sure of is that reducing server load upon arrival (By having clients preload the system/grid) will result in an overall performance increase for everyone. It theoretically should happen considering when clients put load onto the server.
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 06:57:00 -
[31]
Edited by: Whitehound on 30/04/2010 07:49:04
Originally by: Jerid Verges I don't know WHERE you found "Fleet Jump" but I assure you it does not exist. To be fair, I cannot speak of Cyno Bridging. But I have FCed before and there is no "Jump Fleet through X Stargate" option. Every individual member of a fleet must MUST press "Jump" on their own accord.
Then say, do you want to jump an entire fleet or only individual ships with your proposal?
Originally by: Jerid Verges Now you are just backpeddling away from "Fleets" and going to "Individual Members" when in fact there is no difference. Even if an individual jumps through a stargate or a large amount of individuals do, the server still has to load the client with all the stuff in the next system. This creates a huge lag spike for the client trying to load the server, (Which also ripples and effects ships on the server as more server resources are diverted to accomodate the new ships).
I am not peddling anywhere, I am right here. ... There will be a difference if you let everyone jump on their own, or have a fleet jump operation and jump everyone simultaneously.
Originally by: Jerid Verges It is not accurate at all, as I have said, I do not get lag on Eve.
If you do not get lag then why the proposal?
Originally by: Jerid Verges And lol. You are still not even trying to address the REAL proposal here. Which is basically "Invulnerability while loading grid" Jump limbo is just one means to an end.
I already addressed your proposal and said that it will not work. You ignore that the fleet, which is already in the system needs to load all the stuff for the incoming fleet, too. Where do their clients get a chance to preload all the graphics for the ships and weapon effects, the players' standings, corp and alliance names, war state, sec status, bounties, etc.? --
|
Captain Futur3
|
Posted - 2010.04.30 10:03:00 -
[32]
Originally by: Whitehound I already addressed your proposal and said that it will not work. You ignore that the fleet, which is already in the system needs to load all the stuff for the incoming fleet, too. Where do their clients get a chance to preload all the graphics for the ships and weapon effects, the players' standings, corp and alliance names, war state, sec status, bounties, etc.?
The theory behind this (or at least what i think) is: Group A is entering the system where group B is already waiting. Group A is jumping and get some kind of loading screen where the system informations are loaded for BOTH groups, while group A is still in a subsystem until loading is finished. Group B will discover a lag, like they do now, but they wont see group A in the system. Its like there is a big lag but nothing visible changes. Until the point where the server connects the positions of group A with the new system and makes them visible. But at this point, both groups are already in the system. Just think of this idea as some kind of loading screen until all ships are loaded. Only in the very last second, all ships will be connected to the new system, so that they are visible and targetable. Even when the lag for group B will be the same as it is now (as you have already said), they wouldnt see group A in the system.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 10:50:00 -
[33]
Edited by: Whitehound on 30/04/2010 10:51:52
Originally by: Captain Futur3 The theory behind this (or at least what i think) is: Group A is entering the system where group B is already waiting. Group A is jumping and get some kind of loading screen where the system informations are loaded for BOTH groups, while group A is still in a subsystem until loading is finished. Group B will discover a lag, like they do now, but they wont see group A in the system. Its like there is a big lag but nothing visible changes. Until the point where the server connects the positions of group A with the new system and makes them visible. But at this point, both groups are already in the system. Just think of this idea as some kind of loading screen until all ships are loaded. Only in the very last second, all ships will be connected to the new system, so that they are visible and targetable. Even when the lag for group B will be the same as it is now (as you have already said), they wouldnt see group A in the system.
I understand what he wants to do, he just has not worked out his idea yet and does not know the problems it will create. Do you really expect that players on the other side of a gate want to see a loading screen whenever a fleet arrives? Or do you expect players not to complain when the system jumps take longer than before?
His problem is that he sometimes ends up dead on the other side, because of fleet lag. The simple solution is not to jump through, really, and to save the tears. The fleet lag comes from the ever increasing size of fleets, and not because of the game loading part of its data on demand. If the clients start loading all data ahead they might end up loading data that is outdated and not needed (i.e. destroyed ships), thereby adding to the lag. So when he arrives will he be alive but may be targeting an already destroyed ship, gets again killed in a fleet fight, and then complains that he was killed while targeting a non-existing ship. Believe me, he will complain about that, too. He just does not see it coming with his proposal. --
|
Jedziah
Core Impulse
|
Posted - 2010.04.30 12:00:00 -
[34]
In theory, the idea is extremely useful.
At current, the best position to be in when you jump in, in a large fleet is to be the median of the latency in your fleet. Those with excellent connections and low latency will load first, they will likely be primaried and killed before any external measure can prevent it. Those with bad connections will likely not load until the majority of the battle is over and it is likely that their client will spend the majority of the fight playing catch up to re-synchronise with the fight.
If an equilibrium/limbo type holding area was to be implemented, it would need strict rules to govern it. Most notably, it should still batch process based on set time limits. After X seconds, loaded pilots will load into system. Then the limbo system would begin filling up the array with more pilots which have now successfully loaded the system.
Sadly, you can see how this in fact answers both of your arguments. Firstly, yes, you would no longer lose your ship as you would remain in limbo, likely until the fight is long finished with a bad latency. However, the system simply does not remove latency, it merely exacerbates it in an abstract area of Eve.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 12:15:00 -
[35]
Originally by: Jedziah In theory, the idea is extremely useful.
The server already keeps a ship in a void as it cannot exist in both systems simultaneously or jump instantaneously. EVE is then a huge database and all transactions will get processed in batches optimized for best performance. So much for the practice. --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.30 15:30:00 -
[36]
Originally by: Whitehound Edited by: Whitehound on 30/04/2010 07:49:04
Originally by: Jerid Verges I don't know WHERE you found "Fleet Jump" but I assure you it does not exist. To be fair, I cannot speak of Cyno Bridging. But I have FCed before and there is no "Jump Fleet through X Stargate" option. Every individual member of a fleet must MUST press "Jump" on their own accord.
Then say, do you want to jump an entire fleet or only individual ships with your proposal?
My proposal has never said that jumping a fleet through a system would treat the entire fleet as a request from a single player. Stop pulling things out of your ass.
Quote: I already addressed your proposal and said that it will not work. You ignore that the fleet, which is already in the system needs to load all the stuff for the incoming fleet, too. Where do their clients get a chance to preload all the graphics for the ships and weapon effects, the players' standings, corp and alliance names, war state, sec status, bounties, etc.?
They have the grid preloaded because they are already there. Unless I get some statements from someone else that their computer lags when people jump in I think it is pretty obvious who gets the first shot under the current system.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 16:37:00 -
[37]
Edited by: Whitehound on 30/04/2010 16:37:01
Originally by: Jerid Verges My proposal has never said that jumping a fleet through a system would treat the entire fleet as a request from a single player. Stop pulling things out of your ass.
Yes or no? ...
Quote: They have the grid preloaded because they are already there. Unless I get some statements from someone else that their computer lags when people jump in I think it is pretty obvious who gets the first shot under the current system.
Do not jump into the system if you do not like being shot. The fight then does not take place in your home on your computer, but on the server, and CCP is not responsible for Internet lags or slow clients.
Perhaps try to see it from a positive side. Those who try to enter your systems have the same problem. If you then want to move a fleet into a "limbo system" before they can get through a gate then how much longer will it take for reinforcements to arrive when they are like 20 jumps away and get moved on their way to your system 20 times into "limbo systems", because there might be hostile forces at every gate? --
|
Jerid Verges
Gallente The Society of Innovation The Last Stand
|
Posted - 2010.04.30 17:37:00 -
[38]
Originally by: Whitehound
Do not jump into the system if you do not like being shot. The fight then does not take place in your home on your computer, but on the server, and CCP is not responsible for Internet lags or slow clients.
Lol go say that in COAD please, I would love to see you defend that viewpoint in COAD or even GD.
Quote: Perhaps try to see it from a positive side. Those who try to enter your systems have the same problem.
How the hell is "Lag" a good thing? That is basically what you are saying there. It's a pretty unpopular viewpoint to be sure.
Quote: If you then want to move a fleet into a "limbo system" before they can get through a gate
That's not how it works at all. The limbo is a transition not a destination.
Quote: then how much longer will it take for reinforcements to arrive, and when they are like 20 jumps away and get moved on their way to your system 20 times into "limbo systems"?
If there is no lag in those systems then there wouldn't be any waiting time.
Stop trying to make 20 systems seem like 40. That is simply not the case.
In anycase, I'm done arguing this point. Since it is not the proposal at hand, you refuse to even argue the real point, which is to make ships safe from being blown up due to lag when jumping systems.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 19:25:00 -
[39]
Edited by: Whitehound on 30/04/2010 19:31:36
Originally by: Jerid Verges In anycase, I'm done arguing this point. Since it is not the proposal at hand, you refuse to even argue the real point, which is to make ships safe from being blown up due to lag when jumping systems.
Say, where in EVE are you safe from being blown up or from lag?
Oh, I know: inside a station. How about we turn gates into stations with two exists?? You can dock, have a snack, refit your ship and jump/exit right into a gate camp. One will get blown up, but at least one is refreshed. --
|
Douglass Bryant
|
Posted - 2010.04.30 19:31:00 -
[40]
I don't have their code in front of me, and neither do any of us, so we're all talking out our asses.
That being said, however, it appears that grid loading issues are a race condition type problem. The server loads your ship onto the grid before it finishes getting your client the grid. In low traffic nodes, I'm sure these two actions occur simultaneously enough to not be a problem. But in high traffic nodes, I'm assuming it takes less time for the enemy fleet to receive their grid updates and see you on the grid than it does for your client to receive the whole grid.
The solution proposed here also has a race condition, but in the opposite direction. Imagine a large fleet in system, and a large fleet incoming. The incoming fleet will be moved to the temp system until their grid is loaded, whereas the in-system fleet won't be getting grid updates until the incoming fleet has actually left the temp system and entered the final system, thus meaning that while the incoming fleet has all the data it needs, the in-system fleet has to wait for updates. The incoming fleet has the advantage, as they'll be able to see the in-system fleet before the in-system fleet sees them.
The solution to this is not so difficult, but it does require some modifications to the existing system (and sadly a little more overhead). Each player object should have two flags: gridLoaded and gridUpdated. When an incoming fleet jumps, their gridLoaded flag is set to zero until the server has no more outstanding calls to the client AND all objects on the grid have gridUpdated = 1, at which time the server sets gridLoaded to one. On the other side, the in-system fleet gets their gridUpdated flag set to zero until it loads all the incoming ships, at which point that flag now gets set to one. The behavior would work as follows:
gL = 0, gU = 0; You can't see anyone or anything (your grid isn't loaded yet) gL = 0, gU = 1; Shouldn't happen, if gridLoaded is 0 then you can't possibly have an up to date grid gL = 1, gU = 0; Can't see/target/damage gridLoaded = 0 objects, can see other gridLoaded = 1, gridUpdated = 0 object gL = 1, gU = 1; Fire away!
This prevents players already in grid from having locks break whenever anybody enters the grid, but also prevents both race conditions. It also avoids having the clients have to confirm with each other whether or not the grid is loaded, avoiding possible hax0rzsploits. Any tampering with packets could only serve to make your object MORE vulnerable.
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 20:13:00 -
[41]
Originally by: Douglass Bryant The solution to this is not so difficult, but it does require some modifications to the existing system (and sadly a little more overhead). Each player object should have two flags: gridLoaded and gridUpdated. When an incoming fleet jumps, their gridLoaded flag is set to zero until the server has no more outstanding calls to the client AND all objects on the grid have gridUpdated = 1, at which time the server sets gridLoaded to one. On the other side, the in-system fleet gets their gridUpdated flag set to zero until it loads all the incoming ships, at which point that flag now gets set to one. ...
gL = 1, gU = 0; Can't see/target/damage gridLoaded = 0 objects, can see other gridLoaded = 1, gridUpdated = 0 object gL = 1, gU = 1; Fire away! ...
Do you want to stall a fight for every little incoming ship? --
|
Douglass Bryant
|
Posted - 2010.04.30 20:28:00 -
[42]
Edited by: Douglass Bryant on 30/04/2010 20:33:07 Edited by: Douglass Bryant on 30/04/2010 20:31:15
Originally by: Whitehound
Do you want to stall a fight for every little incoming ship?
Follow the logic closely (it is a bit confusing, but it works quite nicely).
Ships already in-system still have a gridLoaded = 1, but gridUpdated = 0, and thus will be able to see and target each other just fine. The fight does not stall then in the case you suggested.
Edit: I can see I wasn't clear on one of the previous post lines. Should read:
gL = 1, gU = 0; Can't see/target/damage gridLoaded = 0 objects, can see/target/damage other gridLoaded = 1, gridUpdated = 0 objects
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 20:39:00 -
[43]
Originally by: Douglass Bryant Edit: I can see I wasn't clear on one of the previous post lines. Should read:
gL = 1, gU = 0; Can't see/target/damage gridLoaded = 0 objects, can see/target/damage other gridLoaded = 1, gridUpdated = 0 objects
This is better, but why does it still need the gridUpdated-flag when one can shoot both - gridUpdated=0 and gridUpdated=1 - ships? --
|
Douglass Bryant
|
Posted - 2010.04.30 21:00:00 -
[44]
It's hard to explain without an example. Let's try one:
2 Ship Fleet in System A (call them FL1). They have the flags gL and gU both set to 1. An enemy ship (call him E1) jumps into system A. At that point, the following things happen:
* FL1 set gU to 0. gL is still 1. They've loaded the complete grid and are just waiting for the grid update. * E1 is set to gL = 0, gU = 0 while they load the grid.
So, who can shoot who at this point? FL1 could shoot and see each other, but can't shoot or see E1. E1 cannot shoot or see FL1. Now, upon E1 loading the grid:
* E1 is set to gL = 1...but wait, we've got some lag. Lots of stuff going on on this grid. FL1 still hasn't loaded the grid updates, so E1 remains gL = 0.
Now, finally, the grid updates get to FL1. FL1 gets gU = 1 and gL = 1. Now, because FL1 finally loaded the updates and no more objects on the grid need any more updates, E1 gets gL = 1 and gU = 1. The fight is on, everyone can see everyone.
Now let's say FL1 and E1 are going pew pew. A buddy (E2) jumps in to help out E1. Here's what happens:
FL1 and E1 get gU = 0, gL = 1. They can still pew pew each other. E2 gets gL = 0, gU = 0 while his grid loads. Finally, his grid loads and the updates get to FL1 and E1, thus setting E2 to gL = 1 and gU = 1, as well as FL1 and E1 to gL = 1, gU = 1. Fight still on, nobody sees any one early.
It's confusing to write, but it's not really all that complex.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 21:09:00 -
[45]
Originally by: Douglass Bryant It's hard to explain without an example.
I was not asking for an example. I am asking, why does it still need the gridUpdated-flag? --
|
Douglass Bryant
|
Posted - 2010.04.30 21:27:00 -
[46]
Edited by: Douglass Bryant on 30/04/2010 21:28:04
Originally by: Whitehound
Originally by: Douglass Bryant It's hard to explain without an example.
I was not asking for an example. I am asking, why does it still need the gridUpdated-flag?
Right, and the example explains that reason.
Simply, incoming ships will never get gridLoaded = 1 until all the ships already in system are gridUpdated = 1. Read the example, and it will make perfect sense.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 21:37:00 -
[47]
Originally by: Douglass Bryant Right, and the example explains that reason.
Simply, incoming ships will never get gridLoaded = 1 until all the ships already in system are gridUpdated = 1. Read the example, and it will make perfect sense.
No, the example does not explain why it is needed. It is not needed when all you do is to wait for a client to load its data. It comes down to gridLoaded=0 or gridLoaded=1. --
|
Douglass Bryant
|
Posted - 2010.04.30 21:58:00 -
[48]
Originally by: Whitehound
No, the example does not explain why it is needed. It is not needed when all you do is to wait for a client to load its data. It comes down to gridLoaded=0 or gridLoaded=1.
That was my original thinking as well, but I discovered that doesn't really cover all the cases. It's a bit of a strange logic problem.
We agree the premise needs to be that the in-system fleet and the incoming fleet see each other at the same time, regardless of how long it takes to load the grid. So my thinking was, you can't see anyone with gridLoaded=0. But, this, in fact, breaks players already fighting in system, since when somebody jumps in they will ALL get gridLoaded = 0, and thus all suddenly not be able to see each other until they load the grid update. So, you really have more than two distinct cases:
1) Objects who have not loaded the full grid 2) Objects who have loaded the full grid 3) Objects who have loaded the full grid but are awaiting an update to the dataset
Which correspond to:
1) gL=0, gU=0 2) gL=1, gU=1 3) gL=1, gU=0
And the rules should be:
1) Can't see anyone, they don't have a grid yet. 2) Can shoot (2) and (3), but not (1) 3) Can also shoot (2) and (3), but not (1); Also prevents any objects with gL=0 from being set to gL=1 until they all become (2).
Basically the gridUpdated = 0 flag tells the server not to allow any incoming ships to see in-system ships before the in-system ships have loaded the new grid updates.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.01 03:51:00 -
[49]
Originally by: Douglass Bryant That was my original thinking as well, but I discovered that doesn't really cover all the cases. It's a bit of a strange logic problem.
Then let us talk about something else .... exploits.
Your idea will work while at the same time opens the chance for exploits. I could hack my network connection and force the flag gridLoaded to be set to 0 to gain invulnerability any time I like. Or, I am in a fight near a gate and about to lose my ship, so I jump through a gate and pull the plug of my network connection. How will you fix this? --
|
Douglass Bryant
|
Posted - 2010.05.03 16:10:00 -
[50]
Edited by: Douglass Bryant on 03/05/2010 16:11:02 The flags are server side only and not writable by the client. The client can read other objects flags, but cannot set any.
If somehow you were able to convince the server that your grid had not loaded even though it had, you wouldn't be able to see anything, target anybody, or move anyway. Until gridLoaded = 1, the server isn't letting you do jack.
The possibility for a logoffski type trick if this was properly implemented is the same as it is currently.
|
|
Trent Nichols
Di-Tron Heavy Industries Atlas Alliance
|
Posted - 2010.05.03 19:01:00 -
[51]
Eve needs something like this now - badly. I can attribute most of my ship losses in the game, in some way, to lag. That's not to say I wouldn't have died anyway in some of those cases but Ill never know. At the very least, it would have been less frustrating to die fighting than sitting helpless in an unresponsive ship being shot by someone I cant see.
So far, I like Douglass' idea but I think a fleet solution is possible as well as long as some limitations are considered.
First the server needs to know what to call a fleet. I think it safe to say that >20 ships trying to enter entering system or grid at once = fleet or the same number sitting on grid at once = fleet. The server then knows to keep the two groups hidden from each other until most clients have loaded most of what is on grid.
I say most because there will be times (often after Dominion) when not everyone is going to load grid. At some point, the server has to pick a percentage or a time to let the clients that are ready have at it.
The rest could load in the way Douglass proposed - invulnerable until they have control of their ships and are able to shoot as well as be shot.
Colonies and Capitals
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.03 21:13:00 -
[52]
Seriously? Do not play the game when you fear losing your ship. Asking CCP to change the code so that when in doubt it favours the survival of a ship rather than its destruction is just not EVE, nor is it CCP's philosophy. --
|
Douglass Bryant
|
Posted - 2010.05.03 21:20:00 -
[53]
Originally by: Whitehound Seriously? Do not play the game when you fear losing your ship. Asking CCP to change the code so that when in doubt it favours the survival of a ship rather than its destruction is just not EVE, nor is it CCP's philosophy.
How very silly. Sure, space is a harsh place, and on and on etc etc. However, at the very least changing the code so it doesn't favor either case nor any side seems to be not only the sensible solution, but the way it should have been done in the first place. Who cares about who wins if the odds of a fair fight are sometimes not very high?
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.03 21:42:00 -
[54]
Originally by: Douglass Bryant ... changing the code so it doesn't favor either case ...
You cannot make it so that it favours a third case. It would not be a progress. A third case would mean that it can get stuck. You can allow for some stagnation, but you also need to run a timer until when to make a final decision. --
|
Trent Nichols
Di-Tron Heavy Industries Atlas Alliance
|
Posted - 2010.05.03 22:32:00 -
[55]
Edited by: Trent Nichols on 03/05/2010 22:35:26
Originally by: Whitehound Seriously? Do not play the game when you fear losing your ship. Asking CCP to change the code so that when in doubt it favours the survival of a ship rather than its destruction is just not EVE, nor is it CCP's philosophy.
No one is complaining about loosing ships. I could loose a few every day and still be alright. Provided you get a good fight, loosing ships can be fun even.
We are talking about loosing ships to lag. There is no good fight, you just die and there is nothing you can do about it. No fun at all.
A mechanic that keeps a ship in limbo until the server is actually ready for it doesn't favor survival or destruction. When the ship finally enters the grid, it isn't guaranteed survival, only a chance to dish out some destruction of its own.
What you are missing, Whitehound, is that the way the server currently handles lag often makes fleet fights no fun. Its bad design and the proper response to it isn't to say "So don't jump in" or "Don't fly in fleets". The proper response is to say "Fix it CCP! NOW!" After all if you watch CCP's vids, big fleet fights are what Eve is supposed to be about.
Colonies and Capitals
|
Douglass Bryant
|
Posted - 2010.05.04 05:22:00 -
[56]
Originally by: Whitehound You cannot make it so that it favours a third case. It would not be a progress. A third case would mean that it can get stuck. You can allow for some stagnation, but you also need to run a timer until when to make a final decision.
I have a feeling I'm being trolled here, but I don't see mentioning a third case in that either/or statement. What third case are you referring to? Just because I like burgers just as much as I like pizza doesn't mean that I favor shrimp ****tail instead. I'm not seeing your logic.
If you carefully run through my logic again, you can see that it can only get stuck if the grid never loads (already happens), except in this case, instead of your ship appearing anyway so it can be blown to smithereens while you sit at a black screen, it doesn't appear to anyone. And again, if you follow the logic carefully you can see that it works just as well for fleets, because ships appear as they have the data and not before. There are no clunky timers necessary, because the server is keeping track of who has what data and who can shoot whom.
I'm not sure what your argument is here. If your argument is that you should thrust the player's ship into the fray even if he never loads the grid, then I feel you've missed the point completely, which is to ensure both sides see a fair fight. If that's not your argument, then I apologize, but the logic I've proposed is simple, straightforward, fair to both the in-system and incoming parties regardless of either party fleet size or position, and as (probably more) exploit resistant than the existing code. Do I know if it's possible given the current engine? No, I don't, but neither do any of us.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.04 10:38:00 -
[57]
Edited by: Whitehound on 04/05/2010 10:41:52
Originally by: Douglass Bryant I have a feeling I'm being trolled here, but I don't see mentioning a third case in that either/or statement. What third case are you referring to?
The state of stagnation, like I wrote above. The state in which no decision has to be made.
A good solution would be to change the timer from the currently fixed 10 seconds into a dynamic timer. For every ship in a system shall the timer be increased by 20ms (for example). At 50 ships do you get an extra second, with 100 ships do you get two seconds more, with 500 ships do you get 10 seconds more. This is just an example and one that uses a linear growth. It would help to know the complexity of the problem - the time it takes for a client to load a grid (i.e. linear, logarithmic, geometric, etc.) - and scale the timer identically to make it match. Possibly, again, with a fixed limit of maybe 30 seconds. If your client fails to load the grid within this time then other players shall continue to get a chance to fire upon your ship.
An additional feature would be to populate/update the client cache at start-up. All ship, drone and station icons are currently only rendered on demand. I do not know what other data the client fetches on demand - some is being fetched on start-up, other on login - but other data might not be in there yet. Having an option to update the cache at start-up would help to reduce the load on the client during game play. Those who prefer a fast client start-up could leave the option turned off. One could also add an option to enter a path to the cache directory and make it point to a RAM disk or SSD. --
|
Douglass Bryant
|
Posted - 2010.05.05 17:30:00 -
[58]
Originally by: Whitehound If your client fails to load the grid within this time then other players shall continue to get a chance to fire upon your ship.
This should never, ever happen. If you don't load the grid, you don't get killed. That defeats the purpose of this whole concept.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.05 18:04:00 -
[59]
Originally by: Douglass Bryant That defeats the purpose of this whole concept.
Not if this concept has to obey the rules of a higher concept - the concept of EVE being a pretty mean PvP game. You need to see the bigger picture here, really. EVE is not a game where you build a ship and get to keep it forever. You build a ship so you can destroy it in a fight with others. --
|
So Sensational
GREY COUNCIL Gentlemen's Club
|
Posted - 2010.05.05 19:47:00 -
[60]
Originally by: Whitehound
Originally by: Douglass Bryant That defeats the purpose of this whole concept.
Not if this concept has to obey the rules of a higher concept - the concept of EVE being a pretty mean PvP game. You need to see the bigger picture here, really. EVE is not a game where you build a ship and get to keep it forever. You build a ship so you can destroy it in a fight with others.
Dying to lag is not a "fight with others", it's a fight against the system, the broken system.
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.05 20:08:00 -
[61]
Originally by: So Sensational Dying to lag is not a "fight with others", it's a fight against the system, the broken system.
The best solution against lag is to destroy ships. If you fear lag, then use the map and check on the activity in a system. It is your choice to jump through the gate, or to stay where it is save. Do not complain about wanting to jump into a fight and then losing your ship due to higher forces. You should know by now that you will fail with your request. --
|
Douglass Bryant
|
Posted - 2010.05.06 16:43:00 -
[62]
Originally by: Whitehound The best solution against lag is to destroy ships. If you fear lag, then use the map and check on the activity in a system.
So, let me see if I have your logic correct. The base premise is that Eve is a harsh PvP game. Therefore, grid loading imbalances should not be fixed to cater to those who may lose their ships flying into lag. So, the answer to lag is to have ships killed and players avoid populated or deadly systems. Thus, actually reducing the amount of PvP that is taking place.
Let's be honest here, one player with a black screen against another player blowing up a stationary undefended target is not PvP. If you want players to kill each other, fine, but then both parties must at least be able to shoot back. What you're talking about isn't PvP, it's player vs. programmer. I think if this issue was resolved, you would have MORE PvP, because each side would be guaranteed an equal start to the fight, thus actually ADDING and not subtracting to the harsh universe that is Eve.
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.06 17:44:00 -
[63]
Edited by: Whitehound on 06/05/2010 17:44:17
Originally by: Douglass Bryant So, let me see if I have your logic correct. The base premise is that Eve is a harsh PvP game. Therefore, grid loading imbalances should not be fixed to cater to those who may lose their ships flying into lag. So, the answer to lag is to have ships killed and players avoid populated or deadly systems. Thus, actually reducing the amount of PvP that is taking place.
It is exactly what the players want to do, to reduce the amount of existing ships.
Quote: Let's be honest here, ...
See, there can only be so many ships, and the fun part is to blow up ships. CCP cannot change the game to accommodate for an infinite amount of ships, but they can allow for others to have fun. --
|
|
|
|
Pages: 1 2 3 :: [one page] |