TorchicBlaziken
- torchicblaziken
- torchicblaziken
- Europe/Stockholm
- Yes
- No
MC-1243![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
I tested this in Creative, and it will work in all gamemodes, but it is a much bigger problem in Survival.
There is a game-breaking bug (but not a game-crashing bug) involving the Wither. It can destroy End Portal frames as well as the portals themselves. This is because the Wither is not coded to be unable to destroy blocks flagged as unbreakable, just Bedrock in particular. This must be fixed. As you might imagine, this bug could be exploited on a multiplayer survival server for griefing. The only way server owners can avoid this is by disabling mob griefing altogether which isn't desirable for servers that want people to have to defend their homes against creepers.
If the stronghold portal is griefed, an op can rectify this by building a new one. But, the exit portal in the End cannot be restored in-game. As a result, if it's griefed players have no way out of the End except falling off of it. People could use an op-placed Nether Portal to go to the Nether and back to the Overworld, but it wouldn't send them back to their individual spawns even with a Command Block. Also, the Nether Portal could be destroyed by simply using a bed next to it because of its nonexistent blast resistance.
This is a side-effect of how exit portal placement is coded. Whether the End Portal itself can be placed in the world depends on the bossDefeated boolean being true. If it's false, it won't place even if you put down frames or /give yourself the portal itself and place it. This
flagis only set to true right after the Ender Dragon dies and after the portal is placed it sets itself to false again. Having it dependent on thatflagat all is pointless, since Survival players can't create their own End Portals without cheats anyway.The flag itself is useless. While it could be used for something else later on, any such feature wouldn't work with old maps if all it did was check if the flag was true.I tested this in Creative, and it will work in all gamemodes, but it is a much bigger problem in Survival.
There is a game-breaking bug (but not a game-crashing bug) involving the Wither. It can destroy End Portal frames as well as the portals themselves. This is because the Wither is not coded to be unable to destroy blocks flagged as unbreakable, just Bedrock in particular. This must be fixed. As you might imagine, this bug could be exploited on a multiplayer survival server for griefing. The only way server owners can avoid this is by disabling mob griefing altogether which isn't desirable for servers that want people to have to defend their homes against creepers.
If the stronghold portal is griefed, an op can rectify this by building a new one. But, the exit portal in the End cannot be restored in-game. As a result, if it's griefed players have no way out of the End except falling off of it. People could use an op-placed Nether Portal to go to the Nether and back to the Overworld, but it wouldn't send them back to their individual spawns even with a Command Block. Also, the Nether Portal could be destroyed by simply using a bed next to it because of its nonexistent blast resistance.
This is a side-effect of how exit portal placement is coded. Whether the End Portal itself can be placed in the world depends on the bossDefeated boolean being true. If it's false, it won't place even if you put down frames or /give yourself the portal itself and place it. This boolean is only set to true right after the Ender Dragon dies and after the portal is placed it sets itself to false again. Having it dependent on that boolean at all is pointless, since Survival players can't create their own End Portals without cheats anyway.
The boolean itself is useless. While it could be used for something else later on, any such feature wouldn't work with old maps unless it could retroactively check if the dragon was dead.
Mojang forgot to make it so that mobs eventually drown in lava like in water. This includes players. Noticeable effects on gameplay are few, but it is still an oversight, as old as lava itself. It was forgivable back then because no mob could survive in lava long enough to be able to drown in it. I'd say that there were no noticeable effects on gameplay until they added Zombie Pigmen, which have intrinsic fire resistance. Even though you could drown one in water, which back then was only observable in vanilla if a pig got struck by lightning, you couldn't drown one in lava.
Minecraft 1.0 made it more noticeable when you were able to gain extrinsic fire resistance through a potion. When you drank it and swam in lava, there was no air meter. Logically the only time you should be able to breathe under lava is when you are under the effects of both fire resistance and water breathing, the latter of which isn't brewable yet but is functional.
If the water breathing effect is extended to apply to lava as well, it could be renamed simply "Breathing". It could possibly also extend to suffocation damage, so witches would drink it if someone attempted to build a suffocation trap with them.
This would probably also necessitate a new mob flag that gives a type of mob the intrinsic ability to breathe in lava, but not water. This would work well with Magma Cubes, and perhaps Blazes. Maybe Ghasts as well so they don't fly into a one-block thick lavafall and drown from that.
Mojang forgot to make it so that mobs eventually drown in lava like in water. This includes players. Noticeable effects on gameplay are few, but it is still an oversight, as old as lava itself. It was forgivable back then because no mob could survive in lava long enough to be able to drown in it. I'd say that there were no noticeable effects on gameplay until they added Zombie Pigmen, which have intrinsic fire resistance. Even though you could drown one in water, which back then was only observable in vanilla if a pig got struck by lightning, you couldn't drown one in lava.
Minecraft 1.0 made it more noticeable when you were able to gain extrinsic fire resistance through a potion. When you drank it and swam in lava, there was no air meter. Logically the only time you should be able to breathe under lava is when you are under the effects of both fire resistance and water breathing, the latter of which isn't brewable yet but is functional.
If the water breathing effect is extended to apply to lava as well, it could be renamed simply "Breathing", or something to that effect which sounds cooler. It could possibly also extend to suffocation damage, so witches would drink it if someone attempted to build a suffocation trap with them.
This would probably also necessitate a new mob flag that gives a type of mob the intrinsic ability to breathe in lava, but not water. This would work well with Magma Cubes, and perhaps Blazes. Maybe Ghasts as well so they don't fly into a one-block thick lavafall and drown from that.
I've been testing the snapshots for a while and this has been happening ever since the client/server merger. This is especially bad with Golden Apples since you can always eat another one, so it'll make you even if the first one fully restored your hunger.
I disagree. This, at least the lava part of it, is most certainly unintentional. It's not that there's an error preventing it from working that way, it's just they forgot to make it work that way. Endermen are smart enough to teleport away from sources of damage; the most dangerous substance in the game should be no exception.
Of course, flint and steel makes sense, because you don't stop being on fire when you teleport away from what set you on fire.
If it were fixed, it WOULD break a few mob traps, but the smart ones were using piston traps anyway, which would still work.
While a trivial bug, it's still a bug. It could be fixed by making a "recipe" where four smooth sandstone into the crafting table like that gives you nothing. Any other combination would still work.