Various designers across the universe have secured contracts to create new SKIN lines, meaning licensed Designer SKINs are soon heading out to hangars all around New Eden. Their bold new looks, inspired by the sunsets on Caldari Prime, the mythology of the brave Matari warriors and more, isn't the only unique thing about them. Each line is created by independent designers that are not shackled to the traditional palettes of each of the four major Empires. Hence some of these designs will have SKINs that are available across multiple factions regardless of hull composition, such as the Blue Tiger line seen below.
The first of the below Designer SKINs, The Raata Sunset line, will arrive with Galatea on 25th August and the rest will follow shortly after.
Available on Caldari hulls
The white wastes of Caldari Prime have ever been washed in the fiery orange of Luminaire's evening light, transforming the landscape into a glowing red field where ice and snow is seen only in the shadows of the Raata Sunset.
Eliina Kariopka is the lead graphic and production artist for multiple Echelon Entertainment holoreels and galnet shows. She has made her name over many years with vibrant and high-impact designs.
Available on Minmatar hulls
Tales of the Valklear soldiers who spearheaded the Great Rebellion and went on to become the elite of the Minmatar military are legion. The Valklear Glory pattern invokes the reputation and mythos of these Minmatar warriors.
Asgeir Huskarl of Core Complexion Inc. is one of the most prolific ship designers in the history of the Minmatar, and also a noted artist often called upon for high-end commissions for his sense of color and style.
Available on Caldari and Minmatar Hulls
Mind Clash Master Joelyn Donalokos is famed throughout New Eden for his control and power in the Clash Arenas. His specialty and trademark is the Blue Tiger illusion and this SKIN pattern exclusively calls on the prestige of an elite Clash Master.
An acclaimed high end product designer, Hari Kam No has worked with the Mercantile Club to develop an exclusive line of elite level designs for the capsuleer market.
Ship designers and nanocoating engineers aren’t the only ones dabbling with aesthetic changes, as a veritable artistic renaissance is sweeping across the fashion industry as well. Refinement has finally come to the hard-working backbone of New Eden, with new Industrial-themed apparel arriving in the New Eden Store. The unique fashion line is named Hephaestus, in honor of the space-faring spiritual descendants of the blacksmiths and artisans that existed well before the EVE Gate collapsed. These stylish new outfits are perfect for those capsuleers who wish to revel in the utilitarian, but with a modern twist.
Soon after the Galatea release you will be able to acquire a complete outfit, offered in various colors which also match the new Designer SKIN lines and are available for both males and females.
Now that we have delivered some much needed love to both the Caldari and Minmatar SKIN lines, we plan to expand designer SKINs to all four major factions.
The Raata Sunset designer line will be expanding to Amarrian hulls and the other three empires will be receiving new lines throughout the rest of the year.
We have been adding something new into the New Eden Store every two weeks and we are aiming to keep up the pace. Sometimes these additions will be smaller and sometimes larger. If there isn’t a SKIN out yet which tickles your space brain, bear with us and hopefully soon you will find what you are looking for!
Till next time,
Before the second tournament weekend arrives with more exciting matches, I would like to give a brief recap of the first weekend and a peek behind the scenes to present some of the heroic work done by the ISD volunteers to deliver this stream. But first, here’s a quick summary of the first weekend.
During the first weekend we saw all 64 alliances fighting for survival and supremacy in each of the 64 matches, played out over two days and two systems. Intense brawls, bold maneuvers, and great sportsmanship together with clever tactics – the first weekend had it all! Before we dive deeper, here’s a quick recap on what the Alliance Tournament is all about.
The Alliance Tournament is a highly anticipated annual event organized by CCP where teams from various alliances from all over New Eden fight against each other for eternal fame, piles of PLEX, and unique prize ships. The winners are determined in a double elimination process (one loss drops you into the loser’s brackets, two losses and you are out). Matches take place within a closed off system far off in unknown space, ensuring that the battle is decided only by those competing. The full set of rules is available here.
The tournament is live streamed and broadcasted with our special “Fancy UI” overview to help visualize the ongoing battlefield. Fancy UI keeps track of each fleets control, attack, and defensive capabilities in real time:
Newcomers as well as established alliances and previous Champions have enlisted themselves in AT XIII. See more about the various teams in the AT XIII team summaries on Crossing Zebras by Apothne.
The first weekend of AT XIII was broadcasted by the ISD volunteers in corporation with CCP.
From the first match until the last we saw teams viciously fighting for victory using a range of team compositions: Typhoon Fleet Issues, Tactical Destroyers, Barghests, Nightmares, Flagships; some teams even used some unique ships given out as prizes in past tournaments . The team tactics showcased were equally as varied, with close-range brawling, long-range kiting, armor turtling, tinker setups, clever use of micro-jumpdrives, and even remote hull repairers. Check out the AT XIII weekend summary on EVENews24 by Tiberius StarGazer and the Highlights of the first Weekend on Reddit by ChessurSB.
Raw footage of the first weekend can be found here and here.
Replays of the matches are available via the CREST interface. A great visualization of those replays can be found on Null-Sec.com in the 3D match viewer (for example the first AT XIII match)
Due to the sheer amount of matches (a total of 64 matches over the course of only two days), the matches had to be distributed over two separate systems. To split the workload and to ensure the best stream quality, the decision was made to broadcast the first weekend on two streams – one stream for each system.
A team of 8-10 volunteers worked actively on the stream, with several more were on standby. The testing and dry-runs lasted for around one month. ISD Athechu was the project manager and kept everything together. ISD Buldath was second in command and also spent lots of time testing and setting up streams. Both volunteers live-streamed the entire first weekend of the Alliance Tournament, while several more volunteers supported the stream with chat moderation, updates and more.
The stream itself was a major success, especially considering that this was the first time that ISD did engage in such a large live streaming event. It was hoped to reach 2000 viewers. After the live stream was completed and the numbers available, we saw that in average 4000 people watched the stream with a peak of 4600. Well done, ISD!
The following parts are written by ISD Athechu and ISD Buldath to give you first hand insight.
“The first step was when the dev blog for ATXIII was released and I noticed that CCP wasn’t going to stream the first weekend. I thought to myself that ISD could do this as we have done things of smaller nature in the past so figured why not try for something on a larger scale.
I focused on building a team and sent out an email which about 15 people replied wanting in on this. I created jobs that needed to be filled and created responsibilities for everyone.
Being a volunteer of course means that things come up and you can no longer help out. A few people informed me real life events have come up and they can no longer help which is perfectly fine most of them were streamers is the only downside.
ISD Buldath and I took over streaming basically the entire weekend and with the night before planning late into the evening we realized some of what we planned just wasn’t possible or really feasible such as commentators or switching off streamers. So we ended up streaming both days during the week.”
“When we were first given the idea that perhaps ISD could stream, I was excited at the opportunity. Normally Preliminary Fights were not streamed, or at a reduced capacity. It was something new, exciting, for the whole team, as well as for the streamers themselves as nothing of this size was ever attempted before.
The first thing we experimented was with OBS, the streaming software. We tried taking feeds from two different cameras, and then mix them all together to have them showing. The first major issue with this was that camera crew would need to record, render, then send that data to a central client. There would be two central clients, one for each system. This created issues with latency and quality, since not everyone had the same type of hardware or software.
It was at this point we were offered the idea of being able to use the FancyUI, and this scrapped everything and we had to start from scratch.
About a week before AT went Live, we were given a time frame of when the FancyUI tools would be ready, only a few days before the live stream. The day when we got the tools, we spent day and night, all available time, all the way up to that Friday night testing, experimenting and implementing ideas to make sure everything worked great.”
“The weekend was very rough … I was tired of just sitting in a chair and just watching matches. While it sounds really easy, think about it getting up about 3 hours prior to the start of the first match getting all the needed client(s) ready making sure commands are applied, streams are good to go, information was updated, no technical problems the list just goes on.
Then the matches begin and we sit there all day basically. So lots went on behind the scenes and I’m sure CCP had something along the same lines as we did. It was a great time working with all the GM’s and CCP members as well.
Think my favorite was while I was streaming ISDSTAR2 my streaming client crashed sometimes and while in a call with ISD Buldath I would just go ‘Uh Oh’ and he would just say …’I don’t like when you say that’.”
“It went far, far smoother then we were expecting. There was a short hiccup at the second match that lasted half an hour, but that had nothing to do with us and the streaming part itself. I know Athechu had a few issues with his streaming client with lock ups and freezes, but it went smooth regardless.
We had ISD Buldath as camera for system 1. We had ISD Athechu as camera for system 2. We had ISD Dorrim Barstorlode from the ISD CCL team helping update and keep Moobot in track, as well as moderation. We had ISD Arooga helping with moderation and answering questions both in-game and in both twitch channels. We had ISD Monksnark helping ISD Dorrim Barstorlode with Moobot. Thank you ISD BH Newmind with helping us test the FancyUI software on Singularity! We had ISD FlowingSpice spice up the Channel descriptions, including adding pretty pictures and getting everything organized. We had ISD Jarret help us with image pictures for the "Presented by ISD" static image. And many, many more that I am forgetting to write down!”
“Absolutely it was. Despite all the planning and working on things and the long hours it was. People always ask me if ISD is worth it and what are some of the perks? Well I would say this is a very nice perk if you’re able to do it. I would be happy to talk to anyone who has questions about STAR or ISD in general.”
“It was worth it. So, so very much worth it! It was a huge learning experience for all of us and I would Love to do it again.”
With those words I would like to close this spotlight, but not before properly thanking ISD and the volunteers who spent countless hours in a most selfless manner to support the EVE Community.
We salute you:
ISD Dorrim Barstorlode
ISD Jarret Pelly
For more information about New Eden’s Finest Volunteers, go visit their page on the EVE Community website.
More exciting matches are lined up, and teams are ready to fight tooth and nail over the next two weekends to reach the grand final on August 30th. Make sure you tune in starting tomorrow at www.twitch.tv/ccp so you don’t miss the fun!]]>
Hello again dear spacebros and welcome back to another structure blog by Team Game of Drones. Time has passed since we last discussed upcoming new structures (Fanfest 2015 and shortly thereafter), which we have spent reading feedback and iterating on concepts. More importantly we have been busy coming up with more detailed answers on the following two questions, which are the most heated topics you wish to see explained regarding this specific feature:
We now have a refined version of how those systems are going to work and are ready to share them with you. However, to avoid heart attacks, eye gouging or bleach drinking we are going to focus this blog on answering point 1, while another blog is to follow on point 2. For all the math wizards, min-maxers extraordinaire, and OCD freaks out there, numbers will be provided, but please remember those aren’t final and will most likely change based on player feedback, testing and various iterations.
Missed a structure blog? Have a look at the following:
As mentioned in Shake my Citadel, new structures are going to use mechanics similar to the revamped Sovereignty system, with a twist to fit our own needs. This naturally implies vulnerable and reinforced states.
All Citadels, no matter their size, will have 3 vulnerability windows. They are supposed to be the safest structures around, and thus provide the longest defense buffer available to owners. Please note this will not be true of all structures. Observatory arrays may have only 2 for example, since they are supposed to be more fragile.
Also, there will be no Command Node spawning under this system – CSM feedback showed it was quite counter-intuitive to fit big guns to your massive structure only to have the fight take place somewhere else.
With the chart below, we are going to go into details how each phase is going to work.
All structures will have a deployment time, which will vary depending on the structure size and type. The larger or more impact on the surrounding the structure has, the more time is going to be needed in an effort to give various parties more time to react.
A new structure that is being deployed is totally vulnerable to entosis links, and any third party can come to disrupt it (for high-security space however, a war declaration is required not to suffer the wrath of CONCORD). The exact details on the attack process are explained under the “entosis link contest” below.
Current numbers to deploy Citadels, our first batch of structures, are:
Citadel deployment timer
Please note those do not require downtime to proceed, unlike existing outposts. It is also important to remember that scooping a structure will cause an immediate and full vulnerability window to begin. If a vulnerability window was already underway, it will refresh the duration to its maximum value. A structure going through a reinforcement timer cannot be scooped until it comes out of it.
A structure that is successfully deployed then enters normal operation mode. Players may use its services, dock, man the defenses or do whatever else is allowed by them. The structure also becomes vulnerable to attack during specific times.
In more details that means:
How players assign weekly vulnerability hours is entirely up to them, as long as they fill the quota. You could assign all hours consecutively if you dispose of enough manpower, or you could spread them out over multiple days. Hours have to be spent whole however, no weird split minute shenanigan is allowed.
Current numbers for the weekly vulnerability window are set as follows and varies based on location or occupancy. Those numbers will most likely change with time.
High-sec, low-sec, Null-sec with full occupancy
Null-sec without occupancy
Structures that are successfully attacked through entosis links during their vulnerability windows go into an invulnerable mode for a specific amount of time, at the end of which another vulnerability window may occur.
Reinforcement timers last for a specific amount of vulnerability hours:
This type of vulnerability window does not appear in a regular operation state, and is a reactionary state appearing once the structure has been set into reinforcement at least once.
Entosis links are needed to be able to attack (or defend) a structure during its deployment or vulnerability window.
The process is as follow:
The entosis contest time will vary depending on the location where the battle takes place and if you are attacking or defending.
High, low-sec and null-sec with full indexes
Null sec with no indexes
Attacking a structure
Defending a structure
We also want to make sure all the previous states and phases are properly represented in the game.
Structure brackets are going to be visible in space and in the overview if:
And that’s it on how to attack and defend structures. Please remember most of this is subject to change based on feedback and time, even if we’re are starting to see the light at the end of the tunnel. We would also like to thank the CSM for their time reviewing this particular feature with us. As mentioned at the beginning, our next blog is going to focus on asset safety, or what’s happening to your stuff when a structure blows up.
In the meantime, happy hunting and may the odds be in your favor.]]>
Hello again people and welcome back to yet another structure blog by Team Game of Drones. We’ve previously talked about the general protection and capture mechanics, now let’s discuss what happens to your stuff when things blow up, otherwise known as asset safety mechanics.
As usual, numbers will be provided but are still up to debate, so no need to soil your undies prematurely. There is going to be time for discussion, feedback and changes.
Missed a structure blog? Have a look at the following:
Before we get started, let’s explain why we even need to consider this particular feature in the first place.
One of the core philosophies of EVE Online is that acquired resources can be lost. This in turn keeps the economy in check, gives a risk versus reward in the game, and promotes conflict and bragging (who doesn’t love those juicy killmails?). However, while this principle is in place for most of the structures in-game (starbases, customs offices, deployables), it does not apply to player built outposts.
This leads to several problems:
So, we quickly decided that our new structures would need to be destructible, especially since they are going to be available everywhere from high-security to wormhole space. However, this introduces another problem: we want our structures to be used, but one of the deterrents against that goal is the fact they compete against existing NPC stations and player outposts (before we nuke them that is). As such, we have to accept the fact no one will want to store items or minions (if you are an alliance leader) in one of the new structures if they can be destroyed and lost on a whim.
And that is how asset safety was born.
So, what happens when players successfully attacks one of the new structures and blows it up?
There are two different ways of recovering impounded items:
There are going to be sinks involved to be able to recover impounded items:
Please note that the recovery time will automatically start counting down as soon as the lost structure has been blown up. As such, users will not have to wait after coming back from a break or if they forget to press a confirmation box.
Of course, there is going to be more conditions based on circumstances.
That leaves us with player docked inside the structure when it was lost:
Please note asset recovery can be done remotely. There is no need to be in the same solar system, or even docking access to initiate the process to recover your assets. In the same vein, the station owner(s) will never be able to tweak or remove items from other character personal hangars. They will only be able to tamper with corporation hangars and their own character hangars. This works the same way for jobs, or even market orders that are started by an individual. This rule exists to prevent asset appropriation in structures that will be open for public use.
Just like for capture and protection mechanics, we also want this feature to have proper visualization in the game.
Since that’s a lot of information explained in a blog, let’s use an example to make sure everyone grasps the fine details of this feature.
The Tasty Fougasse Republic™ is a corporation that operates a Citadel XL structure in EC-P8R. It has the following properties:
All goes well in the life of the Tasty Fougasse Republic™ until a rival corporation, the Wild Fish’n’Chips Warband™ comes along and destroys the Citadel XL after 3 vulnerability cycles.
The following will happen:
To reclaim the corporation items, someone with sufficient roles can:
And that’s it regarding asset safety. We do hope that by now you have a clearer picture on how new structures are going to work. There is still much we need to talk about, like structure price, acquisition, exact defensive capabilities, fittings, fuel, services or bonuses, so expect more blogs incoming as we flesh details out.
Fly safe, and may the odds be in your favor.]]>
“From the frozen wastes of the Northern-Atlantic Ocean a merry band of travelers will emerge, laden with fine wares, good word of internet spaceships and an unending appetite for beer.”
So goes the ancient prophecy and so it shall be!
A bunch of us from CCP are heading to a couple of amaaazing player run gatherings that happen to be held on adjacent weekends in September. EVE_NT takes place in Nottingham on September 19. and Evesterdam takes place September 26-27 in…Amsterdam as fate would have it. We encourage anyone who can attend either one of these insanely funtastic events to set route - we cannot recommend them enough! In fact, that’s a direct order.
But why go all the way home to Iceland just to embark on another trip mere days later? Instead we decided use the week in-between to meet even more capsuleers and thus was born the EVE EURO Tour 2015! In the week we’ll be hitting up PARIS and BERLIN, two grand capital cities where we know a fair few pilots reside between space adventures.
We’ll be at The Dock Bar in Paris on Monday September 21 and at Cosmic Kaspar in Berlin on Wednesday September 23.
Tickets for these two official events will be made available at 16:00 GMT, Tuesday August 11 on Eventbrite
You will be able to choose between a free ticket and a 25 euro ticket that comes with a specially designed EVE Euro Tour 2015 T-shirt.
We’ll be offering free drinks at the bar for everyone who attends, t-shirt or no t-shirt (please wear some clothes though)!
We’ll be giving out EVE swag at all of the meets we’ve mentioned and last but not least, we’ll be giving showing off Gunjack, a brand new virtual reality game few have yet laid eyes on!
We can’t wait to hang out with all you wonderful people whether it’s in in Nottingham, Paris, Berlin or Amsterdam this September!
P.s. poke your local brewery and tell them to double all production – the vikings are coming.
Alliance Tournament XIII is nearly upon us, with the action kicking off this weekend with last year’s winners The Camel Empire taking on SpaceMonkey’s Alliance. If you’re planning on watching, here’s a few things you should know.
The first weekend is being broadcasted by ISD on two different Twitch channels, http://twitch.tv/isdstar and http://twitch.tv/isdstar2. One channel will broadcast fights in the PE1-R1 solar system, and the other channel will broadcast fights in JB-007. For more details on the ISD broadcast, visit this thread on the forums. The matches start at 14:00 UTC and run until 19:30 UTC on both the 15th and 16th of August.
The second weekend is being broadcasted by CCP, and will feature a full studio complete with player commentators. You’ll be able to watch all the action on our Twitch channel at http://twitch.tv/ccp, and we’ll be uploading all the matches to our YouTube channel as soon as we can. We suggest you subscribe to both! The action kicks off at 13:50 UTC until 21:30 UTC on August 22nd, and continues at 13:50 UTC until 21:30 UTC on August 23rd.
For the final weekend we’re bringing you the full studio along with some special CCP guests who will be talking about what they’ve been working on recently. You’ll be able to see it all at http://twitch.tv/ccp starting at 14:50 UTC until 21:10 UTC on the 29th of August. The tournament culminates with the final day starting at 14:50 UTC with the final scheduled match ending at 20:40
The Prize Frigate for Alliance Tournament XIII - The Imp
Click for full sized version
If you’re competing in the tournament, and like streaming, then we’ve got something you’ll really like. If you stream yourself participating in any match of Alliance Tournament XIII, you can enter the draw to win one of two sets of 5x PLEX. To enter, do the following:
As the tournament is a competitive environment, we recommend that you have a relatively long delay set on your stream to prevent your opponents from using it to help them.
This is also a great source for you, dear viewers, to find a different view of the tournament. Seeing the matches through the eyes of one of the many pilots gives a great perspective and really allows you to see the skill required to compete and win in the Alliance Tournament.
The draw itself will take place after the tournament on 2015-09-02.
If you’re following all the action and want to share your reactions to the match results, where you’re watching from, or anything else about the tournament, one of the best ways to let us know is by tweeting with the hashtag #ATXIII or tweeting to @EVETournament. We may take some of the awesome stuff and put it up on the stream, so if you want a shout-out for your stuff, make sure you tweet at us.
And that leaves just a few administrative things for teams competing
Due to differences in how the tournament tool draws up brackets compared to how the brackets were originally drawn up, the match number assigned to matches will change in the next few days on the schedule on the community site. The time and actual matchups in the first round should not change. If you see a change between the two, please let us know. This was caused by the tournament system having a slightly different (but still valid) bracket generator to the original generator used.
Team flagships have been announced on the forums. If you haven’t seen them yet, you can find them here. The Bhaalgorn is the most popular, followed by the Armageddon. On the other end of the scale, the Dominix, Typhoon, and Machariel were only chosen by one team.
The Prize Cruiser for Alliance Tournament XIII - The Fiend
Click for full sized version
We’re really looking forward to the action of the first weekend, and we’re hoping that you guys enjoy the explosions, the drama, and the mayhem as the tournament unfolds. Who will take the Alliance Cup this year? Let us know.
As always, feel free to join us on the EVE Alliance Tournament Discussion forum, or just tweet at us!
And remember: The best ship, is championship.
(Friendship is pretty cool as well)
This dev blog was written collaboratively with CCP Masterplan.
This dev blog is an account of what happened behind the scenes when EVE Online had one of its longest downtimes in years, on July 15th 2015. We are sharing it with you because we know a lot of players work in the IT field and might appreciate the war stories, and because it gives some interesting insight on the inner workings of a rather unique game cluster. If these things interest you, read on for an account of what happened on July 15th. If you are happy to be oblivious to these details, we recommend the more high level summary we posted here shortly after the incident.
Those of you who have been following us for a long time will doubtless have memories of downtimes extending over days rather than hours. In recent years we have managed to, for the most part, eliminate these terribly long downtimes. On July 15th we were inaccessible to players for 699 minutes, which is slightly longer than the downtimes that occurred on 2nd and 3rd of June 2013, immediately prior to the Odyssey deployment (which itself incidentally incurred a 342 minute downtime due to long running tiericide scripts). Prior to that, Incarna in 2011 saw us down for 963 minutes, but really was the last of the very long deployments that followed our 6-month release cadence. Right now, if we simply auto-reboot without deploying anything, we can be confident that that will take approximately 7 minutes, and if we are deploying we can normally expect to be up well within our allotted 30 minute downtime.
The TQ cluster is made of approximately 250 server nodes. To start up the cluster, all the nodes must perform a coordinated sequence of actions. These actions include assigning IDs to each node, making network connections between every pair of nodes, allocating which solar-systems will run on which node, and loading up the necessary data to allow each node to perform its tasks. Node tasks may include handling the region for a market, or a set of corps/alliances, or skill training for a set of characters.
During the start-up sequence, the cluster progresses through several stages. The cluster will not advance to the following stage until all nodes have reported that they have completed the current stage's actions. It begins at stage -4 and continues up to stage 0. Once all nodes have reported in at stage 0, the cluster is considered ready. One master node is chosen to orchestrate this sequence, nicknamed Polaris. The Polaris node is responsible for checking the stage of all other nodes, and sending out instructions to advance to the next stage once the appropriate conditions are met.
-4: The node has started running and we have a connection to the database
-3: The node has successfully opened a network connection to every other node
-2: Address cache has been primed, this is basically the routing table so each node knows what every other node is supposed to be doing
-1: All startup services have completed their initialization and now some pre-loading of data has begun (market, solar systems etc)
0: The node has been told the cluster is ready, all startup data is loaded and services are ready to receive requests
When we took the server down on July 15th to deploy the first follow up patch to Aegis Sovereignty, we expected no incident – the test servers that we had previously applied the update to had started correctly and were behaving normally, and we assumed it would be a very standard 15-20 minute deployment. Our first snag was our deployment tool taking a very long time to deploy the server package, eventually erroring out and being rebooted shortly before 11.30. At this time we messaged a delay in startup but still didn’t expect anything out of the ordinary – tools can occasionally just fail, timeouts happen and we simply deployed again, this time successfully. Server startup was first attempted at 11.42, by 11.46 we had 12 (out of ~250) nodes reporting that they were stuck, preventing a successful startup. Not to be deterred, our first port of call was the oldest trick in the IT book – “turn it off and on again”.
Startup went faster this time around, but we were still faced with 41 nodes stuck in their “-1” state. We decided to set VIP access on the server, meaning that only accounts with special developer roles can access the server when it’s online, and do a full do-over of the deployment to rule out any locks, conflicts or human error from the first time around. All our suspicions at this time were directly on the environment as being the cause, as the code was working on a test server and none of the data was giving off any red flags.
Unfortunately, 2 startups later, we were no closer to having a healthy server online, so it was time to call in the cavalry. EVE programmers joined Operations for further investigation into the code side of things, meanwhile some other developers discussed the feasibility and likely outcome of a rollback to the previous day’s build. A rollback had not been considered up to this point as nothing had indicated that the code was an issue, but since we had some time while the investigation was ongoing, we figured we would test it.
While EVE programmers worked through the start-up logs, attempting to figure out what errors might be related to the cause of the start-up issues, Ops worked through a number of hardware/OS checks, as we had made various infrastructure changes in the previous days. As the Polaris node is critical to orchestrating the start-up sequence, the server normally hosting the Polaris node was removed from the cluster. A node on a different physical server was chosen as a replacement. This change was an attempt to eliminate any hardware/software failures that might be specific to a single server, however no improvement was seen in the next start-up attempt. Our test of the rollback was confirmed to work, but we still didn’t believe the code to be the issue – we were firm that it was either related to the build package itself, data, or the environment.
Testing further, we decided to deploy our original TQ build to the Singularity test server. The reasoning behind this was that Singularity has DUST data and services, whereas Multiplicity, our EVE Hotfix/Release test server, does not. We considered this an unlikely scenario at best, but worth doing, and Sisi did indeed start up fine. We noticed in out monitoring tools that the EVE process was trying to communicate out on an extra network card, IBM USB Remote NDIS Network Device, that was in the IBM blade servers. This network interface is used to manage the server via IMM (Integrated Management Module) or AMM (Advanced Management Module). Through this interface you can manage the server on a low level such as updating the firmware through the OS or getting information on the server. The network interface gets assigned a Windows self-signed IP address that is not used in public IP version 4 space and has no routes to our private networks in the datacenter. Although the EVE process is not supposed to use this network interface, to eliminate the possibility that it could cause issues we went ahead and disabled the interface. On the TQ side, we disabled CREST and associated services to rule out everything we could, made a change to the name of the server package so we could ensure there hadn’t been bad overwrites, and tried again. At 14.21 startup had completed, with 53 nodes stuck at “-1” status.
We tried a few long shots over the next hour as developers continued their investigations. Our next idea came at 15.29, when EVE Dev presented a plan to empty some of the new sovereignty records from the database, backing them up in temporary tables, to see if that data was the cause of the issue. The reasoning behind this was that at gameplay level, the most significant difference between start-up on Tuesday and on Wednesday was that on Tuesday all the sovereignty structures were in a fresh state, before any campaigns or vulnerable windows had been generated. In reaction to this, CCP Lebowski and other QA began generating tremendously large amounts of Entosis campaigns on Singularity, to see if they could cause a comparable spike of errors, or a failed startup. Despite loading Singularity with almost double the amount of sovereignty reinforcement events and vulnerability windows as TQ, it continued to start up perfectly every time. We had the script tested on Duality by 15.48, confirming it worked as expected, and it was off to TQ with it. The script ran, the tables were confirmed to be empty, and at 16.33 we anxiously watched the progression of the start-up sequence
This was great news. Now we had to figure out why clearing out the reinforcement and vulnerability data allowed the server to start up cleanly.
Opening in this state was not an option, considering we had just effectively deleted a day’s worth of sovereignty campaigns, so investigations continued. By this time, there were around 8 EVE programmers participating in the investigation, with several Operations staff conducting their own investigations in parallel, and practically every QA in the building trying to replicate the issue on Singularity. By 17.10 we made the next change - the vulnerability window data only was re-added to the DB. The next start-up would help indicate if it was this or the reinforcement events that were blocking start-up. We deployed the change, started up successfully, and had a vaguely smoking gun – the presence of campaigns themselves was somehow causing the issue. EVE Dev focused their investigations accordingly. The remaining campaign data was then re-added back to the database.
A theory about what might cause the stuck nodes had been formed: during start-up, the nodes running solar-systems with one or more sovereignty campaigns must talk to the nodes managing the related alliances. One of these queries is to look up the alliance's chosen capital system. According to the design for the new sovereignty system, changes to an alliance's capital system will take several days to come in to effect. During the days following the initial feature deployment we wanted alliances to more easily settle in to these new rules, and so we added a configuration option whereby we could temporarily override the 7-day timer with a much shorter delay.
Our theory was that if these cross-node calls to lookup the alliance capital were interacting with the mechanism for loading configuration data (as used to override the default delay) in a particular way, it could lead to a cross-node deadlock. That is, the solar-system node that loaded the campaign is waiting for the alliance node to respond with the info it needs. Meanwhile the alliance node has loaded the capital configuration settings and is sending an update to that capital solar-system telling it "You are the capital, you should use a +2 defense modifier". The alliance node will not respond to any new requests until the solar-system node acknowledges the updated capital status, but the solar system node will not respond to any new requests until the alliance node answers the campaign query. We submitted a code change that removed the configurable capital delay and should have eliminated the possibility of this causing a deadlock. During the next startup at 18.12 we were met with 51 nodes at “-1” – back to the drawing board (after one quick reboot just in case).
So what did we know by that point?
We decided to completely remove campaign loading at start-up. The consequence of this was that the background spawning of command nodes wouldn't happen, but otherwise the sovereignty structures should load up as normal. Note that this is not intended as an actual fix, instead it is to give us a new data point about what conditions cause a successful/failed start-up. This experimental change (Hotfix#2) did indeed get us started up at 19.15, and led us to experiment #3 - what would happen if we now loaded the campaigns, but only after a brief delay, to allow everything else to finish starting up first?
We also tried re-enabling the campaign loading (that we had previously disabled in Hotfix#2), but delayed it and let it run asynchronously to the rest of the start-up. At this point we were hit with some slight snags, with Perforce sync hangs causing delays in our build system, and some unrelated data storage issues, but with every hotfix we were getting closer and closer…
to pizza, which mercifully arrived at 19.48 while our 3rd hotfix was deploying. TQ failed to start up again with this change, which was interesting because in Hotfix#3 we were loading the campaigns independently of the rest of the start-up tasks, and yet loading them was still able to break some nodes.
Reinvigorated by a ping-pong table full of pizza we redeployed Hotfix #2 for more experimentation and LIVE CONSOLE EXPERIMENTS.
Once all nodes were up and we had verified that solar-systems had loaded ok, we opened up a python console on the server, allowing us to issue commands and observe the results in real time. We performed a few checks to ensure that no campaigns were loaded on any nodes. As expected, they all reported that their campaigns were empty. We then requested all nodes to load up the campaigns that they were responsible for. Immediately the cluster started to become slow and unresponsive. After a few minutes, we started to see several nodes die and drop out of the cluster. As this happens, any solar systems on those dead nodes get remapped to remaining live nodes. We were now down to around 200 nodes out of 250. We then instructed the cluster to run the campaign loading sequence again. What we expected to see was each node log out the campaigns it knows about, and then report that no further campaigns required loading (as they were all in memory). What actually happened is that again the cluster became unresponsive for a few minutes, and when everything settled down, a bunch more nodes had also died. This was most strange, as all that should have happened was the nodes logging out some info, as they had nothing new that required loading. A thought occurred: maybe it wasn’t actually the campaigns themselves that were causing the issues - what if it related to the logging that happens around the campaigns? As the cluster was now in a bad state due all the dead nodes, we requested a reboot (staying on Hotfix#2) for some more tests.
Via the console we modified the campaign loading functions so that they performed the load-from-DB operations normally, but all their logging operations were disabled. We then repeated the same test from above - instruct all nodes to load their campaigns. This command completed almost instantly, and the cluster remained perfectly healthy. WTF! Further checks indicated that all campaigns had indeed successfully loaded. We then repeated the second-time load test, again using the loading functions with the disabled logging. This also completed instantly, reporting that no new campaigns needed loading.
As a final test, we then switched the disabled logging back on, and issued another load-campaigns instruction. The cluster then regressed back to the earlier behaviour, showing excessive delays as nodes began to die off. We seemed to have found the culprit (even if we didn’t know exactly how/why!). For some reason, the logging channel used by the campaign system on TQ appeared to degrade node performance to the point that some of those nodes would actually drop out of the cluster.
Note: These channels refer to the logs used by developers for testing feature operation and investigating defects. They are independent of the activity logs that you might see in your character wallets, for example, or that GMs use in their customer service duties.
Hotfix #5 was requested at 21.48, containing what we believed would mitigate the issue. All logging within the campaign system was entirely removed, but otherwise the code was mostly unchanged. If this change led to a successful startup, we would be close to being able to re-open TQ. It was deployed to TQ at 22.07. We had a good startup by 22.22 and able to begin VIP checks to ensure that no sovereignty data had been damaged by our experiments. One problem was found with a duplicate campaign, but that was easy enough to clean away. We brought CREST back online at 22.38 and lifted VIP to open TQ to all players at 22.41.
Aftermath – Monday 20th July
Following our previous adventures in clusters failing to start, we needed to get to the bottom of why one particular log channel (the one used by sovereignty campaigns) on one particular server (Tranquillity) could cause extreme server stability issues. Therefore we scheduled some VIP time on TQ where we could perform a few experiments. Our goal was to find the simplest possible code that we could execute that would reproduce the symptoms in order to aid further investigations. We connected to a python console on a TQ node - from the console we could interactively 'poke at things' to see what we could break. (Prior to this, we had gone through the same steps on the Singularity and Duality test servers, and all tests had completed without triggering the error condition).
We had prepared a series of escalating steps that we intended to follow. Each one would progressively add more factors in to the mix, until the issue could be hopefully be reproduced. As it turned out, we didn't need to go very far at all! Here is what happened:
Firstly we had two logging channels - a generic channel, and then the specific channel used within the sovereignty system for logging campaign activity. We then validated that both channels were working, by executing the following code on a single node.
# generic_logger is a reference to a generic log channel
# campaign_logger is a reference to the log channel used by sovereignty campaigns
# Step 1a: Assert that output to the generic logger works correctly
generic_logger.warn('The quick brown fox jumps over the lazy dog')
# Step 1b: Assert that output to the campaign logger works correctly
campaign_logger.warn('The quick brown fox jumps over the lazy dog')
As we run this we were also observing the log output in real time via Splunk. We did indeed see each line appear once.
Next we run step 1a on all 250 nodes in parallel at the same time. Immediately we see 250 entries pop up on the Splunk display. Then we do the same for step 1b, and see the same result - each node logs one instance of the line, and each line shows it came via the campaign channel.
So far so good. Now let's log a bit more data, but nothing that should cause any problems, right? Right? Hmm...
# Step 2a: Log the same line 500 times per node, on the generic log channel
[generic_logger.warn('The quick brown fox jumps over the lazy dog') for i in range(500)]
# Step 2b: Log the same line 500 times per node, on the campaign log channel
[campaign_logger.warn('The quick brown fox jumps over the lazy dog') for i in range(500)]
For those not familiar with Python, line 2 will loop 500 times, outputting the warning message once per loop via the generic log channel. Line 5 does the same thing, but to the campaign log channel.
First we ran step 2a on all nodes in parallel. The command completed instantly, and we saw a spike of 125,000 lines (250*500) on the Splunk graph. That might seem like a lot of logging, but it isn't anything the system can't handle, especially in small bursts like this. Next we ran step 2b in the same way. This was where something curious happened. The correct number of log lines did show up in Splunk (The logs do show something!), but the command did not appear to return as immediately as it did for step 2a. In fact it took a few minutes before the console became responsive again, and the returned data indicated that several nodes did not respond in time. Looking over the status of the cluster, those nodes were now showing as dead. Somehow this innocent log line had managed to cause these nodes to time-out and drop out of the cluster.
Well that was easier than we thought! We didn't even need to start doing anything with campaigns or the database to reproduce the dead cluster. When a developer cannot rely on simple logging actions to not kill his production server, he is going to have a bad day. Much like we did on Wednesday 15th. Having isolated the problem down even more, we restarted TQ and then gave the go ahead to drop VIP and opened up as normal.
As mentioned on a few occasions in the time-line above, we had never seen this happen on any other test server before or since. There is something unique to the way that TQ operates (or is configured). Investigations are continuing to try to track down why this logging behaviour happens only on TQ, and only on specific log channels. We know that TQ certainly operates at different scale in terms of the amount of hardware, but so far other experiments have suggested that this is not simply a matter of number of nodes. The investigation continues…
Greetings industrious Capsuleers!
This is CCP Fozzie bringing you another dev blog covering our Nullsec and Sovereignty changes coming on July 14th. Today’s dev blog covers the July round of our planned changes to Nullsec PVE and system infrastructure upgrades. This is the fifth major dev blog for the Summer of Sov. We’ll have one more blog summarizing the new system so that people don’t need to dig through five other blogs to get all the information, but this is the last blog that is expected to contain a lot of newly revealed information before our July 14th release date.
Unlike yesterday’s blog which covered quite a few disparate topics, today’s blog will be focused on changes to PVE and system upgrades. We’ll discuss the changes made earlier this year, the changes planned for the big deployment on July 14th, and begin some discussions on changes we’re working on for later this year.
At Fanfest this year we announced the last round of Nullsec PVE and infrastructure updates, which were then deployed in our Mosaic release on April 28th.
These changes focused on the construction and deployment of infrastructure upgrades, as well as mining yields and values in Nullsec space.
We reduced the volumes of Infrastructure Hubs and their upgrades significantly to allow them to be deployed more easily, as well as enabling deployment of structures from fleet hangars. We also replaced NPC sell orders for Infrastructure Upgrades with blueprints that allowed capsuleer industrialists to produce the upgrades themselves, including producing them in their own Nullsec space for easier logistics.
We made three connected changes for Nullsec, Wormhole and Lowsec mining, doubling consumption of Zydrine and Megacyte, rebalancing the mineral content of the Nullsec and Lowsec ores, and completely revamping the content of the mining anomalies generated by the Ore Prospecting Array system upgrade.
We also made some tweaks to the rate of index accumulation for the Military and Industrial Sovereignty Indexes, in preparation for the Activity Defense Multipliers kicking in this July.
All the details of these Mosaic changes can be found in this previous dev blog.
We’re still keeping a close eye on mining rates and ore values in Nullsec, and the results so far are very promising. In the 10 weeks since Mosaic, approximately 20% more ore by volume has been mined in Nullsec than in the 10 weeks before Mosaic. In the same timeframe Lowsec mining has also risen by approximately 11%. So far prices for Nullsec ores are remaining robust and the Nullsec share of all mining done in EVE is approaching record levels.
At this stage it appears that these Mosaic updates have done a good job of improving the value of Nullsec mining gameplay and easing infrastructure logistics bottlenecks without causing serious problems in other areas of space. This is a balance that we are hoping to hit with our July changes as well.
On July 14th we will be deploying the next big set of Nullsec and Sovereignty changes as the second part of the Aegis release. By now most of you will be familiar with the changes to the Sovereignty capture system that are coming on the 14th (if not, check out some of the handy dev blog links at the top of this blog). We’re now unveiling another set of changes to Nullsec PVE and infrastructure upgrades coming with this July 14th release.
By far the most important of the Sovereignty Infrastructure Upgrades is the Pirate Detection Array. This upgrade provides a constantly respawning supply of combat anomalies full of pirate NPCs to fight. These sites are a key part of the Nullsec economy, and form a huge part of the greater EVE economy. A very large proportion of the ISK that enters the EVE economy every day consists of the bounties obtained from these anomalies.
This makes the Pirate Detection Array one of the most powerful tools for adjusting Nullsec PVE opportunities, and also means that we must act with utmost caution when changing these upgrades.
For our July 14th release we are making a series of significant changes to the effects of the Pirate Detection Array upgrades, in the form of added anomaly spawns.
The goals of these changes are to:
This is a tricky balance, and we will need to watch the results of our changes very carefully and be ready to make adjustments as needed. We’ve also been consulting with CCP’s research and economics experts to make use of their expertise and give us the best chance of getting this right.
In this release, we are increasing the number of guaranteed anom spawns provided by each Pirate Detection Array level from 4 to 7. This means that a fully upgraded system will have 35 anomalies instead of the current 20 (a 75% increase). This allows more pilots to operate at their current levels within the same solar system, increasing potential population density.
The types of anomalies added serves as the method by which we are compressing the difference between higher truesec and lower truesec systems. The new anomalies added to the best systems will be of similar quality to the ones that already spawn there. However the new anomalies added to the lower quality systems will be significantly better on average than those available now.
As an example, a fully upgraded -1.0 system will gain the following 15 anomalies in addition to those that spawn there now:
+2 Sanctums, +3 Havens, +2 Forsaken Hubs, +4 Forsaken Rally Points, +2 Forlorn Hubs, +1 Hub, and +1 Forlorn Rally Point.
These additions allow for more players to engage in their PVE activity in the same system, but doesn’t significantly skew the average anom value.
In contrast, a fully upgraded -0.1 system would gain the following 15 anomalies in addition to those that already spawn there now:
+3 Havens, +1 Forsaken Hub, +3 Forsaken Rally Points, +2 Forlorn Hubs, +2 Hubs, +2 Forlorn Rally Points, +1 Port, and +1 Hidden Rally Point.
These new anomalies do not match the average quality of those available in the best systems, but that are much better than the average quality of the anomalies available in current -0.1 systems.
We believe that these changes have a good chance of hitting the correct balance for Nullsec without causing undue disruption to the economies in other areas of space.
Survey Networks and Entrapment Arrays are system upgrades of mid-low popularity under the current system, as their somewhat random nature makes them difficult to evaluate. Survey Networks increase the chance of Data and Relic sites spawning within their systems. Entrapment Arrays increase the chance of combat signatures (complexes) spawning within their systems.
Both of these upgrades are a bit below the curve nowadays, and so we’re making some fairly large changes to both. The spawn rates generated by all levels of Survey Networks and Entrapment Arrays will be doubled in the July 14th Sov update. We will be keeping a close eye on the results of these changes to ensure that we don’t flood the market with the drops from these sites, and we’ll step in and make more changes if needed. However we currently believe that these new spawn rates will be much closer to the ideal balance for these two system upgrades.
Back in the Hyperion release last year, we made some changes to Vanguard Incursion sites in Nullsec and Lowsec. We increased the maximum number of pilots allowed in the fleet before hitting diminishing returns by 50%. These changes were intended to help stimulate activity in Nullsec (and by association lowsec) incursions by allowing pilots in the more dangerous space to bring more DPS ships to compensate for their less blingy hardware. At the time we said that we’d be watching how those changes were received and re-evaluating down the road.
Well we’ve received positive feedback about that change from Nullsec and Lowsec Incursion runners, and we’re now ready to extend that same change to Assault, HQ and Mothership sites in Nullsec and Lowsec. This means that Nullsec Assault sites will take up to 30 players before diminishing returns, HQ sites will take up to 60 pilots, and Mothership sites will take up to 120.
We hope that these changes will be well received by Nullsec and Lowsec Incursion runners, and that more Nullsec and Lowsec pilots will give this challenging group PVE content a try.
One final set of changes that we are implementing in Aegis is a set of tweaks to Nullsec wormhole spawning and Quantum Flux Generator upgrades. Some members of the CSM (I’ll let them identify themselves if they wish) approached us in recent weeks with balance concerns about wormhole travel for Nullsec entities. We took a look at their concerns and decided to make some tweaks to help ease them.
The changes we are making are not intended to kill strategic wormhole travel. We believe that wormhole travel provides an exciting and somewhat unpredictable way to roam across long distances. We are beginning with a set of tweaks to Nullsec wormhole connections in Aegis, intended to ease some of the concerns around WH power projection without negatively impacting wormhole residents or eliminating the ability of Nullsec entities to roam through wormholes.
These changes consist of:
We are also making some slight tweaks to the Quantum Flux Generator system upgrade in our July 14th release. These are intended as a slight buff to anyone who uses Quantum Flux Generators for PVE daytripping, while also addressing concerns expressed by some CSM members. With these changes we still don’t expect that most alliances will find the Quantum Flux Generators to be extremely valuable, but hopefully their PVE value should increase somewhat.
All of the July 14th PVE changes are available for testing on our Duality test server right now! They’ve actually been there for a while but we felt it was a pretty safe assumption that nobody was going to spend their time ratting on the test server without being informed about the changes first.
As we have mentioned in the past, one of the highest priority areas for continued improvement beyond our main summer sov release is improvements to the Activity Defense Multiplier. The first iteration of the Defense Multiplier is completely tied to the old sov index values. These make a decent measure of the most common types of Nullsec PVE and greatly simplify the transition from the old system to the new. However there are a great many forms of local Nullsec activity that are not counted by these indexes and there is a great deal of room for improvement.
In upcoming releases we are planning to make significant updates to the Activity Defense Multipliers to make them more accurately reflect real system occupancy.
The biggest area of improvement would likely be in expanding what activities feed into the Defense Multiplier. Unfortunately there are some activities that cannot be made to powerfully influence the Multiplier without becoming exploitable (PVP kills and Manufacturing jobs are the classic examples). However we are investigating ways that some expanded activities such as Planetary Interaction and Data/Relic sites can contribute to the index, as well as keeping the option open of including manufacturing, trade and research in some limited capacity if they can be made to work.
We are also investigating options around allowing activity by members of the Sov owning Alliance to count more heavily than activity by others.
Another area where we see great potential for improvement is with the Encounter Surveillance System. This mobile deployable structure was introduced in Rubicon 1.1 as a way for Sov owners to increase their profits if they are willing to add risk of theft. They are still seeing some use, however we believe they can do much better. The basic concept is strong, but they are in need of iteration.
We are investigating an update pass on the ESS in which we would simplify its operation by converting it to use the Entosis Link for sharing and stealing, restrict its deployment locations somewhat, and increase the potential value to match the higher risk. The ESS has great potential for allowing Sov holders to choose the level of risk they are comfortable with and receive rewards that match. A revamped ESS also has potential to provide excellent content for roaming PVP forces as well.
Expect to hear more about potential ESS changes in the coming months, as we continue our investigations and solicit your feedback.
One other concept under investigation at the moment is a new Infrastructure Upgrade that would generate dedicated group content for Sovholders. We have never been particularly satisfied with how the majority of Sov upgrade PVE content tends to lean towards solo or multibox play. There is huge potential for reliable and interesting group PVE content in Nullsec. Team Five 0 is hoping to be able to take what we have learned from developing Burner Missions and combine it with the new NPCs and AI under development by Team Space Glitter to create some compelling new content that would only be available to groups of pilots working together within Sov Null. Our leading concepts at this point make use of an Incursion-like scaling payout based on character numbers. These designs are still at an early stage, but we expect to spend the next few months discussing these goals with you and working towards some exciting new content.
Thank you for joining us today for this dev blog. We are very excited to be releasing the new Sov system for all of you this week, alongside these PVE and Infrastructure updates. Huge thanks to everyone who has provided us feedback all throughout this process, and to everyone who has joined the community discussions that provide us with such a great source of inspiration.
From all of us here at Team Five 0 and the whole of EVE Development, good hunting!]]>
Hello dauntless capsuleers! This is CCP Fozzie bringing you another dev blog about the big sovereignty capture changes coming on July 14th.
Here in CCP’s Reykjavik offices we’re hard at work tweaking and polishing the new system for release, and we can’t wait to roll it out for all of you soon. This is the fourth major dev blog providing information about the Summer of Sov, and you can expect two more after this, one covering some hitherto secret changes and another summarizing the whole system so that people don’t need to dig through five other blogs to get all the information.
Today’s blog will be a bit of an information dump, covering quite a few topics related to the new system and its rollout to the Tranquility server.
With the July 14th deployment date of the new sov capture system fast approaching, it’s important that everyone be aware of how the transition from the old system to the new one will play out.
Since the basic functions of TCUs, IHubs and Stations are remaining constant, the transition for most of these structures will be fairly straightforward. We are endeavoring to cause as small of a disruption as possible to any sovereignty conflicts that may be in progress on patch day.
SBUs do not play a role in the new system, and will begin to be phased out this month. During the patch downtime all SBUs in space will be destroyed, and SBU blueprints will be rendered inert. Any new SBUs launched into space after patch day will explode one minute after appearing in space.
At the same time, we will begin the process of phasing out SBUs and their blueprints from the game. NPC buy orders will appear for SBUs and un-researched SBU blueprints so that players can choose to recoup some of the value of their SBU stock at their own pace. After a few months of voluntary buyback we plan to convert all SBUs to TCUs, SBU blueprints to TCU blueprints, and remove the legacy market entries for these types.
Under the new system, only one TCU and one IHub will be allowed in space per system. As part of this transition, on the patch downtime any TCU or IHub that is in space but not in an online state will be destroyed. This will ensure that only one TCU and one IHub per system will remain. We advise all Alliances to ensure that their IHubs are online before the release downtime on the 14th.
In order to prevent unnecessary confusion and complication on patch day, all Infrastructure Hubs, Stations and TCUs that are in reinforced, vulnerable and/or damaged states will be reset to full health and full owner control over the patch downtime. This means that a sov structure that has a reinforcement period straddling the patch downtime will no longer be reinforced after the patch deployment is completed. If the structure’s normal vulnerability period (as determined by the combination of your Alliance’s vulnerability timer and the system’s Activity Defense Multiplier) extends over the time of the server startup, the structure will begin in a vulnerable state with 100% control by its owning alliance. Otherwise the structure will begin in a secure state and become vulnerable at the beginning of its next vulnerability period.
Any stations that are owned by corporations outside of an Alliance during the patch downtime will immediately enter a Freeport reinforcement period for approximately 48 hours from the server startup point.
In order to keep the disruption for ongoing sovereignty warfare to a minimum, we are not currently planning any other “sov invulnerability period” after the patch (beyond the one time removal of reinforcement states over the patch downtime).
Starting immediately after the July 14th downtime, Alliances will be able to designate one of their systems as an Alliance Capital. In order to allow Alliances to gain the benefits of their capital quickly after deployment, we plan to make all capital system selection and changes apply very quickly (as close to instantly as possible given server limits) for the first two days after deployment. This means that between downtime on July 14th and downtime on July 16th Alliances will be able to set their capitals and change it as often as desired with no waiting period. Once downtime on July 16th has passed, changes to Capital system settings will require 7 days to take effect.
The one exception to the 7 day waiting period for Capital systems is that anytime an Alliance only has Sovereignty over one star system (as determined by TCUs) that one system will automatically become the Alliance capital. This means that Alliances taking their first system will not need to wait a week to gain the benefits of the Capital system defensive bonuses. It also ensures that when an Alliance is pushed to a final stand in its last system, that system will always gain the capital defensive benefits.
Any other changes to Capital systems will always require 7 days in order to take effect. This includes cases where an Alliance that controls multiple systems has lost its previous capital and is setting a new one.
As many of you already know, the ability to set your Alliance default vulnerability timer has been available in game since the Carnyx release on June 2nd. So far this setting has only pre-loaded the value in the database in preparation for the next Sov release, but on July 14th it will begin applying to all Sovereignty structures belonging to your alliance. This means it is very important for every sov-holding alliance to choose an appropriate vulnerability timer before the 14th to ensure that their structures match their alliance’s primary time zone.
The setting can be found on Tranquility right now within the Corporation window, Alliances tab, and Home subtab. Characters with director roles in the Alliance executor corporation can edit the vulnerability timer by clicking on the cogwheel on the right. The image below displays where this setting can be accessed.
Sovereignty structures belonging to Alliances that have not chosen a default vulnerability timer will have their vulnerability windows automatically centered on 11:00 EVE Time (downtime).
For those players who have not yet had a chance to try out the new system on the Duality test server, we also want to go over some of the details around deploying structures in the new system. This information can also be found in the show-info window for the Sov structures, but we want to make sure the maximum number of people see it.
In the new Sovereignty system we are largely doing away with the launch/anchor/online process inherent in the older style of EVE structures. Instead, TCUs and IHubs will use the newer spacecomponent deployment system, and will feel quite similar to the mobile structures introduced in recent years.
Both TCUs and IHubs will now need to be deployed at planets. Their location restrictions will actually mirror those of Customs Offices. They must be no closer than 350km from the planet and no further than the distance from the planet to the warpin point plus 1000km. Existing TCUs will be grandfathered in and won’t need to be moved, but any newly deployed TCUs will now need to be placed at planets.
Only one TCU and one IHub may exist in space in each system at one time. This means that if there is already a copy of that structure somewhere in the system you will receive an error when you attempt to launch your structure. Both TCUs and IHubs are now globally visible on overviews everywhere in the system, so you’ll never have trouble finding existing sov structures.
Only characters that belong to an Alliance will be able to deploy a TCU and/or IHub, although no corporation roles will be required.
You may deploy the TCU or IHub through the right click menu, radial menu, or by simply dragging the structure from your inventory into space. Once deployed into space, the TCU or IHub will exist in a neutral state, owned by the Secure Commerce Commission NPC corp. To complete the claim process you must activate an Entosis Link on the neutral structure to capture it for your Alliance. This means that the process of getting an active TCU or IHub into space will be much faster under the new system (total time will be about 12-15 minutes instead of 2-8 hours under the old system). However the process now requires that ships remain on grid for those minutes and other players can challenge your claim and attempt to capture the structure themselves.
When TCUs and IHubs are first launched into space, they will automatically find an appropriate location nearby to anchor themselves. They will always deploy on a spot at the center of a grid (in the same way that starbases deploy to the center of the grid when anchored) to reduce the chance of grid conflicts near the structure. They will also automatically find another suitable nearby location if their first location overlaps with ships or other items. This means that when a TCU or IHub launches it may appear quite a ways away from the ship that launched it.
The deployment process of Outposts will remain largely the same for this release. Deploying a new Outpost will still require your Alliance to have an active TCU in the system, and the outpost creation process will still require the same platform filling procedure. Team Game of Drones is hard at work on the system that will replace this process in the future.
Once you have successfully captured the Sovereignty structure, ownership will transfer to the executor corporation of your Alliance. Infrastructure Hubs will create a new maintenance bill for the executor corp, with a 24 hour grace period before the first payment is required. TCUs will no longer have any bills under the new system. If bills for Infrastructure Hubs expire before they are paid, the structure will automatically self-destruct. Directors in the corporation that own the structure (executor corp for newly claimed/captured structures) can transfer ownership to other corporations within their alliance using the right click menu on the structure when there are no outstanding bills.
When a corporation leaves an Alliance, all Sovereignty structures belonging to that corporation will transfer their ownership to the executor corporation.
To ensure that anyone starting a Sovereignty capture event will also be able to complete the process, characters must be in a valid capsuleer Alliance in order to activate an Entosis link directly onto a TCU, IHub or Station. This restriction does not apply to Station Services.
We know that many of you will be eager to make amazing third party applications and websites, either for public use or for your own Alliances. That’s why we are opening up the new Sovereignty system to Public CREST. Everyone will be able to access a public list of all active Sovereignty structures in the universe, all details about reinforcement timers and the scores of active capture events. They will also have access to capital systems and default vulnerability timers for every Alliance. Finally, the XML API will contain the notifications triggered whenever Sov structures are attacked.
All the details on these Public CREST exposures can be found in CCP Foxfour’s developer blog here.
For the past few weeks we have opened the Duality test server with an in-development version of the new sov system so that players could try it out and help us refine the user experience and find bugs. We also put together a playtest competition in which Alliances could fight over Sovereignty of a region to gain bragging rights and cosmetic rewards. We want to express our thanks to every player who has taken the time to log onto Duality and help submit bug reports and feedback on the new system. You’ve all been a huge amount of help.
We want to congratulate all the Alliances who fought for Providence on Duality over this last month.
The final score for each alliance is obtained by adding one point for each of the three core Sovereignty structures (TCU, IHub, and Station) that they control within the competition area.
Fourteen alliances entered the competition and were each given a starting constellation within Providence or Catch. When all was said and done five alliances remained.
Every alliance that participated in the playtest will have their name added to the description of the Entosis Link I blueprint original, as notable capsuleer alliances that led the way in discovering visionary applications of the new technology.
The final scores are:
Pandemic Legion: 198
Spectre Fleet Alliance: 40
No Not Believing: 35
Fidelas Constans: 7
In a future release we will be listing all the competing alliances in the description of the Entosis Link I BPO, with a special mention for PL as the most successful testers.
We have also drawn four of these five alliances for another special honor, having meta variations of the Entosis Link named after them. The winners of this draw were selected with Chribba’s dice. All the details on how this selection process was executed can be found in this forum post.
The default naming convention for the new Entosis Link variations will be to include the alliance ticker of the winning alliances as the “flavor” name. We will be open to considering alternate suggestions from the winning alliances, but those suggestions will be subject to approval by CCP’s development team and will only be accepted if we determine that the names fit into the EVE universe. Direct references to other intellectual property will not be accepted for obvious reasons. You know who you are.
The alliances drawn for the module naming are:
Pandemic Legion, Spectre Fleet, No Not Believing, and Affirmative.
We’ll be in touch with your team captains and alliance executors to discuss the details.
Thanks once again to everyone who participated on Duality so far, and remember that Duality remains open for people to keep trying out the new system right up until release.
Thanks for taking the time to read this update blog, and I hope it’s been informative. We’ll be continuing our communication over the next week as we prepare to launch this huge revamp of EVE’s Sovereignty capture system on July 14th. We have one more blog full of announcements coming later this week, and after release we will be continuing our iteration on Nullsec and Sovereignty with help from your feedback. Huge thanks to everyone who has provided us with your feedback so far!
From all of us at Team Five 0 and Team Pirate Unicorns, fly safe!]]>
Well, maybe someday, in a not-so-distant future, they will ask again. And the leaders and great commanders of New Eden may actually answer yes.
Aegis promises to deliver some of the biggest changes to New Eden in some time with the new sovereignty system on July 14th, but we want to make sure no details get overlooked so in this blog I’m going to quickly go over all the ship and module changes we have coming for you in the first part of Aegis on July 7th.
FIRE ZE MISSILES!
Let’s start with a package of missile-related balance changes.
First of all, we are introducing two entirely new module groups to enhance performance of all missile systems in the game.
For both module groups we are starting with a Tech I variation, a ‘Compact’ meta variation with reduced fitting requirements, and a Tech II variation. You can find details on their statistics in this forum thread.
The second change, which has been requested ever since the Great Drake Nerf of 2012, is a direct buff to Heavy Missile Damage.
All heavy missile damage will be increased by 5%.
We don’t necessarily expect Drakes and Tengus to once again blot out the sky, but, it may provide some more viability to certain hulls and also grant some more interesting choices between Heavy Missile Launchers and Rapid Light Launchers, especially when combined with Missile Guidance Modules.
And lastly, for missiles, we are going to reduce the volume of all Torpedoes by half. This means you can fit twice as many torpedoes in your launchers before having to reload and also frees up some cargo space.
Now, let’s tranision from making missiles better to making drones a little worse:
Even though we have chipped away at the Ishtar’s power, and even though it’s popularity does seem to be in decline, it’s still pushing around twice as much pvp damage as other top tier ships so we don’t feel too bad going for one final tweak to it.
In Aegis we will be making the following changes to the Ishtar:
Overall this should lead to a huge decrease in power for the vastly more popular shield fits, and especially for those using 100mn afterburners.
We’ve done a lot of talking about the Ishtar in the last few months, but drone bonused ships in general have been performing extremely well. The Gila, Dominix, Tristan, Vexor, Vexor Navy Issue, and Stratios all make top lists for usage and damage in their respective classes. For this reason, in Aegis we will also be making a small nerf to all Drone Damage Amplifiers.
You can find the details of that change in this forum thread.
We were looking into a set of Battleship and Battlecruiser changes as well, but unfortunately we had to delay most of that pass until a later release. One of the intended adjustments will make its way into Aegis though, a nice buff for the Tempest.
The Tempest’s Minmatar Battleship bonus to rate of fire will increase from 5% per level to 7.5% per level.
And to finish things up, let’s not forget the best flying wing to be invented since Kit Cloudkicker’s ride in Tailspin, the Hecate.
Here is some of what CCP Fozzie has to say about this little monster, “With 5 turrets and a 5% RoF bonus, the Hecate enjoys 10 effective turrets, one more than the Confessor and Svipul. It is also the first T3 destroyer with an active tanking bonus. Since both the damage bonus and the active tank bonus come in the form of RoF reductions, capacitor will be a definite challenge for the Hecate and cap boosters should be common.”
If you want to know more, check out this forum thread!
That’s all for now! Fly safe and we’ll see you next time.
Greetings honorable Capsuleers,
As some of you may already have noticed, we have been running our Technical Support through a beta version of a new Help Center since October last year. This was to battle test the transition of all our services to a new solution which has since last Friday (2015-06-26) replaced the ticket part of our old web and in-game ticketing system, and Knowledge Base. Instead of continuing to rely on the out-of-date home grown solution we‘ve had for a long time now, we decided to go for an industry leading 3rd party solution after pretty vigorous comparison testing.
Note that we are only talking about changes to the system itself, not the people behind it. Rest assured that you will still be dealing with the same old friendly and helpful EVE GMs when you contact us.
There are several reasons we moved to this new system but the driving force was our desire to provide the best support possible for our players. The benefits with this change are: greatly improved self-help tools; search features; a rating system; social media integration (starting with Facebook and Twitter); chat support features; and a much smoother overall experience for you. For chat support, we‘ve been wanting to offer it where it makes sense for a long time. Not all of these features will be available from day one (such as social media and chat support) but it is our hope the transition will start making everyone‘s support experience better immediately.
Any tickets already filed in our old system, will be concluded there and you can still access those by clicking My Tickets on our old support web and/or from the EVE client. All new tickets that are created from here on out will be routed through our new system.
The new help center can be found at http://support.eveonline.com, which redirects to https://ccpcommunity.zendesk.com/.
With the new Help Center, we have removed the in-game ticket system completely. By doing this, we aim to simplify and improve the user experience. Furthermore, this will make maintenance easier and more effective for us; maintaining two separate front-ends of our ticket system with different deployment pipelines has proven difficult. Often one system or the other received less support than we would have liked (usually the in-game version) resulting in a less than optimal user experience. We are however planning to add in-game notifications for when your tickets are replied to by GMs.
In the works
Please keep in mind that this is all work in progress. Although the basic setup is ready, we will be adding content, localizing it and streamlining the system in the coming months. While we hope that the transition will be smooth, it‘s almost inevitable that we‘ll run into some snags and snafus in the next few days and possibly weeks. We are especially aware of the lack of localized support in the new system, and resolving this is our first priority. If any further issues do pop up, we hope that you‘ll be patient with us while we work to resolve them. On that subject, if you do run into any issues or if you have some great ideas for us, please let us know in the comments thread, or by emailing email@example.com.
And as always, thank you for your patience. :)
Lead GM Panzer]]>
We announced on The o7 Show we are planning to make some changes to the way fleets work. Since then we’ve had lots of amazing player feedback, and based on that feedback we’re making some tweaks. Unfortunately this means we’ve had to push back the release of these changes to the August 25 release.
What are the planned changes?
As announced: Fleet Commanders, Wing Commanders and Squad Commanders will only be able to fleet-warp to public objects and other fleet members. This means you cannot fleet-warp to the following:
After feedback and discussion, we’ve done some magic on our code and now a wider range of objects will be broadcastable as a Warp-To:
What are the goals of these changes?
Encourage individual fleet member participation
We believe that every player’s actions have an impact on New Eden. Sometimes that impact is small, little more than a ripple. Other times it is a tsunami, shattering empires and destroying dynasties.
Fleet combat is an exciting and engaging part of EVE Online. Individual player actions are the foundation of fleets. Getting the primary target stasis webified to allow your buddies to hit for full damage. Pulling off that critical jam on enemy logistics. All actions of individual players have the potential to make or break fleets.
Fleet-warping discourages individual player participation. It’s more effective to have the Fleet Commander warp the fleet around rather than each pilot warping themselves. This mostly mindless type of movement reduces the impact of each fleet member’s actions on the outcome of the combat. Drone assign was another example of this type of proxy gameplay that we have reduced.
Following the changes, fleet warps will still be possible but will require greater participation by fleet members, such as getting a scout into position. Often fleet warps might not be the most effective solution for movement.
Increase the time it takes for fleets to close ranges
It is time to return some viability to long-range fleets. The proposed changes make it a little harder to close the range to such a fleet, by reducing the efficiency of fleet warping to a very quick on-grid combat probe result.
The most common long range (defined as +150km) fleets seen in recent times are “Slippery Petes”. These are specialized Tengus that are fit with lots of ECCM, making them difficult to probe down. The combination of on-grid combat probing and fleet-warps have choked out most other long-range doctrines.
We expect these changes to give long-range fleets time to deploy countermeasures, such as stop-bubbles. It gives an opportunity for players who enjoy flying cloaky ships and probing to distinguish themselves as valuable assets in a fleet. We anticipate an increase in cool new doctrines being flown.
Reduce the ease of performing a bomb run without reducing their potential damage
The ease of performing bomb runs has stifled the use of battleships and battlecruisers in 0.0 space. Fleet-warps simplify and reduce the response time of bombing runs. With a few probe-equipped squad commanders, it’s easy to land many simultaneous bombing runs on an enemy fleet only a few seconds after they come out of warp.
The changes to fleet-warps will make bombing runs harder to pull off. However, a group of dedicated and well-coordinated players can still decimate entire fleets. We expect bombing runs to take a little longer to setup and execute, giving their targets time for counter-gameplay.
EVE Online is about interaction, and fleets are one of the primary methods of doing so. Being in a fleet should be an engaging experience. If you have suggestions for the future or feedback for the planned changes, please post in the comments thread for this blog.
- CCP Larrikin]]>
Things are slowly getting back to normal after our V5++ shader efforts. As you might be aware of, pretty much all of the art team was on the V5++ project for a big part of winter, and while there is still some work left on that front, we are finally getting there. If you missed it, you cna take a look at this dev blog for more information on the V5++ project.
Once we got some breathing room to start on other projects, the Dominix quickly stood out as an obvious choice! It´s by no means a new project, as the design created by CCP Caiman has been ready for quite some time. Unfortunately workload pushed the actual creation of the asset back several times. This is not unusual for us. We usually have some re-designs ready for a 3d artist to tackle when time frees up.
When redesigning the Dominix we thought about keeping the retro-feel of this old warhorse, so the silhouettes and base design aesthetics are quite similar to the original version. Now we finally have a small window to dive into this very much awaited project. CCP Bluescreen is relentless these days building the asset and getting it ready for the texturing phase. We are very excited to see the final version and it will hit your hangars in the upcoming release in August.
Minmatar ships are also getting some focus on the redesign front these days. We are constantly looking to evolve the style and feel to our spaceships in our efforts to modernize the ships of New Eden. Sometimes we go for bold designs, changing things up a lot from the original versions. At other times minimal changes are required. It’s a fine line in the direction we decide to take. Here are some ideas we are working with at the moment.
These are still works in progress, not planned for any release at this stage, but will give you an idea on what we are thinking.
Closing in on a new Thrasher:
Variants of the Thrasher (possibilties for the Sabre)
We really like the direction the Minmatar ship design academy is going. Have a look, give it a thought, and tell us what you think!
Community influenced designs
On the note of influence from the citizens of New Eden: I think the Caracal and Cerberus are worth mentioning. After we showed the Caracal redesigns earlier this year, the EVE Reddit community started making its own versions. It was a blast looking through all the variations created! Some were very humorous, others quite to the point! A couple of designs stood out where the common denominator was shortening and lifting up the front of the Caracal.
These kind of design changes to the Caracal are typical design questions we have to think about when redesigning a ship. This also relates very much to my earlier point on redesigns in general and whether we should go for bold changes or not. When we designed the Caracal we kept the long, dropped front feel of the Caracal – it is quite iconic for the ship. Should we have gone for a bolder design? After looking through the feedback on Reddit we thought it was a no brainer – thus the new Cerberus was born. We made a quick paint over with the design changes, posted it to Reddit and people seemed to like it. The main concern from the players after that was if the re-re-design would make it into production any time soon. I´m very happy we found time relatively quickly to finish the work and the Cerberus is coming in the upcoming Aegis release.
We really enjoyed this little collaboration, and hopefully we can do more in the future!
A New Art Director
In other news, as of next month I will take on the role of Art Director for EVE Online.
I´ve been concepting for EVE Online now going on 8 years. In that time I´ve tackled various projects along the way—Tech III ships, various ship designs and redesigns, most the turrets and missile launchers when we redid them, all sorts of background work, illustrations, icons, and last but not least the Caracal/Cerberus and the Hecate.
Our Art Director CCP Huskarl is leaving us to embark on a new journey after more than 15 years of devoted service to New Eden. He leaves behind countless designs and the tremendous legacy of the style of New Eden. We owe him much appreciation. Thank you for everything and good luck in your adventures.
Filling the shoes of Art Director for EVE Online is quite a challenge to say the least, and very exciting! I´m up for the task and will do my best to work with the artists and hopefully find new ways to interact and collaborate more with, you, the awesome EVE community.
CCP Jörg, over and out!]]>
The bracket icons for everything in space and on their overviews had all suddenly changed. The great Iconocalypse of 2015 had occurred and new icons arose in the place of those which had fallen:
(click to enlarge)
After the initial psychological adjustment period of the new icons had passed, many of you rightly asked us: why had we decided to overhaul the bracket icons to begin with? There wasn’t anything imminently bad about the previous set, players were used to them, and had gotten accustomed to staking their situational awareness and expensive ships on quickly recognizing the tiny differences in square sizes and cross thicknesses that defined ships on grid for years. So why the change?
To answer that better, these were our initial goals for the update (some of which were laid out on the first devblog many moons ago:
That’s the why of the update to bracket icons. Now let’s get into the how.
A Method to the Madness
The many in-space entities you can encounter in EVE can be categorized in numerous ways, and along different axes. We knew we needed a system of underlying rules for managing the expanded set of icons so that certain heuristics, or groupings, could be identified at a glance.
This began with the most high-level separations, for which we assigned a basic shape profile:
Another super important axis of distinction was between entities that were player controlled vs. NPC/AI controlled. After several explorations we settled on NPC entities having the same base shape, but with an inner fill compared to their player-controlled counterparts.
It’s important to note that initially the reason we decided NPC entities should be filled-in and player entities should be wireframes was that players could gather in potentially far larger groups. And with large-scale blob engagements it was important to keep their icons as “light” on pixels as possible to maintain readability.
UI Scaling at 90%
Releasing the thin wireframe icons accentuated the fact that the UI scaler does a suboptimal job of reducing 1-pixel strokes to less than a pixel. This resulted in a worse experience for a certain segment of players playing at 90% UI scaling, who ended up having a markedly worse experience with the new icons.
EVE UI has always been designed with pixel-perfect accuracy at its core. And when we decided to introduce a UI scaling option for accessibility reasons, we did it for the sake of giving people options to customize their UI, yet with the known tradeoff of knowing the texture scaling would create less than ideal-looking experiences in certain situations. It was by sheer luck that up until now most of the other issues created at 90% happened to be manageable, but the new bracket icons were so gameplay-critical that it made for a step back in usability for those playing at 90% scale.
Mea culpa to those affected. Making the icons at least usable at 90% scaling is one of our top priorities for improvement, along with others outlined below.
The new icons brought major change to the way in-space entities are represented in EVE’s UI, but we’ve also identified several areas of improvement thanks to your feedback. Here are the top items on our list to tackle:
Improve Scaling issues
Improve NPC and player ship distinction
Improve drone distinction
Add icons to overview customization
We are aware that a sudden and drastic update to some small but very important space symbols may have inherently vaporized several trillions of ISK from the economy. As pilots undocked expecting their familiar foes to be square brackets and crosses they unexpectedly came under attack by chevrons, diamonds, and house-shaped adversaries armed to the teeth. Some were so spooked and disoriented they began to fire on any geometric symbols in their vicinity. Others believed they were being attacked by their own warp bubbles and returned fire… Those that managed to adapt quickly in the early days of the great Iconocalypse of 2015 certainly profited handsomely from the confusion it sowed.
But in New Eden space is merciless, and change is ever-present.
- CCP Surge]]>
CCP Affinity and CCP RedDawn from Team Space Glitter to give you a little more detail on the past, present and future of those mysterious space entities, the Drifters.
With the Carnyx release, the previously inaccessible Unidentified Wormholes popping up over New Eden opened, allowing you to traverse them for the first time.
These wormholes only appear in systems that contain the ominous Jove Observatories, which the Drifters and Seekers have been guarding in a rather aggressive manner.
After a lively debate, the CS team has finished their final voting and selected our favourite art to be displayed on the office wall in Reykjavik.
On behalf of the CS team here in Reykjavik, I want to thank each and every artist who took the time to share their work with us. We were simply blown away by the talent and creativity displayed by our players during this contest.
While there could be only two winners for the large canvas display, there were so many great pieces that the team really loved, so we took the liberty of creating 3 runner up positions that will be printed and displayed on a smaller scale in the office as well.
So without further ado, please join me in congratulations our winning artists!
Large canvas winner:
“Sandcastles Before Me” by Kalistonius II
Large canvas winner:
“The Patrol” by Rixx Javix
Small canvas runner up:
“Lobach” by Dome Odu
Small canvas runner up:
“Death of the Tengu” by Saladiin
Small canvas runner up:
”Trap” by Eraly Moonbringer
Once again, congratulations to our winning artists and our sincere thanks to everyone taking part. We’ll get to work on the printing and logistics necessary for displaying the winning entries in the Reykjavik office and will then provide updates showcasing the winning pieces in their final form and full glory once they’re up on the wall.
Lead GM Grave
CCP Customer Support
Greetings honorable spaceship gladiators. Today, we’ve got some details on what you’ll be fighting to claim in Alliance Tournament XIII later this year.
For those of you just tuning in or new to the game, The Alliance Tournament is an annual competition in which alliances pit their best members in a grand contest to see who the masters of spaceship combat really are. Alliances will spend months honing their skills to give themselves the slightest edge in this grueling competition that is played out over three weeks. Some of the most memorable moments in EVE’s history can be found in the Alliance Tournament, with priceless ships being torn apart and turned to ashes, great dynasties falling to an unexpected newcomer, and long standing feuds between rivals played out in nail-biting matches that leave everyone holding their breath right up to the last moment. Any alliance that manages to win this prestigious event will find themselves showered in fame and fortune, rightly respected by all citizens of New Eden.
This year, Alliance Tournament XIII will be held from the 15th of August over three weekends, culminating in the finals on the 30th of August. You’ll be able to watch the action from weekends two and three live on CCP’s twitch.tv channel with our panel of expert commentators. If you’re interested in participating, signups are still open until June 8th so you better get in quickly. For more details on how to sign up, please see this dev blog.
With Alliance Tournament XII, we introduced a new prize structure that had several goals:
As this structure found great success, we’ll be using it again this year. As for the actual prizes, here’s what you’ll be fighting to claim this year:
The Alliance Tournament Cup is an ingame inventory item of which only one copy may ever exist. Every year we edit the description of the item to reflect the complete list of former tournament winners and move the item to the possession of the most recent winners.
The Alliance Tournament Cup was given to The Camel Empire alliance after their victory in the most recent Alliance Tournament XII, and after the conclusion of Alliance Tournament XIII it will be taken from wherever it resides at that time and given to the ATXIII champions.
In previous tournaments, we have given ingame Alliance Tournament Medal inventory items for the teams that places first, second and third in the tournament. The number of medals granted was the same number as the maximum pilots that could be fielded in that tournament. We will be continuing to do this for Alliance Tournament XIII.
However, like Alliance Tournament XII, we will also be giving out medals to every character that was a member of the participating alliances on the first day of the tournament. These will appear on the character sheet, exactly like a medal awarded by a corporation. There will be medals for Tournament Competitor, Top 32, Top 16, Top 8, 4th, 3rd, 2nd, and 1st. Each character will receive only the highest medal that their alliance earned.
Remember, the medals will only be granted to characters in a participating alliance on the first day of the tournament (August 15th)
As with previous Alliance Tournaments, we will be distributing the PLEX collected as entry fees as prizes in the tournament.
This year, the PLEX will be awarded as follows:
Ever since the 7th Alliance Tournament, the main prizes each year have been a set of special edition frigates and cruisers, with unmatched combat prowess. Only 50 of each type of frigate or cruiser are given each tournament.
As with Alliance Tournament XII, this year we will be distributing the special edition prize ships to the top 4 teams, with each team receiving an equal number of cruisers and frigates.
This year, the ships on offer from the Independent Gaming Commission (IGC) are based on Sansha ships. Skilled pilots are sure to be able to use the strengths of these ships to impale and destroy their enemies. The preliminary ship stats are as follows (and may be subject to change):
Amarr Frigate Bonuses:
7.5% bonus to Small Energy Turret tracking speed per level
Caldari Frigate Bonuses:
20% bonus to Afterburner velocity bonus per level
5% bonus to Warp Scrambler and Disruptor range per level
15% reduction in Microwarpdrive signature radius penalty per level
150% bonus to Small Energy Turret damage
80% reduction in propulsion jamming systems activation cost
Immunity to non-targeted interdiction
Slot layout: 3H, 4M, 4L; 2 turrets
3 Rig Slots, 400 Calibration
Fittings: 50 PWG, 180 CPU
Defense (shields / armor / hull) : 700 / 500 / 500
Base shield resistances (EM/Therm/Kin/Exp): 0 / 30 / 40 / 50
Base armor resistances (EM/Therm/Kin/Exp): 50 / 55 / 25 / 10
Capacitor (amount / recharge rate / average cap per second) : 450 / 210 / 2.14
Mobility (max velocity / agility / mass / warp speed / align time): 450 / 3.5 / 1,000,000 / 8 / 4.85s
Drones (bandwidth / bay): 0 / 0
Targeting (max targeting range / Scan Resolution / Max Locked targets): 40km / 800 / 6
Sensor strength: 15 Radar
Signature radius: 35
Cargo capacity: 150
Amarr Cruiser Bonuses:
7.5% bonus to Medium Energy Turret tracking speed per level
Caldari Cruiser Bonuses:
20% bonus to Afterburner velocity bonus per level
Heavy Interdiction Cruiser Bonuses:
5% bonus to Warp Disruption Field Generator scramble range per level
150% bonus to Medium Energy Turret damage
Can fit Warp Disruption Field Generator
20% bonus to all shield resistances
Unaffected by Warp Disruption Field Generator mass & speed effects
Slot layout: 5 H, 6 M, 4 L, 3 turrets
3 Rig Slots, 400 Calibration
Fittings: 900 PWG, 450 CPU
Defense (shields / armor / hull) : 2800 / 1600 / 1600
Base shield resistances (EM/Therm/Kin/Exp): 0 / 80 / 70 / 50
Base armor resistances (EM/Therm/Kin/Exp): 50 / 86.2 / 62.5 / 10
Capacitor (amount / recharge rate / average cap per second): 1800 / 450s / 4
Mobility (max velocity / agility / mass / warp speed / align time): 240 / 6.0 / 10,000,000 / 3.3 / 8.32s
Drones (bandwidth / bay): 0 / 0
Targeting (max targeting range / Scan Resolution / Max Locked targets): 80km / 250 / 7
Sensor strength: 24 Radar
Signature radius: 120
Cargo capacity: 450
As with Alliance Tournament XII, we will be offering a ship SKIN that can be applied to the Nightmare pirate battleships to give them a similar visual style to the Imp and Fiend.
We will be awarding 10 copies of this SKIN for each series won by a team. This includes the single match series that make up the bulk of the tournament. This should provide an additional incentive to try and win every match you can. Again like last year, these skins will be handed out later than the rest of the prizes at a yet to be determined date.
We have made an update to the points cost of Battlecruisers and Navy Battlecruisers. Both now cost one point more at 12 and 13 points respectively. Both the Rules blog and the rules page have been updated accordingly.
Due to the changes in the Sovereignty release schedule, Duality will not be available for teams to practice on until the Sovereignty features have been released as it will be needed for feature testing. We will however provide support where we can to teams that wish to practice on Singularity, such as spawning the arena beacons in systems. This feature testing also means that the hardware that Duality is running on will be upgraded, so teams will find practicing on Duality a much better experience.
With prizes like these on the line, we're looking forward to the clash between teams as they fight to take the blood soaked riches on offer. As always, if you have questions, feel free to head on over to the Alliance Tournament Forum. And remember, signups are still open until June 8th so if you're thinking about participating, make sure you get in as soon as you can.
On behalf of the Tournament Team
CCP FoxFour here on behalf of Team Size Matters to show you some of the stuff we have coming for ship SKINs this summer. As the ship SKINs feature is fairly visual I am going to get straight to the point and show some pictures. First up, along with the Carnyx release we released four SKINs for the Marauders: the Police SKIN for the Kronos, the Blood Raider SKIN for the Paladin, the Thukker Tribe SKIN for the Vargur, and the Kaalakiota SKIN for the Golem.
Click for larger versions
Starting June 9th, we will also be releasing new Sanctuary SKINs for the Sisters of EVE ships: the Astero, Stratios, and Nestor.
Click for larger versions
OK great, new Marauder and SOE SKINs! What about the future though? What else is coming later this year? We have begun working on what we call "designer SKINs" made by corporations or people in New Eden that are setup for the sole purpose of designing dramatic or unique looking SKINs. Right now every SKIN is tied to a single corporation or faction and follows their design philosophy. These designer SKINs help give us a bit more freedom in that we don't have to try and tie each SKIN to an existing corporation or create a new corporation for each SKIN we want to make. With that in mind we are aiming to have four new designer SKINs out this summer. Two for Minmatar and two for Caldari as those two empires have the least number of SKINs available right now.
Here are some concepts that our art director has come up with. These will likely not be what we end up releasing but should hopefully give you an idea of what we are considering doing.
Again these are just concepts but we are aiming to ship some form of the new designer SKINs this summer. The end result of this new designer SKINs system is that we will be able to ship
There have been some questions regarding the SKIN system and why we don't just let players put any SKIN on any ship. Here are a few of the reasons.
While it is technically possible to put any SKIN on any ship in the game that is not how we test internally at CCP. So far we have been using existing faction SKINs which were only designed and tested for a single race of ships. Even then those SKINs don't necessarily work across the whole race. It is fairly common that SKINs will break when going to tech 2 hulls or especially to capital hulls. For example the Moa looks amazing with the Ishukone SKIN as can be seen here.
However when that same Ishukone SKIN is applied to the Wyvern it no longer looks like an Ishukone SKIN. While it could be argued as to how good it looks, the bottom line is it doesn't look like an Ishukone SKIN.
In the above image the Wyvern has the Ishukone SKIN applied but doesn't get the gold to black fade that is a signature feature of the Ishukone SKIN. This isn't just a capital ship issue either. Here is the Ishukone SKIN on an Abaddon, which again doesn't look like an Ishukone SKIN.
Again it's missing that fade from black to gold. Further there are issues where sometimes you just get things completely broken such as in the case of the Ore SKIN on the Revelation.
Those black spots on the Revelation shouldn't be there and are not part of the SKIN. They are the pure black we render when missing parts of a material for the ship. Or even more subtly the Sanctuary SKIN on the Venture results in these black areas that should not be there.
The bottom line however is that each SKIN we put out is tested and tweaked to make sure that the quality level we strive for in EVE is always there. We are extremely dedicated to making sure that we hit a certain quality bar for the art in EVE.
When it comes to SKINs we have two general types of SKINs
Here is a standard Raven battleship.
Here is the same Raven with the Lai Dai SKIN.
Here is the Raven with the Kaalakiota SKIN which includes what we refer to as a custom mask map. That is a whole other texture as part of the material that changes where the colors on the ship goes.
We have concerns about the performance impact of having lots of different ships with different custom mask maps on them. We are pushing this a little with the new Marauders with the thought that they very rarely are seen in large fleet battles.
Another concern of allowing any SKIN on any ship is making Tech 1 ships resemble Tech 2 ships which would have visual gameplay implications. While deciding what SKINs to offer in the release of this feature we carefully selected SKINs for ships by making sure that if we offered a SKIN for that ship the same look was not used by its Tech 2 counterpart. This is the reason why for example there is no Sarum SKIN for the Apocalypse, as it would too closely resemble the Paladin.
The final thing we would like to clarify is that lore is not something that is stopping us from using the existing SKINs we have on other ships. The two biggest factors are quality and performance as demonstrated above. Hopefully this gives you a bit of insight into where things are going and why. Our goal is to continuously be adding SKINs to the game over time. We want to offer a wide range of options for SKINs that appeal to lots of people. We aim to accomplish that using the SKINs from existing factions or corporations along with this new designer SKINs system we are working on.
Until next time,
Hello Capsuleers, CCP Falcon here on behalf of the PLEX for GOOD Taskforce!
On Saturday April 25th 2015 a massive earthquake measuring 7.8 in magnitude struck Nepal and the surrounding region, swiftly followed by an aftershock measuring 6.6, then a second measured at 6.7 less than 24 hours later.
These initial earthquakes, along with a second 7.3 magnitude earthquake that occurred two weeks later on May 12th have caused unprecedented destruction across the region, levelling homes, destroying businesses, and reducing national monuments and sites of cultural and historical importance that have stood for thousands of years to rubble.
With around 8,800 lives lost and more than 23,000 more people injured, the reaction from the EVE community once again left us speechless, with countless players calling for CCP to host a PLEX for GOOD drive.
On Friday, May 1st 2015 we opened up donations for PLEX for GOOD – Nepal Earthquake Relief in association with our partners at the Icelandic Red Cross, allowing players to donate PLEX in order to assist with their relief effort in Nepal.
Due to end at 23:59:59 on Friday May 15th 2015, the drive was extended by 9 days through until 23:59:59 on Sunday May 24th 2015 in the wake of the second earthquake on May 12th.
Throughout the drive we maintained contact with our partners at the Icelandic Red Cross to keep them up to date on the fundraising efforts of the EVE community and like us, they were astonished as the total amount donated by EVE players continued to climb, with many other companies across Iceland donating to relief organizations in order to assist.
On Monday, May 25th the Community Team had the pleasure of tallying the final donation total, and here are the results:
A total of $103,650 US was raised by the players of EVE Online for PLEX for GOOD this time around, this equates to:
This includes a $500 donation from our wonderful ISD Volunteers, as well as a donation of 365 PLEX from the PLEX for GOOD Item Auction.
In terms of donations, this is the second largest PLEX for GOOD drive that we’ve ever hosted on behalf of our community, and this brings the total that EVE players have raised for charity to almost half a million US Dollars:
This is an astonishing feat for a community the size of ours, and really shows that while EVE players may explore the in game limits of morality while they play, our amazing community has once again demonstrated its immense collective strength and capability as a force for good.
There have been some amazing stories that came out of PLEX for GOOD this time around, including an unfortunate player who was scammed out of a number of PLEX which were then directly donated to the PLEX for GOOD fund less than 10 minutes later by an individual who can only be described as the interstellar equivalent of Robin Hood.
PLEX for GOOD “Bit By Bit” hosted by Chribba has also raised an amazing amount of donations once again as a program which puts aside small amounts of ISK from individual contributors, which is then pooled to purchase PLEX as donations to PLEX for GOOD.
However, the most awesome story I personally came across was that of our largest individual donator, who gifted 700 PLEX / $10,500 / 626,500,000,000 ISK (almost 10% of the total to PLEX for GOOD).
This in itself is an immense contribution, however when we looked at this donation further and came to the realization this this player is from the Philippines, which were assisted by our last PLEX for GOOD drive after the terrible impact of Typhoon Haiyan, it became an incredibly heartwarming story of giving something back.
Today we had the pleasure of welcoming representatives of the Icelandic Red Cross, as well as the President of Iceland to CCP Headquarters in order to hand them a check for $103,650 on behalf of the players of EVE Online:
(click to enlarge - Photos courtesy of Arnar Valdimarsson - CCP ArnarV)
Both the Icelandic Red Cross and the President wish to express their most profound thanks to our community for the incredible generosity that has been shown. The President also remarked that the EVE community is a shining example of multi-national crowdsourced fundraising for charity, and that more games companies and online communities should follow the example set by the PLEX for GOOD program in order to assist their fundraising efforts.
Once again, here at CCP we are finding it very difficult to choose words that express our gratitude to the EVE Community for the incredible generosity you have all shown over the course of this fundraiser. The Community Team does however have an amazing display on the windows of our office as a constant reminder of the fact that we serve what is, without a doubt, the finest gaming community on Earth.
(click to enlarge)
From everyone here at CCP Games, we offer our most sincere thanks and profound gratitude for the astonishing level of support you all show for PLEX for good.
EVE Universe Community Manager
On behalf of the PLEX for GOOD Taskforce]]>
As most of you will already know, we here at CCP are currently in the midst of preparing and releasing a major rebuilding of EVE's Sovereignty capture system.
We've released two dev blogs (here and here) detailing these plans so far, and your feedback and contribution has been invaluable as always.
The next part of these changes are being deployed tomorrow in our Carnyx release, when Entosis Links will start being used to enable and disable station services, alliances will be able to pre-set their default vulnerability times and the in-space player activity of a system will begin to be collected in the Activity Defense Multiplier.
As we continue to work on implementing and testing more parts of the new system we are continuously updating our plans and schedules to make sure we release the best possible quality as quickly as possible.
We also want to keep you all up to date on these updates to the plan. Today we're announcing two changes to our schedule:
These updates are part of our commitment to ensuring that this feature has the time to be thoroughly tested internally, with our external testing partners and by the community on our public test servers. It also ensures that we will have enough time to polish the usability of the feature ensure that every player can enjoy the new system. We'll be making full use of the rapid deployment system that CCP Seagull outlined in her recent dev blog in this process. It's always possible that more changes to the schedule could be made if new information comes to our attention, and as we respond to your feedback both before and after public test server testing begins. If more changes do occur we'll continue keeping you all up to date through the dev blog and community news systems, as well as official social media channels. Full information on release dates is also always available on our EVE Updates webpage, your one stop shop for information on what's coming to EVE.
We have more dev blogs planned in the coming month, including one coming soon that will detail the transition plan from the old system to the new system on patch day. We continue to welcome your feedback and we'll be announcing soon when our test server war games will begin to help nullsec alliances try out the new system as well as providing us with more solid testing.
Thanks and fly safe!
Team Five 0