Talk:Biome

From Minecraft Wiki
Jump to: navigation, search

Flower Forest[edit source]

Is there any info for the levels at which flower's will grow at? Like is there a minimum and maximum height or will they grow from bedrock to build limit?

Flowers can exist in levels 1–255. Using bone meal on a grass block, you're only limited by where grass can exist with a free space above it. And during world generation, the biome decorator is able to put flowers at any of those same levels.
Ok thanks a lot. Appreciate the help :) –Preceding unsigned comment was added by 184.145.136.83 (talk) at 16:45, 02 February 2017 (UTC). Please sign your posts with ~~~~

Biome Color[edit source]

Hello, I couldn't find any information about the "Color / Variation Color" column in the § Biome IDs table. What does these colors correspond to in the game? Is it related to grass/foliage color? — Thomas645 (talk) 12:51, 4 February 2017 (UTC)

Biome colors were removed in 1.8 or 1.9, and no longer serve any purpose in PC edition. However, they are kept in the table because they exist in Pocket Edition (though also unused), and are useful for mapping programs (e.g. AMIDST uses those colors as well). Grass and foliage colors are chosen based on a colormap, and not biome colors. Jocopa3 (talk) 18:16, 4 February 2017 (UTC)

A few details[edit source]

Under Biome Types > Neutral, "Redwood Taiga Hills" should be "Redwood Taiga Hills M".

Also, Plains M is unobtainable through both customized and superflat worlds, defaulting to Ocean - basically, they've been removed from the game.

Thanks. — 47.147.237.79 16:52, 4 February 2017 (UTC)

Plains M is categorized as unused, and Redwood hills is a hills biome. The BlobsPaper.png 20:30, 4 February 2017 (UTC)

Plains M's image[edit source]

The image for the supposed 'Plains M' biome is actually a picture of the grasslands biome from beta 1.8. If you go back in the revision history to September 18 2011, you can see the same picture, and the picture itself is labeled '1.8 biomes grassland'. 122.106.169.23 06:32, 22 February 2017 (UTC)

Need someone to add info to The Void biome[edit source]

I'm trying to make a Skyblock map, so I went to the "The Void" superflat template. Unfortunately, I discovered that no mobs will ever spawn in this biome unless you use commands, spawn eggs, or mob spawners. I tried to add this information, but the page is protected. Is there anyone who can edit the page to add the info? Maybe an admin? Please? --108.230.40.67 20:01, 16 March 2017 (UTC)


 Done Please note that an admin is not always required. To check the protection level, add ?action=protect to the end of the URL. The BlobsPaper.png 22:38, 16 March 2017 (UTC)

"Gravel Flowers"[edit source]

needs a comma. :) It's the feature list for Extreme Hills; a comma is missing between Gravel and Flowers. (It's got me wondering what a gravel flower might look like, but it is in fact two separate links. :) -- eekee/derdiggermunster 90.255.108.59 16:32, 17 March 2017 (UTC)

Comma added! – Sealbudsman talk/contr 18:18, 17 March 2017 (UTC)

Existence of Plains M[edit source]

Has it ever existed? Seems strange that plains have two variant biomes... --94.101.51.160 12:39, 16 April 2017 (UTC)

I guess it was the initial mutation for plains before they came up with the sunflowers. They probably just left the unused code. But now in 1.11 it's definitely gone, I just checked on the source code. Fusseel (talk) 01:12, 14 May 2017 (UTC)

Biome Categorization does not match Biome.TempCategory Enum values in MC 1.10[edit source]

I was using this article as a guide while writing a mod. The article lists 5 types: snowy, cold, medium/lush, dry/warm, neutral. However in the code I'm only finding 4 values for the TempCategory biome classification: COLD, MEDIUM, WARM, OCEAN. I'd change this myself, but I'm new to modding and I don't want to jump to gun on a huge article rewrite if I'm wrong for some reason. Orbenn (talk) 23:10, 13 May 2017 (UTC)

You are right. In the article the so called "snowy" actually is the TempCategory COLD while "cold" and "medium/lush" are both from the TempCategory MEDIUM. The separation of the two medium categories exists, because in the biomes labeled "cold" it'll snow at a certain height and in the biomes labeled "medium/lush" there will never be any snow. The terminology doesn't strictly follow the terms used in the code as you can see. Fusseel (talk) 00:42, 14 May 2017 (UTC)

Compilation images[edit source]

It isn't necessary to combine the images together, the separate images can simply be placed next to each other. Keeping them separate allows individual images to be changed easier, and allows for reuse on other pages. Fusseel and Superspace: please upload the new images used in the compilations in their full resolution separately. MajrTalk
Contribs
10:53, 13 June 2017 (UTC)

