"Dominion" via Ga'len

The Planets- Jupiter – Gustav Holst

06.03.cy112 Lonetrek, Okunda Constellation, Kiskoken

As I journey through each system in New Eden, I’ve wondered if there’s a single system that contains all of the planetary types. I’ve not kept up with the types as I’ve traveled, so I’m actually not sure if I’ve encountered such a system yet. I think there has been one or two that have come close. This last week, however, as I was taking my pictures in the Kiskoken system, I realized that each planet type was represented with the exception of a terrestial world. That’s when I wondered if there is a system that contains all the types out there some where and have I already encountered it not realizing. I was so taken in by the beauty of the planets, I never really thought about it thus far.

This weeks images are all from Kiskoken. It has all of the planets types except terrestial. I’ll try and keep my eyes open for one that contains all, but if you’ve been through one, let me know.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

.

Since November 25th 2009, a few days before the deployment of Dominion, we have experienced frequent unscheduled reboots of Tranquility. Almost all of those were due to a bug in the networking subsystem that causes the SQL Server to fail over.

Why, oh, why and what are you doing about it?

As soon as the first failover happened, we, per our policy, opened up a support case with the vendor regarding the incident, since our logs, surprisingly, showed nothing. Their response was that the problem had been caused by a race condition in the system.

We have worked closely with the vendor's support and development teams in an attempt to isolate the bug, collected vast amounts of diagnostic data and implemented changes that were considered potential solutions by the vendor. We believe we've found a workaround that makes it unlikely that the bug is triggered, but does not 100% prevent it. This has yet to be confirmed however.

As one can imagine it is difficult to diagnose a running, high performance production environment like ours without causing lag or other performance or reliability problems. The vendor has been working diligently to attempt to reproduce this issue in their lab, although collecting diagnostic data from similar systems presents a major challenge - doing so without negatively impacting performance levels for customers.

We do have programmers and virtual world system administrators working on putting together a test script to run on the database server we use for Singularity and Multiplicity, and if we are able to reproduce the issue there, we can supply our vendor with code that reproduces the problem in their lab.

I, personally, have been spending quite a large part of my work hours the last 3 months communicating directly with the vendor, collecting diagnostics data, setting up collection tools and working on things related to solving the SQL Server issues.

In short, we are using all the resources at our disposal to resolve this issue. It is a high priority issue for all parties involved as it affects not only our system and customers, but can affect equally massive systems and user bases using similar network and database solutions.

 

What have we done already? What do we know?

We know that problem lies in the TCP stack and likely has something to do with handling of closed or closing sockets. Our vendor has asked us to implement a few potential fixes or workarounds. We've adjusted various networking features and upgraded our SQL Server engine with a version that has a workaround for issues of this nature. The database handler in the EVE application server uses session pooling and we've experimented with changing various settings there.  Turning off recycling of idle sessions seems promising as a workaround that makes triggering the bug less likely.

We still are working toward a fix, as I said before, and we seem to be able to make the failovers happen less frequently with the latest workaround. Expect to hear more in the near future on our progress with this issue.

 

- CCP Valar

 

 

 

Well then, first blog, so where to start? ...Oh yes, we're changing the Scorpion:

Trinity was an awesome expansion, which brought with it what was then called Premium content - the shiny new graphics with updated ship models and textures. Since then support for the classic client has ended and the "Premium" graphics has become the standard, with reduced settings for older graphics cards that can't handle all the shiny goodness.

Most of the art in EVE weathered the change over to the improved graphics quite well, but there are those pieces that we were never quite happy with. The new textures were also less forgiving on blemishes and flaws that previously looked like an interesting design element if left up to the imagination, now became a glaring eyesore begging to be fixed. Well, to artists anyway.

This was the case with the renovated Scorpion. What worked before, didn't really work anymore, so the art director felt that he'd want to see the ship redesigned, in the new style for Caldari introduced by the Tech 3 ships during Apocrypha. He also felt that the current design lacked the feeling of weight that a battleship needed, that it felt rather flimsy. So the goal was to make a beefier, more aggressive-looking
Scorpion. And a chance to redesign and possibly improve on one of the most iconic ships in the EVE universe was not something I was going to pass up.

