For the past few weeks the community team has been working on a forum revamp, including forum mergers, additions and more. We have also completely overhauled the forum descriptions to be more explanatory and helpful for finding the right section. We hope this will lead to easier communication and less confusion of where to post your questions, ideas, or LOLcat pictures.

Some Highlights

One of the most notable changes is the addition of the Warfare and Tactics forum for PVP discussion, including Factional Warfare. With the addition of this area, members of Factional Warfare NPC corporations will no longer be permitted to post in the Corporations & Alliance Discussion forum.

The Science & Industry and Missions & Complexes sections have always held a prime location near the top of the page; trade is an equally important aspect of EVE and we feel it’s time to give the Market Discussions area a boost. These three sub-forums, along with several other sub-forums dealing with gameplay, have been moved to the new EVE Gameplay Center category near the top of the page. We hope this will make it easier to find specialized conversations on gameplay topics instead of just posting in General.

The Trades, trades and more trades and EVE Localization Development and Discussion forums have always been a little skinny; as such, we’ve merged these areas into the larger Want Ads and Known Issues & Workarounds to create Want Ads & Trades and Issues, Workarounds & Localization. This will slim the page size down a bit, meaning less scrolling while browsing the forums. The Events section is also being rolled into the Player Gatherings and Events section, though no name change was necessary.

And finally, several of our forums make their way to the forum graveyard. All readers please take a moment of silence for EveTV and the PvP Championships, Corporations and Alliances Summit, Windows, and EVE Technology Lab. Again, this means less scrolling through the forum area.

A full list of changes is included below. Expect these changes to hit the forums in a couple of weeks!

EVE Information Center

• EVE Information Portal
  All the latest news, announcements and archives from the EVE Online development team. This forum is community reply only; players may not create new threads.

EVE Gameplay Center

• Missions & Complexes
  From Missions to COSMOS sites, exploration and complexes, this forum has all you need to get a head start in PvE.
• Warfare & Tactics
  The home for PVP in EVE: Factional Warfare, 0.0 campaigns, low sec skirmishes and empire wars.
• Science & Industry
  Starbases, outposts, stations, invention, manufacturing and mining – it’s all in a day’s work for EVE industrialists.
• Ships & Modules
  Share your thoughts on EVE’s ships, modules and your favorite fittings.
• Crime & Punishment
  Warn others of the latest scam, hire a mercenary to seek revenge or brag about your kills. This is the place to discuss the criminal elements of EVE.
• Market Discussions
  Share your tips for trade and commerce in EVE: playing the market, utilizing contracts, and trading stocks.
• Skill Discussions
  Discuss skills and training plans for your EVE character.
• Events & Gatherings
  In or out of the game, use this forum to plan events, gatherings, LAN parties, or other social events.

EVE Communication Center

• EVE New Citizens Q&A
  New to EVE? Use this forum to ask, or answer, questions about the game.
• EVE General Discussions
  General discussion about EVE Online.
• EVE Fiction
  There’s a rich history behind New Eden, and it’s still in the making – visit this forum to discuss the world of EVE.
• Intergalactic Summit
  An in-character, role-playing center for the capsuleers of New Eden. Forge alliances and make friends, resolve disputes or declare hostilities.
• Out of Pod Experience
  Have a funny video to share? Need a name for your new cat? This is the place to discuss topics not related to EVE.
• My EVE
  Share your EVE videos, guides, resources, tools, songs, jokes and more!

EVE Corporations, Alliances and Organizations Center

• Alliance and Corporation Recruitment Center
  Use this forum to advertise job opportunities or find a corporation or alliance to join.
• Corporations, Alliance and Organization Discussions
  From political conflicts to battle reports, news, and corporation press releases – this is the in-character political center for all things corporate.

Council of Stellar Management

• Assembly Hall
  A platform for players to bring topics to the attention of the Council of Stellar Management.
• Jita Park Speakers Corner
  A less formal venue to discuss or debate whatever you wish regarding the Council of Stellar Management.

EVE Technology and Research Center

• Features and Ideas Discussion
  Get feedback on your game-related ideas and suggestions from our developers and the rest of the community.
• Game Development Forum
  Feedback and comments about testing on Singularity.
• Issues, Workarounds & Localization
  Discuss known issues, solutions and our ongoing localization efforts .
• Macintosh
  This forum is for EVE on the Mac, including tweaks, performance and bugs.
• Linux
  This forum is about EVE on Lunix, including tweaks, performance and bugs.
• EVE Forum Experiments
  A playground where you can test your signature and/or play with other forum features.

EVE Marketplace

• Timecode Bazaar
  Advertise or buy game time codes. Make sure to set up your trade before your account expires!
• Character Bazaar
  Reinvent yourself – use this forum to sell, buy, or trade EVE characters.
• Sell Orders
  Sell your ships, modules, and other products in EVE. This forum is for in-game transactions only.
• Want Ads & Trades
  The classified ads of new Eden. Find the perfect ship or module – or trade your items with other players.
• Price Checks
  Before you buy or sell, run a price check!

We have been looking at suicide ganking and overall security standing issues, and how these features affect the general landscape of EVE. We are not happy with the current ease of suicide ganking and the relative "no hassle" it has become. In many cases, unsuspecting victims have no chance to escape , nor any help from CONCORD. We want to change this.

CONCORD

CONCORD has some issues, mostly that pilots are killed long before CONCORD arrives. We have decreased the response time, meaning they will arrive quicker, and we should see a more helpful CONCORD aiding those in need.

We also changed the functionality and reduced the spawn. CONCORD now spawns in groups of 3 ships: 2 frigate sized vessels, which will lock the aggressor down in place, and a heavy hitting battleship to reduce his or her ship to metal scraps. The frigates will lock almost instantly while the battleship takes longer to lock, and the aggressor is made more aware of his or her impending doom.

Security penalties

Since the beginning of EVE, security penalties have been flat throughout every region of space (excluding 0.0). It has basically meant that the "security level" of a system means nothing, as the same penalty goes in all spaces. Although CONCORD has faster response times in the higher securities, it has not changed the fact that penalties are the same.

Through our research, we discovered that the balance between gaining standing and losing it was not in line with our intentions. It is too easy to gain back lost standing, taking only a few days to erase all the damage done by ganking. This is about to change.

