Couldn't find a thread on this so hopefully not suggested already.
I'm a stats nerd. I admit it. I like the leaderboard for not only being able to compare my Minecraft addiction with my friends, but also for being able to look at go "wow I've mined 40,000 blocks of sand!" or whatnot.
Problem is... the leaderboard is broke. We all know it. People who hacked, duped, and used glitches in the early days own the top spots and were first to cap at 65k everything.
Other problem... most of the new stuff is not tracked. There is no tracking for things like blocks of netherbrick mined, blazes killed, ghasts, end dragons, enderman, melons harvested, wood chopped, etc.
Would be cool to have a tracking that shows all those stats, even if it is just stored locally for user information as it might be too much data to put into the leaderboards.
That said, even with that, the leaderboards should be "fixed" to cover the changes with the game and make it more relevant to things you can do in the game including having kill counts for magma cubes, blazes, ghasts, endermen, etc. The only panel in the leaderboard that is still relevant is the Traveling one because we can still minecart/boat/walk/fall.
PSN:
Junokaii (although I'd recommend not adding me because I'm on literally like... once every month or two)
Member Details
I think that the numbers also need to be raised.. it's five digits long in numbers all the leaderboard stuff.
Why not go to 99,999? Or even 999,999? It'd be easy to implement.
I think that the numbers also need to be raised.. it's five digits long in numbers all the leaderboard stuff.Why not go to 99,999? Or even 999,999? It'd be easy to implement.They really do need to be expanded.
It would double the memory required to store the stat at those levels. Currently 4J is using C++ for the conversion, and it would seem that they have opted to use an unsigned short integer variable for these stats (which requires 2 bytes to store values between 0 to 65535). In order to exceed this 65535, the only 'easy' next step would be to use the 4 byte unsigned long integer variable (able to go between 0 to 4294967295), or move to floating point notation (also requiring 4 bytes / 8 for using double).Since you are effectively doubling the size of each stat, you are effectively doubling the storage space required for each leaderboard profile, and when tracking millions of players, that can start to be a drain on storage resources and read/write hits.
I'm not sure it would be a significant hit on performance, and secondary storage space is getting cheaper all the time... so I'm willing to support this idea, if it can be done reasonably.
It would double the memory required to store the stat at those levels. Currently 4J is using C++ for the conversion, and it would seem that they have opted to use an unsigned short integer variable for these stats (which requires 2 bytes to store values between 0 to 65535). In order to exceed this 65535, the only 'easy' next step would be to use the 4 byte unsigned long integer variable (able to go between 0 to 4294967295), or move to floating point notation (also requiring 4 bytes / 8 for using double).Since you are effectively doubling the size of each stat, you are effectively doubling the storage space required for each leaderboard profile, and when tracking millions of players, that can start to be a drain on storage resources and read/write hits.
I'm not sure it would be a significant hit on performance, and secondary storage space is getting cheaper all the time... so I'm willing to support this idea, if it can be done reasonably.
Why is it everytime I say something on this site I'm blasted away by some Einstein response?
Anyway, glad to hear you would support that.
I mean, if it was a matter of keeping track of every player on the planet, maybe it's not worth keeping all that. I mean I don't care how I'm ranked in the world, it might be a slight competition with my friends, but I'm fine without world stats.
Why is it everytime I say something on this site I'm blasted away by some Einstein response?
I object....Einstein was a physicist...not a programmer.
LOL J/K
Anyway, just shedding some light that even though this change is (as you said) technically a simple matter... there may be at least some repercussions to extending the data type to accommodate.
I object....Einstein was a physicist...not a programmer.
LOL J/K
Anyway, just shedding some light that even though this change is (as you said) technically a simple matter... there may be at least some repercussions to extending the data type to accommodate.
I certainly support big changes/improvements to the leaderboards. I personally would like to see a local world stats page that only compares the players for a particular map and is available for viewing by anyone invited to sign onto that map. That way, players can compare themselves to the others playing the same world under the same set of circumstances (i.e. difficulty level, server rules, etc.) Perhaps then the "worldwide" leaderboards could then be limited to stating overall blocks mined, and all kills (collectively), AND overall hours played. To me, the stats about so many kills, etc. have no relevance as to the player's skill without a reference indicating how long it took them to accumulate those totals.
PSN:
Junokaii (although I'd recommend not adding me because I'm on literally like... once every month or two)
Member Details
I just always thought that 65,535 was such a weird number.
I also don't remember it always being like that.. Cause I swear my stone blocks mined on Normal Mode was over 73,000. then I saw it down to 65,535.
I also had all my peaceful stats reset for some reason.... I have a friend who hasn't played the game in over a year but she's still more than me because her stats weren't reset....
I just always thought that 65,535 was such a weird number.
(going for that 'Einsteinian' response) 65,535 + 1 (65,536) is on a doubling sequence (2 ^ 16), since in most cases in computing and math, the value of 0 is frequently useful, this takes up the last possible digit slot for that doubling sequence (the 65,536 value) which is why the cap is one less for 16 bits (2 bytes).
But yes, it does look like an odd numeric choice to use from a non-programmer stand point.
(going for that 'Einsteinian' response) 65,535 + 1 (65,536) is on a doubling sequence (2 ^ 16), since in most cases in computing and math, the value of 0 is frequently useful, this takes up the last possible digit slot for that doubling sequence (the 65,536 value) which is why the cap is one less for 16 bits (2 bytes).
But yes, it does look like an odd numeric choice to use from a non-programmer stand point.
If you're a programmer.... good for you then....
Rollback Post to RevisionRollBack
Hebrews 11:1
To post a comment, please login or register a new account.
I'm a stats nerd. I admit it. I like the leaderboard for not only being able to compare my Minecraft addiction with my friends, but also for being able to look at go "wow I've mined 40,000 blocks of sand!" or whatnot.
Problem is... the leaderboard is broke. We all know it. People who hacked, duped, and used glitches in the early days own the top spots and were first to cap at 65k everything.
Other problem... most of the new stuff is not tracked. There is no tracking for things like blocks of netherbrick mined, blazes killed, ghasts, end dragons, enderman, melons harvested, wood chopped, etc.
Would be cool to have a tracking that shows all those stats, even if it is just stored locally for user information as it might be too much data to put into the leaderboards.
That said, even with that, the leaderboards should be "fixed" to cover the changes with the game and make it more relevant to things you can do in the game including having kill counts for magma cubes, blazes, ghasts, endermen, etc. The only panel in the leaderboard that is still relevant is the Traveling one because we can still minecart/boat/walk/fall.
Why not go to 99,999? Or even 999,999? It'd be easy to implement.
They really do need to be expanded.
It would double the memory required to store the stat at those levels. Currently 4J is using C++ for the conversion, and it would seem that they have opted to use an unsigned short integer variable for these stats (which requires 2 bytes to store values between 0 to 65535). In order to exceed this 65535, the only 'easy' next step would be to use the 4 byte unsigned long integer variable (able to go between 0 to 4294967295), or move to floating point notation (also requiring 4 bytes / 8 for using double).Since you are effectively doubling the size of each stat, you are effectively doubling the storage space required for each leaderboard profile, and when tracking millions of players, that can start to be a drain on storage resources and read/write hits.
I'm not sure it would be a significant hit on performance, and secondary storage space is getting cheaper all the time... so I'm willing to support this idea, if it can be done reasonably.
Why is it everytime I say something on this site I'm blasted away by some Einstein response?
Anyway, glad to hear you would support that.
I mean, if it was a matter of keeping track of every player on the planet, maybe it's not worth keeping all that. I mean I don't care how I'm ranked in the world, it might be a slight competition with my friends, but I'm fine without world stats.
I object....Einstein was a physicist...not a programmer.
LOL
Anyway, just shedding some light that even though this change is (as you said) technically a simple matter... there may be at least some repercussions to extending the data type to accommodate.
Ohhhh lol that was a cheap shot. haha
Yeah I can agree now that you point that out.
I also don't remember it always being like that.. Cause I swear my stone blocks mined on Normal Mode was over 73,000. then I saw it down to 65,535.
I also had all my peaceful stats reset for some reason.... I have a friend who hasn't played the game in over a year but she's still more than me because her stats weren't reset....
(going for that 'Einsteinian' response) 65,535 + 1 (65,536) is on a doubling sequence (2 ^ 16), since in most cases in computing and math, the value of 0 is frequently useful, this takes up the last possible digit slot for that doubling sequence (the 65,536 value) which is why the cap is one less for 16 bits (2 bytes).
But yes, it does look like an odd numeric choice to use from a non-programmer stand point.
If you're a programmer.... good for you then....