Since improvements are the order of the day, and this brings me to the title of this blog, one of my other tasks during the first Sprint of our Summer 2010 release was research into the way we pack our textures into the combined dds file types used in the client. For anyone not interested in graphics, this will likely be dry reading, but you might find it informative if you have no idea how game graphics work.

The tl:dr version though: Made stuff look better.
Pics or it didn't happen: See below.

During Apocrypha we introduced new shaders on the Tech 3 ships that allowed us to manipulate the color of the reflections of a given material. These shaders were also of a triple-material variety, which we hadn't done before. The triple-shader type required an additional mask map to denote where the 3^rd material would show up on a ship, and the addition of this new map meant that the current packing convention was not going to be very efficient. Below you will find details listing the gains of changing from the current system, called the NGS file system, to the PGS file system. It does get rather technical, so there are pictures to help :).

The major benefit to the triple-shaders is that we can use a single shader to denote material types on a model, rather than cutting up the geometry into different areas with multiple simpler shader types. Having geometry defining area breaks is not as precise as using a texture to do it, it doesn't look as good was with a texture as the definition line is VERY clear and often doesn't match the texture being placed on top of it , and of course the Art Department likes to control as much as we can. :)

The second big benefit of the triple-shaders is that we can more easily create factional variants of assets.
Now the problem with the NGS system is that it doesn't play as well as we would like with the triple-shaders with regards to number of packed texture files. With the addition of the sub-mask, we have run out of channels to pack it into (as current double and single shaders only use 2 packed textures - a Diffuse, and a NGS texture), thus a new _P (paint) texture map was created to store the extra data.