We are increasing the security penalties throughout high-security space. It will be a gradual change, from 1.0 down to 0.1, where the security level of the system will dictate how much penalty you receive for illegal actions against a fellow capsuleer. This means that 1.0 will now be the safest of places, where aggressions and kills will be severely penalized and can quickly outlaw the aggressor from higher security levels. Conversely, 0.1, 0.2, and 0.3 will see a decrease in penalty, but not a big step down. This should move most ganking to the lower security areas where it belongs.

CONCORD will always frown on pod killing, thus the lowest penalty will not go below its current, which is a 12.5% standing loss. It is still possible to pod kill in high-security areas, and of course those at war or in 0.0 won't be affected.

The changes to security standings will make it harder for players to casually gank another player, and creates a challenge, so that if you are going to kill someone, you better realize the consequences.

Note that the security penalty uses the actual security rating of a system. A system listed with a 0.5 rating, for example, can actually range from 0.45 to 0.54. This means that the penalty can vary from system to system, so don't be surprised if you notice a varied security penalty in similarly rated systems.

Player vs. Player standing penalty

We will also count the standings of the two players involved; this extra variable can affect the total penalty received by a few percent. For example, if an aggressor has a high standing, and the victim negative standing, the aggressor get less of a penalty hit. This works in reverse, too. If you have low and the victim high, you will get an increased penalty.

As it currently stands, every whole point of standing difference will increase or decrease the penalty by 1%. If the aggressor has +5 and the victim -4, the overall penalty would be reduced by 9% (and increased if the other way around).

This is, of course, a major change in the landscape of EVE, but we are confident that these changes and the future plans will make EVE a better experience for everyone.

But what for the future?

We have a taskforce (Named TaskForce Doughnut!) which is dedicated to looking over these changes and proposing plans for the future. We have already started work on the above, but the future holds more changes.

In addition, the highly requested feature of removal of insurance in CONCORD related events will be implemented in the near future.

The CONCORD changes and Security penalty will be hitting TQ this fall, with Empyrean Age 1.1.

Be safe out there!

CCP Fear

This year’s fanfest PvP tournament will be a competition like no other. It will shake your perception of combat to its core, redefine the way you think about making other people explode, and force you to think long and hard about how to fit your ship.

Yes, pod pilots of New Eden, at the Eve Fanfest 2008 you will have the opportunity to experience firsthand...

The Super Ultimate Eve Online Mining Tournament of Awesomeness
Now, before you start worrying that we’re going to make you sit in a team of barges and see who can activate their strip miners faster, I'll give you an outline of the rules:

The Super Ultimate Eve Online Mining Tournament of Awesomeness: Rules Overview

• Teams are composed of five players, all of whom will have ‘super characters’ with every skill at level 5.
• Each team will be allowed to field a maximum of four tech 1 frigates and one tech 1 cruiser. All basic, un-named tech 1 modules, rigs, drones (including remote repair drones) and ammo will be allowed, with the exception of ECM drones and remote repair modules.
• The combat zone will be laid out like so:
• 
  

• The distance between the station and the warp-in point on both sides will be 3au, and the distance between each object in the arena itself will be 20km.
• Combat will only be allowed in the arena around the asteroids. Combat will not be allowed outside the stations.
• The objective of the tournament will be to see who can get the most points worth of ore into their Rorqual in the space of fifteen minutes. Any method within the rules can be used to accomplish this and stop your opponent from doing the same. Mining ore for yourself, killing enemy miners and looting their wrecks, stealing from enemy jetcans, or just outright destroying the opposing team are all within the rules. The Rorquals will be corporation locked to each team so stealing from them will not be possible.
• Each stored unit of Arkonor is worth 500 points, each unit of Gneiss is worth 100 points, and each unit of Veldspar is worth 1 point.
• Ships are all replaceable. You may, at any point, warp to your home base and pick up a replacement ship, or switch the one you are currently piloting for a new ship.
• 
  
  And there you have it, the basics of this year’s PvP tournament!
  
  The full, official, detailed rules for the tournament will be posted in late August along with signup information. Hopefully this overview has peaked your interest and it contains all of the rules necessary for you to be able to start considering setups and tactics. The full rules will contain more specifics of the arena and how the guidelines will be enforced, but none of the essentials should change.
  
  So we’ll be back soon with that final update – and until then, may the sound of many practising Miner I’s ring out among the stars!
  
  -CCP Claw

Until now there hasn't been a clearly defined process for releasing the data export after each expansion, and it has usually fallen on the shoulders of individual developers to sort it out and release it. The last data export was released by CCP Garthagk after Revelations 2 and, prior to his involvement, CCP t20 was responsible for it here and here. After a handful of releases, we concluded that better tools and processes were needed to allow our Quality Assurance and Deployment groups to easily create and release these data exports. This makes them more easily available for other EVE projects, such as EVElopedia that will, among other things, include a new and improved Item Database. The task of creating those tools wound up on my desk.

With a new developer comes a new approach. The previous data exports, both by CCP Garthagk and CCP t20, were in the form of text files with table definitions and insert statements for the data. That method isn’t as maintainable as we would desire and instead our future exports will be in the form of MSSQL database backups (.BAK), which third party developers can restore on their machines to extract the data into whatever form their application uses. If you do not have any available methods of working on MSSQL databases then try

Attention! The modifications discussed below are all subject to change, based on player input and testing experience.

Hey there!

This blog, and the changes to which it pertains, has been a long time coming. I'm going to try to be as thorough as possible and explain the intent of every change. The blog will be structured thusly: I will start by listing the ideal, craved order of in-game affairs; then identify the present problems impeding this utopian order of balance; then proceed to describe our proposed solutions and their implementation; and finally take a squinting step back to make a beard-stroking analysis of the altered big picture.

Utopia

OK, right of the bat I’ll admit that “Utopia” is a misnomer. A utopia is someplace where all tension has been dissipated with a grand unified order of infinite peace, calm and maximized fairness (and obviously, any truly utopian planning is an exercise in futility). Our order of business however, is not peace but balance, not calm but stability; ours is a world of volatile thermodynamics where all tension has its equal but opposite counterpart. Not inherently, unfailingly fair, but as fair as you dare to make it – revenge, redemption and riches are always an option to the arduous and crafty pilot. But I digress; the current focus is on speed.

