[MC-28151] Block Spawners do not support block 36

Block spawners, such as sand entity spawners etc., cannot spawn sand entities which turn into block 36.

This is specifically a problem for mapmakers since block 36 has very unique properties and can be made solid or pass-able. For example you can make walls which appear to be invisible,are solid and mobs still track players through this wall as if it wasn't there.

To recreate the issue easily:

1. Download MCEdit and create a region of block 36 blocks.
2. Next use http://sethbling.com/structurespawner2 to create structure spawners for the region of block 36.
3. Next delete the region of block 36.
4. Go into minecraft and try and spawn in the structure with the structure spawning.

The first image shows what happens when you try and spawn the block 36 in.
The second image shows one of it's uses. A 2 by 2 region of block 36, which is to turn into iron blocks in 99999999999 seconds, is used to hold back a horde of zombies tracking the player while the player can shoot through the region with a bow and hit the zombies with his diamond sword.

All this having been said we can destroy the region of block 36 with the spawner method.

Attachments

Comments 17

Tails 2013-08-05T01:07:46Z

This site is for bug reports only. For feature suggestions or changes please use the Minecraft Forums: Suggestions.

sancarn 2013-08-05T01:14:47Z

Wait... Structure spawners are a feature. This is a bug to that feature. This is a bug. NOT a suggestion.

Tails 2013-08-05T01:36:30Z

1. Download MCEdit and create a region of block 36 blocks.

The use of 3rd party tools like MCEdit makes this ticket invalid automatically.

sancarn 2013-08-05T01:41:01Z

Wait....
https://mojang.atlassian.net/browse/MC-15515
https://mojang.atlassian.net/browse/MC-1004

Both of these reports require external 3rd party tools like MCEdit yet they were classed as bugs, not suggestions, and they were fixed and ultimately the bug report was resolved. Yet now you are telling me this bug doesn't apply because it requires MCEdit and custom spawners? I cannot see any sense in that... You can't say it is a bug once when previously it has been classed as a bug!

Direct quotation from the report:
"Open MCEdit and use the Change Spawners filter..."

and another

"The ability to set these properties on spawners was a deliberate feature in 1.4.
If a feature doesn't work as intended, that's a bug."

Th3F4114n0n3 2013-08-05T15:11:01Z

I think the difference is that MCedit in those instances was modifiying a standard feature to start in a way it possibly could in game.

With your issue you are making something spawn in that by default cannot be spawned in by normal means which is why it isn't the same thing. you basically telling Minecraft to act in a way its not meant to.

7 more comments

sancarn 2013-08-05T22:29:33Z

By 'standard features' what do you mean exactly? An Health potion with strength 5 cannot be spawned in naturally in a world. The maximum strength is 2.

"you basically telling Minecraft to act in a way its not meant to." Well... no. I'm telling minecraft to create a sand which will turn into a certain block id. This itself is something which doesn't happen naturally yet this was added as a feature. A special case of the feature that doesn't work is still known as a bug right?

Just because it is a very special case doesn't necessarily mean it should be ignored and classed as "working as intended". The issue is not resolved either and I don't really see why it should be classed as resolved... =S I must be missing something extremely obvious here?

Th3F4114n0n3 2013-08-06T14:03:20Z

I'll repsond once more to this even though its marked closed. while your first statement says that the max a potion can be naturally in the world is true but you can set it to five through an eidtor just because it is coded to allow it. The code is implace to allow for that to be enhanced passed its default vaule through an editor (per minecrafts release notes). while your increasing the strength of the potion past its natural point your not telling it something it can't do like telling it to suddenly become a regen postion when thrown. your not telling it to do something it cant do mechanically (so to speak).

Your second point. Where in any release note does it say "give the ability to force a block to change ID at random/on command"? I've read through all of them since 1.4 and nothing states that you can tell a block (sand or other wise), to change into another block.

I'm not saying special cases shouldn't be ignored, I'm just saying that the majority of your problem is based on using a 3rd party software to modify the use of Minecraft past its standard intent and the bug is more than likely do to either, forcing minecraft to do something it shouldn't/can't do per the laws of its internal coding or cause by MCedit directly.

sancarn 2013-08-08T10:42:53Z

