U’K | The Wandering Druid of Tranquility

Around and around she goes, where sov will land, well, the TCU doesn’t know…

5 Comments »

I caved into pressure, here is the Friday post.

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

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

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

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

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

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

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

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

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

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

See you out there!

Tags: , , , , , , , , , , , , , , , ,

Related posts

Weekly Highlights February 19th 2010

“And the sun also sets…”

8 Comments »

Here’s your weekly roundup of all things EVE!  It’s a long post as I have a discussion point at the end.  Do take the time to read and think about this one.  I am looking for discussion from all viewpoints.

  • The war in Providence continues.  It’s no longer a matter of a few systems but the entire region now.  As 9UY4-H fell on Monday and with -A- and it’s allies continuing it’s push, many say it will only be a matter of time before CVA disbands.  Some think that CVA will dissolve itself from it’s current form and head into faction warfare as that may be the only place they will be able to continue their role playing gaming style.  The reality is, unless CCP changes major parts of the Amarr/Minmatar story with the freeing of all slaves in New Eden, there will always be room for the role play side of the game.  Many people have written about the events in the Provi-war.  I’ve consolidated the D-GTMI and 9UY4-H Google items into the ProviWar feed.  You can catch all the blog posts, public forums postings and/or videos by subscribing to the feed itself.  More to come as things unfold but I will say this.  Monday was a day that will live in the heart of every Warrior of the Ushra’Khan.  Fighting at the side of -A-, Ushra’Khan was able to re-take 9UY4-H and Unity Station.
  • Karn Mithralia made a great post on the EVE Forums Intergalactic Summit section relating to the retaking of Unity Station, head over and read [UNITY] – The Fire that Burns Within!
  • Additionally, Ushra’Khan  and allies began taking systems from Sylph when they pulled a Goonswarm and forgot to pay their alliance bills.  They were able to take the J6QB-P  system and station, despite server crashes rolling the station damage indicators from zero armor and shields and less than 60 percent structure to 100 percent structure and 50 percent on shields and armor.  To relieve some of the frustration of that database failure, the station has been renamed for the time being, “C C P roll back  UK does not“.  I am sure a different name will be put into place by alliance leadership in the future.
  • The Fan Fiction Blogfest #2 is still going on, head on over and join in the fun, write an entry today!
  • Roc over at Roc’s Ramblings has some wonderful posts this week.  First head over read A hero address the world and then a  wonderful fiction post called Lament, head over and take the time to read it, it’s awesome!
  • As always, update work for the blogs listed on The EVE Online Portal and the OPML download continues.  Head over and see who we added this week!

Now we have the discussion point I mentioned at the beginning of this post.  It relates to the siege of J6QB-P and the rollback event that occurred.

No, this is not a rant, only some observations and yes, it’s open for discussion as it’s a good topic for discussion.

Petitions were filed by many on the damage rollback issue.  Below is a copy of the responses from one of the GM’s:

Hi there,

I am sorry to hear what happened. My theory is that since the server underwent an ungraceful shutdown (in other words, it crashed), the state for the station (its shield, armor and structure level) wasn’t saved correctly to our database, and was therefore reverted to an earlier state when the server came back up.

Now, the problem with this, is that since the information was simply not saved correctly, it is not possible for us to verify in which exact state the station was in when the server crash happened. That means that we will sadly not be able to take any action here, as our logs surrounding the event are simply not conclusive.

I don’t doubt your description of the event, but my hands are simply tied due to the lack of verification from our end. I am sorry for this inconvenience.

Best regards,
Senior GM Lelouch
EVE Online Customer Support

Obviously this is not the response that anyone wants to ever see, that the data for the literally DAYS of shooting a station was simply lost.  This response is, however, one of the better responses I have even seen from a GM for this sort of issue.

Their position was explained clearly, not a simple “log show nothing” answer, but a valid, honest explanation.  One who puts in such a petition would see an insult as ‘your word is not good enough’.

I would have to disagree with that simply because there are those people who would make such a petition and falsely recount the problem.   It’s called cheating and unfortunately, this is why the GM’s take this stance on this sort of issue. Unless they have valid evidence in the way of database records,  there is nothing that can really be done.

Or is there something that they can do?  By their own admission, the database was not saved correctly due to the crash and thus the integrity of all the data pertaining to that time frame comes into question.   That is an issue that leaves me with some questions of my own.

Let me explain.  Every time you shoot a gun, ammo is consumed.  Crystals have a usage indicator, listed as damage.  Projectile, missile and hybrid ammo counts are reduced.  All that ammo usage is recorded by the inventory system with the usage indicator and location, mainly a weapon on a ship object.  Same goes for stront used by a dread in siege.   Ship objects are recorded in the database with your location sx, sy, sz.

So, when you shoot your ship, that means the inventory system records the removal of ammo, A1, from gun, G1, for ship, S1, at location s1x, s1y, s1z.  If you take that information from the database and match it up with the location of the station object in system and you can now establish that the station was in fact taking damage.

If  you expand the search for all inventory reduction events recorded in that time frame with other ships x, y, z locations in close proximity to the station object and you can confirm who was shooting at the station at the time.  You can not confirm the actual damage done sadly or any repairing done by the opponent using the inventory system.  So, for those of you thinking that the inventory reduction events data could be used to adjust the damage indicators for the station, I am sad to say that simply can not be effectively done.

However, in this case, the station damage was not recorded.  If all that data was lost, hours of damage indicator updates sent to hundreds of game clients, hours of inventory updates made for the ammo being used, hours of drones being used and/or lost, Stront consumed by dreads in siege, why was the only data rolled back the station damage indicators? 

What happened to all the ammo?  What happened to all the drones that were destroyed?  What happened to all the stront consumed?  Why was that data not rolled back?

If the database updates for damage taken/repaired for the station were not saved, then the ammo, stront and drones should still be there, is that not correct?  One would logically think so.

So, the questions for discussion are these:

Since the damage to the station can not be verified, why was the inventory system not returned to the same previous state for all those who were in system at the time?

How do you resolve the lost isk for ammo and/or stront consumed for damage that was not realized?

Should CCP be looking into the inventory system for such petitions and return ammo/stront used during a “rollback event” where the results of that used ammo/stront were not realized?

Can such incomplete database cleanups lead to other database inconsistencies?  Would these potentially be the source of all the crashes we have been seeing?

These are some of the questions that come to mind.  Please feel free to comment on this blog post or write a post of your own with your thoughts on this.  Feel free to answer any or all of these questions.

Personally, I think that CCP should be returning the ammo and stront that was used.

It’s a matter of examining the inventory system and placing those consumed items back into the respective hangers of the pilots whom their ship and character objects were present in the system with recorded inventory events at the time.

It’s the least they can do for having a server crash and “rollback time several hours” for a station that was under siege.

See you out there mates!

Tags: , , , , , , , , , , , ,

Related posts

Discussion Point, Weekly Highlights February 12th 2010