Speed Goals

Designing towards specific goals is a base tenet of game design; without goals there is not much to aim for. Yet, design goals can be very hard to put down on paper. Even with a room full of people where you’re sure everyone has the same basic vision, nailing a lengthy and lively brainstorm down in a clear and concise way can be like returning the toothpaste to the tube at the end of the day. That being said, this is what four of us came up with during the course of a mere five hour meeting on the current speed crisis:

• Speed must never reach ludicrous speed, which is defined as speeds where missiles and drones don't intercept the class of ship they were intended for.
• There should be a significant and meaningful difference in speed between the ship classes.
• Speed should not permit a larger ship to perform the role that a smaller specialized ship was intended for.
• Afterburners should be a viable module selection for PVP.
• Guerrilla warfare must remain a viable combat tactic.

This is our celestial vision.
Ooops

As it stands, however, the previously mentioned arduous and crafty pilot won’t get to his revenge, redemption and riches without a microwarpdrive (MWD) at full throttle rattling his nanofiber hull. A MWD perpetually wielded in your mid-slot is becoming an axiomatic truth, not an option with an alternative. What’s more is that speed, alas, can only be countered properly with yet more speed, and so on in a dreadfully unidirectional tipping of the scales. There is no tension, just increasing slack. This is bad.

Currently we’ve got a number of different systems that affect speed that aren’t stacking nerfed towards each other, resulting in phenomenal speed that in turn results in near invulnerability. At the office we refer to this as “ludicrous speed”.

Here’s a quick overview of stuff that currently affects max speed.

Skills

• Navigation - 25% velocityBonus
• Acceleration Control - 25% speedFactor

Implants

• Pirate Implants - Snake - 53.63% velocityBonus
• Shaqil's speed enhancer - 8% speedFactor
• Hardwiring - Eifyr and Co. 'Rogue' MY-2 - 5% speedFactor

Modules

• Nanofiber Internal Structure - -12.5% massBonus
• Overdrive Injector System - 22.2% velocityBonus

Rigs

• Polycarbon Engine Housing - -20% massBonus
• Auxiliary Thrusters - 15% velocityBonus

Gang Bonus

• Skill: Skirmish Warfare - 10% velocityBonus
• Module: Skirmish Warfare Link - Rapid Deployment 38.81% speedFactor

Boosters

• X-Instinct - 20% velocityBonus

Overheating

• Overheating MWD - 50% speedFactor

Combining all of the above with a faction MWD results in as much as an eightfold increase in speed over what a vessel can reach with a normal tech2 MWD.

If one then takes a look at the max velocity on missiles and drones, it is readily apparent that our combat system was never designed for such speeds. Even when we did some basic tests on our internal servers, with special high-speed missiles, we quickly noticed Destiny (our physics engine) behaving very strangely.

Then there is also the size/price factor; why would I spend ISK on a sleek, fragile interceptor (that’s lithe and quick, supposedly), when I can just spend the money on a more durable heavy assault cruiser and reach even greater speeds?

MWD's have become a necessity in any combat situation. Setups almost revolve around fitting them, limiting variety and unpredictability, and there is no clear advantage to fitting an afterburner over one.

So what are we thinking? Laying the groundwork

We are considering a lot of base changes in order to ensure significant and meaningful differences in speed between the ship classes. Mass, agility and maximum velocity were tweaked. Let’s take a look at some before and after graphs:

The red and green markers are the minimum and maximum attainable speeds with a single tech2 MWD of each ship class; the white bar indicates the standard deviation.

As you can clearly see, the old values were all over the place, creating a hazy distinction between ship classes and resulting in considerable redundancy with the speed advantage of smaller ships minimized. The new values result in a smooth slope across the classes, yet still allowing some fringe cases, which is fine as long as it holds true to our utopian speed goals.

Changes around microwarpdrives

Warp scramblers (the close range ones), are due for a complete makeover. Our current idea is to have MWD's deactivate as soon as they get hit by their effect, and continue to be disabled until the effect is lifted.

This creates a whole new dynamic for PVP; the choice between fitting an afterburner or a MWD becomes a tricky one. It could also create a scenario where smaller ships would prefer to use an afterburner and scrambler, instead of a MWD, webifier and disruptor. Who knows? We might even see some crazy setups where both afterburners and MWDs are utilized.

A brief reactivation delay added to the microwarpdrives might ensure a speedy target actually slowed down, and of course with the MWD disabled, a webifier would have an even greater effect.

Our current idea is to have MWD's only differ in capacitor capacity penalty as well as reactivation delay, instead of the speed progression between meta levels. This means they would all give the same speed boost, 500%, the aim being to reducing the number of factors affecting the maximum velocity attainable over a normal tech2 MWD.

Webifiers

Currently when you’re webbed it’s pretty much game over unless you’re doing more DPS or have a better tank. The 90% speed reduction makes combat too static and predictable when webifiers have been applied. To address this, webifiers in our proposed changes have been reduced in effectiveness down to between -50% and -60%.

Nanofibers & Polycarbon Engine Housings

In order to reduce the slots required to attain maximum speed, we have to get rid of some variables. As you probably know one can fit 3 modules affecting the same stacking-nerfed attribute without being significantly hit by the stacking penalty. For example, if we had two types of damage modifiers—one that only increases the rate of fire and another one that ups the damage multiplier—one could fit 6 of them without being affected by a stacking penalty. In a nutshell, this is what’s happened with nanofibers and overdrives.

Nanofibers and polycarbon engine housings changed to affect maximum velocity and agility (which is basically what they did before, through mass reduction) would ensure balance, morphing them into a mixture of overdrives and inertia stabilizers and thus stacking penalized against those modules.

Our current implementation makes 3 nanofibers approximately as effective as 2 overdrives and 2 inertia stabilizers. This means, if one would want to fit for maximum speed, go for overdrives; maximum agility, fit inertia stabilizers; a bit of both, use nanofibers.

Polycarbon engine housings are overpowered, both in general and with regard to corresponding modules; this is because the tech1 version is currently more effective than a tech2 nanofiber. Following our changes we’re looking at them being 30% less effective than their module counterparts, which is more similar to the difference between modules and rigs in other categories.

Overdrives, Implants and Gang Bonuses

