Mining a spawner ??[]
The article says you can't obtain a mob spawner, then the next sentence says "the proper tool to mine with is pickaxe". I thought mining means breaking stuff to obtain loot ?
Either reword it or explain how to "properly" mine a spawner, rather than just destroy it. –Preceding unsigned comment was added by 96.23.166.33 (talk) at 08:46, 6 February 2016 (UTC). Please sign your posts with ~~~~
- The "proper tool" means the one that you have to use to mine it quickly. Anomie x (talk) 12:22, 6 February 2016 (UTC)
- Done I reworded the sentence. The Blobs
23:39, 6 February 2016 (UTC)
- Shouldn't it be yellow, since it doesn't drop anything? Or does the experience count? –Majr ᐸ Talk
Contribs 10:45, 7 February 2016 (UTC)
- I personally am neutral on whether to count experience here or not (it is a drop, but not an item), though but setting it to yellow would be less confusing for people who don't know about proper tools not always dropping the block. –KnightMiner t/c 22:07, 7 February 2016 (UTC)
- When I mine the block in the new update (Better Together), I get the monster spawner as a drop in survival. Hambo325 (talk) 19:05, 10 October 2017 (UTC)
Exclusion Zone[]
The wiki doesn't mention the zone the spawner checks to see if the area is full. The talk page mentions that 1.8 changed this zone to be the same as the spawning zone, but I feel it should be mentioned at least, in the page itself. 172.68.59.131 07:29, 17 August 2016 (UTC)
- Yes it does: "If, at the time of spawning, 6 or more mobs of the spawner's type are present within a 9×9×9 area, centered on the spawner block, the spawner "poofs" without creating any mobs and then waits for the next cycle." Anomie x (talk) 11:28, 17 August 2016 (UTC)
So a pig spawner (or in my case: a chicken spawner) have a vertical range of 3 blocks, but where should I place the floor for maximum spawning space? I want to use 2 floors if possible
S = Spawner
[] = testing place for a spawn
B = Blocks
Example:
[ ]
[S]
[ ]
So where should I place the floor? (2 floors if possible)
[ ]
[S]B
[ ]
B
or instead:
[B]
[S]
[B]
Don't Know if it's a bug or not[]
So, when I mine a monster spawner with my pickax on the new Xbox One update (Better Together), it drops as a block. I don't know if your information is wrong but I'm in survival and I can legitimately get this block but I can't "use" it (no spawn eggs in survival) Can anyone explain? Hambo325 (talk) 19:01, 10 October 2017 (UTC)
Can someone try it on Xbox? --Hambo325 (talk) 18:29, 20 October 2017 (UTC)
Disabling spawners with torches.[]
I removed the claim that a single torch on top of a spawner will disable spawning since it isn't entierly true. Firstly it's the light level in the spawning block that matters, not the level in the spawner meaning that a wall placed next to the spawner can allow spawning on the other side even if the spawner itself is well lit. Secondly a single torch on top of the spawner doesn't provide enough light in the bottom corners of the spawning volume. As a matter of fact, even torches on top and on all four sides didn't completely stop spawning from a cave spider spawner with the floor dug away 5 blocks around it. –Preceding unsigned comment was added by Hexalobular (talk • contribs) at 02:01, 21 October 2017 (UTC). Please sign your posts with ~~~~
Further testing shows that a single torch on top of the spawner allows spawning in the corners of a 7X7 dungeon as well as outside the walls of a 5X5 or 5X7 dungeon (Tested) and should allow it in the entrance if it is in a corner. Hexalobular (talk) 08:59, 21 October 2017 (UTC)
Radius of 16 Blocks through X and Z but not Y[]
The quote i'm referring to: "A monster spawner is only active when a player is within a radius of 16 blocks from the spawner"
I don't know if the radius only refers to the X and Z axis, but i'm just confused as to why there's no mention of the Y Axis being limited to a distance of 10 blocks. –Preceding unsigned comment was added by 92.17.90.163 (talk) at 06:36, 21 March 2018 (UTC). Please sign your posts with ~~~~
- "Radius" typically means the spherical area of that radius, i.e. euclidean distance. RealWormbo (talk) 08:41, 31 December 2018 (UTC)
Recent Move suggestion[]
It has been suggested by MinecraftPhotos4U (talk • contribs • logs • block log) that this page be moved to Spawner because it is supposed to be renamed that in Java 1.13.
Strongly oppose. It has not been renamed in Bedrock (yet?) or, I presume, in Nintendo 3DS or Legacy Console editions. Renaming it to match just Java would show favoritism, which is contrary to Mojang policy. Arguments that retaining the current name also shows favoritism fail because it's the name used by most versions and the majority of players, and because failure to take an action is a weaker argument than taking it when it comes to implied intent. A redirect from Spawner to Monster Spawner is clearly the appropriate action. – Auldrick (talk · contribs) 15:30, 17 July 2018 (UTC)
- I asked HelenAngel about it, and she replied that bedrock will follow the new names sooner or later. "Arguments that retaining the current name also shows favoritism fail because it's the name used by most versions" Bedrock edition is just 1 version and legacy console is basically depreciated nowadays, and as I just said, they'll update to that name soon-ish.
- It has also been talked about a LOT on the community portal what naming should be used, and the 1.13 names is the outcome. FVbico (talk) 15:35, 17 July 2018 (UTC)
- "...they'll update to that name soon-ish": Then why not wait until then, when the question of favoritism will no longer be an issue? It's not like leaving Spawner as a redirect has any real consequences for readers.
- "Bedrock edition is just 1 version, and legacy console is basically [deprecated] nowadays": Not by Mojang, it's not, and you just dissed Nintendo 3DS like it's dirt. But even if Java and Bedrock were the only 2 versions, ignoring one to follow the other still implies favoritism, whereas not moving the page implies no preference.
- The only related discussion on the Community portal certainly isn't "a LOT" (7 comments from 5 editors), and except for you nobody even mentioned article names. Furthermore, the discussion was about when names used in development can be adopted as official, and when it was pointed out that different current versions can use different names for a feature, the subsequent discussion concluded that any such name can be used equivalently. It certainly did not say that 1.13 names are preferred, or anything of the kind. Since neither name is preferred, and the current page name is a correct alternative, there is no requirement to rename the page, and no reason to unless you're a Java elitist. –Preceding unsigned comment was added by Auldrick (talk • contribs) at 17:47, 17 July 2018 (UTC). Please sign your posts with ~~~~
- "and you just dissed Nintendo 3DS like it's dirt" you're reading too much into that, the 3DS edition is basically bedrock edition without the cross-platform play and marketplace.
- "(7 comments from 5 editors)" it has been discussed on the discord as well as there, and naturally, more messages are left in discord than a wiki talk page.
- "and no reason to unless you're a Java elitist." Yes I prefer Java, but I keep that preference away for basically anything.
- As the names on bedrock can basically update at any given moment, there's no reason not to follow the java name, as that' the newest name it is given; I bet you didn't even consider following the latest given name for articles or images. And realistically speaking, there are only 2 versions, as (what I've said before) 3DS edition is basically bedrock, and legacy console it as good as depreciated (additionally, less than 5% of the community still plays on those according to mojang IIRC). FVbico (talk) 18:09, 17 July 2018 (UTC)
- For me, I always thought that the article were named based on the name of the latest version of the Java edition... It would make sense to continue to be consistent everywhere on the Wiki. And in addition, we have a confirmation from Mojang that Bedrock will eventually follow the same name... I don't understand why this discussion even happens. JSBM (talk) 19:08, 17 July 2018 (UTC)
- The statement that not renaming does not show preference is false. Any state of the article will indicate preference, even if the underlying action is a decision not to take some other action. --AttemptToCallNil (report bug, view backtrace) 19:57, 17 July 2018 (UTC)
- I never said that it doesn't show preference. I said it doesn't imply preference, just like not acting to condemn something evil doesn't imply that you endorse it. Whereas deliberately choosing the Java name over the Bedrock one when both are current, and with no other reason, clearly does imply a preference. As to whether it shows preference, that's for the reader to decide. We can't control what they choose to infer in the absence of evidence either way. – Auldrick (talk · contribs) 22:34, 18 July 2018 (UTC)
- "Spawner" has been redirected to this page in 2010. --AttemptToCallNil (report bug, view backtrace) 15:39, 17 July 2018 (UTC)
- Support contingent on seeing the discussion where HelenAngel mentioned this. I believe FVBico totally when he reports the conversation, but it's a matter of making my own judgement on that Helen discussion, and on the discussion being something others could read as well. As for the naming discussion, having read it myself, I didn't see that we agreed what to do when two release versions have different names. I don't agree that "1.13 names is the outcome" applied to this case. I'll wait on hearing it from Helen or some other Mojangsta. – Sealbudsman talk | contribs 18:12, 17 July 2018 (UTC)
- Support Of course, this is now the official name (and it makes more sense, given that we can make spawn any entity). JSBM (talk) 16:37, 17 July 2018 (UTC)
- And of course, here we are three years later and the favoritism shown to Java based on the as-yet empty promise that Bedrock will "update to that name soon-ish" remains as a monument to Java elitism, and in spite of there being nothing even close to consensus given my strong opposition and Sealbudsman's contingent support, for which contingency I find no evidence here. I remain hopeful that henceforward we can remain fact-based instead of blindly accepting assurances from Java bigots based on timey-wimey speculations, be they from Mojang or the author's own imagination. — Auldrick (talk · contribs) 08:04, 6 August 2021 (UTC)
- I am not sure what this is about. The article is called "Spawner". While I prefer that our style guide be changed to favor Bedrock naming simply because Bedrock has the larger installed base (and I still chafe from the fact that the style guide favors Java naming due to a unilateral un-discussed change by someone in the past that never got reverted), for this article, the name "Spawner" isn't going to confuse anyone, and the lead sentence clearly explains the difference anyway. Amatulic (talk) 21:23, 1 February 2022 (UTC)
- It began when Java renamed the block to just "Spawner". The article, originally named "Monster Spawner", was moved to "Spawner" leaving "Monster Spawner" as a redirect. The objection was made that Bedrock still called it "Monster Spawner" and that Java players still knew it by that name, so it would make more sense to retain the original name and make "Spawner" the redirect. However, a certain forceful person claimed authority by saying he'd been told by a Mojangster that Bedrock would "eventually" adopt the Java names. Notwithstanding that (1) this is unverifiable original research, that (2) the wiki is not supposed to speculate about unannounced changes, and that (3) "eventually" doesn't seem to be in any hurry to get here, no clear consensus was reached and the move was allowed to stand. Personally, I gave up because nobody was bothering to put up an opinion for discussion, let alone call for a consensus.
- With respect to your argument that "Spawner" isn't going to confuse anyone, I'm not sure I entirely agree, but you're right that the first sentence clarifies the ambiguity so it's not worth arguing about. But what concerns me is that whenever a preference for either Bedrock or Java is inevitable, Java almost always wins out. When the text needs to contrast the behavior of a block or item, the Java behavior is almost always given first. When separate tables are required, the Java table always appears first. This is a subtle, institutionalized way to denigrate Bedrock as a "little brother," despite its preeminence as the dominant version. I suppose many editors see my attitude as a tempest in a teacup, but this is important to me, and I will continue to push for editors to become more egalitarian. — Auldrick (talk · contribs) 02:14, 2 February 2022 (UTC)
- I'd like it the other way round too. Most readers would come here with a Bedrock perspective, so that should be up front in the articles. But, we have a style guide that favors naming things according to Java edition. And, I suspect even without the style guide, Java information would appear first in new articles simply because the Java builds tend to be released first, and the Java Edition code can be examined, unlike with Bedrock Edition. So part of the bias we see is institutionalized, and part is probably just naturally occurring due to release order and code transparency. Amatulic (talk) 07:02, 2 February 2022 (UTC)
Moving the page[]
This page should be renamed to Spawner, to be up to date, and based on the naming that will be use in other versions in the future (based on HelenAngel). JSBM (talk) 13:45, 20 September 2018 (UTC)
- Agreed, only 1 person opposed ever since 17w47a was released; same for Redstone. FVbico (talk) 13:47, 20 September 2018 (UTC)
- Since when do we base decisions on the number of users who supported or opposed a viewpoint? Note that this doesn't mean you shouldn't express support of a stated idea. --AttemptToCallNil (report bug, view backtrace) 13:53, 20 September 2018 (UTC)
- That's exactly the reasoning I suggested not to use... --AttemptToCallNil (report bug, view backtrace) 14:17, 20 September 2018 (UTC)
- I mean I suggested not to assert that the number of users supporting a viewpoint is indicative of whether this is the viewpoint which should be accepted in the decision. --AttemptToCallNil (report bug, view backtrace) 14:28, 20 September 2018 (UTC)
Disabling Blaze Spawners[]
I'm playing on a 1.14.4 local game with no mods, and placing 4 glowstone blocks on the four sides of a Blaze spawner does not disable it like the article states. I tried placing glowstone in a full square all the way around it and on an extra block on top of the spawner, that still didn't work. Not really sure how to do it, but the article is incorrect. Vaindil (talk) 22:43, 6 October 2019 (UTC)
- Can confirm on 1.15.2 in a local game with Optifine and no other mods that placing four glowstone blocks on the four sides of a blaze spawner does not disable it. That section is incorrect. The method above it where you place sixteen blocks in a pattern around the spawner does disable it. Maybe the four block method only works in Bedrock? The image's description specifies that it was done in Bedrock, and that the spawner still "poofs" without any blazes spawning. --Sam 86314 (talk) 05:59, 5 April 2020 (UTC)
- @Sam 86314: That's my image, and yes, placing blocks of light level 15 on the four vertical sides of a blaze spawner prevents blazes from spawning. I used jack'o'lanterns but they have the same illumination as glowstone. If this doesn't work in Java, then the statement should be tagged {{only|bedrock}}. I've just done so. ~ Amatulic (talk) 08:14, 5 April 2020 (UTC)
- @Amatulic: I should clarify that I initially tested your method with a spawner that I cleared out a 9x9x5 area around. Your method doesn't produce enough light to disable the spawner in that situation. I have another spawner that I haven't cleared out, and your method works for the smaller room. --Sam 86314 (talk) 02:48, 6 April 2020 (UTC)
I'm playing 1.15.2 and blaze spawners aren't completely disabled using a 7x7 torch grid, centered on the blaze spawner and its y value. I'm noticing they are spawning just outside of the 7x7 grid (4th block out from the spawner). --Vorlice (talk) 23:03, 6 May 2020 (UTC)
The claim "Laying 9 blocks in the pattern shown on the right using blocks having a luminance value of 15" is with conditions. It requires the spawner to be placed on a floor. If there is no floor, the Blazes will spawn where the floor was. MikkoLukas (talk) 13:46, 13 March 2023 (UTC)
Generating spawners[]
I once watched a video where someone generates a monster spawner by putting cobblestone with a flying machine into a not generated chunk. Because there is the cobblestone structure, the game then thinks that a spawner should be in the middle of the structure and generates one when you enter the chunk.
I don't know if it still works but if it does then it should be mentioned in the Obtaining or in a new category, if it doesn't then it probably should be mentioned in the history category. --Neikrodent (talk) 20:39, 15 February 2020 (UTC)
- Something somebody did in a video (and by the way there are fake YouTube videos about Minecraft out there) should not be mentioned in the article. If it's a bug, then it can be mentioned if it was reported in the bug tracker. ~ Amatulic (talk) 00:34, 16 February 2020 (UTC)
- I understand that there are fake YouTube videos and after trying different tags I found several videos of spawner generating machines. Thanks for notifying me about the bug tracker system, I don't think it has been reported in the bug tracker yet.--Neikrodent (talk) 19:57, 20 February 2020 (UTC)
Spawner mini-model loadouts reset?[]
So yesterday, I found four spawners with special loadouts on the mini-model inside the cage. One was a zombie spawner clad in full gold armour, two were skeletons with enchanted bows, and the third was a skeleton clad in full iron armour. It was too late at night for me to wanna build a grinder of them, so I left them as they were. Come to today, the aforementioned spawners all have default mob loadouts. That is to say, the zombie spawner lost its gold armour, and the skeletons all reverted to standard bows and no armour. Aside from the fact that that really bites because that could have been some serious hardware potential, is this a thing that's happened for anyone else? 90.198.143.131 16:28, 28 February 2020 (UTC)
- The spawners contain data for the entity directly, as such random variants for defaults can get displayed as well, but that doesn't mean that variant would spawn at all from it that spawn rotation. FVbico (talk) 17:24, 28 February 2020 (UTC)
Spawner Renders[]
Now, before I say anything, I understand that rendering every mob/entity in a spawner could be extremely tedious and time consuming. Now, I would like to make a request: Spawners with every mob/entity inside. Just a thought… -FezEmerald (Talk to me|See what I've been up to) 23:05, 10 April 2020 (UTC)
Skeleton Spawner in Nether no longer Spawn Wither Skeletons[]
I know that at some point in the game's development in some versions Skeleton Spawner in the Nether spawned Witherskeletons instead of Skeletons meaning that it would be easier to farm Heads. In 1.14.4 and above they spawn regular Skeletons, when did they changed that and in which versions was it possible? –Preceding unsigned comment was added by Deathcounter-gpuser (talk • contribs) at 16:16, 9 June 2020 (UTC). Please sign your posts with ~~~~
This changed in 16w32a (1.11). This wasn't a change to the spawner, it was a change to the skeleton mob/wither skeleton.
Prior to this, the wither skeleton was really just a skeleton mob with a SkeletonType tag to indicate it was a wither skeleton. This means it is a skeleton and can spawn from a skeleton spawner. If the spawner was in the nether, then it uses the type for the nether, meaning it would spawn wither sekeletons.
From 16w32a onwards, the wither skeleton was its own mob type. As it was no longer a skeleton mob, the skeleton mob spawner cannot spawn it. Instead a wither skeleton spawner would be needed.Jack666Black666 (talk) 22:40, 16 May 2022 (UTC)
Bedrock Edition Name[]
The name of the spawner in Bedrock Edition is 'Monster Spawner'. --Universespy (talk) 13:00, 14 October 2020 (UTC)
Mechanics section has totally broken numbers[]
While the block is active, it spawns mobs up to 4 blocks away from the spawner horizontally, and up to 3 blocks away vertically, effectively meaning mobs can spawn in a 9×9x6 area around the spawner.
A 9x9x6 area would be 9 wide, 9 high and 6 deep. The correct form, as used in the rest of the page, would be 9x6x9. But 3 blocks away vertically is 9x7x9. I would also suggest replacing "around the spawner" with "centered on the spawner".
but vertically, mobs spawn with their legs at either the same layer as the spawner block, one block above it, or one block below it.
Now it says only 1 blocks away vertically, so 9x3x9, which matches with the rest of the page. I believe everything before that to be wrong. – Unsigned comment added by 46.5.255.32 (talk) at 09:10, 10 March 2021 (UTC). Sign comments with ~~~~
- I changed 9x9x6 to 9x7x9 but I agree there are still contradictions. If a mob can spawn with its feet one block above or below the spawner block, and the mob is 2 blocks tall, that means that a vertical space of 4 blocks is required to ensure that the mob doesn't spawn with its head stuck in stone. Amatulic (talk) 19:26, 13 March 2021 (UTC)
Can someone please explain...?[]
The second sentence under Usage reads: "Suitable spawning locations for the block's mob type are provided in the area." I don't understand what this is meant to be telling me. The spawner block certainly doesn't provide any such locations. Was it perhaps an awkward use of "are provided" when the editor was thinking "must be present for the block to accomplish its function"? I suspect so, but the current phrasing has been around long enough without a challenge that I doubt myself. Consequently, I'm inviting alternative interpretations. — Auldrick (talk · contribs) 08:15, 6 August 2021 (UTC)
Can generate naturally pig spawner in vanilla[]
There is a glitch about world gen, there is a buried chest but it is the same location for posion spawner location. It make 5 pig spawner surround it
- This is obviously a bug. While we do document bugs occasionally, it's only when they are understood very well, some people find them useful, and Mojang has therefore not decided whether they will fix them. This bug sounds like something somebody (maybe you) found recently, probably hasn't been studied enough to verify that it works the same way for everybody, and that nobody has any reasonable use for. It's probably a bug Mojang will fix fairly soon, so taking time to describe it in the article and then remove it again in a month or two is just wasting time. Also, a bug like this could be in either Java or Bedrock but almost certainly not both, so when you add something like this to an article you need to indicate which one with an
{{only}}template (or similar), and you also need to reference it back to the bug report where it's fully described. — Auldrick (talk · contribs) 18:20, 14 December 2021 (UTC)
Can we get confirmation on pistons?[]
When the article begins, it states that spawners CAN be interacted with in terms of pistons (I believe this is under the first or second subheading?). At the bottom of the page under interactivity, it states pistons/sticky pistons CANNOT be used interactively.
Can individuals use pistons? If yes, interactivity should be reworded. If no, the beginning should be removed/reworded, no?
The parts I'm speaking about are under obtaining which reads: Obtaining
Spawners cannot be obtained in Survival, even with Silk Touch.
In Bedrock Edition, a monster spawner can be obtained from creative inventory or by using pick block. It is initially empty and inert, but can be configured to spawn a desired mob by using a spawn egg on the placed block. Although not obtainable as an item, it nevertheless can be manipulated by pushing or pulling it with a piston or sticky piston.
And then:
Piston interactivity
Spawners cannot be pushed by pistons. They also cannot be pushed nor pulled by sticky pistons.
Thanks in advance everyone.
108.175.225.191 12:35, 21 January 2022 (UTC)
- Fixed it. Incidentally, please don't space out text unnecessarily, it just causes unnecessary scrolling. — Auldrick (talk · contribs) 14:36, 21 January 2022 (UTC)
Do spawners check for obstructions?[]
The article says that spawners attempt to spawn within a 4-block range, with the actual spawn volume shape being different in Java vs Bedrock.
Some dungeons have just a 5×5 floor. That is, there are only 2 blocks between the spawner and the wall. If there is nothing on the other side of the wall, that's still 1 block of horizontal space in which the spawner can spawn a monster.
However, I have never seen a spawner create a mob outside the dungeon walls. Admittedly my observation samples are small. And because I play Bedrock edition, the spawn volume is an octahedron, so the spawn volume sticking outside the wall of a 5×5 room would be just 1×1×1, giving such a low probability of spawning that I have never seen it happen.
Does this happen in Java Edition? Or does the spawning range stop at an obstruction like a wall? Amatulic (talk) 01:21, 25 January 2022 (UTC)
- I just repeated my experiments to verify these results. The range for a Bedrock mob spawner is the same 9×3×9 range as Java except that the corners are cut off, similar to shapes based on taxicab distance. The mob's hitbox bottom must be within this range, and of course there must be enough air blocks above it for the mob to fit. An obstruction between the spawner and the candidate spawn block does not block the spawn. Note that it's misleading to say the shape of the spawnable range is defined by taxicab distance, as in the layers below and above the spawner the actual taxicab distance is 5, not 4. The shape of the range is a blockified rectangular prism rotated 45 degrees, not an octahedron. I'm sorry I can't give you specifics for Java; I'm not able to run it on my PC. — Auldrick (talk · contribs) 02:51, 25 January 2022 (UTC)
- OK, so it's taxicab distance horizontally, but full distance vertically. Thanks for the correction.
- By "obstruction" I meant the walls of the dungeon. If a the four walls of a 5×5 dugeon are surrounded by air, can a monster spawn in the space outside the walls?
- I thought what I said would make it clear. Obstructions within the spawn range, whether single blocks or walls, do not block spawns. For example, you can completely surround the spawner with solid blocks and it will still spawn outside the encasement. One more thing: It's 9×3×9, not 9×4×9. A spider spawner cannot spawn spiders at Y+2, only Y+1. 2-block high mobs need air at Y+2, so maybe that's what you were thinking, but if you include the air blocks above the spawn block in the spawnable range it gets complicated because of mobs having different heights. — Auldrick (talk · contribs) 17:35, 25 January 2022 (UTC)
- I've never seen this in Bedrock Edition because only a 1-block column of air from the corner of the diamond sticks out of each wall, so the probability of this happening is so low that it never came up for me. Java Edition, with its rectangular spawn volume around the spawner, has 32 columns of air around the outside of the dungeon it in which a monster can spawn. So I was wondering if this actually happens, or do the walls matter? Amatulic (talk) 17:24, 25 January 2022 (UTC)
- All clear now. Thanks. That tells me, for Bedrock at least, making a flooded dungeon is probably best with a 7x7 floor. Water management is easier that way, it's more compact than 9x9, and I'm giving up only four 1-block columns of the spawning volume at the corners.
- As I did with File:Lightning distribution BE.png to show the distribution of lightning strikes, I tried a similar test to fill the spawn volume with objects to show where zombies spawn, using command blocks to place a sign in the spawn location (and kill the zombie after it spawns), but this wasn't effective. Some of the signs were placed but most dropped onto the ground. Tried it with flower pots but those have a collision box. Red mushrooms don't have a collision box but they had the same problem as signs, most of them dropped on the ground. Amatulic (talk) 21:41, 25 January 2022 (UTC)
- I'm not following you. My test setup for the spawner seems simpler than yours sounds. If you'd like to see it, you can use this link to my Realm: https://realms.gg/ifKqrY8Gwr0. My skeleton dungeon is 9x9 diamond-shaped with 5 water sources and doesn't miss any spawnable blocks. If you'd like to see it, you can download a copy of that world from https://1drv.ms/u/s!Agfpi9lElwxOgbAc0Hkc0nBXYxalWQ?e=VmD8xG. (Note: It's a big world.) The dungeon is at -2225, 7, -1281. — Auldrick (talk · contribs) 22:20, 25 January 2022 (UTC)
Disabling blaze spawners with slabs?[]
Now and then I've run across a video in which someone puts a slab on top of a blaze spawner to disable it. I don't understand how or why that would work unless blazes always attempt to spawn directly above the spawner, but if it's effective, perhaps it should be mentioned. Amatulic (talk) 14:48, 27 May 2022 (UTC)
- I just tested that here and it certainly doesn't seem to do anything. I get it when they do it on, say, a spider spawner because you want to keep spiders from hanging out on the top of the spawner in an XP grinder, but for blazes... it does nothing for me at least. - AD OffKilter (talk) 16:45, 27 May 2022 (UTC)
- I forgot to mention I'm using Bedrock Edition. But yeah, I just tried it too, and it didn't do anything. I tried building a room around the spawner to enclose it, but that made no difference. The only thing that worked was to put a jack-o'lantern all all faces of the spawner. Now I'm wondering what the purpose of putting a slab on a blaze spawner could be, other than preventing them from spawning above the spawner. Maybe it's to force the blazes to be pushed by flowing lava in a farm, which doesn't happen if a blaze is on top of the spawner. Amatulic (talk) 20:19, 27 May 2022 (UTC)
Phantoms, Zoglins, and Endermites.[]
Will naturally monster spawners that produce Phantoms, Zoglins, and Endermites? Because they spawn rarely.
Move to Monster Spawner[]
For me, I Support this move. Because it's a new name for the block in JE 1.19.3, which is released. It's also a name for the block in Bedrock Edition. 
Brain180 "click here to talk" 10:56, 8 December 2022 (UTC)
Why did Mojang rename it?[]
I get parity, but why change Java to Bedrock instead of change Bedrock to Java? "Spawner" is pretty ambiguous, where as "Monster Spawner" can mislead that it specifically only spawns monsters. You would think something that you can use to spawn pretty much any entity should have an ambiguous name such as "Spawner". – Unsigned comment added by ProfuseMartian (talk • contribs) at 04:21, 24 December 2022 (UTC). Sign comments with ~~~~
- To make a long answer short: Its Mojang, and they can do what they want. Feedback about this can be made here. BDJP (t|c) 04:32, 24 December 2022 (UTC)
- I wish it were that easy, anytime I've posted feedback to that site they just remove my posts without any reason (even though they 100% follow the guidelines). Knowing Mojang, this is something they will never change back. ProfuseMartian (talk) 14:08, 24 December 2022 (UTC)
Spawner Not Disabled at Post-1.18 Light Requirements?[]
It seems like monsters still spawn from spawners depending on the pre-1.18 light level requirements [which I approve of]. Now, the spawn requirements are light level 0 for many of them. In this article, it seems like that has not been accounted for in the explanation. I have tested this with a zombie spawner, and they spawn above light level 0.
Sorry if I have misread or misunderstood. Thank You.