Top player LMG - missing kills.

[delems]

Need to look at this report, i'm sure I have more than 13 LMG kills. My player summary shows 19 LMG kills. Something seems to be missing from the top player report.

[delems]

Couple more LMG kills yesterday, not reflected in Top player stats; are stats working still?

[delems]

There are kills that seem to still be missing - top player LMG report showing 13, yet my player stats show 21.

[delems]

Regarding what happened to report, not sure; my guess is you require the 50 player sorties to count before including in report.

However, if 3 personas had 40, 40, and 40, none of them would be over 50, yet for the top player report they really have 120, well over 50. But just guessing.

[Eagletree]

It looks like the report is correct, the data is wrong. I created the queries for player summary using sorties to get the data. The Top Player reports are modified versions of the Top Persona reports and depend on a more efficient table for doing all players in one query. That table is missing data for you. It has only 14 kills listed.

Of the 14 that show up, there are multiple branches represented, so it doesn't appear to be a branch issue, though that was a excellent guess.

A more basic problem with the CSR1 server is probably at the root of this. Last campaign we lost 1000s of records to that system and/or it's db instance hanging. I haven't been watching it for nearly this entire campaign due to the minor health issues I mentioned in that other thread. But the "versus" record is clearly not updating everything it is supposed to from the game server. I'll take this up with Dave because if anything was corrected during this time, he will know. If it's still failing, as seems likely since you haven't incremented, I'll see if I can find the culprit.

You will also notice that many Adversaries are missing from your "vs" report. That report uses the same table.

If we are very lucky, this data will be backed up and queued, but I rather doubt that from past experience.

This is unfortunately applicable to all weapon reports but I'm not sure yet what the time period for the drop-out is.

[delems]

How is it my player data is correct, but top player data isn't? It seems the data is there somewhere.

At the end of the map - can you just run a 'better' report to get all the correct data for the final list?

[Eagletree]

The database is designed so that there are multiple ways to retrieve what seems to be the same type of data. Sortie data is what I used on queries that didn't exist before. That works really well for discrete player data and somewhat well for weapon data (which is still centered around one player when you query). It won't work at all for reports that have to look across all the players in the db. They got around this by creating other types of records that aren't so voluminous as the sortie data. It's those other types of data that get screwed up if a script goes south, and they don't recover.

Potentially, if that's going to be a regular thing, I could rebuild those other types of records on an as-needed basis, by running a daily batch job that checks to see that the DB cross checks and then rebuild if it doesn't. The one in question here was the "versus" data that consolidates the vehicle/weapon that each player uses. It's a downstream product of the sortie data, but done by a separate script.

TGUNR fixed this by restarting the scripts that failed, that's why it started to increment again. But it is not one of the scripts that queues all the data, so then it just took off from the point it was functional again, leaving a dropout. The way the back end processes work, they will re-sync everything if sortie data is dropped, but not recreate summations that failed.

Nothing can be done to correct after the campaign, because currently the archive process makes the data inaccessible. I understand why the original developers did this. It's a lot of data, the old system (where the database still resides) is out of space and has some hang issues, plus that old db software is shockingly slow compared to the same software in a 2013 incarnation. We really need to prioritize getting the db off CSR1 and shutting it down. It's unlikely the problem will occur again once we do. In our defense, it's a hazardous process to just move everything. We already tried this once and stats were offline for several days as a result. It's the type thing that can't just "be done", it has to be planned meticulously, and that means a thorough understanding of all the supporting processes. We are quite a ways along to having that understanding, but it's gone to the back burner several times due to a variety of issues.