The balance between these systems is very delicate. Our suggested solutions would mean, yes, a general decrease in maximum velocity across the board, now that the interplay of all affected systems is duly accounted for. But the proportional gains are similar to before.

Our intent is to have overdrives range from approximately 7% to 12.5%; the high-grade snake set 24.7%; the low-grade snake set 16% and the gang bonuses down to 25.8% but with an added agility bonus. So yes, there is a speed nerf underway, but exclusive speed bonus items still retain their relative value, the snake set for instance still being the fastest single speed bonus item that money can buy.

All of this is of course done to push maximum velocity below the cursed ludicrous speed as it was defined, safely stitching back the burst seams of both our physics engine and gameplay.

Boosters

Although these aren’t consumed a whole lot (D.A.R.E. at work?), we need to reduce the number of independent systems that affect maximum velocity. We propose to have the X-Instinct boosters cause a reduction in signature radius, rather than an increased base velocity.

Smaller changes

• Web drones changed to be in-line with the new webifiers
• Marauders will probably get their web bonus boosted
• Due to the slight reduction in battleship MWD speed, the radius of the large mobile warp disruptors might get reduced
• Afterburners are being slightly adjusted to decrease the variation in speed boost from 105-171% to 112.5-162%
• Slot placement of other speed implants may shift

Mmm, beard

Yes flock, the dev giveth and the dev taketh. And surely, many will lament that he is heavy on the taketh this time around. But let us not succumb to exclamations and “I quit’ threats” just yet. These changes are of many dimensions, and even though there are few actual statistical boosts, each perceived nerf levels the playing field in such a manner where overall variety and inventive gameplay is being boosted. The battles will hopefully once again teem with ships of all sizes and makes, giving added weight to strategy and tactics (our very favourites).

We are fully aware that such complex changes can have unforeseen results, especially since such an agglomeration of them is difficult to test without the participation of a large number of players. Thus, we urge you to log onto Singularity (our test server) this Monday, July 28TH to give them a spin and spare us no feedback or thoughts on these issues. We're allocating a long time (a month or more) to oversee the changes because we are open to further tweaks, based on your suggestions.

-Nozh, bringing balance to the galaxy

Since my last blog entry, there has been some awesome work done in QA Engineering. This is the work of many people at CCP, most in the Quality Assurance department, but we have also received great assistance from the programmers and operations guys.

Empyrean Age introduced a large number of new objects and system changes. Some of these are huge and would require a herculean effort to manually test. QA Engineering was asked to step in and script as much as possible to allow the QA Testers to focus on testing functionality. CCP Atropos took the lead in this and below are some of the cool new testing tools we have available as a result of his work.

Many of our new tools were never previously needed, since the data they would test had been tested by the Bug Hunters and the EVE player base; for example, how often do Stargates change where they are going to? In earlier expansions, changes to these systems were made on a very small and limited scale, so testing time was short and simple. With Empyrean Age, though, that was all changed.

Automatic Gate Verification. With the addition of Black Rise we encountered some new testing issues that we had never faced on this scale. We added a large number of Stargates and these had to be checked to make sure they went where we wanted them to go, and that they were properly paired. How it works: the test would draw up a list of systems in the current region and break them down into constellations. The test could then be invoked on a constellation or region basis. Once a list of candidate systems was compiled, it would transfer itself into the first system, then navigate to the first gate, and jump through. On the other side of the gate, it would check to ensure that the destination system was correct and that it was within range of the correct return gate. Once that returned a positive or negative result, it would log the response, transfer back to the previous system, and proceed to check the next Stargate. And so on, and so forth, loading systems up as needed, since many would be offline. This meant that we could get 6 testing machines, assign each to test a different constellation in Black Rise, and complete the entire test in about 45 minutes. This also meant that it was repeatable on demand. To manually test this would have taken far too much time and would have meant that it was not easily repeatable.

The result of this was that we quickly identified 6 gates within Black Rise that were broken and needed fixing. This fix was applied and then, rather than just test the 6 fixed gates, we reran the entire test again. We also reran the entire set of tests on Tranquility while we had the server in testing mode to confirm that the gates in Black Rise were all working correctly after deploying the Empyrean Age updates.

Ice and Asteroid Belts. With the success of the Stargate testing, we wanted to apply similarly simple scripted tests to check other stellar data. We wrote a new script to get a ship to check the contents of a belt. This then gave us a report of what was in each belt and a warning if an Asteroid Belt had Ice or Ice Belts had Asteroids. As a result, we found that there were no Ice belts in any system in Black Rise, but there were several Asteroid Belts with Ice. The actual fault was that the celestial record was wrong and needed to be fixed (Ice Belts being marked as Asteroid Belts). We then reran the entire test to verify the fix.

Loot Table Changes. There were a lot of changes in Empyrean Age around the loot tables; these needed testing. To do this manually would have been a huge job (there are almost 4,000 different entities in the database in various states of design and use), so the decision was made to script a large amount, then select specific NPC entities for manual testing. A simple script was created that would spawn a quantity of a particular NPC from the list, then destroy them and check whether the wrecks did or did not contain loot, in line with the designed drop rate for that NPC. Some entities were harder to test, such as Overseer Structures (since they are massive and have rules determining how many can be deployed on a grid), but we could still check that we were getting some results. It was also discovered that some NPCs simply had no loot – they generated no wreck, no containers, no loot, nothing! After checking these results with the EVE Game Design Group, we determined that this was as intended for some but not all NPCs. On the other hand, some NPCs had no wreck type associated with them, meaning that they simply spawned a cargo container with the corresponding loot inside it – again, some by design, some not. This allowed us to identify a number of issues that were fixed and then the entire test was rerun.

Capture Point Bunkers. Another new feature that was introduced with Empyrean Age was the Capture Point Bunkers, and these not only needed to be tested for functionality, but to make sure they were in the right solar systems and not in other systems. We had scripts jump to all the Factional Warfare systems, test for the existence of a Bunker, and verify that it was within a certain distance of the Sun. We also had a script that checked that there were no bunkers outside of factional warfare systems. This test took so long to execute, we set the tests running and then came back later to review the results.

These scripted tests allowed us to test positively, for the presence of a particular variable or effect, and negatively, to ensure that something did not appear. This was the case with Capture Points which should only exist in systems flagged as being part of Factional Warfare and nowhere else.

