Talk:Map item format

Color-table
After coming to the conclusion from Talk:Map (Item) about how the colors data should be used, it seems it is some sort of color-table, like in gifs. Although, we only know a few of these colors what they represent, and it seems it is over 50 that we are not sure what they are. I would suggest that someone adds this color-table as a table to this article. Probably the ids in the table is final as it would else destroy backwards compatibility for maps in the future. --McTwist 18:19, 27 May 2011 (UTC)


 * Thanks to Gameslinder creating a PNG/DAT converter he checked what values it were and therefor got some color values. Currently these looks valid but needs to be validated by checking the colors on normal maps. It also seems that the fourth color for each group is the same as the second in the same group. --McTwist 19:39, 27 May 2011 (UTC)
 * That looks very nice! I'll be able to validate those colors in a short time, I'm currently writing a program that renders these maps to an image file --Flippeh 22:12, 27 May 2011 (UTC)
 * Someone should verify, but I'd guess 36-39 is clay - seems to be about the right color. As for the other grays, the first two sets might be Smooth and Cobblestone, but it's hard to say (I'm sure *one* of them is at least smooth stone).  The bottom one (44-47) may be Bedrock.  Obviously though, I'm guessing here based on the colors. --Warlock 22:24, 27 May 2011 (UTC)
 * I don't actually think the colors represent types of blocks, since 1 pixel on the map is about 8 square blocks ingame, so the colors are best interpreted as they are, not what they could be. --Flippeh 22:34, 27 May 2011 (UTC)
 * I finished my map rendering program using the color values from this table, and it looks pretty accurate, I'll link it on imgur since I don't want to abuse the wiki upload for this: http://i.imgur.com/exthq.png --Flippeh
 * That might be one reason of why he didn't use blocks, because there will be blocks interfering with each other. Then the description should instead say either what it contains most or what blocks could be mixed to create that particular color. When I wrote that I just predicted which one was which, nothing else. Still, this color-table will help either for those creating images for the map or those creates programs that reads them to images(Enough saying...).
 * Feel free to do any changes to the table. The wiki is good on making backups so there will be no loss if you do anything wrong. --McTwist 05:12, 28 May 2011 (UTC)
 * Looking at Zooming scales it clearly tells how water works. First it uses 4 colors. But then it mixes two colors to form 4 colors more. This is an old technique that used when there was only 256 colors to pick from. This gives the water 5 depth, where the darkest one is the deepest. It is odd that Notch didn't used the extra duplicate color to add 3 more depth. Anyone got an idea of why Notch is duplicating the fourth with the second in each group, and why he even thinks of duplicating 12-15 for 24-27? Either it is a final system that made his work even easier(Or faster) or it is for future updates where the color will change.
 * One thing other to think about is if creating a map in the Nether, it will look like rubbish, just like the compass is going in circles. --McTwist 12:04, 31 May 2011 (UTC)
 * The colors are much more straight-forward than most people are making them. Each block type has only 1 color associated with it. The shading comes from the map rendering elevation changes, and from people testing sections that aren't properly aligned. You can test pixel color by creating 8x8 areas of one block type, but that 8x8 area has to be aligned perfectly with the chunk or you can get discoloration due to blending. I can verify that #606060 is the pure color of smooth stone, cobblestone and ore blocks, #6d9930 the color of grass(unsure about biomes?), #9d5b28 for dirt, #59472b for planks, #d5c98c for sand and gravel, #59472b for all types of logs, #006a00 for all species of leaves, #909090 for sponges, and glass transmits the color of the blocks underneath it. NZPhoenix 14:23, 9 June 2011 (UTC)
 * Those colors are correct and we've already verified them. Although, first the wood color is the same as log is a new thing, as long with sponge that probably makes that color an undefined color, i.e. blocks that have not been mapped as a color. Also, due that the glass isn't visible, I guess that the built-in heightmap is used.
 * Moreover, those colors is exactly what is in the table, and I guess that the color is more about how the blocks works. The only thing to do is fixing some of the colors and add the others. Other than that, the article is done.
 * Also, there could be an addition of making the color-table more easy manageable with a template. --McTwist 16:41, 9 June 2011 (UTC)
 * It's confusing to list multiple colors for the same blocks, especially since 2 of the 4 are the same. I would recommend listing only the base color, and then showing the higher-elevation/lower-elevation variants. NZPhoenix 18:45, 9 June 2011 (UTC)
 * Just make the template and it will be easy to do such a task later on. --McTwist 21:10, 9 June 2011 (UTC)
 * I just made the template. I took it from the Programs and editors page as I felt it easy understandable. Need to add some documentary later, but that could be up to somebody else's job. --McTwist 07:38, 17 June 2011 (UTC)

Zooming scales
When Flippeh mentioned in the Color-table discussion I saw a pattern in his "1 pixel is 8 blocks". The scale now is as default 3, as I suggest this might be a 2 power of the scale value. It might be also a bitwise moving to the left as that contains the same pattern and would be a lot faster to process(Even if that in this case probably wouldn't be necessary). This means that each "step" when zooming is doubled each time.

0 = 1 block, 1 = 2 blocks, 2 = 4 blocks, 3 = 8 blocks, 4 = 16 blocks, etc, up to 16 (actually 255, but that ain't gonna happen) = 65536 blocks. There probably is a limit because processing power to determine that much data is bigger than the world itself (255 = 5,7896044618658097711785492504344*10^76 blocks).

I suggest that someone tries to mix with this value to see what we get. This would mean that the zoomable maps are implemented, but not possible to make without cheating as we do. --McTwist 05:10, 28 May 2011 (UTC)


 * Editing this value (tested on SMP with the server stopped), I'd agree powers of 2 are correct. However, values larger than 4 (16 blocks/pixel) do not work (they're treated as if it's set to 4). JonAtkins 16:23, 29 May 2011 (UTC)


 * Thank you for verifying it. I checked it myself, but it don't zoom in but only changes the size of the circle that is used to make the map go bigger. When I tested it I could only go down to 3, but maybe I saw just wrong. I also tried to use width and height, but those are not used yet and are set to 128 each time, so they are probably hardcoded.


 * Conclusion: The scale function was implemented and should have been visible when Notch released it, but unfortunately he probably commented out a big pile of it and the only thing he forgot to comment out was parts of the scale code. This means that we cannot zoom in nor out, but only change the size of the view-circle, a good thing for those don't wanting to explore the whole map. I wonder why he commented out so we cannot have real scalable maps... --McTwist 05:04, 30 May 2011 (UTC)


 * Scaling does work - see for some samples. Keep in mind any existing explored areas will not be rescaled when editing the value (I crafted a fresh map and took a copy before viewing it to use as a blank template for map hacking). JonAtkins 01:06, 31 May 2011 (UTC)


 * You are right. I checked once again and it worked. Therefor I made 4 different kind of maps: 1, 2, 3 and 4 scaling. I then went through the first two, and some on the last two and got this:




 * scale1.png
 * scale2.png
 * scale3.png
 * scale4.png
 * }


 * I will continue on the two last so this will be complete. I might also put these images on either Map (Item) and/or this article. There is also a scale 0(?) compare here made by PixelMap (Rotation: 270, Up: East)). --McTwist 11:53, 31 May 2011 (UTC)
 * Yes, I tried the scale 0, which will result in a map being 1:1 (that is, 1 pixel = 1 block). I found that really useful when mapping, for example, castles or building sites, as the default scale will show big buildings tiny and blurry on the map. -- TheKax 07:50, 2 July 2011 (UTC)

Name of maps
As I wrote in this article, the name of maps comes from the filenames. Although, I have not validated this yet. I only thought so because the names was identical from the file and the name in-game. I might validate this, but others will feel free to do it as well. --McTwist 05:33, 28 May 2011 (UTC)


 * Using NBTEdit, I went through level.dat looking for how map worked. First, it seems that it stores the map connection to the item in the Damage field. This is a short, which probably is one of the reasons of the limit of the maps. Then I went and changed the name, and suddenly it created an another map instead of the other one that I renamed. This was expected as it didn't know about the change. This id number could probably be what he meant of cloning the maps, e.g: Use same id for multiple items. And according to his twitter it seems to work fine to clone it, but he does not tell if it really works.


 * I myself would do as the world saves is made: Store in each map item an extra field TAG_String and use that as a link to each map. This could also be used to link maps together if the name is he same one instead of the incrementing folder in world saves. --McTwist 07:17, 28 May 2011 (UTC)

idcounts.dat Format
"Curiously, this file, while still NBT, is not gzip compressed"

By Specification, every NBT file consists of a single GZIPped Named Tag of type TAG_Compound. Since idcounts.dat isn't GZIPped, it isn't NBT. It's just similar to NBT. DiEvAl 14:39, 5 June 2011 (UTC)


 * Fixed. --McTwist 08:45, 6 June 2011 (UTC)
 * Yeah, GZIPping a file containing a single value (if I'm right) would seem like wasting time. That kind of file might actually get bigger in the process... (again, correct me if I'm wrong, but that would seem logical, to me at least.) -- TheKax 07:57, 2 July 2011 (UTC)