Which score is right?

[Vorlon]

In the schedule we have 199905 points from our 27 guild wars participants, but in the ranking only 196887. How is this possible if the best 27 scores count? This was still the case 1 hour after reset.

[mitamata]

I think this issue was addressed in the most recent dev Q&A:

@Lyrian

What’s the current progress with the Guild Wars Scoring Issue?

• Problem is related to Mongo database issues.
• Issue is caused when two players complete a match at the same time and is an unresolvable flaw with Mongo.
• Issue may be resolved by future upgrade to a SQL database (in consideration for feasibility currently).
• No planned compensation for issue.
• Guild War bracket movement issue long-term resolutions currently under consideration for a future update.

At least, I think that’s the scoring issue they were talking about. The TL;DR: they know it’s an issue, but it’s requires big infrastructure changes that they don’t have an ETA for. We just have to live with it.

[blindnighto]

Regarding this statement, I have a question to the players who state issues with their scores (I tried asking this before but didn’t receive an answer):

For those guilds that have 100% participation in GW and that finish relatively early on Sunday (i.e. have the full information of all battles), is any tab correct? By any tab, I mean Attack tab help popup, Schedule or Ranking.

The functionality is supposed to count only the top 27 scores. This means that guilds with 27 or less players that complete all their battles can just add up the scores and see if they match Schedule and/or Ranking tabs. Guilds with 28-30 will have to do some basic algebra.

Essentially what I’m trying to get at is: If the information is correct somewhere, then the unresolvable Mongo DB issue devs have states is responsible for this would become a non-issue.

My guess is that the scores for each individual player are stored correctly. If so, then Attack/Ranking/Schedule tabs just need to change the logic they use to display. If any of Attack/Ranking/Schedule already has the correct numbers, then they just need to change the display to use whatever calculation is already working and display it on the other places.

[Fourdottwoone]

@blindnighto

Essentially what I’m trying to get at is: If the information is correct somewhere, then the unresolvable Mongo DB issue devs have states is responsible for this would become a non-issue.

The information is correct somewhere, it doesn’t make it a non-issue. Allow me to translate what has been said into less politicial terms:

“We neglected implementing basic concurrency handling for guild score aggregation. Atomic transactions are a core database feature, even in Mongo, it would be trivial for anybody somewhat familiar with the concept to fix it. However, those incorrect scores just randomly shuffle the placement of a few guilds around, the overall reward payout across all players stays the same. Since this doesn’t hurt us in any way and won’t drastically increase the demand for torches and pitchforks, no fix and obviously no compensation either.”

[blindnighto]

Fair.

To be clear, when I said non-issue, I meant that whatever might be happening with the database, i.e. the reason why this can’t/won’t be fixed, would not have to be resolved in any way to roll out the fix because they are just grabbing the score from the wrong place/handling it incorrectly.

I’m just optimistic that someone will actually make what I assume is an extremely simple QoL change. And that’s why I was curious about information from the playerbase confirming where the score is actually correct. That way the next bug report would be a one line “Fix attack/ranking/schedule tab score by using the calculation/value being displayed on [correct tab]” instead of a complaint about “I know it’s wrong but you need to investigate why yourself.”

I realize many are tired and jaded. But for those that actually care about GW, wouldn’t this be a welcome QoL change if it turns out to be such a simple fix? (I’m aware that if it really were such a simple fix, then it could’ve/should’ve been fixed earlier.)

[Fourdottwoone]

@blindnighto

To be clear, when I said non-issue, I meant that whatever might be happening with the database, i.e. the reason why this can’t/won’t be fixed, would not have to be resolved in any way to roll out the fix because they are just grabbing the score from the wrong place/handling it incorrectly.

As much as is known the issue is the aggregated guild score. Simplifying things a bit, whenever a player finishes a GW fight:

• Total guild score S is read from the database
• Player score A is added to read score S
• New total guild score (S + A) is written back to the database

Whenever two players finish a GW fight close enough together:

• Total guild score S is read from the database by player A
• Same total guild score S is read from the database by player B
• Player score A is added to read score S
• New total guild score (S + A) is written back to the database
• Player score B is added to the read score S
• New total guild score (S + B) is written back to the database, losing A

Two trivial solutions:

1.) Wrap the read, add, write sequence into a critical section, making it an atomic operation.
2.) At weekly reset, don’t use the flawed aggregated score, sum up the individual score of each player instead for bracket movements and rewards (those are available and can no longer change at that point).

Those are both server side, they don’t require any client update and could be done at any time.

@blindnighto

I realize many are tired and jaded.

Especially when getting fed some fantasy story about unresolvable Mongo DB issues when it’s really all about funneling your resources towards more worthwhile areas, like adding extra monetization features. Anybody remember the class switch fee (50 gems) that couldn’t possibly be changed to any other number due to technical limitations?

[Snooj]

@Fourdottwoone

New total guild score (S + B) is written back to the database, losing A

In the last Dev Q&A when the GW scores were talked about, they stated they want to move from Mongo to SQL (I assume there’s other reasons, just commenting on this one relation). They’re in for a treat when they realize SQL still requires proper transaction handling.