|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.28 08:40:00 -
[1]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.28 22:06:00 -
[2]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.28 23:43:00 -
[3]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 00:25:00 -
[4]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 01:15:00 -
[5]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 02:00:00 -
[6]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 03:17:00 -
[7]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 04:02:00 -
[8]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 09:21:00 -
[9]
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! --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.29 17:31:00 -
[10]
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. --
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 06:57:00 -
[11]
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.? --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 10:50:00 -
[12]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 12:15:00 -
[13]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 16:37:00 -
[14]
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? --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 19:25:00 -
[15]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 20:13:00 -
[16]
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? --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 20:39:00 -
[17]
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? --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 21:09:00 -
[18]
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? --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.04.30 21:37:00 -
[19]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.01 03:51:00 -
[20]
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? --
|
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.03 21:13:00 -
[21]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.03 21:42:00 -
[22]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.04 10:38:00 -
[23]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.05 18:04:00 -
[24]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.05 20:08:00 -
[25]
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. --
|
Whitehound
The Whitehound Corporation
|
Posted - 2010.05.06 17:44:00 -
[26]
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. --
|
|
|
|