No your not getting the point. Falling sand entities CAN and DO turn into other blocks.
http://www.youtube.com/watch?v=G4IdOzIwZDI
Watching that will show you that minecraft does support sand turning into other blocks. You will see that here falling sand entities are created which turn into stairs etc. However the only block that doesn't do this is block 36. Sand entities can turn into every block except for block 36. Block 36 is an exception therefore this has to be classed as a bug.

There currently isn't any implementation for thrown potions to instantly change what they are. If they had implemented a way to throw a splash potion of poison and for it to turn into a splash potion of regeneration in mid air you'd expect to be able to do the same thing but with damage and health potions right? If you couldn't you would naturally class it as a bug.

This is the same situation here. If structure spawners works for sand, stone, sponge, chests, furnaces, bedrock... you would expect it to work for block 36. It doesn't and so it should be classed as a bug.

Th3F4114n0n3 2013-08-09T12:17:26Z

I am getting your point and I will admit that was pretty cool. But your own video proves my point. Its an MCedit trick ("MCedit Magic") which means your using a 3rd party software to force minecraft to do something its not supposed to. So while it may work for other items its not something we can consider a bug since your forcing minecraft to do it in a way that goes against the "natural" coding of the game.

Again, if the implementation was there because Mojang wanted it to be something that can be done then yes, I would classify it as a bug. Mojang didn't intend for people to use a 3rd party program to force its blocks to basically change from what they are coded to do, so I wouldn't classify your issue as a bug.

sancarn 2013-08-09T12:30:23Z

That's the thing though. Sand entites are coded to transform, when they land, into a block of a certain ID value. Minecraft is designed to allow this. The fact that it may not be possible in survival doesn't have much standing since there are many things which aren't obtainable in survival. You have to remember the structure spawners do not force the game to do anything unnatural or magical. They do not exploit a bug, but a feature that was added by DB. It is perfectly natural for a sand entity of ID value 1 to turn into stone when it lands.

Equally it should be perfectly natural for a sand entity with ID value 36 should turn into block 36 when it lands. This is all within the constraints of the code. There's no modding required for this kind of thing to happen.

Th3F4114n0n3 2013-08-09T14:29:50Z

There coded to transform into a specific block id (not any block id). This isn't a feature as much as its coding. the point being you are forcing minecraft to deviate from code by telling it to change the block id of landed sand entity blocks to something else using MCedit to make the forced change.

If it was a feature in the sense of what a feature is, then there would be a vanila way to adjust these items to do what your telling it. The fact that you are "exploiting a feature" using a 3rd party program, is really a way of saying I'm forcing the code to be something else it wasn't actually intended to be, which in terms of gaming, you are modifying the code past its original intent (i.e. it wasn't put in place for people to change but to make the game work) then you are Modifiying it. This in tern makes structure spawners (which were never conceived by the game developers) a modification of the code.

I'm not kicking on NBT editors which Mojang is allowing the use of and making adjustments to the coding on there end, to which the user can adjust attributes to specific things, they never mentioned the actual intention of making items change the coding just utilizing it (i.e. mobs riding mobs is actually coded already and hints is not modifiying the code, attributes values of potions and armor values allowing adjustments past natural spawning elements such as level X enchatments is in the code and thus not modifiying it). Changing Block ID's during natural aspects (falling sand entity to sand block) is not intentional as it isn't an NBT change so its a code change. Thus making this not a bug and invalid.

MCedit, while contains NBT editor properties, isn't a NBT editing program, so certain things it can do are not by terms of what Mojang is doing and allowable change and thus makes certain "bugs" invalid. This is one of them.

sancarn 2013-08-09T15:28:11Z

Well by that token these:

https://mojang.atlassian.net/browse/MC-15515
https://mojang.atlassian.net/browse/MC-1004

shouldn't be classed as bugs. For the very reason that you need mcedit to create spawners which spawn potions and custom mobs. You need mcedit or other NBT editors to create custom potions. These 2 bugs were also 'forcing' the game to do something that it wasn't designed to do. So by that token they should not have been classed as bugs and they should not have been 'fixed'.

However they were... So your logic doesn't follow through.

P.s. you are also not modding at all... You are changing the block id of the sand entity. That is NBT data editing. That hasn't got anything to do with mcedit. MCEdit just makes the spawners to make these sand entities with the edited NBT data spawn. The structure spawners do not force the game to do anything unusual.

Like healing potions don't normally give you 20 hearts of health back, sand entities don't normally turn into stone. However if you modify the NBT data of the sand or the potion you can change it such that it will do these things. This is not modding. If anything these are not bugs as the NBT data has been allowed, by Mojang, to be edited since Dinnerbone implemented this as a feature.

Th3F4114n0n3 2013-08-09T18:12:41Z

For the record NBT is Named Binary Tag
http://www.minecraftwiki.net/wiki/NBT
The tags of items are attributes associacted with specific thing not Block Id's. I beleive I already stated why potions are editable the way they can be. There TAGs are set to allow them to be increased past the default value. The whole point of your argument is that your changing the Block ID of an item, not the Tag associated with an item. Spawners spawn entities in, which is allowed based on its general code. Hints to why I'm not arguing you being able to spawn in the falling sand ENTITY.

the issue is the changing of the Block ID it turns into when it ceases to fall. You can try to argue that the block ID is a TAG but it isn't. Its a coded variable that minecraft uses and by using MCedit (which again is not a NBTeditor by nature) you are changing the behavior of the game. The block ID is just that. The Id of the block itself. By telling Minecraft to change a falling sand entity into something other than the sand Block Id (which is what its CODE says not some NBT Tag) you are changing the way minecraft works. This is basic coding and attributed editing. In MCedit you are not changing an NBT value for the sand entity to turn into something, your changing the Block ID in the code. This is where the deviation from an NBT editor and MCedit comed into play. MCedit is not an NBTeditor. It contains the ability to modify NBT tags, but its not a true NBT editor. Mojang has allowed the editing of NBT items (I've stated that before, thanks your stating again) but the falling sand entity does not contain an NBT for what it turns into when it stops falling.