To make factional variants of assets we would like to change the "paint-job" in some instances, and not just change the colors in the shader settings(Which often leads to a "washed"-look that the art director isn't very fond of. The way the NGS textures are packed would mean we would have to generate a new NGS and P texture of every factional variant. If we repack textures in the PGS way, we would only need to generate a new P texture for every factional variant, thus reducing client size, as we'll be reducing the number of textures needed. You'll notice that the different files and their sizes change, but in the end we end up with two 1024x1024 textures and one 512x512 texture, so the PGS system should be very similar in per-file size. As an example, the texture sizes on the example ship below are:

NGS - 3 files (3 MB)
PGS - 3 files (2.83 MB)

The third benefit, and the cherry-on-top, is that the PGS system also gives us an improvement in quality of the textures over that of the NGS system. Below you will find screenshots of the new scorpion using both NGS and the PGS textures and you can see the results yourself.

And yes, this does mean that we will have to update every ship in the game, but it is a process that will be done over multiple expansions, starting with the Summer 2010 expansion.

And since this is an Art blog, I'll leave you with a shot of the Scorpion dressed in the various Caldari factional colors. Not all of these variations will be included in the Summer 2010 expansion, as there is still much work to be done regarding the different factions of the four major races in EVE. But previews are always nice.  :)

For those interested, the factions colors are:
Front row (from left to right): Civilian, Navy Issue, Rattlesnake (Guristas), Ishukone Fleet
Second Row: Widow (Kaalakiota), LaiDai Protection Service, Mordus Legion , NOH Internal Security
Back Row: State Issue, Wiyrkomi Peace Corps


- Salvo

 

 

I caved into pressure, here is the Friday post.

I twittered last night that I was not making a Friday post as I was very frustrated with the game breaking bugs dealing with sov.  I said I did not want to make the post because I really did not want to rant.  I also received many emails, both in and out of game, for a summary of the situation.  So, I broke down and wrote the post.  I am still frustrated and I will try not to rant, just convey the situation and then get on with the normal Friday post stuff.

There are a few blogs that have discussed these issues with the two systems in question.  Those systems being  Z-REF3 and 3D-CQU, where bugs with the sov mechanic have broken game play:

• To Me. To You. To Me. To You.
• Broken Record

The following thread on the EVE forums sums up the issue:

http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1270539

In short, there are two systems, Z-REF3 and 3D-CQU, where sov can not be obtained.  The TCU goes online, you are awarded sov and then 20 to 48 minutes later the TCU goes offline and you loose sov.  Bringing a TCU online again and 8 hours later, the same issue.  U’K and AM have been dealing with this bug for literally days now with TCU’s going online every 8 hours and dropping sov less than an hour after that point.

Petitions have been submitted and CCP’s response to date has been less than stellar. I am not going into the responses, I don’t want to rant.  CCP is really dropping the ball on this one.  You would think that Ushra’Khan may be just ranting here, playing the COAD games, but that’s not the case.  Our enemies are supporting us on EVE Forums posts concerning this issue.

So, for all those people who were on the fence when Goonswarm made their claims that Dominion and it’s new sov mechanic was still in the Alpha level of development and not worthy of even being called a “Beta Test”, you should take note of this issue.

For all of us who saw this same issue on the test server prior to Dominion going live, well,  it’s very familiar and at the same time disappointing.  You would think that code from the test server would have been resolved before being rolled into production.  I have to say at this point and I can’t believe I am about to write these words, I agree with the folks in Goonswarm concerning the new sov mechanic.  Nullsec warfare is broken to the point that it’s simply not playable.

Please understand me here, I don’t agree with the Goonswarm position that the new sov mechanics are bad.   I think the new sov mechanic is a great change for the game and I want to see the new sov mechanics be used in game.  My issue is not with the mechanics themselves, my issue is that the testing on the test server showed obvious game breaking bugs with the new sov mechanics that needed further testing and tweaking.  These same issues were obviously not resolved when Dominion was brought onto Tranquility, hence the current issues.

I hope this was not too much of a rant.  Ahem, now that is out of the way, on to more items of note:

• Bugs notwithstanding, the ProviWar feed continues to grow with more material.
• Rooks and Kings had a great kill in the past few weeks of a Goonswarm freighter with a 155 billion isk price tag.
• Someone in my corp shared a funny TeamSpeak recording of a EVE pilot making a phone sex call.  It’s made the rounds, but I had to share it again.  WARNING, NSFW.  Enjoy the lols, but do take note that the lovely lady made one heck of an effort to keep the call on track.
• George Allen Miller wrote an interesting article, Star Trek Online Versus Eve Online revisited, comparing Star Trek Online to EVE Online.  He states that “…but STO was doomed from the start…”.  Go read the entire article, it’s a good one.
• Shameless plug for the folks over at EVE Development Network.  They have been working very hard on EDK 3.0, the newest version of their very popular killboard web application.  I recently upgraded to their new version and let me say, it’s a dream.  The built in support for a single pilot killboard was a major feature I was looking forward to using.  I’ve been using their application for years and I have to say, they have outdone themselves.  Good job guys and thank you for all the hard work!
• As always, update work for the blogs listed on The EVE Online Portal and the OPML download continues.  Head over and see who we added this week!

See you out there!

Share and Enjoy:

Tags: 3D-CQU, AM, CCP, Dominion, EDK 3.0, EVE Development Network, EVE Forums, George Allen Miller, Goonswarm, killboard, Petitions, ProviWar, sovereignty, Star Trek Online, Timezone, U'K, Z-REF3

Related posts

• Dominion is another SWG:NGE….unless it doesn’t go live (10)
• It’s been busy (7)
• Finally, another week is done (0)
• “And the sun also sets…” (8)
• I hope you like flying a freighter, your time has come! (12)

The war in Providence is currently raging around the systems of 3D-CQU and Z-RFE3. Last night two Ushra’Khan territorial claim units were successfully onlined. Unfortunately a flaw in the DED systems resulted in them coming offline again within a few hours and CVA destroyed them and planted their own. It looks like Aegis Militia were able to online their own TCUs only for them to drop again after an hour. Something is seriously wrong in these systems and I hope CCP looks into it. Until then there is going to be a lot more fighting…

No related posts.

  CCP Tanis just posted a dev blog concerning the ever increasing efforts to combat lag in New Eden.  It looks like they have quite a bit of new gear in the toolkit which I hope makes their jobs a little easier; although I can't imagine all that data is fun to look at.  One of the really intersting bits is the upgraded test server complete with new and re-written debugging code which should make for improved testing all around.

  I also found it very interesting that the dev team plans to share more information about the testing results.

Information and transparency

One thing that we feel has been a shortcoming in our previous mass-testing exercises thus far is the lack of reports and information being relayed to you, the players of EVE. To remedy this, we will begin publishing the results of each test. Over time, we will add to what is being reported and, hopefully, even get a sub-site on eveonline.com to host the results from all these tests so that anyone can view results from recent tests, as well as historical results.

  While I will probably only glance at the reports every so often I have to say that any increase in information sharing is a welcomed improvement.  One of the only major complaints I have with the CCP team is the occasional lack of information about what is going on inside their world.  With that said, I still feel that CCP is probably one of the best communicators in the game industry and that they put a lot of effort into sharing information with us players.  To me, more is always better.

  The testing team still needs our involvement if we want to improve EvE but they will be making it a little easier on us by moving testing closer to prime time whenever possible.  They are also inviting Alliances to join up together whichshould help improve the numbers.  If you would like to stay up to date on planned testing the dev team has created a new in-game mailing list "Mass Testing Info", so don't forget to join up.
 
 
Dev Blog: http://www.eveonline.com/devblog.asp?a=blog&bid=728
Also, don't forget to join "Mass Testing Info" (mailing list) and hop on the test server when you can.


 
Getting on the test server
 Evolopedia guide to connecting to Singularity Start here, this contains everything you need to know about getting on to singularity.

Once you connect to the test server you will need to be in the test server chat channel "Singularity"

If you have trouble there are some additional rescources on the forum, start here: Singularity Post (some of this may be a bit out of date)

Wow, this has turned into quite a long blog, but it's chock full of much info-goodness which hopefully addresses many of the questions and concerns people have had about public testing and how we approach large-scale performance and feature testing for EVE.

What's in our anti-lag arsenal?

As EVE grows, more features are added, more players are online at once, and the whole system becomes more complex we find that our ability to weed out sources of lag becomes increasingly difficult. Throughout EVE's development we've used various methods to identify and fix sources of lag; server performance monitoring, special task-forces to ‘seek and destroy' lag, monitoring forums and petitions, public test servers, and intensive regression tests of all new code, for example. Though these are great tools, we don't feel that it's enough. Over the years, while creating all of our expansions and the new features and changes that come with them, it became apparent that we had a problem: We had no good way to simulate high-load situations such as fleet fights, factional warfare, Jita, etc. This is a particularly difficult situation for us. In any high-load situation there are always a very wide range of actions being performed simultaneously, with many different hardware configurations on the client machines, and many small factors quickly add up. But these factors are all relatively unpredictable and almost random in practice.

Consider Jita. Think of how many people are there; now think of all the different market transactions, combat, chatting, industry, and other activities that are going on simultaneously in that system - you can see that testing this scenario is not as simple as "load up 1000 clients and let them run." We needed a way to get as many different transactions and machine configurations as possible in order to confidently say that we've gotten a valid test for high-load performance.

Over a year ago, in order to address this issue, we began exploring several different options. We looked at everything, from specially built load-testing clients (bots), to hiring many more testers, to community-supported testing, to developing specialized test suites and scripts, and everything in between. After some prototyping, tests, and wracking our brains, we finally came up with a multi-prong approach that includes community-supported testing (i.e. Mass-Testing - more on this shortly), massive test-server upgrades and changes,  load-test clients (still in the early stages of development), special debugging code, and more data logging than you can shake a stick at.

Mass-Testing

The cornerstone of our approach is an initiative, dubbed "Mass-Testing." Simply put, we figured that the best way to "simulate hundreds of players all doing many different actions at the same time" was to, well, get a bunch of real players together and run through proper test scenarios. This is such a vital thing because it is the only way we can accurately gauge how the new code behaves under such extreme conditions as fleet fights with several hundred pilots. This is because of various factors which only become apparent in such highly loaded situation, such as diminishing returns, and code scalability.

At its core, Mass-Testing is a very basic framework which allows us to invite hundreds, or even thousands, of players onto the test server to hammer away at various things. This framework provides us with an excellent venue to present new features or changes to people and not only see how well it performs, but also to get critical feedback about the new changes directly from the players who've taken the time to try them out on the test servers. By running these events regularly, we also gain the ability to track empirically the performance of the client, server, and network layer over time. This all comes together to give us a much clearer picture of where we stand now, where we came from, and where we should focus our efforts moving into the future.

Can't we do this another way, like testing live on TQ?

Unfortunately, testing is never as straight-forward as it seems on the surface. Even in fairly simple programs, the number of possible combinations of inputs, raw data, transactions, and hardware can add up quickly to the point where ‘testing everything' would literally take several human lifetimes. Because EVE is constantly being updated and changed, this adds another level of complexity to the issue overall. How we choose to address this for EVE is by prioritizing areas that need more attention; based on previous history, the complexity of the system or the changes made to it, risk to the cluster/game, player feedback, and several other factors.

When dealing with testing for EVE, we must always keep one thought in the back of our heads: "how will this affect the game, the cluster, and the players?" Sure, we could test directly on TQ, add all sorts of debugging code, join in every fleet fight, etc, but at the end of the day, TQ is for players, not for testing. Adding debugging code would kill the server's performance and make laggy battles much worse. Sending testers into fleet fights could very well lead to cries of favoritism or ‘DEVH4x'. Neither of those results would be desired. We in QA feel, very strongly, that anything that would negatively impact the performance of the live servers or people's enjoyment of EVE should be avoided like the plague.

What good will all of this really do for EVE?

We have been running a pilot of this program for roughly the last year, and it's certainly done its job in helping us identify certain performance issues on the server, client, database backend, and also in our networking layers. This program also provides us with a direct line of communication between CCP and the EVE player base to find how well the expansions perform for you, and also to get some critical feedback about new features and changes in those expansions.  This feedback has helped developers tweak and tune their changes in an attempt to make sure that we're providing you with a quality user experience. Some examples of changes that have come about as a result of your feedback are:

• Overview tweaks, such as the ability to toggle all brackets on/off easily
• Improvements to fleet-finder
• Fixes to improve lag in factional warfare
• Cleaning up POS code
• Fixes for EVE Voice

In addition to the feedback we've been able to gather, we've also isolated and killed several problems well before they ever made it to TQ. Some examples of these resolved are:

• Server-side memory leaks
• Runaway DB procs
• Client FPS instabilities
• Client memory leaks
• Services being called too often (kills server and client performance)

I am the great and powerful OZ!

Just as it was with Dorothy and the great Oz; an unfortunate fact about Mass-Testing is that most of what's being done is all behind the scenes, which can lead to many folks getting the wrong impression about what's actually going on. But unlike with the great Oz, there is a lot of actual work going on behind the scenes here. We have staff from our Software, Quality Assurance, Operations, and Game Design departments, plus our awesome Bug Hunters, all working in concert to collect data and feedback, analyze the information, and fix what's wrong. I'll give you a brief summary of what we look at during these tests:

DB traces

We collect full traces from our databases. This information tells us what transactions are being made, what procedures are being called and how often, and how long they take to execute. In addition, we also track overall database's load, health, and performance.

Server-side metrics

We collect detailed metrics on the servers' performance, especially detailed statistics on CPU and memory usage for discrete layers of the server code.  In addition, we collect data from every piece of the game code during execution to see how well they're playing together, where bottlenecks occur, and if there are any runaway tasklets in our code.

Client-side metrics

We also collect metrics on several developer clients during these tests that collect data on the client's CPU and memory usage as well as things like FPS, response time, desync, etc. This data allows us to pinpoint pieces of the client code that need to be fixed or streamlined in order to improve the client's performance.

Network-layer metrics

In a game like EVE, which use a single server with many thousands of simultaneous users, network traffic, bandwidth, routing, and load-balancing are very important. This is why we also gather full network traces for connected clients and collect data on how well the load balancers are coping with the new expansions.

All of this data is collected and kept from one test to the next so that we can compare, analyze and find performance trends, which in turn helps us identify those areas we need to spend more time cleaning up in order to ensure that EVE runs as smoothly as possible.

Growing up a bit

Over the past year, this program has really just been in its infancy, and we're proud of our baby, but it's time for it to become a toddler and start walking on its own. We need this program to get bigger, better, and provide more value to EVE as a whole. In that spirit, we are moving into the next phase of the Mass-Testing program, where we will be making improvements across the board, but especially in scheduling, backend support, and, later, reporting and information.

Calling all alliances!

In the past, we've had problems getting enough players to show up for these tests, and we will be addressing this issue directly. Ideally, these tests should have at least 400 participants, up to 1500 pilots per test; historically, we've managed to get around 100-200 pilots per test. In an effort to improve numbers, we will do three things. First, we will try to hold these tests on the weekends to avoid work/school/real life conflicts. Second, we have setup a moderated, public mailing list, "Mass Testing Info", which anyone can join, which we will use to send out dates and information about testing. Finally, we will also invite all alliance leaders to bring their members onto the test servers to participate in these tests. The idea being that, by working with alliance leaders, we can hopefully achieve the numbers we're looking for in these tests.

How will this work?

Before each test, we will put up a sign-up thread on the forums with details and an open invitation to any alliance with more than 150 members, as well as sending an in-game EVE-mail to the "Mass Testing Info" mailing list and also direct mails to the leaders of all alliances with 500 members or more. Alliance leaders can then sign-up and indicate roughly how many pilots they are confident that they can bring; we will take the first 1800 pilots, on a first-post, first-serve basis. If we don't get enough pilots signing up, we will cancel that test run.

• Important caveats
• Players not in alliances can still join in
  • You just need to show up at the correct time and follow directions
• We will accept all alliances who sign up, until we reach a maximum of 1800 pilots
• Do not sign up if you're not confident you can bring people!

 

First of a new breed

You folks have been saying that you want test events that are held at more opportune times for you, and we've listened! These tests do indeed require as many players as we can get, but holding events on weekends or too late into the evenings, on a regular basis, is not as easy to coordinate as one might think. Even game developers and testers have real lives, families, and friends that they enjoy spending time with too. But, we aren't afraid of change, so we've worked out staffing and, from now and into the future, we will be holding test events on weekends, close to peak hours. There will be exceptions to this rule, if critical issues come up that require special testing, but we hope that this new schedule makes participating in these events much easier for you all.

The first event in this new series will be held on Saturday, February 20 at 20:00 GMT

This first test will be a return to our standard "fleet fight and POS siege" format, with some tweaks and slight changes, look for an official test announcement thread in the General Discussion forums in the coming days. We will post full details and goals for the test there.

Information and transparency

One thing that we feel has been a shortcoming in our previous mass-testing exercises thus far is the lack of reports and information being relayed to you, the players of EVE. To remedy this, we will begin publishing the results of each test. Over time, we will add to what is being reported and, hopefully, even get a sub-site on eveonline.com to host the results from all these tests so that anyone can view results from recent tests, as well as historical results.

And I'm spent...

Testing for EVE is an ever-evolving process, one which we strive to constantly improve. One important measure of quality, at least for us, is determining how good of a gaming experience we have delivered to the players of EVE.  Though this can be difficult to quantify, or even be a bitter pill to swallow, we still find your input and feedback to be vital to making EVE better.

To that end, I'd like to invite you all to give us your input about the overall quality and performance of EVE. Tell us what areas of EVE you think could do the most good from performance tweaks, what new things you think we could add to give you better control over your user experience, what changes or additions we have made that helped you, etc.

Mass-testing is an ongoing process and is intimately tied into the community of EVE; let's use this as another way to improve EVE together.

 

 

I got a lot of really interesting feedback and conversation when I suggested on Twitter that Dominion has experienced wild success. We’ve seen major shake-ups, lots of fights, and an evolving sovereignty map. Okay, I’ll admit it hasn’t seen unalloyed success, but the problems we’ve seen are natural in system performance tuning.

Essentially, when you want to improve the performance of a system, you find the major bottleneck and remove it. This only means that the system performance improves up to the next bottleneck. (Note here that the actual method of bottlenecks will vary, so that a given problem could actually crash the system rather than slow it down.) You keep iterating through this process until the effort needed for the next iteration is larger than what you’ll gain from the performance increase. That is, when you reach the point of diminishing returns in cost and benefit, you stop.

Prior to Dominion, the bottlenecks largely came from design. POS spam, area-of-effect doomsday weapons, relative ease of maintaining Sov 4 (and thus cynojammers) everywhere, all that jazz. Once that went away, we started seeing even more massive fleet fights and all the shakeups. Plus, some alliances either couldn’t afford the sov bills or couldn’t manage their wallets appropriately. As far as I’m concerned, that amounts to the inability to properly direct your alliance.

After that, though, we found out that node capacity is the next bottleneck. While CCP does deserve some criticism for their initial handling of the problem (right after I commended them for riding the Cluetrain, sigh), they’ve finally made substantial improvements so that these fights can actually occur. They still need to do more, of course, but even once they’ve done that, we’ll just run into the next bottleneck. Unfortunately — actually, not — such is our voracious love for this world that fights and struggles will just expand to fill available capacity up to the next bottleneck.

But we’ll have lots of fun in the meantime.

Dominion has succeeded originally appeared on Ecliptic Rift on 2010-02-08.

Share/Save

Related posts:

1. Dominion: What I want to see
2. Post-Dominion Sovereignty: Small alliance options
3. Hidden Dominion screenshot

  CCP Atlas just posted an interesting DevBlog concerning the degradation in fleet fight lag following Dominion.  The good news is that you aren't all crazy and the CCP team does know that Dominion has broken something in the hamster cage.  The bad news, at least in my opinion, is that the primary focus seems to be on keeping the node up and running during the fight.  While the Devs are working on both issues it appears they are more concerned with node stability than directly confronting lag.  I believe that both are serious issues but with node stability affecting all parties eqaully and lag often giving the upper hand to the first party to land in a system I feel that it should be the primary focus.  In any event; I am glad that the complete and utter pounding we took in D-GTMI gave the Devs so much data to analyze, considering that the lag so heavily affected that fight.

  On a related note CCP Atlas did share some tips for operating in high-lag environments. The major point he stresses is PATIENCE which is very important when your client is responding slowly.  Beyond that the guys in Fatal Ascension have been sharing their tips since the D-G fight and I thought I would post some of the tips on preemptively combatting lag that my CEO shared here:

The Client

  Can't See Can't Fight

  It is absolutely imperative you setup your client properly before a capital battle. You may be using a NASA supercomputer in some basement in a government complex in Florida, but that still does not mean you are going to have the bandwidth to function in a capital engagement with hundreds and hundreds of ships on the grid at one time.

• Turn off ALL effects.
• Turn down ALL graphics.
• Zoom out!
• Close unnecessary channels.
• Do NOT play in windowed mode.

The Overview
 Holy Brackets Batman

  You can easily find yourself lagged out for thirty seconds if you so much as flip over to a new tab in your overview that has all brackets showing in space. In addition to that, without a proper overview setup, you'll play hell even finding the primary target regardless of whether it has been broadcast or not. 

• Turn off ALL brackets on ALL tabs.
• ONLY reds and neutrals on your primary tab.
• Create the following overview settings:

•  Planets, Stations, Sun, Control Towers, No Ships
•  Only carriers
•  Only dreadnoughts
•  Only battleships
•  Only interdictors and heavy interdictors
•  Only super capitals

 ~Mendolus (AU-F CEO)

Edit: Manasi chipped in a few good ones which I can't believe I overlooked:

1) remove the timer animations from the HUD


2) ungroup your guns

Aside from turning off auto repeat the next most important thing to remember is to ungroup those guns.