First of all, I want to make my own jar mod (including server/client) for one of the tagged versions. Do NOT suggest forge, please. However, each version I tried to decompile with MCP/RetroMCP is lacking of many fields. Is there a good solution or do I have to guess which one is which? I somewhat managed to make the boats unbreakable and replace cobblestone with flint in stone tools recipes, but I'm afraid I'm going to fail if I go further.
And also, which version is the best? I hate the 1.7+ world gen and content additions honestly, but is it more optimized than 1.6.4 in any way?
Rollback Post to RevisionRollBack
", courier, monospace">imagine if minecraft hadn't ended in 2013
And also, which version is the best? I hate the 1.7+ world gen and content additions honestly, but is it more optimized than 1.6.4 in any way?
Optimized for what? There's different things to optimize for and this word loses almost all of its meaning unless you're specifying that part. Some things may optimize for performance. Other things may optimize for visuals. Others may optimize for lower hardware utilization. And others may optimize for features or quality of life behaviors. You sometimes have to trade something off to optimize further in a given area.
Neither of those two version are well optimized for performance, visuals, features, or quality of life compared to what current versions allow, but instead they both have lower hardware needs so they will result in more performance on certain slower hardware that may be overburdened by the increased demands of later (particular 1.13+) versions. Both come from 2013 and were developed for the very different hardware landscapes of their time. There were slower CPUs, less cores, less memory, slower GPUs, and slower storage.
As for 1.6 compared to 1.7 in this regard, here's a few key differences I see between them.
1. 1.6 is less optimized for visual quality. The game used to render all textures at full resolution in all circumstances. This is terribly inefficient from an image quality standpoint as it results it worse aliasing issues.
This increasingly becomes a problem further in the distance, because this is where the game is running up closer against the "there is too little screen real estate to properly resolve the intended image with side effects" conditions, which is what ultimately causes aliasing issue (you can never truly avoid them with rasterized graphics approaches, only develop in a way that doesn't run into them). For the same reason, it's also worse the lower the resolution. If you ever noticed a "pixelated static noise" look when the camera is slowly moving, or moire patterns, this is why. The reason this is a pronounced issue in Minecraft in particular is because it uses pixelated textures that can have a lot of contrast, as opposed to texture filtering where pixel-to-pixel value color changes are less far apart.
The game has made improvements to alleviate this, but 1.6 has none of them, whereas 1.7 has one of them.
The first change was made in 1.7, which added mip-map support. This allows the game to create lower resolution textures to use in circumstances where there's less screen real estate. OptiFine for 1.6 allows this, but you'll have to make OptiFine compatible with your mod to have it.
Another change was made in 1.14, as the reason the new textures were "smoother" was to reduce the contrast that contributed to this issue.
There are texture backports you can use to get the 1.14+ textures in both 1.6 and 1.7. I personally found this necessary for me to enjoy both 1.6 and 1.8 when I revisited them recently. If you have a nostalgic attachment to the original textures and don't care about the visual issues I'm describing, this may not matter to you.
Even with those two methods to alleviate things, the game still suffers from aliasing issues today. The final thing it needs is real anti-aliasing options. Even back in 2012, I noticed how bad this was and sought out using anti-aliasing because of it (one of the reasons 1.7 initially gave me grief was because its frame buffer object rendering prevented the anti-aliasing method I was using from working, but you can easily disable this rendering behavior of 1.7 in the options file and it will fall back to the prior way). Current day drivers don't allow the anti-aliasing methods from back then to work without issue anyway (you need drivers, and thus hardware, nearly a decade old on nVidia's side to get a version that last worked properly with it), so you'll probably need to resort to super sampling methods instead, which are better anyway. Again, 1.6 is worse off here because OptiFine didn't integrate the shader options which allowed internally rendering at a higher resolution until versions for 1.7. You can instead achieve supersampling at the OS/driver level (via VSR with AMD and DSR with nVidia, no idea about Intel) for 1.6, but there's some real drawbacks to this method. Better than nothing though, maybe.
2. 1.6 suffers to a far worse extent of the old lighting bug that causes lighting to not be computed initially and will be deferred, often times not until you are within a chunk of the offending area. 1.7 still has this issue as well though, but less so. I'm not sure if this is a mere visual bug (meaning, only the client thinks the light is 0) or if it's server side (meaning mobs can spawn where they shouldn't be able to!?) but it's critical issue either way.
3. 1.7 offers some nicer benefits, such as skin support (only partial though), and some better sound and control options. Whether these are major to you is up to you, but there are there.
4. 1.6 is most likely worse off overall with bugs since it is older. I recently revisited 1.6 and 1.8 so I can't speak for 1.7, but the former had some serious issues that the latter didn't. Mobs clipping/rubber-banding into the ground in 1.6 was a horrifying one (I have no idea if this one affects 1.7, but I didn't notice it in 1.8). If you want to use maps, 1.6 has some real performance issues with them. From the standpoint of 2026 though, both are a pair of 2013 versions and both going to be nearly as bad, but one more so. A good place to check here would be to look up what issues the various 1.7 versions fixed, and see if any of them are critical to you.
5. Not so much a difference between the two versions, but you can improve some of the missing quality of life of both versions relative to current versions with some mods. You don't even need to be talking about very old versions such as 1.6 or 1.7 for this. For example, I use this mod to get 1.21.5+ music in 1.21.4 and that's a rather recent version. It does work despite being made for 1.7 so I presume there's a chance it may also work with 1.6, but you'll have to verify that by trying. But there might be rather easy solutions to some of the shortcomings 1.6 and 1.7 have.
If you dislike 1.7 era world generation (me too) and if any of the content beyond 1.6 is undesired, then you will need to put effort into changing and removing those. So the real question to ask is "which has issues for me that would entail more effort to resolve". For example, if you don't care about the lighting, visual, or quality of life things I mentioned above, and if modifying 1.7's world generation will be more work, then the answer is to go with 1.6 as your foundation despite it's additional issues. If you're worried about being in over your head, take the path of least resistance. That sounds like it might be 1.6 for you since you mention personal issues with its world generation and its content.
If you want specific guidance with how to modify these older versions, Master Caver would be one of the ones to ask because he plays in a modification of 1.6 and I think (?) modifying both of them might largely be the same.
What do you mean by "lacking of many fields"? There are some things that MCP didn't deobfuscate and still have names like "func_12345" or "field12345" but the majority of the main ones have (mostly) sensible names, e.g. the recipe for crafting flint and steel (using MCP 8.11 for 1.6.4):
(the letters like "A" and "B" are just used by the crafting code as "ids" for the respective input items and can thus be any valid characters)
e.g. I changed this to a "shapeless" recipe in my mods, which is simpler since you only need to specify a list of input items:
this.addShapelessRecipe(new ItemStack(Item.flintAndSteel), new Object[] {Item.ingotIron, Item.flint});
Variables and parameters still have names like "var1", "par1" but MCP often adds comments that say what they are, e.g. "World.setBlock", and my own renamings, and parameters that are an object type will include that (e.g. "par1World", which I often leave as-is):
/**
* Sets the block ID and metadata at a given location. Args: X, Y, Z, new block ID, new metadata, flags. Flag 1 will
* cause a block update. Flag 2 will send the change to clients (you almost always want this). Flag 4 prevents the
* block from being re-rendered, if this is a client world. Flags can be added together.
*/
public boolean setBlock(int par1, int par2, int par3, int par4, int par5, int par6)
// flag is notifyNeighbors (1) + sendUpdate (2) + dontRender (4), usually set to 3 for notify+update, 2 during world generation.
// 1 and 2 are server-side only while 4 is client-side only (functionally the same as 0 server-side).
public boolean setBlock(int posX, int posY, int posZ, int block, int meta, int flag)
Of course, having extensively modded 1.6.4 for the past 12+ years, I can offer countless code examples and advice on how to do something (I've also fixed issues Princess Garnet mentioned. e.g. lighting, even dozens of bugs which have never been fixed as of the latest version (or only like 26.1; to fix "leader zombies" not having more health just add "this.setHealth(this.getMaxHealth());" after the second line that sets "leader zombie bonus" in "EntityZombie.onSpawnEithEgg", a bug I fixed no later than early 2017, at least 9 years before Mojang fixed it), as well as large-scale optimizations, 1.7 itself has some issues in this regard, e.g. "Excessive Clientside Chunk Ticking 1.7.4+", and no, 1.7.2 is not better as it has a lot of new bugs of its own, as is typical for the first release of a major update).
Also, mobs clipping into the ground (which wasn't fixed until 1.8)? Easy solution (I even recommended this and/or my "World1 custom client" to Princess Garnet when they played on 1.6 but they refused):
I even took many fixes from its source code, though the GitHub repository no longer exists and it wasn't fully archived (an archived page describing the issues it fixed); notably, the main issue it fixes, mob glitching into/through walls server-side* (1.8 only fixed the more common client-side issues), wasn't fully resolved until last year, while I haven't experienced it for closer to a decade thanks to the fixes provided by Unglitch:
*The way to fix these issues is two-fold, first, directly construct the bounding box in "Block.getCollisionBoundingBoxFromPool / addCollisionBoxesToList" (instead of using the block bounds fields) and add a small margin to AxisAlignedBB.calculate(X/Z)Offset:
Examples of bounding box fix (in vanilla 1.6.4 if you place two anvils, one rotated 90 degrees, and look at one while pushing against the other you can clip through it). Half-slabs are also notorious for letting mobs fall into/through them, most apparent when you have a lot of upper and lower slabs (just upper/lower will likely not cause issues as their state is always the same, the same is true for blocks like fences, and any other block which has multiple shapes depending on metadata or how they are rendered):
// BlockAnvil
public AxisAlignedBB getCollisionBoundingBoxFromPool(World par1World, int posX, int posY, int posZ)
{
if ((par1World.getBlockMetadata(posX, posY, posZ) & 1) == 0)
{
return AxisAlignedBB.getAABB((double)posX + 0.125D, (double)posY, (double)posZ, (double)posX + 0.875D, (double)(posY + 1), (double)(posZ + 1));
}
else
{
return AxisAlignedBB.getAABB((double)posX, (double)posY, (double)posZ + 0.125D, (double)(posX + 1), (double)(posY + 1), (double)posZ + 0.875D);
}
}
// BlockFence
public void addCollisionBoxesToList(World par1World, int posX, int posY, int posZ, AxisAlignedBB par5AxisAlignedBB, List par6List, Entity par7Entity)
{
boolean north = this.canFenceConnectTo(par1World, posX, posY, posZ - 1);
boolean south = this.canFenceConnectTo(par1World, posX, posY, posZ + 1);
boolean west = this.canFenceConnectTo(par1World, posX - 1, posY, posZ);
boolean east = this.canFenceConnectTo(par1World, posX + 1, posY, posZ);
if (north || south)
{
double minZ = (north ? 0.0D : 0.375D);
double maxZ = (south ? 1.0D : 0.625D);
AxisAlignedBB var8 = AxisAlignedBB.getAABB((double)posX + 0.375D, (double)posY, (double)posZ + minZ, (double)posX + 0.625D, (double)posY + 1.5D, (double)posZ + maxZ);
if (par5AxisAlignedBB.intersectsWith(var8)) par6List.add(var8);
}
if (west || east || (!north && !south))
{
double minX = (west ? 0.0D : 0.375D);
double maxX = (east ? 1.0D : 0.625D);
AxisAlignedBB var8 = AxisAlignedBB.getAABB((double)posX + minX, (double)posY, (double)posZ + 0.375D, (double)posX + maxX, (double)posY + 1.5D, (double)posZ + 0.625D);
if (par5AxisAlignedBB.intersectsWith(var8)) par6List.add(var8);
}
}
Example of fix for floating-point precision errors, adding a small margin so entities are never right against a block:
This comment also mentions mobs growing up, which has a fix posted on its own issue: https://bugs-legacy.mojang.com/secure/attachment/148216/MC-9568 Proposal.txt; with my rewritten version below (mainly to avoid "new AxisAlignedBB" as unnecessary object creation is the root of all evil, e.g. why 1.8+ churns though memory like crazy, putting unnecessary load on the system, no matter how good modern garbage collectors may be. The code here / in the attachment is placed in "EntityLivingBase"):
// Moved from Entity to fix incorrect offset when AABB changes size, such as when baby animals grow up, and correctly push
// them out of blocks (100% success rate when tested with baby chickens compared to >90% failure rate in vanilla)
protected void setSize(float newWidth, float newHeight)
{
this.setSizeFixed(newWidth, newHeight);
}
protected void setSizeFixed(float newWidth, float newHeight)
{
if (newWidth != this.width || newHeight != this.height)
{
float oldWidth = this.width;
this.width = newWidth;
this.height = newHeight;
double halfWidth = (double)newWidth * 0.5D;
// Note - hasBeenUpdated replaces private firstUpdate in Entity (was private). Must be before World.isRemote to avoid
// NPE in mob spawner rendering
if (!this.hasBeenUpdated && this.width > oldWidth && !this.worldObj.isRemote)
{
// Based on a fix for MC-9568
AxisAlignedBB oldAABB = this.boundingBox.copy();
this.boundingBox.minX = this.posX - halfWidth;
this.boundingBox.minZ = this.posZ - halfWidth;
this.boundingBox.maxX = this.posX + halfWidth;
this.boundingBox.maxY = this.boundingBox.minY + (double)newHeight;
this.boundingBox.maxZ = this.posZ + halfWidth;
this.pushEntityOutOfBlocks(oldAABB);
}
else
{
this.boundingBox.minX = this.posX - halfWidth;
this.boundingBox.minZ = this.posZ - halfWidth;
this.boundingBox.maxX = this.posX + halfWidth;
this.boundingBox.maxY = this.boundingBox.minY + (double)newHeight;
this.boundingBox.maxZ = this.posZ + halfWidth;
}
}
}
// Based on a fix for MC-9568
private void pushEntityOutOfBlocks(AxisAlignedBB oldHitbox)
{
List<AxisAlignedBB> aabbList = this.worldObj.getCollidingBlockBounds(this.boundingBox);
if (aabbList.isEmpty()) return;
double newMinX = this.boundingBox.minX;
double newMinZ = this.boundingBox.minZ;
double newMaxX = this.boundingBox.maxX;
double newMaxZ = this.boundingBox.maxZ;
boolean changed = false;
for (int i = 0; i < aabbList.size(); ++i)
{
AxisAlignedBB aabb = (AxisAlignedBB)aabbList.get(i);
// Added new intersectsWith method to AxisAlignedBB that takes in coordinates instead of another AABB
if (!oldHitbox.intersectsWith(aabb) && aabb.intersectsWith(newMinX, this.boundingBox.minY, newMinZ, newMaxX, this.boundingBox.maxY, newMaxZ))
{
double minX = newMinX;
double maxX = newMaxX;
double minZ = newMinZ;
double maxZ = newMaxZ;
// Check for collisions on the X and Z axis, and only push the new AABB if the colliding blocks AABB
// is completely to the opposite side of the original AABB
if (aabb.maxX > newMinX && aabb.minX < newMaxX)
{
if (aabb.maxX >= oldHitbox.maxX && aabb.minX >= oldHitbox.maxX)
{
minX = aabb.minX - this.width;
maxX = aabb.minX;
}
else if (aabb.maxX <= oldHitbox.minX && aabb.minX <= oldHitbox.minX)
{
minX = aabb.maxX;
maxX = aabb.maxX + this.width;
}
}
if (aabb.maxZ > newMinZ && aabb.minZ < newMaxZ)
{
if (aabb.minZ >= oldHitbox.maxZ && aabb.maxZ >= oldHitbox.maxZ)
{
minZ = aabb.minZ - this.width;
maxZ = aabb.minZ;
}
else if (aabb.maxZ <= oldHitbox.minZ && aabb.minZ <= oldHitbox.minZ)
{
minZ = aabb.maxZ;
maxZ = aabb.maxZ + this.width;
}
}
newMinX = minX;
newMinZ = minZ;
newMaxX = maxX;
newMaxZ = maxZ;
changed = true;
}
}
if (changed)
{
this.boundingBox.minX = newMinX;
this.boundingBox.minZ = newMinZ;
this.boundingBox.maxX = newMaxX;
this.boundingBox.maxZ = newMaxZ;
}
}
(I think you get the idea of what I mean by being able to provide a lot of code and stuff, I could show you a lot more via links if you could see private messages, which is all most seem to use to communicate these days, no idea why they prefer microscopic (e.g. Reddit) chatboxes with no formatting, probbaly the same for Discord, which I'll never use no matter what, I have considered at times to make a comprehensive thread detailing many of the fixes and improvements I made but it does take a lot of effort, considering a lot of my code also uses custom methods, some of which is seen here ("AxisAlignedBB.getAABB()" is simply a wrapper for "getAABBPool().getAABB()" to simplify code, I also added a new "intersectsWith" method that accepts raw coordiantes instead of an AABB)
If you go with 1.6, might 1.6.2 be a better option here than 1.6.4? I thought the changes of 1.6.4 was mostly, perhaps entirely (?), to accommodate the then-upcoming 1.7, and some of those things might even be harmful.
For example, I encountered very severe issues with performance in 1.6.4. As the mineshaft.dat file grew further in size, internal server performance further suffered. This was occurring on what was amongst the fastest and newest CPUs for the time. Client performance was not impacted, and it only occurred when hosting the game as a server, not when running it locally or when opening it to LAN. Most people probably never experienced it nor were aware of it as a result, but if you're wanting to have a server option available, this issue might be relevant.
I've also fixed issues Princess Garnet mentioned. e.g. lighting, even dozens of bugs which have never been fixed as of the latest version
With respect to the effort you've put into things, can you stop pretending like the effort you've put into TMCW erases the issues with the vanilla version itself? TMCW is an effort spanning over a decade, many of the things it resolves came well after the point in time where its foundational version was current, and most importantly, its a content modification mod and not a "vanilla" bug fix only mod (meaning it certainly doesn't apply in the sense of discussion about 1.6 itself). It's like you take second hand offense any time someone mentions an issue with an old version.
How come you put down the work of other developers (both Mojang and other modders in the community) for the things that you have fixed, either that the game fixed later than you or not at all, when the inverse is also true? You have your own list of issues too, you know. There's a lot of improvements, features, or quality of life that the current day game offers that TMCW does not. There are things that it took longer to address, or things that it still doesn't. I think some of the things you neglect are far more important. As a player, it's sad to see when developers feel the need to belittle the work of others in order to promote their own.
Have you fully resolved the lighting issues? I'd be very happy to hear that because it was one of the many highly critical issues with some of those very old versions. The last time you said something about it, you seemed to dismiss it as not a big deal. That was shocking to me, but I also took it to mean you hadn't yet resolved it? Maybe I was mistaken about that, or maybe you only addressed it more recently.
I even recommended this and/or my "World1 custom client" to Princess Garnet when they played on 1.6 but they refused
This is such a weird thing to be offended about and I'm surprised you keep bringing it up.
I was indeed not interested in content modifications, especially ones for a version that need more effort to mod, for a world that I had already started playing, and for a version I was only going to play short term. Part of the reason for the revisit was precisely to see how the "vanilla" state would hold up, yet you seem to miss that.
If you go with 1.6, might 1.6.2 be a better option here than 1.6.4? I thought the changes of 1.6.4 was mostly, perhaps entirely (?), to accommodate the then-upcoming 1.7, and some of those things might even be harmful.
For example, I encountered very severe issues with performance in 1.6.4. As the mineshaft.dat file grew further in size, internal server performance further suffered. This was occurring on what was amongst the fastest and newest CPUs for the time. Client performance was not impacted, and it only occurred when hosting the game as a server, not when running it locally or when opening it to LAN. Most people probably never experienced it nor were aware of it as a result, but if you're wanting to have a server option available, this issue might be relevant.
I fixed that issue by disabling structure saving for mineshafts but retained it for other structures to avoid possible generation bugs (temples and village buildings split in half vertically along chunk boundaries when they are generated across sessions because unless the game saves the average ground level under the first half to get placed in the world the second half may use a different altitude).
Which incidentally, was broken when Mojang multithreaded chunk generation in 1.13:
You may also ask, but won't disabling it cause generation bugs with mineshafts? Yes, but they generate at a predefined altitude so the only issue is that two spawners may be placed in a corridor that gets generated across two sessions as their location is dependent on whatever part gets placed first in the world (which is again not saved pre-1.6.4, and in any case the exact location of a spawner depends on the order of chunk generation). I also consider this to be a neat quirk leading to occasional exceptional finds (two spawners touching) and while TMCW fixes this by making the locations of spawners depend on the structure seed I added a chance of two spawners in a corridor to replicate the vanilla behavior (I did not fix this for my first world):
Example of server performance in an extremely large (by standards at the time) world, around 165000 chunks / 10 max zoom maps, yet it runs almost like a brand-new world (1.78 ms server tick and 60 MB memory, the only significant difference is from nearly 1000 chests, signs, and item frames. I did disable spawn chunks but I'm standing within them (spawn is at -92, 236) so that wouldn't matter here):
I was indeed not interested in content modifications
Fun fact: you can disable many of the (relatively minor) modded features in "World1 custom client", which is more or less the "vanilla" version of TMCW (same core codebase/code changes but without all the new content, just a handful of minor features, some of which are even totally optional anyway, e.g. "rail blocks" only ever exist if you craft them, I even accommodate those who refuse to play on 1.6 simply because it has horses (not kidding, it really is that common, "Why do people choose 1.5.2 over 1.6.4?", even making mods like "Better than Horses", a reference to the OG "alternate timeline" mod "Better than Wolves" which was created after they were added due to the developer's extreme dislike of them (or even TMCW itself due to my dislike of 1.7+ world generation and other features), the next update (which fully updates the codebase to match TMCW as I prioritize the mod I'm using when playing) will also add an option to disable baby zombies, another commonly dislike feature of 1.6 (I've even seen some playing on 1.6.1 despite all the bugs it had which were fixed in 1.6.2, albeit that included naturally spawning baby zombies):
optionsworld1.txt includes various settings to toggle some non-vanilla features, including the spawning of mobs which do not naturally spawn in vanilla (cave spiders, giants, witches) as well as horses (many dislike 1.6 and prefer 1.5 because of them); whether ender chests have 54 slots instead of 27 (if this is set to false and there are items in the additional slots they will be dropped at the player to avoid item loss); additional mob effects (e.g. zombies with all iron and diamond tools and a higher chance, spiders with potion effects on Easy-Normal, creepers keep moving before exploding, maximum regional difficulty increased from 1.25 to 1.5 on Hard); time inhabited time starts rising from (this is added to the value read from chunks and does not affect saved data, default is set to 25 hours out of 50). If waterOpacity is changed then chunks will automatically be relit when loaded to correct lighting:
betterMineshafts:true // mineshafts are as common near 0,0 as further away and do not generate in dense cave systems
betterSnowyBiomes:true // uses Frozen River in all snowy biomes, not just Ice Plains, and places snow under trees
customCrafting:true // enables custom crafting recipes*
deathPoint:true // show death point in inventory
inhabitedTimeStart:1800000 // time inhabited time/regional difficulty effectively starts at; max is 3600000 / 50 hours
invStats:true // enables stats/coordinates/etc in inventory
largeEnderChest:true // enables larger ender chests (54/27 slots)
moreMobEffects:true // enables zombies with more weapons, creepers keep moving, etc
spawnCaveSpider:true // enables mobs which do not naturally spawn in vanilla, as well as horses
spawnGiant:true
spawnHorse:true
spawnWitch:true
versionName:Minecraft World1 // sets title and version displayed in F3
waterOpacity:1 // sets light opacity of water (vanilla = 3)
*new/modified recipes:
- changed flint and steel to shapeless recipe (like 1.7.2+)
- changed trapped chest to shapeless recipe (like 1.9+)
Toggled by customCrafting:
- cobweb block crafted with 2x2 cobwebs
- compressed (mossy) cobblestone crafted with 2x2 (mossy) cobblestone
- fireworks craft 3 items instead of 1
- rail block crafted with 3x3 rails
- two enchanted books can be combined to give one book (like disenchanting tools)
- two very damaged anvils can be combined to give an intact anvil (like repairing tools)
It's something that exists in 1.6.4 though, and is therefore something that someone looking to mod 1.6.4 might have to fix. Your solution sounds like it has a new issue of its own that you've personally accepted.
The reason I was wondering if 1.6.2 would be preferable was because that's something that wouldn't need fixed, and I've often seen it said that 1.6.2 is mostly the "same thing" as 1.6.4 minus the changes to get things ready for 1.7. The issues that 1.6.4 fixed should also be looked at though. The Wiki mentions these as those things.
"From released version before 1.6.1
MC-1867 – Double sound for fall damage
MC-3464 – Arrows don't stick in soul sand.
From 1.6.1
MC-21066 – minecraft crashed on a server, it only seems to do this on this server.
From the previous development version
MC-31065 – Villages not generating? (snapshot 13w37b)
Other fixes
Fixed handshake exploit."
That seems like a short list, and some of them seem unsure of themselves whereas some others seem minor. You would have to decide how important they are. The issue with the server crashing, assuming there was anything to it in the first place, and the exploit might be important if server functionality is desired though?
This has all been assuming the thread starter goes with a 1.6 version, but since they mentioned disliking 1.7 world generation, I sort of figured 1.6 might be a better starting place. I sort of overlooked that they were also asking about 1.5 because I personally don't see much point of that one unless you really dislike horses, coal blocks, or carpets. I guess everyone has their own "straw that broke the camel's back" change so someone is bound to dislike it for one of those reasons, but I would imagine the numbers are low. The outcry against 1.6 that I remember from its time was that it was a "lazy update" since it "just added a literal mod", but I don't remember any outcry that any of the changes that it was making were things that people couldn't tolerate playing with. So I don't know.
But going with 1.5 might also mean avoiding some key issues too. Didn't the issue with untamed wolves despawning after a couple of minutes start in 1.6? And does that apply to all 1.6 versions, or was it only later 1.6 updates?
I asked why you do this, and you ignored answering only to do it again. I presume you're familiar with the phrase and concept of "throwing rocks from glass houses"?
Two things having a shared underlying variable doesn't mean that frequency or severity of both of them is equal. Mojang can consider something a duplicate as they see fit, but I can tell you from experience that while ships with mismatched wood types are very common, villages with misalignment or missing portions aren't. Even that bug tracker page supports this because notice the few examples that show villages are all old villages that were last in the game in 1.13. Most of them are even using snapshot or pre-release versions. So it's pretty apparent that by 1.14 at the latest, if not a 1.13 version, this was largely addressed with villages.
Rollback Post to RevisionRollBack
"'Tis foolishness! If all were so easy, why, none would suffer in this world!"
First of all, I want to make my own jar mod (including server/client) for one of the tagged versions. Do NOT suggest forge, please. However, each version I tried to decompile with MCP/RetroMCP is lacking of many fields. Is there a good solution or do I have to guess which one is which? I somewhat managed to make the boats unbreakable and replace cobblestone with flint in stone tools recipes, but I'm afraid I'm going to fail if I go further.
And also, which version is the best? I hate the 1.7+ world gen and content additions honestly, but is it more optimized than 1.6.4 in any way?
", courier, monospace">imagine if minecraft hadn't ended in 2013
Optimized for what? There's different things to optimize for and this word loses almost all of its meaning unless you're specifying that part. Some things may optimize for performance. Other things may optimize for visuals. Others may optimize for lower hardware utilization. And others may optimize for features or quality of life behaviors. You sometimes have to trade something off to optimize further in a given area.
Neither of those two version are well optimized for performance, visuals, features, or quality of life compared to what current versions allow, but instead they both have lower hardware needs so they will result in more performance on certain slower hardware that may be overburdened by the increased demands of later (particular 1.13+) versions. Both come from 2013 and were developed for the very different hardware landscapes of their time. There were slower CPUs, less cores, less memory, slower GPUs, and slower storage.
As for 1.6 compared to 1.7 in this regard, here's a few key differences I see between them.
1. 1.6 is less optimized for visual quality. The game used to render all textures at full resolution in all circumstances. This is terribly inefficient from an image quality standpoint as it results it worse aliasing issues.
This increasingly becomes a problem further in the distance, because this is where the game is running up closer against the "there is too little screen real estate to properly resolve the intended image with side effects" conditions, which is what ultimately causes aliasing issue (you can never truly avoid them with rasterized graphics approaches, only develop in a way that doesn't run into them). For the same reason, it's also worse the lower the resolution. If you ever noticed a "pixelated static noise" look when the camera is slowly moving, or moire patterns, this is why. The reason this is a pronounced issue in Minecraft in particular is because it uses pixelated textures that can have a lot of contrast, as opposed to texture filtering where pixel-to-pixel value color changes are less far apart.
The game has made improvements to alleviate this, but 1.6 has none of them, whereas 1.7 has one of them.
Another change was made in 1.14, as the reason the new textures were "smoother" was to reduce the contrast that contributed to this issue.
There are texture backports you can use to get the 1.14+ textures in both 1.6 and 1.7. I personally found this necessary for me to enjoy both 1.6 and 1.8 when I revisited them recently. If you have a nostalgic attachment to the original textures and don't care about the visual issues I'm describing, this may not matter to you.
Even with those two methods to alleviate things, the game still suffers from aliasing issues today. The final thing it needs is real anti-aliasing options. Even back in 2012, I noticed how bad this was and sought out using anti-aliasing because of it (one of the reasons 1.7 initially gave me grief was because its frame buffer object rendering prevented the anti-aliasing method I was using from working, but you can easily disable this rendering behavior of 1.7 in the options file and it will fall back to the prior way). Current day drivers don't allow the anti-aliasing methods from back then to work without issue anyway (you need drivers, and thus hardware, nearly a decade old on nVidia's side to get a version that last worked properly with it), so you'll probably need to resort to super sampling methods instead, which are better anyway. Again, 1.6 is worse off here because OptiFine didn't integrate the shader options which allowed internally rendering at a higher resolution until versions for 1.7. You can instead achieve supersampling at the OS/driver level (via VSR with AMD and DSR with nVidia, no idea about Intel) for 1.6, but there's some real drawbacks to this method. Better than nothing though, maybe.
2. 1.6 suffers to a far worse extent of the old lighting bug that causes lighting to not be computed initially and will be deferred, often times not until you are within a chunk of the offending area. 1.7 still has this issue as well though, but less so. I'm not sure if this is a mere visual bug (meaning, only the client thinks the light is 0) or if it's server side (meaning mobs can spawn where they shouldn't be able to!?) but it's critical issue either way.
3. 1.7 offers some nicer benefits, such as skin support (only partial though), and some better sound and control options. Whether these are major to you is up to you, but there are there.
4. 1.6 is most likely worse off overall with bugs since it is older. I recently revisited 1.6 and 1.8 so I can't speak for 1.7, but the former had some serious issues that the latter didn't. Mobs clipping/rubber-banding into the ground in 1.6 was a horrifying one (I have no idea if this one affects 1.7, but I didn't notice it in 1.8). If you want to use maps, 1.6 has some real performance issues with them. From the standpoint of 2026 though, both are a pair of 2013 versions and both going to be nearly as bad, but one more so. A good place to check here would be to look up what issues the various 1.7 versions fixed, and see if any of them are critical to you.
5. Not so much a difference between the two versions, but you can improve some of the missing quality of life of both versions relative to current versions with some mods. You don't even need to be talking about very old versions such as 1.6 or 1.7 for this. For example, I use this mod to get 1.21.5+ music in 1.21.4 and that's a rather recent version. It does work despite being made for 1.7 so I presume there's a chance it may also work with 1.6, but you'll have to verify that by trying. But there might be rather easy solutions to some of the shortcomings 1.6 and 1.7 have.
If you dislike 1.7 era world generation (me too) and if any of the content beyond 1.6 is undesired, then you will need to put effort into changing and removing those. So the real question to ask is "which has issues for me that would entail more effort to resolve". For example, if you don't care about the lighting, visual, or quality of life things I mentioned above, and if modifying 1.7's world generation will be more work, then the answer is to go with 1.6 as your foundation despite it's additional issues. If you're worried about being in over your head, take the path of least resistance. That sounds like it might be 1.6 for you since you mention personal issues with its world generation and its content.
If you want specific guidance with how to modify these older versions, Master Caver would be one of the ones to ask because he plays in a modification of 1.6 and I think (?) modifying both of them might largely be the same.
"'Tis foolishness! If all were so easy, why, none would suffer in this world!"
If you're having performance concerns with Minecraft, I hope this may prove useful.
A retrospective of the most important game to me (or, a try to stay awake while I never stop talking about something challenge).
// CraftingManager this.addRecipe(new ItemStack(Item.flintAndSteel, 1), new Object[] {"A ", " B", 'A', Item.ingotIron, 'B', Item.flint});(the letters like "A" and "B" are just used by the crafting code as "ids" for the respective input items and can thus be any valid characters)
e.g. I changed this to a "shapeless" recipe in my mods, which is simpler since you only need to specify a list of input items:
this.addShapelessRecipe(new ItemStack(Item.flintAndSteel), new Object[] {Item.ingotIron, Item.flint});Variables and parameters still have names like "var1", "par1" but MCP often adds comments that say what they are, e.g. "World.setBlock", and my own renamings, and parameters that are an object type will include that (e.g. "par1World", which I often leave as-is):
Of course, having extensively modded 1.6.4 for the past 12+ years, I can offer countless code examples and advice on how to do something (I've also fixed issues Princess Garnet mentioned. e.g. lighting, even dozens of bugs which have never been fixed as of the latest version (or only like 26.1; to fix "leader zombies" not having more health just add "this.setHealth(this.getMaxHealth());" after the second line that sets "leader zombie bonus" in "EntityZombie.onSpawnEithEgg", a bug I fixed no later than early 2017, at least 9 years before Mojang fixed it), as well as large-scale optimizations, 1.7 itself has some issues in this regard, e.g. "Excessive Clientside Chunk Ticking 1.7.4+", and no, 1.7.2 is not better as it has a lot of new bugs of its own, as is typical for the first release of a major update).
Also, mobs clipping into the ground (which wasn't fixed until 1.8)? Easy solution (I even recommended this and/or my "World1 custom client" to Princess Garnet when they played on 1.6 but they refused):
https://www.chunkbase.com/mods/unglitch
I even took many fixes from its source code, though the GitHub repository no longer exists and it wasn't fully archived (an archived page describing the issues it fixed); notably, the main issue it fixes, mob glitching into/through walls server-side* (1.8 only fixed the more common client-side issues), wasn't fully resolved until last year, while I haven't experienced it for closer to a decade thanks to the fixes provided by Unglitch:
MC-2025 Mobs going out of fenced areas/suffocate in blocks when loading chunks
*The way to fix these issues is two-fold, first, directly construct the bounding box in "Block.getCollisionBoundingBoxFromPool / addCollisionBoxesToList" (instead of using the block bounds fields) and add a small margin to AxisAlignedBB.calculate(X/Z)Offset:
// BlockAnvil public AxisAlignedBB getCollisionBoundingBoxFromPool(World par1World, int posX, int posY, int posZ) { if ((par1World.getBlockMetadata(posX, posY, posZ) & 1) == 0) { return AxisAlignedBB.getAABB((double)posX + 0.125D, (double)posY, (double)posZ, (double)posX + 0.875D, (double)(posY + 1), (double)(posZ + 1)); } else { return AxisAlignedBB.getAABB((double)posX, (double)posY, (double)posZ + 0.125D, (double)(posX + 1), (double)(posY + 1), (double)posZ + 0.875D); } } // BlockFence public void addCollisionBoxesToList(World par1World, int posX, int posY, int posZ, AxisAlignedBB par5AxisAlignedBB, List par6List, Entity par7Entity) { boolean north = this.canFenceConnectTo(par1World, posX, posY, posZ - 1); boolean south = this.canFenceConnectTo(par1World, posX, posY, posZ + 1); boolean west = this.canFenceConnectTo(par1World, posX - 1, posY, posZ); boolean east = this.canFenceConnectTo(par1World, posX + 1, posY, posZ); if (north || south) { double minZ = (north ? 0.0D : 0.375D); double maxZ = (south ? 1.0D : 0.625D); AxisAlignedBB var8 = AxisAlignedBB.getAABB((double)posX + 0.375D, (double)posY, (double)posZ + minZ, (double)posX + 0.625D, (double)posY + 1.5D, (double)posZ + maxZ); if (par5AxisAlignedBB.intersectsWith(var8)) par6List.add(var8); } if (west || east || (!north && !south)) { double minX = (west ? 0.0D : 0.375D); double maxX = (east ? 1.0D : 0.625D); AxisAlignedBB var8 = AxisAlignedBB.getAABB((double)posX + minX, (double)posY, (double)posZ + 0.375D, (double)posX + maxX, (double)posY + 1.5D, (double)posZ + 0.625D); if (par5AxisAlignedBB.intersectsWith(var8)) par6List.add(var8); } }Example of fix for floating-point precision errors, adding a small margin so entities are never right against a block:
// AxisAlignedBB private static final double MARGIN = 0.000001D; public double calculateXOffset(AxisAlignedBB par1AxisAlignedBB, double par2) { if (par1AxisAlignedBB.maxY > this.minY && par1AxisAlignedBB.minY < this.maxY && par1AxisAlignedBB.maxZ > this.minZ && par1AxisAlignedBB.minZ < this.maxZ) { if (par2 > 0.0D && par1AxisAlignedBB.maxX <= this.minX) { double var4 = this.minX - par1AxisAlignedBB.maxX; return (var4 < par2 ? var4 - MARGIN : par2); } else if (par2 < 0.0D && par1AxisAlignedBB.minX >= this.maxX) { double var4 = this.maxX - par1AxisAlignedBB.minX; return (var4 > par2 ? var4 + MARGIN : par2); } } return par2; }This was also taken from a comment on MC-2025, posted years before it was fixed, there are many similar code fixes I've implemented, many quite trivial: https://bugs-legacy.mojang.com/browse/MC-2025?focusedId=408089&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-408089This comment also mentions mobs growing up, which has a fix posted on its own issue: https://bugs-legacy.mojang.com/secure/attachment/148216/MC-9568 Proposal.txt; with my rewritten version below (mainly to avoid "new AxisAlignedBB" as unnecessary object creation is the root of all evil, e.g. why 1.8+ churns though memory like crazy, putting unnecessary load on the system, no matter how good modern garbage collectors may be. The code here / in the attachment is placed in "EntityLivingBase"):
// Moved from Entity to fix incorrect offset when AABB changes size, such as when baby animals grow up, and correctly push // them out of blocks (100% success rate when tested with baby chickens compared to >90% failure rate in vanilla) protected void setSize(float newWidth, float newHeight) { this.setSizeFixed(newWidth, newHeight); } protected void setSizeFixed(float newWidth, float newHeight) { if (newWidth != this.width || newHeight != this.height) { float oldWidth = this.width; this.width = newWidth; this.height = newHeight; double halfWidth = (double)newWidth * 0.5D; // Note - hasBeenUpdated replaces private firstUpdate in Entity (was private). Must be before World.isRemote to avoid // NPE in mob spawner rendering if (!this.hasBeenUpdated && this.width > oldWidth && !this.worldObj.isRemote) { // Based on a fix for MC-9568 AxisAlignedBB oldAABB = this.boundingBox.copy(); this.boundingBox.minX = this.posX - halfWidth; this.boundingBox.minZ = this.posZ - halfWidth; this.boundingBox.maxX = this.posX + halfWidth; this.boundingBox.maxY = this.boundingBox.minY + (double)newHeight; this.boundingBox.maxZ = this.posZ + halfWidth; this.pushEntityOutOfBlocks(oldAABB); } else { this.boundingBox.minX = this.posX - halfWidth; this.boundingBox.minZ = this.posZ - halfWidth; this.boundingBox.maxX = this.posX + halfWidth; this.boundingBox.maxY = this.boundingBox.minY + (double)newHeight; this.boundingBox.maxZ = this.posZ + halfWidth; } } } // Based on a fix for MC-9568 private void pushEntityOutOfBlocks(AxisAlignedBB oldHitbox) { List<AxisAlignedBB> aabbList = this.worldObj.getCollidingBlockBounds(this.boundingBox); if (aabbList.isEmpty()) return; double newMinX = this.boundingBox.minX; double newMinZ = this.boundingBox.minZ; double newMaxX = this.boundingBox.maxX; double newMaxZ = this.boundingBox.maxZ; boolean changed = false; for (int i = 0; i < aabbList.size(); ++i) { AxisAlignedBB aabb = (AxisAlignedBB)aabbList.get(i); // Added new intersectsWith method to AxisAlignedBB that takes in coordinates instead of another AABB if (!oldHitbox.intersectsWith(aabb) && aabb.intersectsWith(newMinX, this.boundingBox.minY, newMinZ, newMaxX, this.boundingBox.maxY, newMaxZ)) { double minX = newMinX; double maxX = newMaxX; double minZ = newMinZ; double maxZ = newMaxZ; // Check for collisions on the X and Z axis, and only push the new AABB if the colliding blocks AABB // is completely to the opposite side of the original AABB if (aabb.maxX > newMinX && aabb.minX < newMaxX) { if (aabb.maxX >= oldHitbox.maxX && aabb.minX >= oldHitbox.maxX) { minX = aabb.minX - this.width; maxX = aabb.minX; } else if (aabb.maxX <= oldHitbox.minX && aabb.minX <= oldHitbox.minX) { minX = aabb.maxX; maxX = aabb.maxX + this.width; } } if (aabb.maxZ > newMinZ && aabb.minZ < newMaxZ) { if (aabb.minZ >= oldHitbox.maxZ && aabb.maxZ >= oldHitbox.maxZ) { minZ = aabb.minZ - this.width; maxZ = aabb.minZ; } else if (aabb.maxZ <= oldHitbox.minZ && aabb.minZ <= oldHitbox.minZ) { minZ = aabb.maxZ; maxZ = aabb.maxZ + this.width; } } newMinX = minX; newMinZ = minZ; newMaxX = maxX; newMaxZ = maxZ; changed = true; } } if (changed) { this.boundingBox.minX = newMinX; this.boundingBox.minZ = newMinZ; this.boundingBox.maxX = newMaxX; this.boundingBox.maxZ = newMaxZ; } }(I think you get the idea of what I mean by being able to provide a lot of code and stuff, I could show you a lot more via links if you could see private messages, which is all most seem to use to communicate these days, no idea why they prefer microscopic (e.g. Reddit) chatboxes with no formatting, probbaly the same for Discord, which I'll never use no matter what, I have considered at times to make a comprehensive thread detailing many of the fixes and improvements I made but it does take a lot of effort, considering a lot of my code also uses custom methods, some of which is seen here ("AxisAlignedBB.getAABB()" is simply a wrapper for "getAABBPool().getAABB()" to simplify code, I also added a new "intersectsWith" method that accepts raw coordiantes instead of an AABB)
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
If you go with 1.6, might 1.6.2 be a better option here than 1.6.4? I thought the changes of 1.6.4 was mostly, perhaps entirely (?), to accommodate the then-upcoming 1.7, and some of those things might even be harmful.
For example, I encountered very severe issues with performance in 1.6.4. As the mineshaft.dat file grew further in size, internal server performance further suffered. This was occurring on what was amongst the fastest and newest CPUs for the time. Client performance was not impacted, and it only occurred when hosting the game as a server, not when running it locally or when opening it to LAN. Most people probably never experienced it nor were aware of it as a result, but if you're wanting to have a server option available, this issue might be relevant.
With respect to the effort you've put into things, can you stop pretending like the effort you've put into TMCW erases the issues with the vanilla version itself? TMCW is an effort spanning over a decade, many of the things it resolves came well after the point in time where its foundational version was current, and most importantly, its a content modification mod and not a "vanilla" bug fix only mod (meaning it certainly doesn't apply in the sense of discussion about 1.6 itself). It's like you take second hand offense any time someone mentions an issue with an old version.
How come you put down the work of other developers (both Mojang and other modders in the community) for the things that you have fixed, either that the game fixed later than you or not at all, when the inverse is also true? You have your own list of issues too, you know. There's a lot of improvements, features, or quality of life that the current day game offers that TMCW does not. There are things that it took longer to address, or things that it still doesn't. I think some of the things you neglect are far more important. As a player, it's sad to see when developers feel the need to belittle the work of others in order to promote their own.
Have you fully resolved the lighting issues? I'd be very happy to hear that because it was one of the many highly critical issues with some of those very old versions. The last time you said something about it, you seemed to dismiss it as not a big deal. That was shocking to me, but I also took it to mean you hadn't yet resolved it? Maybe I was mistaken about that, or maybe you only addressed it more recently.
This is such a weird thing to be offended about and I'm surprised you keep bringing it up.
I was indeed not interested in content modifications, especially ones for a version that need more effort to mod, for a world that I had already started playing, and for a version I was only going to play short term. Part of the reason for the revisit was precisely to see how the "vanilla" state would hold up, yet you seem to miss that.
"'Tis foolishness! If all were so easy, why, none would suffer in this world!"
If you're having performance concerns with Minecraft, I hope this may prove useful.
A retrospective of the most important game to me (or, a try to stay awake while I never stop talking about something challenge).
I fixed that issue by disabling structure saving for mineshafts but retained it for other structures to avoid possible generation bugs (temples and village buildings split in half vertically along chunk boundaries when they are generated across sessions because unless the game saves the average ground level under the first half to get placed in the world the second half may use a different altitude).
Which incidentally, was broken when Mojang multithreaded chunk generation in 1.13:
MC-134978 Village houses split in two (duplicate of MC-131745)
They did eventually fix it, but how long did it take?
MC-131745 Shipwrecks sometimes generate split into different variants at chunk boundaries
Fix Version/s: 26.1 Snapshot 4
You may also ask, but won't disabling it cause generation bugs with mineshafts? Yes, but they generate at a predefined altitude so the only issue is that two spawners may be placed in a corridor that gets generated across two sessions as their location is dependent on whatever part gets placed first in the world (which is again not saved pre-1.6.4, and in any case the exact location of a spawner depends on the order of chunk generation). I also consider this to be a neat quirk leading to occasional exceptional finds (two spawners touching) and while TMCW fixes this by making the locations of spawners depend on the structure seed I added a chance of two spawners in a corridor to replicate the vanilla behavior (I did not fix this for my first world):
Example in 1.6.1: https://www.reddit.com/r/Minecraft/comments/1htgcl/found_a_double_cave_spider_spawner_spawners_are/
Example in 1.15.2: https://www.reddit.com/r/Minecraft/comments/iddrvj/double_cave_spider_spawner_i_am_just_curious_how/
Example of server performance in an extremely large (by standards at the time) world, around 165000 chunks / 10 max zoom maps, yet it runs almost like a brand-new world (1.78 ms server tick and 60 MB memory, the only significant difference is from nearly 1000 chests, signs, and item frames. I did disable spawn chunks but I'm standing within them (spawn is at -92, 236) so that wouldn't matter here):
Fun fact: you can disable many of the (relatively minor) modded features in "World1 custom client", which is more or less the "vanilla" version of TMCW (same core codebase/code changes but without all the new content, just a handful of minor features, some of which are even totally optional anyway, e.g. "rail blocks" only ever exist if you craft them, I even accommodate those who refuse to play on 1.6 simply because it has horses (not kidding, it really is that common, "Why do people choose 1.5.2 over 1.6.4?", even making mods like "Better than Horses", a reference to the OG "alternate timeline" mod "Better than Wolves" which was created after they were added due to the developer's extreme dislike of them (or even TMCW itself due to my dislike of 1.7+ world generation and other features), the next update (which fully updates the codebase to match TMCW as I prioritize the mod I'm using when playing) will also add an option to disable baby zombies, another commonly dislike feature of 1.6 (I've even seen some playing on 1.6.1 despite all the bugs it had which were fixed in 1.6.2, albeit that included naturally spawning baby zombies):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
It's something that exists in 1.6.4 though, and is therefore something that someone looking to mod 1.6.4 might have to fix. Your solution sounds like it has a new issue of its own that you've personally accepted.
The reason I was wondering if 1.6.2 would be preferable was because that's something that wouldn't need fixed, and I've often seen it said that 1.6.2 is mostly the "same thing" as 1.6.4 minus the changes to get things ready for 1.7. The issues that 1.6.4 fixed should also be looked at though. The Wiki mentions these as those things.
"From released version before 1.6.1
MC-1867 – Double sound for fall damage
MC-3464 – Arrows don't stick in soul sand.
From 1.6.1
MC-21066 – minecraft crashed on a server, it only seems to do this on this server.
From the previous development version
MC-31065 – Villages not generating? (snapshot 13w37b)
Other fixes
Fixed handshake exploit."
That seems like a short list, and some of them seem unsure of themselves whereas some others seem minor. You would have to decide how important they are. The issue with the server crashing, assuming there was anything to it in the first place, and the exploit might be important if server functionality is desired though?
This has all been assuming the thread starter goes with a 1.6 version, but since they mentioned disliking 1.7 world generation, I sort of figured 1.6 might be a better starting place. I sort of overlooked that they were also asking about 1.5 because I personally don't see much point of that one unless you really dislike horses, coal blocks, or carpets. I guess everyone has their own "straw that broke the camel's back" change so someone is bound to dislike it for one of those reasons, but I would imagine the numbers are low. The outcry against 1.6 that I remember from its time was that it was a "lazy update" since it "just added a literal mod", but I don't remember any outcry that any of the changes that it was making were things that people couldn't tolerate playing with. So I don't know.
But going with 1.5 might also mean avoiding some key issues too. Didn't the issue with untamed wolves despawning after a couple of minutes start in 1.6? And does that apply to all 1.6 versions, or was it only later 1.6 updates?
*sigh*
I asked why you do this, and you ignored answering only to do it again. I presume you're familiar with the phrase and concept of "throwing rocks from glass houses"?
Two things having a shared underlying variable doesn't mean that frequency or severity of both of them is equal. Mojang can consider something a duplicate as they see fit, but I can tell you from experience that while ships with mismatched wood types are very common, villages with misalignment or missing portions aren't. Even that bug tracker page supports this because notice the few examples that show villages are all old villages that were last in the game in 1.13. Most of them are even using snapshot or pre-release versions. So it's pretty apparent that by 1.14 at the latest, if not a 1.13 version, this was largely addressed with villages.
"'Tis foolishness! If all were so easy, why, none would suffer in this world!"
If you're having performance concerns with Minecraft, I hope this may prove useful.
A retrospective of the most important game to me (or, a try to stay awake while I never stop talking about something challenge).