Lyle Alexander Artain

Heres a Gif so you can see the whole outside.

Here's a the magma Cube texture using the old texture but in the new correct format. Basically I copied and pasted the old texture for the layers then I repainted the outside using the top and bottom textures as a guide, trying to match the style. So now you can see how the Magma Cube was supposed to look essentially.

I give Mojang permission to use this texture for the fix if they want considering it's the majority of the old. 

Here i've used Block Bench to create the correct Magma Cube texture.

In Block Bench UV textures can be automatically made, and when these textures are made they include the layers that you wouldn't normally see on the models where the neck meets the body for instance. If these pieces are mapped via UV here without rewriting how the UV works then it's safe to say you could import the magma cube and it should make the correct texture mapping for each of the inner layers of the model. Therefore you wouldn't even need a code rewrite, right? Or would a code rewrite still have to happen? 

I'm pretty sure Jeb brought up Notch not finishing something on a minecraft live at one point, but Jeb didn't know what it was, and I think perhaps the Magma Cube texture was the thing that wasn't fully finished, thus why only the layers that the eyes are drawn on are the ones properly mapped in the texture .png.

With Block Bench existing maybe that could be used to help mojang fix this?

@Dhranios While I don't know the technical aspects of remapping the overlay or I guess rezoning, I do know that each mob has a different overlay map for their textures, Mojang would just have to find the coding for the Magma Cube and redo it.

Because each mob model is different and has separate overlay mapping for their unique texture, changing the code for the magma cube overlay shouldn't affect any other mob overlay. therefore causing less hassle. The way the magma cube texture is now doesn't even have a layout that would be specific to say mapping left to right. You can tell by how inconsistent the placements are.  

But making the file larger would cause many issues as they would have to enlarge all mob textures. 

The two inner layers, the patty and tomato that i copied that are correctly made, the sliver under them is the same as the slivers that are inconsistently placed on the top left area overlapping the top under layer and bottom under layer. There aren't any overlapping mapping issues with the patty and tomato layers touching the slivers that make up the outer edges of those layers, so separating pieces more isn't going to solve the issue, especially since there aren't enough pieces there in the first place, as in the overlapping zones aren't the correct size, and even if you separated them you would still have to remap the overlay for the new locations.

In short theres no way to fix this without remapping the overlay or rezoning the .png. you can move colors around as much as you want and increase size but the map overlay will stay the same unless edited.

Here you can see the texture mapping showing the pieces of the model, but instead of having 8 top and bottom cubes for all the inside layers and the bottom like how it's shown with the patty and tomato in the bottom right of the texture .png the texture mapping is set to overlap the top and bottom image of the top and bottom of the whole mob, resulting in an overlapping texture on the inside for a majority of layers (tomato and patty excluded because they happen to have their own top/bottom section in the bottom right)

I'm unsure if the mapping defaulted to this setup to fill each part of the model because it didn't have all the sides it needed available, or if the overlay is manually made to fit the image and paired with the model through coding. The texture file itself doesn't need to increase in size, I took the original, moved things and duplicated the current tomato and patty cubes to make the amount needed to fill the whole model. The blank space in mine being where the inner cube texture would go. The file itself is a perfect size, nothing has to be rescaled or resized. 

In vanilla the magma cube is majority of one color and texture, a texture that when overlapped can look fine, but if it were changed ever, it would be very noticable. This issue especially impacts the community members who make resource packs and texture packs because they can't utilize the unique layers or this mob without it ending up looking, like a mess. 

I'm all for limiting things to spark creativity, but this should not be something that contributes to the limitations.

Now with 1.20 coming up, and the fact that a big part of the theme seems to be self expression, I think this is the perfect time to fix this. Not only is it a simple fix of tweaking the texture .png to actually be fully complete (which you could just use mine, its not like its an original idea or anything) but to just fix the texture overlay, heck i'd do it myself if I knew how. 

Must depend on the biome because I didn't have any trouble with those when I did taiga biome, only stuff that was misplaced for me were some mineshafts, and villages, and the piliger building, because some would spawn under the floating islands over the void. I think when the generation changes to floating islands that the structure spawn area changes in it's Y coordinate, maybe make it dependent on spawning on blocks in general. Reason I say that is because not all villages were misplaced just some, but it could also be fun for a survival map cuz they might risk the drop into the void in order to loot them.