Why do this through the client? All of the data we were testing was present in the database, but if it was not being delivered to the user in the intended manner, then the data becomes. We decided to test it through the client to confirm that a particular feature actually worked through the client.

Log Server Changes. It was decided that use of the client side Log Server had gone far beyond its original use as a debugging tool and was now being used to provide intelligence and scripting hooks. After much debate it was decided that these tools outweighed the advantage gained in testing from having complete client logs and changes were made to how the EVE client reports information to Log Server. What this also means is that player supplied Logs are not as useful as they once were and that the CCP QA members or the ISD Bug Hunters now have to spend extra time duplicating an issue and collecting complete client logs. This will have an impact on resolution time for these issues. We are not happy with this but it is a fact of the changes. Please note that these changes only affect the logs captured client side, not server side, so this won’t affect chat or combat logs. Once identified these changes were completed by the EVE Software Group, specifically CCP Laurelle.

Startup Tests. You know those "Not Accepting Connections" and "Unknown Protocol" messages that you received on occasion during downtime? The Deployment and Operations groups were actually testing the deployment of the Empyrean Age code base onto Tranquility during the downtimes before the update. This also highlighted some issues of scale and timing for the upgrades with cluster startup which we could fix before the official deployment. This allowed us to better calculate the needed downtime and allow proper time for any errors or issues that could arise. Most things went to schedule and thus we opened the server early, which was rather nice to do! CCP Mephysto and his team in QA Deployment took the lead on this and, with the help of Operations, got the code up and running on the cluster. After that a number of people from different departments (Software, QA and Operations) went over the resulting logs looking for errors and fixing them.

Starbases. Previously Starbases have always seemed to cause issues after every patch. This was noted and we conducted special tests avoid this. We actually copied some common Starbase configurations onto a dedicated server and then performed a full Empyrean Age software upgrade on the test server to verify that Starbase configurations, modules and functions worked as intended. This gave us greater confidence that we would have no significant issues with Starbases.

Unit Testing. We have developed a new unit testing framework based on pyUnit and integrated this into our Walking in Stations (formerly Ambulation) code base, as Walking in Stations is derived from the EVE code base. This is now being used to build up a set of unit tests for the basic 'services' used in EVE in a controlled environment. When "Walking in Stations" is integrated back into the main EVE code base this will integrate the unit test framework into our main code base with a much lower risk of issues. CCP Atropos has been taking the lead in this work.

Graphic Assets Testing. How do you test graphics assets? Well, we started with the ship models and looked at the rules governing them. To start, we developed a test that ensured: texture maps and specular maps are the correct size, the modules have 5 or more damage locators, and the ship and turrets both have a shadow effect associated to them. We ran this test over all of the ship model files and started looking for ships that did not meet the rules. Additionally, we have now started to proto-type a new stripped-down testing framework into which we can add all these tools and other tool ideas that have resulted from this work. Once this work is complete it can be packaged and made into a tool for the Artists to use to check all new graphic assets before entering them into the EVE code base. CCP Sputnik, with the assistance of CCP Redundancy, has worked very hard on this.

Load Client. In my last blog I spoke about wanting to develop a light weight, scriptable client that would enable us to run load and controlled testing on the test servers. After Fanfest last year we completed a proof of concept of this project and got a number of clients running on remote computers (up to 3 clients per computer) all following the commands from a central computer doing some simple tasks. This was a nice validation that we could get this working. We identified that, to make this truly successful, we needed to reduce the 'weight' of the client and have been working on this since then. We have created stubbed version of our audio and graphics engines so that we can now replace these in the client and significantly reduce the amount of CPU and memory used by the client, allowing us to run more clients on a single machine. Now that this has been done we are shifting our focus back to the control framework and the network control systems. There is still much more to do here but, when complete, it will allow us to run very controlled, repeatable tests so that we can exactly compare results on one code base versus another and look and the differences.

API Testing. CCP Elerhino, over in EVE Software, has taken on the mantle of API developer, fixing a number of bugs and standardizing the code and caching systems that the API uses. These needed to be tested so QA Engineering scripted it and made it repeatable and automatic. We now have a basic unit test framework for the API. In addition, we got the EVEMon code base and added some testing options so we could point it to our internal API test server to test the API changes. We then sent the EVEMon changes back to the developers and this is been integrated into the code base (thanks again to Araan Sunn from the EVEMon team). If any other developer of tools that uses the API wants to do something similar then please look at the changes in EVEMon as an example. As a result of this we are also looking into the deployment of an API test server for the developers to use. At this point it is still very much just an idea, but the concept is to point it at SiSi and have reduced caching timers to make development and testing faster.

There isn’t a conclusion of any sort – this is not a critical issue, but one wouldn’t hurt! In conclusion, we are building up a suite of tools that help us test the individual components of EVE in an automated fashion. We have started to Automate some common tasks so that they can be run on dedicated machines and free up the time of our testers to focus on other testing work. Next we will be looking into the Load Client (as mentioned above) and starting to string together the individual tests to trigger them automatically upon completion of a build. All in all, some exciting developments that will help us continue to make EVE a better product.

For quite some time we have wanted to create an official wiki based on EVE. For some time it existed only as a white paper in our design backlog, with no resources to actually pull it off in a way which would be satisfactory for us. But, with a rising sun, which currently shines all the time here in Iceland, we have been able to move forward beyond the concept and white papers into a functional entity, living on the intrawebs. This has been in the pipeline for some time. About a year has passed since the initial work was done in-house on a prototype, and I want to go a bit into the history of it, and how it has evolved.

The first pass

After deciding on the ground rules, what we would need and what it would be called and such, we needed to have a simple prototype done. We had some general requirements and with the help of an experienced web programmer we prototyped different types of wikis and various formats. We made the decision that it should be called EVElopedia. We also decided that it had to scale, it had to work with existing framework and it should be familiar to those who would end up using it.

We quickly realized that we would not be able to do this in-house, mostly due to technical limitations and man-hours needed for such a project, so we outsourced it. For one, it would take a company experienced in creating custom wikis much quicker than we would be able to, and at a far lower cost, as they would do it faster. Saving development time can sometimes be crucial and it would also have delayed the project for an unforeseen time. We finally settled on a company experienced in the business of wikis, and decided on using MediaWiki. MediaWiki being used in most wikis today and it is my favorite Wikipedia.

