Talk:Scoreboard

@WolfieMario thanks for your great work on the initial versions of this article!  LB ( T 22:04, 24 January 2013 (UTC)
 * No problem :) --WolfieMario 03:30, 1 February 2013 (UTC)

Limits
Is there a limit to the amount of different "scores" that can be tracked? That is to say, is there a limit to the number of players that can be tracked on one scoreboard and the number of unique scoreboards that can be added? 115.70.128.50 12:51, 29 January 2013 (UTC)
 * It's theoretically unlimited (I'm sure there is no hard limit - that would make absolutely no sense), though of course it depends on their implementation for parsing/saving NBT and how the data is represented in memory. It could also just depend on how stuff in Java's standard library works. To be safe, though, try not to exceed ((2^31)-1) players or total scores, no matter how tempting it may be.  LB ( T 21:39, 29 January 2013 (UTC) -- Oh, and it also depends on how much memory and hard drive space you have.
 * You're correct; avoid anywhere near ((2^31)-1). In fact, the maximum number is probably closer to 2,147,483,639, surprisingly. The size of a list is stored as a 32-bit integer, so that's one hard limit of the NBT file format.


 * The 2,147,483,639 figure is eight less than the highest number a 32-bit int can store, because, depending on your JVM, arrays store header data in the array size, and thus that 32-bit int isn't fully available (although, I'm not quite sure how those eight values can store meaningful data; while it makes sense that the highest bit (used only for negatives) can store a bit of information, those additional eight values can't even form a single bit in this context. Perhaps those are literally eight reserved array indices, and the JVM adds eight to any referenced index for the non-header info? All I know is, strange as this information may be, it comes from the Java source code, which is about as credible as you can get). This limitation is especially relevant because NBT List tags are implemented using a Java ArrayList, which itself uses an array and explicitly declares 2,147,483,639 its maximum number of elements (thus, it wouldn't even vary by JVM, unless some JVM reserves more than eight values). Thus, ((2^31)-9) is the maximum number of elements an NBT List can store without risking crashes or corruption.


 * One caveat: this does not mean you can safely have ((2^31)-9) objectives. Let's hypothetically say you create ((2^31)-9) "deathCount" criteria objectives, for whatever reason. When one player dies, the game will allocate ((2^31)-9) elements in the PlayerScores list, filling it to capacity. Assuming this (or the existence of ((2^31)-9) objectives) hasn't yet caused your computer to implode, the moment a second player dies, you're guaranteed an OutOfMemoryException, even if your system had memory to spare, due to the JVM limit being surpassed. In general, you should limit your number of objectives based on the number of players you expect to have on a single map: if it's 30, then avoid going above (((2^31)-9)/30) objectives (that's 71,582,787, rounded down): even if not all players are likely to get scored in all objectives, it's best to not take the risk of crashing Minecraft.


 * Oh, and you know what's funny? All of these large numbers are actually entirely irrelevant. By my calculations, a single objective takes a minimum of 52 bytes (1 byte for the compound (although its header is omitted as it's in a list, it still has an End tag), 15 bytes CriteriaName header, 7 bytes minimum CriteriaName contents (I assume the criteria "dummy"), 14 bytes DisplayName header, 2 bytes minimum DisplayName contents (I assume an empty string), 7 bytes Name header, 6 bytes minimum Name contents (I assume 4 bytes worth of character data, else our theoretical max of ((2^31)-9) is impossible: this value must be unique for each objective. Note that 4 bytes is enough to encode a four-letter string)), not considering the effects of GZIP compression. At 52 bytes per uncompressed objective, our max of 2,147,483,639 would actually take around 104 gigabytes to store uncompressed. Sure, it may be less when compressed, but the whole thing has to be loaded into RAM, and Java's design actually means it may cost around 50% more in RAM. Assuming we can only afford to spend 3GB RAM on objective data (entirely ignoring the player data we also need), and assuming that Java indeed bloats the data to around 78 bytes per objective (considering we're talking about many String Objects, the references alone total 24 bytes, surprisingly close to the figure of 26 I tacked on... and that's assuming you're not in 64-bit Java!), you should seriously avoid having more than 41,297,762 objectives.


 * TL;DR:
 * The absolute limit is ((2^31)-9), or 2,147,483,639 objectives, but you'd be a madman to even try it.
 * If you don't want to crash even NASA's Minecraft when 30+ players play your map, avoid any more than 71,582,787.
 * If you have the slightest ounce of decency, and don't want your objectives to cost more than 3GB in RAM alone, don't go above 41,297,762.
 * If you're a normal person, you shouldn't be able to come up with more than a few hundred objectives anyhow, regardless of how large and complicated your map may be. Similarly, you'll never have enough players on a single such map for you to ever come close to these numbers, even in total.
 * TL;DR of the above: you literally don't even have to worry about it if you're just a normal mapmaker. Even Sethbling, myself, and anyone else who normally does complicated things has nothing to worry.
 * This is the first time I have put this sort of knowledge to use since my first year of Computer Science in college. --WolfieMario 03:30, 1 February 2013 (UTC)

Scoreboard team table
Hello I made this table with the new team commands. I wrote it quite quickly so maybe there are mistakes in it. Where should I put the valid values for the options 'friendlyfire and color? Maybe adding a column to the table of Formatting codes with the official color names: black, dark_blue, dark_green etcetera

217.123.123.177 18:58, 31 January 2013 (UTC)