I am aware that it would be harder to update images if they are used in a compilation. However, having a massive "tower" of images like what was seen in the Hill biome was aesthetically unpleasant. I can't speak for Fusseel so I don't know his or her reasoning behind the other compilation (which in my opinion was unnecessary since the End biome only had 2 images). If someone with knowledge of table formatting could find a way to place the individual Hill image files in a more compact pattern (like in the compilation image) within the table, we'd definitely do it that way. The individual Hill images have already been uploaded and should still exist for use in other pages. Superspace (talk) 19:05, 13 June 2017 (UTC)
Maybe something like:
TheEnd 1.9.png End (Biome Part).png
New End 15w31b.png
and
ColdTaigaHills.png Forest Hills Biome.png
Redwood Hills.png JungleHills.png
DesertHills.png
Sealbudsman talk/contr 19:18, 13 June 2017 (UTC)
Perfect! That's exactly what I was imagining. I'm not sure how well that formatting would mesh with the actual table though. I will experiment and see. Superspace (talk) 04:37, 14 June 2017 (UTC)
I just saw that the table was getting longer and longer because of the images so I made them into one compilation. I didn't think of including the separate images side by side. But I have a minor problem with this: if one of the images changes with a new aspect ratio the compilation is going to look terrible. That wasn't possible when there was only one file containing the whole compilation and to be honest I didn't think that anyone would have any problem changing a single image inside of this one file. But alright, we'll see how this goes. Fusseel (talk) 10:53, 14 June 2017 (UTC)

Minor detail to be edited[edit source]

Since Plains M has been removed like it should've a while ago, the note on how many biomes there are near the top of the page needs to be edited as well. I also thought that it could redundantly add the number of actually obtainable biomes in a normal world, which is three less than the total.

47.150.251.217 17:41, 15 June 2017 (UTC)


 Done The BlobsPaper.png 01:18, 16 June 2017 (UTC)
There are 62 biomes, not 63. Simply counting the entries on the page yields that number. Btw, plains M never was a thing. It either was a prank by someone or just a mistake, as the internal name of the sunflower plains is "mutated_plains". --Fusseel (talk) 10:17, 17 June 2017 (UTC)

Vertical tables on mobile[edit source]

The wide tables on here look pretty bad on mobile, would styling the table to be vertical be acceptable for mobile? We could probably do this for other wide tables where the headers aren't very important. MajrTalk
Contribs
03:14, 10 July 2017 (UTC)

It doesn't look too bad on desktop either. The biome names and sprites make very nice pseudo-headers. With some minor adjustments to the width, I definitely
 Support this change. Superspace (talk) 06:44, 10 July 2017 (UTC)
Perhaps we just scrap the table entirely, and go for a more infoboxish styley. MajrTalk
Contribs
07:14, 10 July 2017 (UTC)
That could work too. I actually prefer that setup, mainly because it doesn't look as cluttered with a bunch of stacked headers. How would it work with multiple images? (In the case of hills/plateaus.) Superspace (talk) 07:35, 10 July 2017 (UTC)
I have to say although I like this last suggestion of yours it won't work out. You picked two biomes with a decently sized description, but that's not the case for most of them. There are many biomes where the description consist of only one sentence, sometime not even more than ten words. The images and tables on the right will be fine, but the left side of the page featuring the descriptions will be almost empty at some places. That's just going to look terrible. Of course one could fill that space with some more images, but that would only lead to the whole page becoming a real mess like it already is the case with generated structures. A table like now is the best way for structuring such a complex article. But using a vertical design isn't going to help. Mobile users will benefit from this change, but c'mon, you can't tell me that it "doesn't look too bad" on desktop. It's terrible! One way or the other mobile or desktop will have to be prioritized. There is no way of supporting both of them in an equally good looking way. Fusseel (talk) 10:37, 10 July 2017 (UTC)
I have to disagree. The tables already have a loads of empty space on single line descriptions, the only real difference is it being broken up by the text being right in the centre of it, which we could probably still do if that is the issue. In fact the only increase in empty space is ~40px, half of which comes from the header having its own line. If we could find a way to pull the floating content to be inline with the header, the height of each "row" would only be ~20px higher.
Here's a comparison of a single line description (with the largest features text), showing only a small increase in empty space and height: http://i.imgur.com/O5lwpkS.png
Here's a comparison of a long description on a common smaller resolution (1366x768), showing an improvement in height, due not only to the slightly larger width for the description, but the text wrapping around the floated content: http://i.imgur.com/Xe3CR2f.png
Ultimately, the design looks to me much more readable on smaller screens (including desktop), while wasting a small amount of space on large screens. Seems like a net win.
Also in case I wasn't clear, the original vertical table design would be mobile only, desktop wouldn't change. MajrTalk
Contribs
12:30, 10 July 2017 (UTC)
You really do back up your arguments very well that's for sure. ^^ I understand that the increase/decrease in size is minor, but I still prefer the table from a visual standpoint. But if it's possible to show the vertical table only on mobile im cool with that, but I wouldn't know how to do it. Fusseel (talk) 17:00, 10 July 2017 (UTC)
Mobile has a separate stylesheet, so it's really simple to have mobile-only styles. MajrTalk
Contribs
05:21, 11 July 2017 (UTC)
I personally like the section approach, I've never been a fan of giant tables to show that kind of information which is why I was so much in favor of scrapping it on Commands. My only concern is with the two side boxes, the text becomes quite thin (iPad size simulation) before it entirely moves below the infobox/picture. I guess it already does that only worse on the actually article's table so its still an improvement. KnightMiner t/c 17:24, 10 July 2017 (UTC)
Fortunately, the text can be easily set to a minimum wrapping width to fix that. Although I think I would've preferred to force the floating content to wrap first, but I don't think that's possible without JS. MajrTalk
Contribs
05:21, 11 July 2017 (UTC)