EVE Echoes: The Final Battle of RG9-7U

Share This Post

The Silent Alliance (SHH) made waves in the EVE Echoes community for their accomplishment of dropping the first player outpost in the northern reaches of Deklein, RG9-7U. Their rapidly growing fame also put a rather large target on their back. SHH has made plenty of enemies in the game. Enemies means fights which means easy content for players. However, last Friday night these enemies would meet to discuss the strategy of bringing the outpost down. 

The Silent Alliance logo

In the late hours of 11/6, several alliances worked to take the outpost down. The two key ones: Fire Flies (FF) and 第三势力 (DSSL) worked tirelessly the week before to grind the outpost through the shield and armor timers. This wouldn’t be the first time the structure was at risk of dying, but it was going to be the last. 

RG9-7U in Deklein from dotlan.net

 

With the structure sitting pretty in prime North American timezone (USTZ), many alliances would not be at their full strength as compared to SHH, who was most active in USTZ. However, on a Friday evening, most working adults don’t work on the weekends, which allows them to alarm clock the timer and attend where they normally otherwise cannot. The attacking forces brought ~24 alliances with ~800 members to the fight. SHH and their allies had ~250. 

Normally, this is the part of an article where I would jump into the mechanics of the battle, the triumphs and mistakes from the fleets, any decisive plays which turned the tides of battle. But really, any one of the 1,000+ combatants will be able to tell you this battle was atrocious. It wasn’t because of the attackers; it wasn’t because of the defenders. It was because NetEase is not prepared to handle these large scale fights. 

Most videos of the fight will show constant disconnects. Players would get a screen informing them of the disconnect and that they would be reconnected. Many times, the reloading of the game would show a black screen, which could take up to minutes before loading the background, other players, and the structure. This was the best case scenario. In other instances, games would just crash completely and players had to reboot in order to play again. 

Commonly seen disconnecting screen during the battle

If folks were able to stay connected, they could lock and fire on the structure or enemies, but only the first shot would hit. Weapons would continue to cycle but not apply damage. Other modules, like shield boosters, would cycle but not take cap nor apply the effects. What players had hoped would be an epic last stand of the first placed player outpost turned out to be both sides of the fight battling the server for any stability. 

Modules cycling but capacitor remaining unchanged at 100%

The server stability was only one issue of the fight.

NetEase has known about a standings bug for quite some time. This affected both the attackers and the defenders. For the attackers, the standings bug prevents certain groups from using the player outpost as their home. Access to the player outpost is on standings, and with the bug, some of the attacking side simply couldn’t get access no matter what the owner (SHH) did. For the defenders, many had set temporary blue status to show allies vs enemies (SHH as red). However, due to the bug, this wasn’t always apparent. Like many other instances, there was plenty of blue on blue PVP happening. 

The player outpost has limits and bugs of its own. The first being the most obvious: it has no offensive or defensive capabilities. Granted, SHH wanted the bragging rights of placing the first one, but with that they had to take on the burden of being unable to fit it properly like one would expect. Other stations in game, which are owned by NPCs, have the functionality of setting up a base, performing industry, and having a market. Player outposts, which act like stations, do not have any of these features. Additionally, they are unable to equip offensive or defensive capabilities. In battle, they are merely a sitting duck. 

I pointed out earlier the battle took place in USTZ. The defenders get to decide when these timers occur. However, when setting the time, it was unclear which timezone the structure was set for. Additionally, when discussing with SHH, they pointed out they have the timer set to Friday 22:00 UTC. However, anyone there knows the timer came out at 21:00 UTC. This is assumed to be due to Daylight Saving Time. 

Beyond these timer issues, there are other factors at play: server maintenance. EVE Echoes is a new game, and like all new games it has its server downtime. However, server downtime changes the time of these player outposts and their reinforcement timers. Anyone who has alarm clocked for these since release will tell you how an extended server maintenance or unexpected downtime caused the timer to change, without any warning to the attackers or defenders. 

At the end of the day, the player outpost fell. And while victory is supposed to be sweet, it does not come without the bitter taste of server performance and bug issues. 

The first placed player outpost exploding on 11/6

With the sovereign systems on the horizon, NetEase clearly has some core gameplay issues to tackle and resolve before players can make full use of player outposts and the grand battles that come with them. 

Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments

Related Posts

Why “Expert Systems” Won’t Create Expert Players and How to Change It

In a recently published article, CCP introduced their newest...

WWB2: The Story So Far

World War Bee 2 has been rampaging through New...

To Catch an AT Ship – The Work Behind Hunting the Most Elusive Targets

On January 20th 2021, an Utu was ambushed and...
0
Would love your thoughts, please comment.x
()
x