Production Ramp up

Soon, we started seeing basic versions of it pop up which we could look at and we were quite happy with the results. However, we ran into various problems where tie-ins with our own systems had to be made. My "It's MOZO" moment was when we finally had our CSS made, and the EVElopedia started looking more EVE-style (orange and pink was the first color choice).

Testing and Delivery

We are currently testing it and reporting bugs to our partner, and it is looking quite well so far. Mostly there are aesthetic changes and some minor problems we have been running into, which makes us very confident that we can release it very soon™. A previous blog from Ginger explained YARR, a division in ISD which will handle moderation of the wiki, which took us one step further towards release. We have decided to go with a full moderation initially and possibly change it to less moderation at a later time, once we get the feel for it. YARR will be responsible for handling this, making sure that all new articles, and changes to existing ones are accurate and meet our standards. The rules are very similar to the TOS and EULA and there are similar repercussions for misbehavior as those used on the EVE Online message boards. We can't say exactly when it will be released, but we will announce it once we get deeper into testing and we are satisfied with our product.

Wait... there is more!

The wiki won't be just a wiki, it will contain something special, which most of you have wanted for quite some time, or more to a point, an up to date one. There have been various complaints about the Item database not being up to date; this is mostly due to the process of updating it being a hard and difficult process (who would have thought we would have more ships and items!). But we made it a requirement that our Item DB could be easily exported from our internal servers, and using a custom made macro we have been able to insert all items into the EVElopedia. It will look similar to the website DB as it looks now, but you’ll notice that there are some minor changes, mostly aesthetic ones. One good thing about the macro is that we can update it at any given time. So on a patch day we can export it from the server, use the macro to update the wiki and voilà, an up to date Item Database, on patch day!

One last thing, the wiki will work using the in-game browser. However, as it is… not as robust as any other browser shall we say, there can't be any edits or changes through the in-game browser. But it will render all text and images quite well, so there is no need to start your browser to search for something as you can do it through the in-game browser.

This is going to be the most awesome thing to hit the EVE universe, and this will be available before the apocalypse, soon™ and all that jazz!

E-ON is about to reach a significant milestone, having passed its third year in operation, an event that will naturally be marked by the publication of a new magazine, #012, which is available for pre-order and will be mailed on July 4th. In celebration of this (and that of American Independence... or of the Philippines if that is closer to home) all buyers of the magazine will receive with their order a free poster of the entire Empyrean Age New Eden star cluster.

Veteran readers will remember that we gave away a galaxy map with our first birthday issue (which math tells me was two years ago), but this one is much more useful since it's been created by stellar cartographer Serenity Steele and can be used alongside the EVE Strategic Maps book (assuming you have that fine atlas of New Eden). Region names are included, with current outposts as well as Faction Warfare-enabled regions highlighted and security status colour-keyed. Also, region names reference corresponding page numbers from the book. You won't need the book to fully make use of the free map, of course, but with both at your fingertips total galactic domination is assured. ...Maybe. Actually, probably not. Still, it's a very cool map and also larger than the one previously given away with E-ON #004, at almost a meter in height (841mm x 594mm – 33in x 23in).

As for the stuff that matters (like, who would be shallow enough to buy a magazine just because it comes with a freebie?), inside E-ON #012 we have a report on the recent meeting between the Council of Stellar Management and CCP, for which I was lucky enough to be able to attend. We also have guides to fiction and the forums, a past, present and future look at mining, profiles of Goonswarm, Ev0ke, Curzon Dax and the second part of the ‘0.0 Thought Experiment’ where Julia Caesar, JRR Tolkien and Greyscale the red macaw meet up one final time to ponder the question of null-sec domination. There’s loads more too.

Quite a good issue I reckon. Did I mention that it comes with a free map poster? :P

Following the Empyrean Age expansion we’ve made some additions to the API where players can access Factional Warfare information about their characters and corporations. The additions also include top-X lists for characters and corporations, information about factions and solar systems being fought over and who is at war with whom.

The additions are:

• Character Stats (char/FacWarStats.xml.aspx) - your character’s stats (requires: userID, apiKey and characterID).
• Corporation Stats (corp/FacWarStats.xml.aspx) - your corporation’s stats (requires: userID, apiKey and characterID).
• General Stats (eve/FacWarStats.xml.aspx) - general Stats for all factions.
• Top X lists (eve/FacWarTopStats.xml.aspx) - Top X lists for Victory Points and Kills by day, week and total for characters, corporations and factions. Top 100 for characters, Top 10 for corporations and factions.
• Occupancy Data (map/FacWarSystems.xml.aspx) - List of Factional Warfare systems, with owner and current occupier and any contested systems.

Note that even though the Factional Warfare data currently has a caching time of one hour, the data is only calculated on TQ once a day during downtime. The cache time is set to one hour to make sure new data is available in the API as soon as possible without causing load problems.

Official documentation for these additions doesn’t exist just yet. We’re working on documentation for the whole API which will include the new stuff. We’ll be making that available on our own servers soon.

Also included in the latest patch were some bug fixes:

• Added corp member title roles to API authentication and MemberTracking. The rolesMask and grantableRoles now show roles added by title as well.
• Added corp member title roles to API authentication. Roles granted by title now count for accessing API data.
• Fixed issues on KillLog. A fatal error which was occurring when Involved Parties was empty and added the missing security status to first attacker.
• Fixed issues on CharacterID. Single quote is now usable in search strings which are also no longer case-sensitive.
• Fixed the Sovereignty dataTime.
• Some general performance and load tweaks.

Also worth mentioning is that we are now starting to define some long term plans for development and support of the API which we will finalize and bring to you at a future date. This includes setting up a test API server against the Singularity test server with reduced cache times but limited capacity for developers to test their code against. More on this as we work out the schedule.

It started one year ago – the idea to revive the Council of Stellar Management (CSM) and make it even better than the original implementation. Today, after few days of organizing and processing what transpired during the CSM Summit last week, it is a time for a blog.

In short, the Summit was a resounding success. The amount of effort and time spent by the CSM on polishing the topics on the agenda was extensive and now our work is laid out for us. The benefit of the meetings between the CSM and CCP became evident the first day when everyone came prepared and eager to get to work.