Since, you're for what ever reason trying to draw out why your invalid bug was placed in the invalid state. I'm going to be the bigger man and stop this argument. The down to roots reason why Block 36 isn't able to be spawned in is because its a place holder block. It is the place holder used for when a block is being pushed by a piston (sticky or not). Basically turning the block into a slated entity and not a true entitiy in order for it to move. The reason why it can't be spawned in is because it needs a specific set of rules to happen before it can occur. Plain and simple. do a /give for the block, and while it looks like the piston arm, it can not be placed. it requires the series of rules (piston, redstone signal or activator code, block to move) to be able to be there. After the block as moved (even if the block is an air block) the place holder block is replaced with either the piston arm, or the block as a block.

E 2013-09-15T15:18:58Z

I don't understand how this is marked as invalid. There is an nbt tag built into falling sand entities to allow it to morph into any block id when it reaches the ground. There is a bug causing falling sand with its nbt tags set to tile id 36 to crash upon reaching the ground. You cannot argue that using mcedit invalidates this issue because of the fact that it is a vanilla feature that you can access with an nbt editor. Not only that, but with the release of the 13w36a /summon command, you are able to replicate this issue without needing any external editors. Just by typing the command: /summon FallingSand ~ ~5 ~ {Tile:36,Time:60}

Th3F4114n0n3 2013-09-16T11:51:26Z

I concede to your reasoning for falling sand, as I have since been searching through NBT's and realized there is a tag for it. I am sorry for arguing it as much as I was. The issue I think is that block 36 is a mechanical block. One that requires a set of rules to happen before it can be produce/exist in the world. If I'm not mistaken block 36 is the place holder for "any" block being pushed by a piston (bassically the block in the moving state). As it isn't a physical block and has no data on its own without the set of rules telling it what it is, Minecraft most likely errors out. I know you can use the /give command to get block 36, but when rolling back my minecraft versions, I can't seem to place it past 1.4.2 which I'm assuming is something they fixed in the code (or a combination of things), probably due to a bug fix.

BTW: is this still an issue (of crashing) in the current snapshot? I know dinnerbone said they made it/were making it impossible to get blocks that you shouldn't be able to get (technical blocks) such as restone torches (in off state), piston arms, etc.

Torabi 2013-09-17T14:28:14Z

Block 36 is a technical block used by pistons. It's not intended to be used for anything else. Any other use of it would be a bug. They may not have fixed it deliberately; it may just be a casualty of fixing some other bug.

Crashing is something they should fix – though they've said in the past that the game crashing when you do something you're not supposed to do (ex MC-1510, MC-31447) is intentional, desirable, or not worth fixing.

kazblox 2014-07-06T21:11:34Z

Being that /setblock and /fill can spawn block 36, this is logically considered as "dealt with".