EVE Search - CCP incompetence...

All Channels

EVE General Discussion

CCP incompetence...

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 3 [4] 5 :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Bleeshtar	Posted - 2008.06.09 16:33:00 - [91] Originally by: Tacit Blue Like clockwork, we get this same type of post EVERY Sunday. This
Shidhe The Babylon5 Consortuim	Posted - 2008.06.09 16:35:00 - [92] Edited by: Shidhe on 09/06/2008 16:38:54 Copied from the last Jita post I answered - if the OP's can't be original, why should I? Maybe CCP should install a Jita whine filter... <<< The LAG must flow! (with apologies to Dune fans...) Remove all special status from Jita - all systems should be treated equally, trying anything to `improve' this will only cause more problems. If players can't market things sensibly, then they deserve to be lagged. And CCP have 1000s of more urgent things than worrying about Jita. Can we just put a stake in the heart of this dead horse now, please! >>> I am really serious about removing the special status - it has done nothing but make the problem worse, though it was an understandable fix at the time. Some experiments fail for unpredictable reasons. By allowing Jita to grow more, it was made too indispensable for the trade system, so traders felt more constrained to use it.
Aclyn Seriy Center for Advanced Studies	Posted - 2008.06.09 16:59:00 - [93] Originally by: Fifth Horseman Yeah, because god forbid that CCP ever be expected to supply anything they promised or implied, rather than keep pumping the server full of irrelevant nonsense like ambulation or to a lesser extent FW. Nice to see your still around Fifth, making snidey remarks about a game you seem to hate and STILL haven't left! Anyway, about this thread.....FAIL. I think that covers everything. Originally by: techzer0 I'm the failboat captain
DubanFP Four Rings Souls of Vengeance	Posted - 2008.06.09 17:00:00 - [94] Originally by: Aclyn Seriy Nice to see your still around Fifth, making snidey remarks about a game you seem to hate and STILL haven't left! Anyway, about this thread.....FAIL. I think that covers everything. /end thread _______________ ReiAyanami> We bring you tidings of AARRRRRRRRR
Beltantis Torrence	Posted - 2008.06.09 17:17:00 - [95] Originally by: Tarminic So please, tell us how to "fix" the issue. Preferably, list which algorithms CCP probably uses and which ones they should use to get better performance. Support your arguments and show your work. I can only talk about what I can see (ie, the client side), along with some guesses at how they're running the backend. That disclaimer being said, Python is not a fast language. They're handling window management and object management in Python, which is ridiculously slow. Furthermore on Windows they're using CryptoAPI for encryption, which is pointless considering you can decompile the client if you wanted to get the secret key. Instead of having all that overhead they could just XOR the data against the username or a session token, which would be somewhere around 100x faster than what they're doing. Would be roughly as secure and they can reserve higher levels of encryption for the initial handshake. I also tend to think compression should be left for dial-up modems rather than the default option, as CPU resources are more limited than bandwidth in the general case - both server side and client side. This also avoids some overhead associated with interop between Python and ZLib/CryptoAPI, currently these libs are being marshaled to every time a network frame gets processed. If you think of a logical node as physically represented by one database cluster and one application server, then it'd actually make sense to take the stations and chat and put them into separate physical servers and buffer the chat relative to the number of people in the system (ie, purposefully lag chat to reduce the typical payload of each frame). I haven't sniffed the traffic but assuming it doesn't cater traffic to locale I'd further say that you shouldn't recieve object locations and "space data" while you're docked. From what I could see though, when you connect to Eve you actually only connect to one physical access point. Ideally you'd want to separate out chat/market/etc onto one connection and have display/fighting/physics come in on another connection. I didn't see any multithreading on the client-side at all, but likely you'd want to have the physics calculations and ancillary tasks (chat buffering, etc) on background threads and leave the main thread for doing the actual drawing/interface interaction. The HL2 engine utilizes an asynchronous method like this for level loading. To allow for better caching of market data, they should institute a lag of say 5 minutes between when you sell something at a specified price and it gets listed on the market. This would allow them to cache queries in memory and only have to repopulate those buffers at predetermined intervals. From what I can tell it handles that on demand right now, which means you're probably hitting disk every time you run a query. Those are just some things off the top of my head, though I realize you were just being sarcastic as if no one else works in the field of distributed computing.
Gone'Postal Scoopex The Volition Cult	Posted - 2008.06.09 17:25:00 - [96] Is there an update on this Super Computer or is it just a pipe dream for CCP ? Questions, Comments, Problems, Please address them to the CSM.. Now CCP Never have to visit the forum. -V8I-
Tarminic Black Flame Industries	Posted - 2008.06.09 17:37:00 - [97] Originally by: Beltantis Torrence I can only talk about what I can see (ie, the client side), along with some guesses at how they're running the backend. That disclaimer being said, Python is not a fast language. They're handling window management and object management in Python, which is ridiculously slow. I'm not positive about this, but I believe that CCP is in the process of rewriting the client in C++. Quote: Furthermore on Windows they're using CryptoAPI for encryption, which is pointless considering you can decompile the client if you wanted to get the secret key. Instead of having all that overhead they could just XOR the data against the username or a session token, which would be somewhere around 100x faster than what they're doing. Would be roughly as secure and they can reserve higher levels of encryption for the initial handshake. I also tend to think compression should be left for dial-up modems rather than the default option, as CPU resources are more limited than bandwidth in the general case - both server side and client side. This also avoids some overhead associated with interop between Python and ZLib/CryptoAPI, currently these libs are being marshaled to every time a network frame gets processed. I'm not terribly experienced with cryptography so I have no idea about how well this would work. It sounds like a good plan, however. Quote: If you think of a logical node as physically represented by one database cluster and one application server, then it'd actually make sense to take the stations and chat and put them into separate physical servers and buffer the chat relative to the number of people in the system (ie, purposefully lag chat to reduce the typical payload of each frame). I'm not positive, but I believe that there are already distinct nodes (I.E. Blade CPUs) for chat, market activities, and in-space/combat activities. I have no idea about chat buffering, however, though based on my observations it looks like chat isn't buffered except by limiting the amount of messages the client can send to once every 3 seconds or so. Quote: I haven't sniffed the traffic but assuming it doesn't cater traffic to locale I'd further say that you shouldn't recieve object locations and "space data" while you're docked. I don't believe that you do, though I haven't done any packet sniffing either. Quote: From what I could see though, when you connect to Eve you actually only connect to one physical access point. Ideally you'd want to separate out chat/market/etc onto one connection and have display/fighting/physics come in on another connection. I'm not sure that this happens, but it's an interesting idea. I would be concerned about the additional complexity of adding a separate connection and the potential problems this could cause when one of the connections fails. It doesn't seem like it would be impossible to implement, however. Quote: I didn't see any multithreading on the client-side at all, but likely you'd want to have the physics calculations and ancillary tasks (chat buffering, etc) on background threads and leave the main thread for doing the actual drawing/interface interaction. Currently the client isn't multithreaded at all, yeah. As I said above, I think that CCP is in the process of rewriting it. ---------------- Play EVE: Downtime Madness v0.81 (Updated 4/8)
Tarminic Black Flame Industries	Posted - 2008.06.09 17:39:00 - [98] Quote: To allow for better caching of market data, they should institute a lag of say 5 minutes between when you sell something at a specified price and it gets listed on the market. This would allow them to cache queries in memory and only have to repopulate those buffers at predetermined intervals. From what I can tell it handles that on demand right now, which means you're probably hitting disk every time you run a query. I like this idea, but I don't think that disk access time are the current bottleneck (IIRC, the two RAMSAN drives they use are solid state) as it is network latency and server computations. Hopefully infiniband will help alleviate this issue. Quote: Those are just some things off the top of my head, though I realize you were just being sarcastic as if no one else works in the field of distributed computing. Sarcastic in the sense that I don't think that CCP just intentionally doesn't try and fix lag-related problems, but honest when asking for suggestions. Can't hurt. ---------------- Play EVE: Downtime Madness v0.81 (Updated 4/8)
Beltantis Torrence	Posted - 2008.06.09 17:54:00 - [99] Originally by: Tarminic [I like this idea, but I don't think that disk access time are the current bottleneck (IIRC, the two RAMSAN drives they use are solid state) as it is network latency and server computations. Hopefully infiniband will help alleviate this issue. I've noticed my main source of lag in the typical scenario is selling stuff after I get back from running missions. When you go to sell, it tries to figure out the "effective price" of what you'd sell it for if you just sold it to the max open bid and in Lonetrek that sometimes takes me 5-10 seconds. Theoretically you'd want to summarize these at least for systems within some threshold, then update the in memory tables as needed at given intervals. IE, you figure out the effect selling price of say, bloodclaw missiles, for every system in the region then when people add new buy orders they go into a queue and every five minutes a job sweeps through the summary tables to update them. This way its just request/response, with no calculation and that should be able to turn around requests like that within milliseconds. The only time you'd hit lag is if you happened to go to sell the item at the exact same time the pre-calc data is getting refreshed.
Ralle030583 The Wild Hunt Pure.	Posted - 2008.06.09 18:19:00 - [100] Edited by: Ralle030583 on 09/06/2008 18:22:49 every time the same since years... 1) lag cause x ppl in a system like jita 2) ccp fix it (in somes a good sometimes a nerv way (less drones f.e.^^) 3) ppl see that x ppl in system arent so laggy anymore 4) more ppl enter the system 5) ppl blame ccp cause of lag 6) GOTO 1 this same also hit for fleet battles, the sizes are rising everytime its improved only a bit and i also think that most ignore that load isnt raising linear when more ppl enter its raising exponential, every for others relevant data needs to be distribute to every other participent /edit cause of spelling.. P.S. close this threat.. its threat no.3495734 about same issue... You need a free Killboard? check: http:\\www.eve-kill.net Originally by: CCP Sharkbait i have untrashed this bug report and i will take car
DubanFP Four Rings Souls of Vengeance	Posted - 2008.06.09 18:28:00 - [101] Originally by: Tarminic I'm not positive about this, but I believe that CCP is in the process of rewriting the client in C++.. I don't think they ever directly said they would be changing the programming language. What they did say was that they would need to rewrite the code so that it can run with the new supercomputing options that they've been talking about. So basically they will need to rewrite a lot of the server code to run with the new technology, this is what's taking so long. Also I'll be the first to admit that I don't know much about python, and that server/databases aren't my computing specialty. _______________ ReiAyanami> We bring you tidings of AARRRRRRRRR
Leviathan9 Royal Hiigaran Navy	Posted - 2008.06.09 18:41:00 - [102] Originally by: Declan Intaki So here we are... again..... Jita has now been completely lagged out for 4 hours so that nobody can enter or exit. Bravo CCP! What a wonderful product you are charging your customers for. And the official CCP response: "we are working with IBM on a super computer", is now after 2 years frankly looking more like an insult than a joke. If you have been "working" (as in putting man hours every day into developing this "super computer", why isn't there some sort of progress report - after two years?? Come one.....! CCP's reputation for disrespect towards it's player base is bad enough as it is(How are you, t20?). Surely there's no need to add outright mocking to the list....!? Just come clean and admit that you are unable to solve anything, and that this super computer is in fact NOT something that any player should expect to see in his or her life time. Just tell it like it is - for a change... Jita isn't the only place where you get cheap stuff from... Have you ever thought about going to a different market hub? Ours, Amarr, Rens... change and adapt (w/e the saying is). But i think your too imcompetent to realise that.. If your still angry then just quit doesn't hurt anyone. PS. Can i haz your stuff? ----------------------------
Doc Fury	Posted - 2008.06.09 19:03:00 - [103] Edited by: Doc Fury on 09/06/2008 19:04:02 Originally by: DubanFP Originally by: Tarminic I'm not positive about this, but I believe that CCP is in the process of rewriting the client in C++.. I don't think they ever directly said they would be changing the programming language. What they did say was that they would need to rewrite the code so that it can run with the new supercomputing options that they've been talking about. So basically they will need to rewrite a lot of the server code to run with the new technology, this is what's taking so long. Also I'll be the first to admit that I don't know much about python, and that server/databases aren't my computing specialty. CCP relies on Python because it is a "crutch" and because their graphics designer's use 3D design tools that can optionally use Python scripting. Almost all professional 3D design and animation packages support Python scripting, and your more experienced 3D designers are usually somewhat comfortable doing basic Python scripting because of this. Content developers can also be trained to perform basic scripting at a minimal expense using custom (python) tools, which CCP has likely invested substantial time and effort into creating. CCP has stated in the past that they do convert parts of their codebase to C++ as needed, what is killing them now is that their code isn't multi-threaded, and their core server/network foundation is over 6 years old. CCP also did not (could not) anticipate the widespread adoption and production of multi-core CPUs by the computer industry, vs. much faster single-core CPUs. It's so safe to play along, little soldiers in a row Falling in and out of love, with something sweet to throw away. I want something good to DIE for...to make it beautiful to live.
Kolwrath Imperial Shipment	Posted - 2008.06.09 19:15:00 - [104] Edited by: Kolwrath on 09/06/2008 19:21:48 Originally by: Beltantis Torrence I can only talk about what I can see (ie, the client side), along with some guesses at how they're running the backend. That disclaimer being said, Python is not a fast language. They're handling window management and object management in Python, which is ridiculously slow. Furthermore on Windows they're using CryptoAPI for encryption, which is pointless considering you can decompile the client if you wanted to get the secret key. Instead of having all that overhead they could just XOR the data against the username or a session token, which would be somewhere around 100x faster than what they're doing. Would be roughly as secure and they can reserve higher levels of encryption for the initial handshake. I also tend to think compression should be left for dial-up modems rather than the default option, as CPU resources are more limited than bandwidth in the general case - both server side and client side. This also avoids some overhead associated with interop between Python and ZLib/CryptoAPI, currently these libs are being marshaled to every time a network frame gets processed. It's not a client side problem. Its a database backend problem. The lag in Jita is caused by the massive amounts of database transactions that occur there. Oh and "roughly as secure" is hillariously bad. Sorry but "roughly" is not a word you can use when dealing with enterprise level applications and thier security. Making tradoffs in security for the sake of performance is just asking for trouble, and well just a plain bad design decision. (Remind me to never, ever, ever, hire you for a programming position) Originally by: Beltantis Torrence <snip> To allow for better caching of market data, they should institute a lag of say 5 minutes between when you sell something at a specified price and it gets listed on the market. This would allow them to cache queries in memory and only have to repopulate those buffers at predetermined intervals. From what I can tell it handles that on demand right now, which means you're probably hitting disk every time you run a query. How would a lag of 5 minutes solve anything? You would end up with huge database race conditions that you would have to deal with. Your just trying to force the data to cache. The market in Jita would get all messed up after this. Traders will no longer have a eye on the "pulse" of the market since everything would be 5 minutes behind. They wont be able to make good market price decisions due to the lag. They would just move to Perimieter and it will all start over. You are failing to see the human aspect of the problem. I would like to reiterate: Jita is a database problem ... not client side. You seem to be focusing on your strengths (python / etc) but you fail to realize that its the DB that is the issue. They have a RAMSAM for a reason ... to maximize the database IO. Even with that ... they still have these lags. I see what you are trying to go for, but your suggestions, IMHO, would at most improve the client applications speed ... but nothing else. The client will still have to wait for data from the server, which in turn needs the information from the database. Originally by: Chaos Space Marines Do you hear the voices, too?!?!
c4 t	Posted - 2008.06.09 19:49:00 - [105] more like "ccp competance." i know i dont have to tell you devs, but dont listen to this ***. you guys should lern that lag will always be on the internet until we use light based processors sometime in the future. or supercon based processors. ____________________________________________________________________ mostly* harmless
Beltantis Torrence	Posted - 2008.06.09 21:01:00 - [106] Originally by: Doc Fury CCP relies on Python because it is a "crutch" and because their graphics designer's use 3D design tools that can optionally use Python scripting. Almost all professional 3D design and animation packages support Python scripting, and your more experienced 3D designers are usually somewhat comfortable doing basic Python scripting because of this. Content developers can also be trained to perform basic scripting at a minimal expense using custom (python) tools, which CCP has likely invested substantial time and effort into creating. Direct3D uses compiled models. The tools used to generate the models and the usage of those models aren't linked. As is they're using a Direct3D wrapper with the compiled models, so this wouldn't change anything. In fact the graphics bit itself wasn't actually a problem as far as I could tell (because Direct3D is doing the heavy lifting), rather the higher level management of the workflow.
Doc Fury	Posted - 2008.06.09 21:06:00 - [107] Edited by: Doc Fury on 09/06/2008 21:06:14 Originally by: Beltantis Torrence Direct3D uses compiled models. The tools used to generate the models and the usage of those models aren't linked. As is they're using a Direct3D wrapper with the compiled models, so this wouldn't change anything. In fact the graphics bit itself wasn't actually a problem as far as I could tell (because Direct3D is doing the heavy lifting), rather the higher level management of the workflow. Cool! Except that what you said has nothing to do with what I said. It's so safe to play along, little soldiers in a row Falling in and out of love, with something sweet to throw away. I want something good to DIE for...to make it beautiful to live.
Xparky Federal Navy Academy	Posted - 2008.06.09 21:11:00 - [108] .
Beltantis Torrence	Posted - 2008.06.09 21:37:00 - [109] Originally by: Kolwrath Edited by: Kolwrath on 09/06/2008 19:21:48 It's not a client side problem. Its a database backend problem. The lag in Jita is caused by the massive amounts of database transactions that occur there. Oh and "roughly as secure" is hillariously bad. Sorry but "roughly" is not a word you can use when dealing with enterprise level applications and thier security. Making tradoffs in security for the sake of performance is just asking for trouble, and well just a plain bad design decision. Maybe I should have dumbed it down more so you would understand what I'm saying. Next time I'll use a color based system. Its a qualitative distinction. If you consider Eve client secure as is, you're wrong. XOR'ing is a weak encryption method, vulnerable to a number of attacks such as plaintext dictionaries. Then again when your client is written in a scripting language then that is also vulnerable to a number of attacks, like in this case just intercepting the encryption key. The question is who are you trying to secure it from and for what purpose? If its just to avoid simple snooping then XOR'ing fixes that problem. If its meant to actually protect the data that's going over the wire then it fails either way. Hence I said "roughly" because its my opinion the security is meant to stop the user from seeing the data rather than an eavesdropper. In either case it doesn't really work as is, so why waste the overhead? The reason why us engineers on a sidenote make everything simple for "business types" in enterprise settings is because business people are too stupid to understand anything beyond "AES gud, DES bad". The reality is always a shade of gray. Originally by: Kolwrath How would a lag of 5 minutes solve anything? You would end up with huge database race conditions that you would have to deal with. Your just trying to force the data to cache. The market in Jita would get all messed up after this. Traders will no longer have a eye on the "pulse" of the market since everything would be 5 minutes behind. They wont be able to make good market price decisions due to the lag. They would just move to Perimieter and it will all start over. You are failing to see the human aspect of the problem. Asynchronous queuing is how you handle bulk operations. On demand doesn't work above a given number of transactions. You're throwing around terms you obviously don't know the meaning of. Hint - there are no race conditions on bulk inserts unless the dependencies change and the way the Eve market works it isn't an issue. Adding a buy order would only have to worry about concurrency if the user ID the order is linked to, station they ordered it from or product it involved were going to change somewhere between when the user input the order and it got committed. None of those are concerns. Obviously being unable to use the market or enter the system is more of a problem then whether or not people can "day trade" from Perimeter. Originally by: Kolwrath I would like to reiterate: Jita is a database problem ... not client side. You seem to be focusing on your strengths (python / etc) but you fail to realize that its the DB that is the issue. They have a RAMSAM for a reason ... to maximize the database IO. Even with that ... they still have these lags. I see what you are trying to go for, but your suggestions, IMHO, would at most improve the client applications speed ... but nothing else. The client will still have to wait for data from the server, which in turn needs the information from the database. Client side processing is easier to comment on because its readily viewable. Like I said those are merely examples of some of the things they could be doing to optimize.
Beltantis Torrence	Posted - 2008.06.09 21:54:00 - [110] Originally by: Doc Fury Edited by: Doc Fury on 09/06/2008 21:06:14 Originally by: Beltantis Torrence Direct3D uses compiled models. The tools used to generate the models and the usage of those models aren't linked. As is they're using a Direct3D wrapper with the compiled models, so this wouldn't change anything. In fact the graphics bit itself wasn't actually a problem as far as I could tell (because Direct3D is doing the heavy lifting), rather the higher level management of the workflow. Cool! Except that what you said has nothing to do with what I said. Sorry, I thought you were saying having the client not run in Python would have some adverse impact on their ability to use Python scripts to generate models. Rereading it I get what you were saying, though I doubt its the same engineers doing both artwork and client-side programming.
Kolwrath Imperial Shipment	Posted - 2008.06.09 22:01:00 - [111] Edited by: Kolwrath on 09/06/2008 22:05:17 Originally by: Beltantis Torrence Maybe I should have dumbed it down more so you would understand what I'm saying. Next time I'll use a color based system. Edited to be less insulting. Wow you sure are a jerk. Shesh. if I missed your point, well I missed your point. You don't have to be a complete ass about it. Originally by: Chaos Space Marines Do you hear the voices, too?!?!
Misanth Electro Fuels	Posted - 2008.06.09 22:59:00 - [112] Originally by: Helsir Qyrdun Not to mention we're complete strangers to one another. ..and boy what a cute stranger you are. wink
Sinnae Takeda	Posted - 2008.06.09 23:07:00 - [113] when the service you pay for has real problems you do not attack your fellow customers who are complaining, you complain with them. it is the better approach for you as a customer. i won't insult your intelligence further by explaining why...
Pan Crastus	Posted - 2008.06.09 23:10:00 - [114] Originally by: Tarminic This may be hard to understand without knowing a bit about databases, [... I know everything about RDBMs, thanks - speculative bull**** deleted ... ] 1. the MS SQL server isn't the current Jita bottleneck, if you don't know, pay attention 2. I could post a long explanation why your assumptions are naive and pointless, but the short answer is: optimizing this, spreading the DB load, minimizing the amount of data that needs to be moved around with UI improvements (= more powerful search = fewer rows returned), caching results - that's no problem at all. The main point is that this scales well while Jita doesn't. Making simple read-only database queries fast and painless is one of the easiest things nowdays and CCP can do it. 3. you don't solve one bottleneck by spreading speculative FUD about what might happen if you choose a solution, that's unconstructive and stupid. But I'm not delusional and know that CCP has no manpower/brainpower to fix their sol node bottlenecks, why would they try to come up with a better design? It's simply not a priority and they have enough fanbois who post crap like "if it worked for 500 people then 1000 would come!", seemingly arguing away every need for improvements. So, I posted a solution, keep moaning about how Jita is the holy grail of everything and cannot be fixed even though CCP are the gods of programming etc. lol ;-) EVE Online: a cold, cruel world where (RL-)rich people replace their losses with GTCs sold to poor students who need to farm ISK to afford their play time ...
Faekurias Black Legion Command	Posted - 2008.06.10 00:08:00 - [115] I claim stuff! Supreme Legion Commander of the Black Legion Fleet We're recruiting \o/ Hitmeup ingame.
Lumen Atra GoonFleet GoonSwarm	Posted - 2008.06.10 00:11:00 - [116] Originally by: Montmorency Heres a progress report for you CCP are running a MASS PLAYER ONE SERVER GAME THERE IS GUARANTEED TO BE LAG DON'T GO INTO JITA AT PRIME TIME DIP SHIP.... YOU KNOW ITS GOING TO BE BAD.... P.S. NOTICE I POSTED WITH MY MAIN!!! Gauranteed? No. One server? No. - You should figure out the concepts of "game server" (tranquility) and "actual, physical server machines" (many machines running a game server). Jita at prime time? Newbies aren't going to know jack about any place in Eve. Your main? Who gives a flying fish a trout?
Doc Fury	Posted - 2008.06.10 00:46:00 - [117] Originally by: Beltantis Torrence Originally by: Doc Fury Edited by: Doc Fury on 09/06/2008 21:06:14 Originally by: Beltantis Torrence Direct3D uses compiled models. The tools used to generate the models and the usage of those models aren't linked. As is they're using a Direct3D wrapper with the compiled models, so this wouldn't change anything. In fact the graphics bit itself wasn't actually a problem as far as I could tell (because Direct3D is doing the heavy lifting), rather the higher level management of the workflow. Cool! Except that what you said has nothing to do with what I said. Sorry, I thought you were saying having the client not run in Python would have some adverse impact on their ability to use Python scripts to generate models. Rereading it I get what you were saying, though I doubt its the same engineers doing both artwork and client-side programming. It's definitely not the same "engineers" that write application code who are also doing art and/or content development. Using Python just allows all these non-engineers the ability to produce product more rapidly. This is for better or worse, depending on how you analyze it, and what your end-game is. (sorry for the pun) It's so safe to play along, little soldiers in a row Falling in and out of love, with something sweet to throw away. I want something good to DIE for...to make it beautiful to live.
Fifth Horseman	Posted - 2008.06.11 09:44:00 - [118] The one system that never lags is the one that takes your money. Curious. --- Did I upset the wrong alliance with this post? Please don't ban me when it's your shift to control the Mitnal account.
Killer Kelly Allied Tactical Unit Scalar Federation	Posted - 2008.06.11 09:56:00 - [119] Shut the **** up. Kindly. ___________ I Get Money in the Scalar Federation
Roshan longshot Ordos Humanitas Brutally Clever Empire	Posted - 2008.06.11 10:39:00 - [120] You know if you dont like Jita lag...then do what everyone else with half a brain cell has done...LEAVE, multiple gates, little waiting, entertainment not providided, and of course all flights out of Jita are no smoking. Damn you CCP! Why did you have to make such a good game?? Yes you drew me back AGAIN! Oh well wheres the Omber?

Pages: 1 2 3 [4] 5 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.