The next step is to sort the discussed topics according to viability and priority. The first criteria is the amount of work required by CCP in terms of programming time, design and balancing etc., and the second criteria is the priority set on the topic by the CSM. A third measurement has already been placed on the topics – the technical feasibility of addressing topics brought up by the CSM – that was done during the meetings between the CSM and the CCP Council. After some planning, we will proceed to insert the results from the discussions into our development pipelines based on the above criteria. Such items will be noted in future patch notes as issues that were raised by the Councilors so that the citizens of EVE will be able to track the progress, effectiveness and results of the Council.

It should be noted that some requests may take longer to address than others but we will always do our best to communicate the closest timeline estimates we can provide based on current workload, available resources and release schedules.

The most important results of the Summit may not be immediately evident, but the seeds planted by the CSM into the minds of the EVE dev team members are already sprouting.

Since EVE was launched 5 years ago the GM team has answered millions of petitions, written guides and articles to enlighten players and worked extensively with all other departments within CCP to make the EVE universe a better place for our players. While working busily in the background, the GM team hasn’t been the most visible element of CCP but we now have plans to increase our communication with the player base and to allow players to see more of what it is we do.

In this blog we will tell you all about how the global support team is structured and about all the other stuff we do apart from what we are best known for, answering petitions.

Game Masters

To kick this off, let us clear up one common misconception we have encountered about Game Masters.

As we have often noticed through petitions, some people believe that the Customer Support team consists of volunteers. However, while CCP has very capable and enthusiastic volunteers that take care of a wide range of responsibilities, everyone in Customer Support is a paid employee of CCP. What this means for you, is that every issue you seek assistance for through the petition system, is handled by a paid professional and receives the full attention it deserves by CCP staff.

Many of us have been working here as Game Masters for years and most of the first GMs that started working here before EVE was even launched, are still here. The employee turnover of CCP’s support department is far lower than in your regular support center and we like to credit that to the great working conditions CCP staff enjoy, the diverse assignments GMs partake in, and to the never ending adventure that EVE is for both players and staff. This low turnover of GMs results in a much deeper pool of knowledge and more accomplished staff. Something we firmly believe is necessary to provide proper service for the largest and most complex online world in history.

During the last two years our Support Team has spread to all corners of the globe…or a few of them at least. We now have GMs working from four locations worldwide. The largest team operates out of CCP’s HQ in Reykjavík, Iceland. Iceland is where it all started and due to the accumulated experience of the Icelandic team and the daily proximity to CCP management and other departments, the Reykjavík support team acts as the nerve center of CCP’s Customer Support. The second largest and second oldest team operates from CCP’s office in Shanghai, and then we also have teams in Atlanta and Dusseldorf which constantly grow in terms of size and experience.

Winds of change

To meet the ever-growing demand of quality our customers rightfully expect from us, the internal organization of Customer Support was recently completely revamped. GMs were split up into different groups each of which hold different responsibilities. You see, a GMs day at the office isn’t just about answering petitions although that will always be the most prominent part of the job. When not handling petitions, we do a lot of proactive work to reduce the things that players would otherwise be forced to petition about, thus reducing our own workload and making the EVE experience more enjoyable.

So how is the GM team split up and organized exactly?

Hierarchy

The Customer Support Service ladder is split into three ranks.

Game Masters:

Game Masters are the first (but not the least) level of Customer Support. From Billing and Technical petitions to Game Play or Stuck petitions, Game Masters are always on call to tend to your needs and assist you with any issues you might encounter. 23/7, 365 days a year, come hell or high water…they are there for you.

Game Masters are the eyes and ears of CCP due to their constant interaction with the player base, and are therefore relied on quite a lot to spot potential problems in the game mechanics.

Senior Game Masters:

Senior Game Masters make up the second step of the service ladder. Players can escalate their petitions to a Senior Game Master if they wish to have a second opinion of their case after a full investigation has been performed by a Game Master. Senior Game Masters are bound by the same rules and policies as Game Masters, but serve as your second point of contact should you feel the need for a review on an important matter or if you feel your petition has somehow been mishandled. For further information on escalation rules, please check here.

Senior Game Masters also have increased responsibilities when it comes to complex petitions, meaning that problems widely affecting a large group of players may end up being taken care of by a Senior GM from the start.

Lead Game Masters:

Lead Game Masters each manage their own group of GMs. They tend to administrative duties and the most important cases we have to deal with. When required, petitions are escalated to a Lead Game Master either for a final review of a complex matter, or to have the work of other GMs reviewed. Lead Game Masters are the highest level of Customer Support and as such their decisions are final.

Internal Structure/Groups

As mentioned before, the Customer Support team is split up into internal groups, each responsible for managing a few areas of expertise. Game Masters are selected into groups based on their skill sets, goals and fields of interest.

Back-Ends

The “Back ends” (name derived from their location near the back wall of the Reykjavík GM department) is the group responsible for the technical petition queue and all GM/QA (Quality assurance) relations. The Back ends are also responsible for “GM defect management” which is an important job since GMs identify their fair share of issues and file quite a few defects for our friends in QA to look into and fix. The Back ends are also responsible for following up on the making and maintenance of all the tools that GMs need to perform their duties as quickly and efficiently as possible.

Braincell Group

The Braincell group’s (they think they are smart) main responsibility apart from answering petitions is to maintain the Knowledge Base and to make sure that Knowledge Base articles are up to date. They are also responsible for maintaining a list of known issues with the game, and are responsible for all necessary communication with the Game design department.

Hell Cell

Hell Cell doesn’t just have a really cool name. They take care of all petitions that have to do with billing and real money issues, and also assist our web programmers in maintaining and improving our billing systems. Due to Hell cell’s focus on billing issues, they are responsible for our relations with the Marketing Department and WebCell (CCP’s team of web programmers). Finally, Hell Cell is in charge of GM Quality control which means that they audit our work regularly and slap us if we fail.

Law & Order

The Law & order group is responsible for creating and maintaining internal and external policies. The external policies are the rules and boundaries we set for our players and on top of that we have a lot of internal policies and procedures to ensure coordination between a large global team. The Law & Order group also goes after the bad guys when needed. They work with our web programmers and the Eve Store on credit card fraud prevention, organize RMT investigations and exploit investigations, and are in charge of our relations with CCP’s Internal Affairs department.

