stats is dead again

[captainsnarf]

The scores have exceeded some limit. It will glitch out when any of these players play:

GhostBukkake, Vugluskr, John_von_Dong, BLA$TER.

[pooty]

Ah thanks, spent about 2 hours poking at it yesterday, figured there was something like that since some work, some didn't. Some matches were fine, some weren't. The code is supposed to log the errors but it really doesn't and I am not a php guru, its close enough to other languages... but I do know databases.

That is really helpful to narrow it down.

Not sure why we'd have some limits, I was pretty sure I fixed them all. And shame on the original developer for using tinyints, or even small ints for scores.

[McLovin]

...And shame on the original developer for using tinyints, or even small ints for scores.

Aw, that sucks. I guess back in the day, they didn't anticipate scores would go so high.

Once upon a time, I used float. It didn't have the precision I needed. Since that mistake, I've been on a rampage to always use double. And for fuck sake, I land on a team that was using float for everything again. Idiots! LOL

[pooty]

Okay I did find something.

There's a table for players that tracks player stats

--- ORIG
-- plr_nodeconstructed mediumint(8) unsigned NOT NULL default 0,
-- plr_nodedestroyed mediumint(8) unsigned NOT NULL default 0,
-- plr_nodeconstdestroyed mediumint(8) unsigned NOT NULL default 0,

So max value 16,777,215

but the ut_players table has this: (Values are out of ordrer but the point is they are way too big)
John_von_Dong 16,766,328 7616373 12288039
Vugluskr 10565709 4062995 9480252
BLA$TER 8887652 4820502 5939720
GhostBukkake 9319753 4853390 5414405

So winner, winner chicken dinner for Snarf


1. Those values max no sense, as if you look at career stats
GhostBukkake (Enyo) 7837 15026 8857 Orders of magnitude off!
It apparently doesn't even use the huge value columns. Not sure why they are off, but its definitely overflowing and screwing the database loading...
Its basically for all players too the numbers are off by magnitudes...

I changed the player table:

plr_nodeconstructed int(10) unsigned NOT NULL default 0,
plr_nodedestroyed int(10) unsigned NOT NULL default 0,
plr_nodeconstdestroyed int(10) unsigned NOT NULL default 0,

which gives max value 4,294,967,295 so should be good.

The loading code seems to make sense
$plr_nodeconstructed += $gt_pickup; (game stores nodesconstructed as pickups)
$plr_nodedestroyed += $gt_taken;
$plr_nodeconstdestroyed += $gt_drop;

And those adds are pretty small nodes, basically tens at most, but something screws it. I figure I don't need to track that just increase the fields that are overflowing.

The changes are made, lets see if it works tonight, there might be some matches still messed up, not going back to fix those, I tried reparsing the logs but it failed (likely since HALF the data is there and the overflow error..)

[captainsnarf]

That almost fixed it. The kill charts are broken still. there is probably a similar variable there.

[pooty]

Yep but at least its not stopping all the loading....but I can take look those now might be on the output side.

But it worked on this match https://www.omnipotents.com/utstats2/ma ... match=6616 (MasterShower) and seems ok before and broke after that..

[captainsnarf]

The kill charts are broken when one of the same trouble players is in it.

[pooty]

Yeah something in the php code isn't doing the math right... lol. Should have just made the database all INTs to begin with. Saving a few bytes per record is pretty silly and likely was silly even in 2004ish.

[McLovin]

I know it's not a priority, but is there any sense of if this will be fixed. Can we apply the fix we did last year to resolve this, or it is more complicated than that? I thought we dumped the entire database and that fixed it once. If I understood the posts correctly, this database is not used to do the balancer, right?

[pooty]

The StatsDB has nothing to do with the balancer.

Its more complicated than just wiping and restarting.

1. Code is a PITA to deal with.
2. Time is better spent elsewhere
3. Players keep changing their keys/stats info so it messes it up anyway https://omnipotents.com/utstats2/onsrankings.php See how many duplicates? Its just dirty data now.
4. I am going to disable it for this week to see if its the source of the lag spikes.