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...). --McTwist 04:58, 28 May 2011 (UTC)
 * (Edit:) 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)

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)

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)