Pages: 1 [2] 3 4 5 6 7 8 9 10 11 12 .. 12 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 5 post(s) |
Agent Unknown
Caldari
|
Posted - 2010.02.04 16:02:00 -
[31]
Edited by: Agent Unknown on 04/02/2010 16:02:48 So, I'm guessing I was experiencing a different bug then? I tried to jump OUT of D-G to F9E (which had like 9 in local), but I was stopped by traffic control for over 10 minutes, after which I relogged and found myself in F9E in a pod. Petitioned, got the same old "the logs, they show nothing" response. Oh, and I got podded by a bomb after the e-warp, but that's different.
Edit: The first time I relogged I was still in D-G, but was stuck on loading game; next time I relogged I was in a pod in F9E. Also, I now have one of those annoying sigs.
Originally by: CCP Fallout
And yelling is bad. It makes the baby Jesus cry and when the baby Jesus cries I'm forced to lock threads
|
Batolemaeus
Caldari Free-Space-Ranger Morsus Mihi
|
Posted - 2010.02.04 16:33:00 -
[32]
Interesting. You are missing the point. Completely and utterly.
CCP created a system that required more people than before. CCP concentrated multiple goals into singular ones. Even if the cluster behaved like before dominion and even if you get fights up to 1.5k under control, your failure in game design will produce higher and higher numbers until the nodes break again.
Had anyone spent any thought on the sov system beyond "let's make it like the old one", we wouldn't have this problem in the first place and you could spend your energy and time on something different.
Also:
Quote: The conclusion has, however, always been to leave fleet battles alone rather than reimbursing them as a whole.
This is not consistent with GM actions taken in the past months. Not that inconsistency in the GM department is anything new when it comes to game related petitions.. ----------------------------------------------
Originally by: CCP Prism X In New Eden, EVE wins you.
|
Crimson11
Targeted Logistics and Manufacturing
|
Posted - 2010.02.04 16:38:00 -
[33]
Honestly, Move SBU's so that they are on the outside of a system rather than inside the system. That way attackers and defenders must be spread out. Solves alot of problems rather quickly too.
Simple
This idea has been mention several times now!
Crim
|
Yaay
UK Corp
|
Posted - 2010.02.04 16:44:00 -
[34]
The cause for the backup of data seems to be very closely related to damage calculations. That is to say, If you jump in and have time to load before damage calculations start happening, you will always load, and quite fast.
If instead you jump in and very quickly start receiving large amounts of damage calculations, the grid never loads. The most obvious form of this is when 1 single bomber launches a bomb on a fleet, it can prevent grid load.
Part 2 for server crashes seems to be high instantaneous damage calculations. This seems to be typically linked to grid load, but happens after grid load from time to time as well. The only real cause for this seems to be large fleets and their x 5 drones being hit by large swarms of bombs.
Now on to more of a rant mode. If you guys would quit balancing races by giving them more drones that they never needed, it would help with a lot of the lag your game creates. It would benefit this game greatly if you rebalanced all ships and limited drone bays to those ships that really deserved it. Case and point, why in gods name does a falcon have a drone bay.
Battleships too should not have a drone bay unless they are: geddon, Mega, domi, Phoon. Recalabrate all the others to do weapon damage are remove 5 entities from the game for all the other BS in engagements.
Even on great performing servers, once the drones start piling up, even with brackets off, the server takes a very noticable performance dive. And consider this, A BS that has 75 drone bay, if that's 3 waves of light drones, it's very likely by the end of the fight all 15 of his light drones will be deployed. So rather than just 5 active, he has 10 extras creating space junk on a grid.
DD changes
Docking PVP games |
Batolemaeus
Caldari Free-Space-Ranger Morsus Mihi
|
Posted - 2010.02.04 16:50:00 -
[35]
Originally by: Yaay Part 2 for server crashes seems to be high instantaneous damage calculations. This seems to be typically linked to grid load, but happens after grid load from time to time as well. The only real cause for this seems to be large fleets and their x 5 drones being hit by large swarms of bombs.
Nah, it's much simpler.
If you order everyone to shoot the gate while the enemy jumps in / warps on grid, he will never load. ----------------------------------------------
Originally by: CCP Prism X In New Eden, EVE wins you.
|
Yaay
UK Corp
|
Posted - 2010.02.04 17:00:00 -
[36]
Originally by: Batolemaeus
Originally by: Yaay Part 2 for server crashes seems to be high instantaneous damage calculations. This seems to be typically linked to grid load, but happens after grid load from time to time as well. The only real cause for this seems to be large fleets and their x 5 drones being hit by large swarms of bombs.
Nah, it's much simpler.
If you order everyone to shoot the gate while the enemy jumps in / warps on grid, he will never load.
That would be part 1?
DD changes
Docking PVP games |
Batolemaeus
Caldari Free-Space-Ranger Morsus Mihi
|
Posted - 2010.02.04 17:13:00 -
[37]
Yes, but you will hesitate to bomb your own fleet. Shoot a gate? Not so much. |
Manfred Rickenbocker
|
Posted - 2010.02.04 17:35:00 -
[38]
I for one will welcome our larger blob overlords when this gets fixed.
By the way, does CCP realize this will only exacerbate the problem? Once the lag has been fixed and you can bring more peeps, it will only increase the number of players that try and get in on the fun (pain?). Eventually we will just see people complaining about 2000 vs 2000 fights... ------------------------ Peace through superior firepower: a guiding principle for uncertain times. |
Caoim Fearghul
Caldari Ammatar Free Corps Curatores Veritatis Alliance
|
Posted - 2010.02.04 17:35:00 -
[39]
I've seen that the response from CCP regarding the ships being killed over an hour after logging out is that there are no logs of clients logging out. Now, correct me if I'm wrong, but events are handled server side, and we have this little device called an emergency warp that normally kicks in if you quit the client, or even if you sever your internet connection. That means the server does monitor the status of its connection with a local client under normal conditions or else there would be no way for the server to be able to initiate an emergency warp.
Out of curiosity, would the games that CCP were playing with the server to prevent node death involve overriding the normal timeout protocols? Prodesse Non Nocere
|
Xtover
Suicide Kings
|
Posted - 2010.02.04 17:49:00 -
[40]
Originally by: Crimson11 Honestly, Move SBU's so that they are on the outside of a system rather than inside the system. That way attackers and defenders must be spread out. Solves alot of problems rather quickly too.
Simple
This idea has been mention several times now!
Crim
excellent idea, but what happens when you need to fight over the ihub?
|
|
El'hith
Gallente The Phoenix Enclave
|
Posted - 2010.02.04 17:58:00 -
[41]
Honestly post-big update lag threads do amuse me.
Everytime they release a new big patch this happens, most people expect it due to new content / new variables.
The new patch comes out, 6 months go by with terrible lag 6 months later a massive fix comes out that not only supports large fleet engagements, but even larger fights than before the previous patch.
Every year this happens, its nothing new but the trend is that the game gradually does get more stable and capable of having more players on grid at the same time. (Till the next expansion when it breaks again)
In short... if your new welcome to the cycle of lag > blob > lag > blob etc
For everyone whos been here a few years just help out by reporting bugs and joining in stress testing.
'Hith
~~~~Back from the dead! ~~~~
|
Gnulpie
Minmatar Miner Tech
|
Posted - 2010.02.04 18:12:00 -
[42]
Any idea WHY the lag is suddenly such drastically increased? |
AgentFruitfly
|
Posted - 2010.02.04 18:20:00 -
[43]
Sounds like you guys need to get log better perf metrics.
|
Ancy Denaries
Forever Unbound
|
Posted - 2010.02.04 18:24:00 -
[44]
And here I was, thinking that people would be grateful that CCP is finally doing something about the lag. Shame on me for being positive. You bunch o' whiners. ---- The Demigodess with a Conscience - An EVE IC Blog
Originally by: CCP Dropbear rofl
edit: ah crap, dev account. Oh well, official rofl at you sir.
|
Venkul Mul
Gallente
|
Posted - 2010.02.04 18:27:00 -
[45]
Originally by: Ga'len
So, finally after many of us have been literally screaming for you to actually monitor a live fleet fight on the production server because that's where the problem was occurring, you actually listened to us.
....
In the future, when your stakeholders are first asking, next demanding and then screaming at you to do something, perhaps you will listen to them next time.
Your reply why it was not done before 8at least on this scale, as sometime you see CCP guys in big battles) is here:
Quote: Well, if the node had died (thank you for artificially keeping it alive so we could be lagged out longer and loose ships you then won't reimburse. Being guinea pigs in a live environment without notice is surely what we play and pay for) there might have been a chance to get an actual fight as a percentage of people from *both* sides would have loaded the grid.
and in all the similar posts.
|
AgentFruitfly
|
Posted - 2010.02.04 18:40:00 -
[46]
Originally by: Xtover
Originally by: Crimson11 Honestly, Move SBU's so that they are on the outside of a system rather than inside the system. That way attackers and defenders must be spread out.
Crim
excellent idea, but what happens when you need to fight over the ihub?
Wouldn't come to that. On that scenario, defenders only have to blob sbu systems 1 by 1 until below the 50%+1 threshold. Attackers are unlikely to have enough numbers to lag out many systems simultaneously.
|
Miklas Laces
tr0pa de elite Triumvirate.
|
Posted - 2010.02.04 18:59:00 -
[47]
it's been 2 months already, and you still dont have a clue worst dev blog ever
________________________________________________ CCP Claw > Sokata has been destroyed for boundary violation Drug Kito > Sokata you'll always be remembered as a noob in history of alliance tourname |
Masada Akiva
Gallente Phoenix Division Libertas Fidelitas
|
Posted - 2010.02.04 19:13:00 -
[48]
I am glad CCP is working on figuring out the grid load problem. I'm sure it is not an easy one to solve. I look forward to its eventual fix.
The decision not to reimburse losses due to risk of CCP being "arbitrary" is a disappointment. The CVA capital fleet suffered 75-80% losses while -A- did not lose a single capital ship. The CVA armada is mortally crippled and without reimbursement CCP is arbitrarily giving victory over Providence to -A-. While -A- certainly did not initiate an "exploit" they sure did benefit from this bug. The last check I made put the death tally at 140 CVA capitals lost in D-GTMI... some of those hours after the pilots logged out.
The game goes on... but this response is not satisfactory. "If given the choice between knowledge and imagination, I choose imagination." ~Einstein |
Khandahar Bob
|
Posted - 2010.02.04 19:20:00 -
[49]
I'd like to point out a flaw in some of the advice being given by players to "alleviate the lag" is likely going to cause more problems. I've seen people advocate that you should ungroup all of your guns and fire them separately to prevent them from getting into a 'stuck' state. This seems entirely wrong to me, as for a Battleship this will multiply the number of calls to the server by up to 8.
Can someone from CCP please say out loud, for the uninitiated, "this is a very bad idea"?
It seems pretty obvious to me that this would cause more problems, but nobody listens to me.
|
Pallidum Treponema
Body Count Inc. Against ALL Authorities
|
Posted - 2010.02.04 19:23:00 -
[50]
Originally by: Caoim Fearghul I've seen that the response from CCP regarding the ships being killed over an hour after logging out is that there are no logs of clients logging out. Now, correct me if I'm wrong, but events are handled server side, and we have this little device called an emergency warp that normally kicks in if you quit the client, or even if you sever your internet connection. That means the server does monitor the status of its connection with a local client under normal conditions or else there would be no way for the server to be able to initiate an emergency warp.
Out of curiosity, would the games that CCP were playing with the server to prevent node death involve overriding the normal timeout protocols?
I think it's a matter of the client sending a "LOGOUT" message to the server, but as the server is overloaded, it won't actually act on the logout until, say 40 minutes later. This means that if you logged out at 19:00, the server will log it as 19:40, meaning that for the GM staff, it's impossible for them to see if you actually logged out at 19:00 like you claim, or if you logged at 19:40, after hostiles actually started shooting your ship.
The server will initiate the ewarp as soon as it realises that you've logged out, but the issue here is that the server doesn't actually KNOW that you've logged out, because it hasn't had time to process it yet.
Yes, it sucks, I've lost ships to that too. I trust CCP to work on improving it though. --
|
|
Caoim Fearghul
Caldari Ammatar Free Corps Curatores Veritatis Alliance
|
Posted - 2010.02.04 19:34:00 -
[51]
Originally by: Pallidum Treponema I think it's a matter of the client sending a "LOGOUT" message to the server, but as the server is overloaded, it won't actually act on the logout until, say 40 minutes later. This means that if you logged out at 19:00, the server will log it as 19:40, meaning that for the GM staff, it's impossible for them to see if you actually logged out at 19:00 like you claim, or if you logged at 19:40, after hostiles actually started shooting your ship.
The server will initiate the ewarp as soon as it realises that you've logged out, but the issue here is that the server doesn't actually KNOW that you've logged out, because it hasn't had time to process it yet.
Yes, it sucks, I've lost ships to that too. I trust CCP to work on improving it though.
I can show you this is false quite easily, simply pull out your internet cable and have a friend watch what happens to your ship after a few moments. The client cannot sent a "LOGOUT" message, it is simply severed from the game.
In order to keep the server up I suspect they overrode the normal timeouts which is why hours later a ship is still in game after the pilot left. Prodesse Non Nocere
|
Fina Kelitan
|
Posted - 2010.02.04 19:40:00 -
[52]
I think that if the "logout" message (more likely a disconnect than an actual message, but still) is delayed 40 mins, then it's also likely that the messages for the enemy locking and firing on you were similarly delayed.
So while you weren't dead (as far as you could tell) when you logged, events were already queued that would cause your death.
If there's actually a difference in delay between different people in the grid, so that e.g. you could try to log out, then the enemy locks and kills you (with little lag), and then the logout is finally processed, that would be a lot more serious.
Anyone able to confirm which it is?
- Experienced EVE player trying a new character |
Batolemaeus
Caldari Free-Space-Ranger Morsus Mihi
|
Posted - 2010.02.04 19:49:00 -
[53]
Edited by: Batolemaeus on 04/02/2010 19:49:26
Originally by: Pallidum Treponema
I think it's a matter of the client sending a "LOGOUT" message to the server, but as the server is overloaded, it won't actually act on the logout until, say 40 minutes later.
Wrong. Everyone who has an alt can do a little test: Log out while gridload isn't working. Your main will be flagged offline immediately. You can see him going offline in your address book. So the info is there, it's just gms not caring if you lose your ship hours after logging out. |
InnerDrive
Shiva Morsus Mihi
|
Posted - 2010.02.04 20:03:00 -
[54]
Edited by: InnerDrive on 04/02/2010 20:04:15 While im happy your working on it i can only say one thing.
OMG can u work harder?
i was at your sisi tests and i will continue to come and try get as manny people to come as possible , please do more if needed
|
Le Ming
|
Posted - 2010.02.04 20:12:00 -
[55]
Somehow it's bitter to read that the node was kept alive intentionally, as it would have crashed otherwise which in turn would have saved a lot of peoples ships and pods. On top of that you reject reimbursement, because your logs don't show when someone disconnects and when a ship explodes. If there is like an hour or two in between, things should be obvious.
On the other side it's good to hear that you're on it and fixes will be deployed soon - hopefully very soon.
|
Jackson Taus
|
Posted - 2010.02.04 20:47:00 -
[56]
First, let me say that as a CS student, I understand that lag is a very difficult to tackle problem.
But I think that prolonging node uptime is a mistake. It's better to have the node crash than to have a situation where "playing" devolves to "shoot once every 5 minutes" or where we have grid-loading issues. Both from a balance PoV and an enjoyment PoV, I would think "node's crashed, sorry, play on an alt for 45 minutes" is superior to being stuck in super-lag or stuck not loading grid.
I think you should also look into structural changes which discourage blobbing. Others have suggested putting the SBUs on the other side of the 'gates or similar measures. Even a brilliant and heroic fix will at best only allow slightly larger fights. If large fleet fights in a single system continue to be encouraged by the mechanics, we're going to eventually have even larger blobs that make the lag return.
I'd also like to suggest a temporary fix to the reinforcing problem - predictive reinforcement. It should be possible to go over a data-set and tease out trends in day[x-1] that predict which nodes will be high-traffic in day[x]. For instance, if there are reinforced nodes unallocated and unrequested, assign them to systems which have high-value targets coming out of reinforce (stations and iHubs, say). Or if a system saw heavy fleet action yesterday (but nothing put into reinforce) and there are spare beefy nodes, use them for that. Obviously the actual assignment algorithm would be more complex (and based on mining accumulated data) than that, but you get the idea.
|
Adril Alatar
Minmatar Galactic Shipyards Inc Curatores Veritatis Alliance
|
Posted - 2010.02.04 20:52:00 -
[57]
Originally by: Batolemaeus Edited by: Batolemaeus on 04/02/2010 19:49:26
Originally by: Pallidum Treponema
I think it's a matter of the client sending a "LOGOUT" message to the server, but as the server is overloaded, it won't actually act on the logout until, say 40 minutes later.
Wrong. Everyone who has an alt can do a little test: Log out while gridload isn't working. Your main will be flagged offline immediately. You can see him going offline in your address book. So the info is there, it's just gms not caring if you lose your ship hours after logging out.
Confirmed. Most of the caps where logged out according to corp member list for quite some time when being killed. Some of them even logged alts on on the same account an hour before the got killed. GM's even refuse to escalate petition because they think the issue is closed after there copy&paste lag answer....
disappointing really
|
TraderRefinerJane
|
Posted - 2010.02.04 21:12:00 -
[58]
Edited by: TraderRefinerJane on 04/02/2010 21:15:40 CCP, this devblog is probably the most failure I've seen from a MMO company in a while, especially with regards to your reimbursement policy. Only boot.ini tops Dominion in terms of sheer incompetence.
The logic your customers will gleam from the dev blog is elegantly simply -- you say "We Are Aware of the Problem" but we won't reimburse anything -- so why should players play your game if they die to a bug? Why play at all when all major 0.0 conflicts since Dominion have been decided by game/server bugs or people quitting the game?
No wonder CCP's customer service is a joke in the industry.
|
Allen Ramses
Caldari Typo Corp
|
Posted - 2010.02.04 21:17:00 -
[59]
Now that it appears CCP understands why things are not happening, a fix should be on its way relatively soon. This is good...
...But it's too bad they don't spend the same kind of effort (or any effort, for that matter) trying to find out why the client is beyond unstable. How long must a person live with low gfx settings to use 2 clients, fear crashing whenever initiating warp, and experience terribad FPS before CCP mans up and says "Oops, we ****ed up. We're looking into it."? Most of the uberblobs have to complain about it, I guess.
____________ I'd make a forum signature that didn't suck, but I'm restricted by a character limit that does. |
Charles37
|
Posted - 2010.02.04 21:20:00 -
[60]
Even though this lag does not affect me, I appreciate the upfront and forthcoming nature of this blog post. In addition, it has been a fascinating peek behind the scenes at what makes EVE run.
I hope that the problems that the solutions that were alluded to help the problems.
|
|
|
|
|
Pages: 1 [2] 3 4 5 6 7 8 9 10 11 12 .. 12 :: one page |
First page | Previous page | Next page | Last page |