If you sign up to the site you will be given access to post articles via your control panel.
March 3, 2010 marked the final day of the collection of PLEX to aid victims of the devastating Haiti earthquake. EVE Online players were extremely generous: 2776 PLEX were donated through 1107 contracts. An additional 9.5 billion ISK was donated, enough to purchase 37 additional PLEX from the market. 100 percent of your donations will be given to the Red Cross. Thanks again to everyone who participated.
Since November 25th 2009, a few days before the deployment of Dominion, we have experienced frequent unscheduled reboots of Tranquility. Almost all of those were due to a bug in the networking subsystem that causes the SQL Server to fail over.
Why, oh, why and what are you doing about it?
As soon as the first failover happened, we, per our policy, opened up a support case with the vendor regarding the incident, since our logs, surprisingly, showed nothing. Their response was that the problem had been caused by a race condition in the system.
We have worked closely with the vendor’s support and development teams in an attempt to isolate the bug, collected vast amounts of diagnostic data and implemented changes that were considered potential solutions by the vendor. We believe we’ve found a workaround that makes it unlikely that the bug is triggered, but does not 100% prevent it. This has yet to be confirmed however.
As one can imagine it is difficult to diagnose a running, high performance production environment like ours without causing lag or other performance or reliability problems. The vendor has been working diligently to attempt to reproduce this issue in their lab, although collecting diagnostic data from similar systems presents a major challenge – doing so without negatively impacting performance levels for customers.
We do have programmers and virtual world system administrators working on putting together a test script to run on the database server we use for Singularity and Multiplicity, and if we are able to reproduce the issue there, we can supply our vendor with code that reproduces the problem in their lab.
I, personally, have been spending quite a large part of my work hours the last 3 months communicating directly with the vendor, collecting diagnostics data, setting up collection tools and working on things related to solving the SQL Server issues.
In short, we are using all the resources at our disposal to resolve this issue. It is a high priority issue for all parties involved as it affects not only our system and customers, but can affect equally massive systems and user bases using similar network and database solutions.
What have we done already? What do we know?
We know that problem lies in the TCP stack and likely has something to do with handling of closed or closing sockets. Our vendor has asked us to implement a few potential fixes or workarounds. We’ve adjusted various networking features and upgraded our SQL Server engine with a version that has a workaround for issues of this nature. The database handler in the EVE application server uses session pooling and we’ve experimented with changing various settings there. Turning off recycling of idle sessions seems promising as a workaround that makes triggering the bug less likely.
We still are working toward a fix, as I said before, and we seem to be able to make the failovers happen less frequently with the latest workaround. Expect to hear more in the near future on our progress with this issue.
![]()
Intaki, Placid - A major push by Federal Defence Union forces in the last week has resulted in 13 systems which were originally held by the Gallente Federation returning to its governance, including Intaki Prime.
The 13 systems resecured by the Federal Defence Union between 21.02.112 and 27.02.112 were:
Essence
** 08:53 27.02.112 Vifrevaert
Verge Vendor
** 03:49 20.02.112 Jovainnon
** 18:50 21.02.112 Loes
** 04:50 22.02.112 Hevrice
** 00:53 26.02.112 Melmaniel
** 23:53 26.02.112 Muetralle
Placid
** 18:50 22.02.112 Brarel
** 08:51 23.02.112 Vey
** 17:52 23.02.112 Agoze
** 14:51 24.02.112 Intaki
** 15:51 24.02.112 Frarie
** 22:53 26.02.112 Reschard
** 08:53 27.02.112 Eugales
Faraelle Brightman of FDU corporation Eleutherian Guard claims that the battle for Jovainnon in Verge Vendor was a very close thing. State Protectorate corporation Space Perverts and Forum Warriors United [PERVS] managed to engage and conquer an FDU outpost just in time to protect the system’s vulnerable control bunker early in the day, but persistent efforts from FDU forces spearheaded by Handsome Millionaire Playboys [HAMPB] rendered the bunker vulnerable again and went on to destroy it.
Both PERVS and Costolle Military Assistance Corporation had been resisting the efforts of Handsome Millionaire Playboys and their FDU allies in Verge Vendor, both by capturing FDU outposts and engaging with FDU-aligned pilots as they attempt to force State Protectorate forces to deploy elsewhere, but the attacks appear to have been too persistent and widespread for them all to be met effectively. According to John Tanashima of ICS-762 Drunken Butterflies, the main FDU onslaught coincided with a substantial curtailing of PERVS operations, leaving only a few corporations and a number of individual pilots directly in STPRO service to oppose system captures.
Loes and Hevrice, a system that had already changed hands three times this year, fell with what HAMPB representative Tavis Darwin describes as “only light resistance,” but then the conflict in the region reached a stalemate that was only broken with the fall of both Melmaniel and Muetralle to the FDU 4 days later.
Meanwhile in Placid, an organized coalition of FDU corporations were pushing towards the recapture of the Intaki homeworld. Azure Horizon Federate Militia, Moira., Eleutherian Guard, Strix Armaments and Defence, ArmoredCore Armed Forces and many other FDU affiliates worked intensively in the pirate-infested region to capture State Protectorate installations and drive out occupying forces.
Different corporations in the FDU coalition took on the task of organizing and leading the strikes to recapture various systems, with Azure Federate Horizon, sources claim, taking a leading role in the liberation (those in the Intaki separatist and pro-state movements might prefer to say “reconquest”) of the Intaki system itself.
John Tanashima accorded particular respect to Luminaire General Julianus Soter as an opponent. His corporation, Moira., took the lead in the assault upon STPRO defences around Eugales. “General Soter of the FDU did a great job organising an attack, they changed tactics. Started to take space superiority in a single system and pound the Caldari Navy down, instead of looking for deserted systems to take them by surprise.”
Tanashima felt, however, that the sudden reorganization and drive from the FDU was not the only factor involved. He continued, stating “At the same moment, the Space Perverts and Forum Warriors Incorporated corporation diminished its global presence, leaving a small core of Caldari capsuleers to defend. Any one of these without the other would have diminished the STPRO effectiveness in keeping systems, but both at the same time… Well, you can see the results.”
Meanwhile, more reports coming in of further systems falling to the Federal Defence Union – a forthcoming report will give more details.
![]()
KBP7-G, Providence – Atlas Alliance reinforced two Sev3rance [-7-] industrial structures in the KBP7-G system in what was declared as the first move in the full scale deployment to the Providence region.
“We are here to burn down Providence just like we did with Geminate” commented Tzuko1, an Atlas pilot, as the fleet engaged the second tower in the system. This is now a full scale deployment that started with just roaming gang participation in a similar manner to the previous Atlas deployment in the Geminate conflict. “We are looking for good fights” he added, again denying any interest in full territorial control: “We will split it to renters, Against ALL Authorities [AAA] and some other entities, in territory terms we are looking for moons.”
Asked to describe the outcome of these engagements Tzuko1 stated that besides the reinforcement of the two industrial structures, opposing casualties were counted as around 30 battleship class vessels and about the same number of support ships.
An anonymous source close to Sev3rance considered the moon resources as a “prepared argument to cover the real reasons for coming to our space. There are no juicy moons in this region or any nice minerals in the belts. You do not come to Providence because of the profit the systems give you by default. I think in their position as servants to AAA and the southern bloc, they will for sure take part in larger scale operations in this space… The real movements will be made soon and we will see what the complete plan of the southern bloc is like. At this moment it looks like [it is focused on] cutting off all exits in this region… It is motivated by AAA… There is for sure a plan… and ATLAS will have to play a part in this or is doing this as part of their relationship… this Drake fleet reinforced two industrial [towers] and nothing else… I’m looking forward to good fights.”
EvilPHish of Cold Steel Alliance [STEEL] affirmed his alliance’s commitment to their relationship with Sev3rance and willingness to do everything possible to aid in any possible way. “Sev3rance is like a sister alliance to us. STEEL and -7- go way back to the times when we were both helping Curatores Veritatis Alliance [CVA] drive Ushra’Khan from Northern Providence. It’s pretty obvious AAA got its… allies into the [conflict]. We will stay to fight until and beyond our last system if need be.”
CVA Executor Aralis commented that the situation was “pretty obvious” since “people like ATLAS do not come for good fights” and affirmed his belief that this move by ATLAS results from their relationship with AAA and is part of the greater offensive in Providence. “They think we are busy and they hope for some easy kills.”
GalNet References
Sev3rance Alliance Battle Records – KBP7-G
ATLAS Alliance Battle Records – KBP7-G
tl;dr Lots of exciting things are happening, including some changes to the way standings work for players. The most important bits are bolded, so scroll down and have a look-see.
Hi everyone, my name is Greyscale, and I’ll be your systems designer for various upcoming client changes related to the next EVE release, and tying into the new EVE Gate social network site. Today I’m going to give you an overview of what we’ve got coming up, how it’s going to affect you, and dive into a few changes we’re considering for existing systems.
I’m not a web specialist, so I’m going to stick mainly to client-side changes, and let the interweb dudes explain their shenanigans in a later blog. In general though, we’re following a mandate to ensure that functionality is comparable in the client and on the web. Pretty much everything I’m describing here will therefore be available in your browser too.
We’ve got two teams handling the feature work on this project – Team Stonehenge and Team Yggdrasill. Each team is responsible for a particular key feature, and contains a mix of client, server and web programmers, to ensure we can deliver on the web and ingame simultaneously. Both teams have their own QA resources, and a shared design team ensures that everything matches up at both ends.
Anyway, without further goodbye, here’s what the teams are working on.
Team Stonehenge
Any questions?
Yes, we’re adding a calendar. The above image represents about half a sprint’s work, so it’s essentially an early visual prototype and in no way even approaching “done”. Expect it to be approximately eight times more awesome by release.
For now we’re only planning on having a “month” view; we think the majority of players are unlikely to have more than two or three events per day, and the fact that we’re a 23/7 game means trying to show “day” and “week” present some visual hurdles. Events can be created for yourself, or for whole/corps alliances (restricted by roles), and we’re also planning on having a “CCP” category for occasional official use, and on allowing you to invite other players to personal events. The filters on the left will allow you to toggle all events in a given category on and off, and there will also be an “upcoming events” box in that area (and perhaps in other places such as character selection).
Our initial target has a fairly concise feature set, to give us more room to polish the product. EVE Gate will be an ongoing project, and improvements there should in most places be replicated in the client too.
Team Yggdrasill
EVE Gate is, among other things, a social network site, and you can’t have a social network site without a friends list. Thing is, we already have a way of formalizing relationships with people ingame: the standings system. The good news is that the standings system already does about half of the stuff we need to do, but the bad news is… that the standings system only does about half of the stuff we need to do.
As a result, we’ve decided to make some changes to how standings work between player entities. Standings from NPC entities will be untouched; support for standings to NPC entities will likely be dropped as they’re essentially non-functional.
Here is another work-in-progress half-a-sprint UI prototype of the new contacts section of P&P:
This window is the frontend for contacts management in the next expansion. It merges the functionality of the address book and the personal standings list, and adds a few cherries on top. Things that you will likely notice:
· You can still filter by online/offline
· The “watch list” is essentially the old address book’s primary functionality – contacts who are added to the watch list will show up in here and give logon/logoff notifications and green/red squares
· The “blocked” list is now managed here too
· A lot of the words may seem out of place – this is because they’re not final yet! We’re still deciding on final terminology.
· There are now only five levels of standings
This last thing is probably what you noticed first, and it’s worth repeating in a more obvious way, I think: there will only be five levels of standings in the new system.
Currently there are ~200 settings you can choose, which in the vast majority of cases is overkill. Indeed, in the majority of cases there are only five states that you care about: dark blue plus, light blue plus, nothing, orange minus, red minus. These five correspond to the five options you see here, in a fairly obvious way.
There are three situations we’ve located where this represents an in-practice reduction of functionality:
· Diplomatic book-keeping. For entities managing large numbers of standings with a wide range of nuanced diplomatic states, the old system was useful in ensuring that everyone knows exactly what the relationship with a given entity is. With this new system, we feel that the advantages of a simpler system outweigh any disadvantages in this respect – and we’re pretty confident that our players are more than smart enough to find their own alternate solutions here.
· Starbase forcefield access. The reduction of granularity here degrades the functionality somewhat, but we’re hoping that it won’t cause widespread issues. Nobody here at CCP will deny that, as with several other aspects of starbases, this whole area of functionality could do with an overhaul, but that is unfortunately out of scope for this release.
· Player-owned station charges. The current system uses a fairly arcane formula for calculating various pricing options, the most significant of which we think is the refine tax rate. Again there’s some degradation of some functionality here – assuming you’re only letting friendlies dock, you’re essentially limited to two settings now, which may be slightly restrictive for some alliances.
We’re anticipating a range of player opinions on these issues, which is why we’re discussing this so early in the development cycle. We’ll be paying attention to the feedback thread, and taking any well-reasoned arguments into account going forward. Also, see the final paragraph of this blog for bonus info on these systems.
Other things you should know:
On that subject, there are two other changes we’re considering that we’d appreciate feedback on.
Firstly, the way standings are calculated for color tags in the overview and so on. Currently the code goes down the list of tags, checks if a pilot (or whatever) meets the criteria for each in turn, and as soon as it finds a match it uses that tag. When it comes to standings, it checks to see if any standings (personal, corp or alliance) that apply meet the criteria. This means that, in the default setup with the blues first, it’s essentially “highest standing counts”. (If you flip the tag ordering, you can force it to do “lowest standing counts” instead, I believe.)
The change we’d like to make here, at least as far as it relates to in-space tags, is to make alliance standings override corp standings, and corp standings override personal standings. (It would go alliance-alliance, alliance-corp, alliance-personal, corp-alliance and so on.) This means that you can have friendly personal relationships with people in enemy alliances (which is relevant to EVE Gate functionality), but have them still show up red in space.
Secondly, corporate membership lists (for player corps). Currently you can see this in two places: in your P&P, and in the corp interface. We’d like to remove it from P&P, because it doesn’t really belong there, and we’ve been discussing adding it to the corp’s “show info” instead. The question then is whether the corp member list should be globally viewable, or just viewable to corporate members. This becomes more complicated when you add EVE Gate to the picture, because if you have the same publically viewable information there as in show info, it’s considerably easier to build a corp membership database by simply pulling all the pages and associating names with corporations. The info is obviously already available through the client in principle, but compiling it is a non-trivial exercise; a web version simplifies it considerably. Opinion is still divided here on whether this is a serious issue or not.
We welcome feedback on both these issues!
Some other cool things
In making these changes, we’re probably going to have to make some changes to corporate and alliance standings management. We can’t make any promises about the eventual functionality, but at the very least it’s unlikely that we’ll discover a way to make these windows any harder to use…
There’s also a little story I’d like to tell about Alliances. See… Alliances don’t really exist – not in the same way that corporations exist, anyway. That’s why, for example, there’s no such thing as “alliance roles” – the thing that you attach corp roles to doesn’t exist for Alliances (at least, this is what I understand when the programmers try to explain it to me). It’s also at least part of the reason why Alliance “standings” are currently a bit… odd.
For those of you who’ve never poked around in the politics tab of an Alliance, you “set standings” by selecting options for what are essentially +10, +5, -5 and -10 from a dropdown. It works, but in a bit of a non-standard way – which is why you can’t use alliance standings for useful things like configuring outposts, or stopping your starbases from arbitrarily deciding to kill all your friends.
Well, in the process of implementing the new standings system, it has been determined that it’s easier to rewrite Alliance standings than make the old system play nice with the new Contacts system. As a convenient side-effect of this, Alliance standings will now be used whenever stations or starbases make a standings check. This, we hope, should make managing these things much easier in most scenarios.