LiveGroup

The LiveGroup monitors the status of Tranquility and the effect that server issues have on player activities. They dig around for all sorts of data, do server analysis and make daily reports on the server status. Obviously they work very closely with our Operations team and are responsible for our communication with them.

Atlanta Group

The Atlanta team’s main responsibility apart from answering petitions is what we refer to as “Queue control”. They monitor the state of the various petition categories, average response times, petition influx and the output of individual GMs. They use this information to make plans that help us evaluate how much manpower is needed in each field at any given time and how much time we have to spare for all the special projects and proactive work we have lined up.

Dusseldorf Group

Our GMs in Dusseldorf are a stronghold of multi language support. Additionally to standard TQ support in English, they handle our official support in German. Solving a wide variety of issues in two different languages takes great versatility.

Shanghai Group

The Shanghai team does TQ support alongside all the other teams. They are a very important link to our Chinese community.

LeadGroup

As each of the aforementioned groups is lead by a Lead GM, we also have a LeadGroup which consists of all the Lead GMs and the director of CCP’s global customer support. The LeadGroup works closely together on steering the Support Department. They discuss the hiring of new GMs, take care of administrative duties and make cool plans for the future.

And finally we come to…

Info Group

InfoGroup, the group responsible for this blog, differs slightly from the other groups due to the fact that many of its responsibilities are new. These include the delivery of GM blogs, publishing an internal GM newsletter and coordinating GM convention participation. By sending more GMs to game conferences and conventions we want to add to our own knowledge, and have our best and brightest out there telling the world all about EVE and the exciting life of interstellar GMs.

More traditional tasks include managing the training of GMs, the creating and maintenance of training material, and the hosting of seminars and lectures for GMs. One of the main reasons InfoGroup was created was to increase and improve information flow, both externally and internally, however the training part of our agenda is the backbone of what we are all about. With our global team growing in direct correlation with subscriber growth, we need to make sure that our training program keeps up and keeps delivering kickass GMs and great service.

The creation of InfoGroup means that you will be hearing more from us GMs in the future. With increased communication you will start seeing more red bars on the forums, more blogs from the GM team on current issues, and red text on the help channels as time allows.

Internally we have started sending out a monthly newsletter about everything that goes on in GM Land, both to keep GMs around the world updated on what is going on everywhere else, and to include the rest of the company in our wheeling and dealing.

Epilogue

We hope this blog has given you all a little more insight into what a GM’s job entails and what we are all about. If you have any tips and pointers for us about issues you would like to see addressed in future blogs, we are very open to ideas.

Thank you for reading and fly safe.

Empyrean Age marks a big turning point for EVE Online. The cluster of New Eden has seen a lot of great storytelling and roleplaying but until now, most of that activity has been created by the players and there has been very little interaction between player created content and the content created by CCP. Almost no changes have been made to EVE since its launch that reflect the developing story of EVE.

That is now about to change. Starting in the middle of May CCP began to create a direct link between the evolving story of EVE and the actual game environment. This has been done a few times before in very limited circumstances but the path we are on now is really unprecedented.

Tony Gonzales’ novel EVE: Empyrean Age is a prequel to the events of the next expansion. The 4 major Empires of EVE will shift from peace to war as a result of the events in that novel. We wanted to bring a sense of those changes to the players in a natural way that immersed people in the unfolding plot. The first and most visible highlight of that strategy was the news items, video teaser, and in-game changes related to the destruction of the Ishukone HQ by a Gallente suicide attack. Players could read about the peace conference at the station, then see a newsreel of the attack itself, and in game, they can travel to the site of the disaster and see the massive damage caused to the station, linking fiction, multimedia, and game assets together to create a total experience for the players.

Now that the expansion is released the players will see even bigger impacts of the story. Many of the events of the novel are reflected in changes to the game itself. During the downtime period while the game was upgraded with the Empyrean Age expansion the players were treated to an unfolding series of plot threads communicated in the form of news items. Once the servers came back on line people were able to fly to many of the sites of conflict described in these news releases and see the changes made to the environment as a result, including ship graveyards and an orbiting Titan supercapital. The biggest effect is the game system we call “Factional Warfare”. Factional Warfare allows players to directly take part in the action by having their characters join the 4 militia organizations of the Empires and fight on their behalf for control of contested space. The war that is begun in the novel will be fought in real time, by real players, in EVE Online, totally merging the story with the game.

This is just a start. We have big plans to continue to mix all forms of storytelling together to make a richer and more meaningful experience for the players. Factional Warfare gives us some of those tools including the ability to track successes and losses in the raging battle zones, the rise in rank of especially effective pilots, and the economic impact of the war. That information, combined with observations of player behavior, threads on message boards, and interactions in many other venues, will be channeled through the EVE story team, and used to continuously change the EVE environment to reflect the progress of the fighting.

And Factional Warfare is just the first of several ideas we have plans to implement that will allow players to immerse themselves fully in EVE. Our goal is to start from this initial point, and make regular, steady forward progress in bringing the player storylines and the CCP storylines closer together.

The challenge we face is that EVE has already evolved a very vibrant and crucially important self-directed story based around Alliances and their battles in 0.0 space. We see that experience as the ultimate expression of the sandbox ideals of EVE. Eventually, we hope all players will become involved in Alliance activities, once they become experienced pilots and wise to the ways of EVE. Our challenge is to continue to support that advanced level of play while creating a consistent, directed, immersive storyline system in Empire space. We have to carefully navigate the integration of our story threads with the adventures arising naturally out of the decisions of hundreds of thousands of players. We want to tell stories with the EVE community, not to the EVE community.

This is really unexplored territory. We’re going to be doing things with narrative structure, player feedback, game design, and virtual reality that have never been tried before at this level of complexity. Our strategy is to go slow. We’re going to add features carefully, watch the results, adjust our plans, and generate a lot of feedback and commentary. Empyrean Age is the first step on this path, but we are convinced it leads to a wonderful destination.

I thought I should write a blog to let everyone know that we at CCP have some big plans for PvE and for mission-runners in particular. To give you a sense of how much effort we’re putting into it I can reveal that we currently have eight developers working full-time on mission and deadspace creation. We also have a number of freelancers assisting with