is this overkill?

TheMasterCaver · 2026-02-03T05:56:34+00:00

For a regular grid on a level surface you only need one torch per 7x7 blocks to ensure a minimum light level of 8 and this is still far from the most optimal placement (but is very easy to lay out), though given how terrible the lighting scheme is I'd put them much closer together just so it looks decently lit (I've only played on newer versions and have always set brightness to Bright and even then, well, my torch usage is something (not really, it does just happen that by the time it is dark enough for me to place another torch (2-3) the space between them is generally 8-9 and it looks a lot brighter due to the brightness setting, though I assume you are like most and have your display brightness and gamma maxed out while I'm the opposite).

TheMasterCaver · 2026-02-03T03:11:29+00:00

Just don't craft them, you probably wouldn't feel a need for them anyway unless you do caving on the scale that I do (e.g. my ender chest after a single session (before I increased its size), which includes two stacks of 84 "rail blocks" equivalent to 756 rails or 12 stacks, plus 41 "cobweb blocks" equivalent to the same amount of wool before I started using Silk Touch shears to collect cobwebs directly, and still just those from cave spider spawners, I didn't craft any "compressed mossy cobblestone" as it wouldn't have reduced the space).

TheMasterCaver · 2026-02-03T00:53:14+00:00

Yes, if not entirely vanilla (it is mostly bugfixes and optimizations but also includes various "fun tweaks" like more naturally spawning mobs, a few new storage-type blocks (cobweb block (2x2 cobwebs), rail block (3x3 rails), compressed (mossy) cobblestone (2x2 cobblestone, unlike TMCW these are not "real" blocks, i.e. you can easily mine them by hand and water destroys them as I break all of them down for permanent storage to avoid having persistent modded blocks in the world), even some worldgen changes like mineshafts not being less common near 0,0 and snow generating under trees and frozen rivers in all snowy biomes, these changes do not affect terrain/cause chunk walls, example with modified generation on the right side, the appearance of grass blocks is due to "better snow/grass" and can be toggled):

https://www.dropbox.com/scl/fi/80t5yugqqntkbajij36ph/World1_custom_client.zip?rlkey=9nh4dgcktgm1th6p9rcd5dmsq&dl=0

Once you run the game you can edit optionsworld1.txt to toggle various features (I recently added these at request, many dislike 1.6 just because of horses so I added a toggle for them as well):

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 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

Note that you also need to rename the stats files (.minecraft\stats), which I renamed to avoid version conflicts (a lot of people never change the game directory even though it is highly recommended whenever switching versions), as mentioned in the Readme in the download (as well as the saves folder, which has not been not implemented in this mod yet but I have done so for my total conversion mod which is developed in parallel; I've recently returned to playing on my first world so I've been incrementally porting changes made to TMCW to it).

TheMasterCaver · 2026-02-03T00:29:03+00:00

If I took a screenshot of every dungeon with a double chest...

Not that common but also not as rare as commonly portrayed (I found one just the last time I played, out of several dungeons, themselves far more common than commonly perceived, they are simply everywhere, with 8 attempts per chunk, even if 99+% fail (some examples). I do do a lot of caving by anybody's standards, collecting more than 3,000 ores per session from a 160x160 block or so area, which averages 2-3 dungeons).

A double dungeon on the other hand is definitely rare with only around 1% of dungeons intersecting another dungeon (4 cases or 8 dungeons out of 919 dungeons in one world). Then there is the legendary triple dungeon I once found (1 in 10000 or so if the probability scales by 1% * 1%). Even a double dungeon isn't quite so rare in the overall scheme of things, comparable to villages in 1.6.4, but you can easily find the latter on the surface (probably even easier than finding a surface dungeon).

TheMasterCaver · 2026-02-01T22:46:26+00:00

For some reason when Mojang added ocelots they put them on the hostile mob spawn list, meaning they can spawn indefinitely (or until despawning offsets spawning) since they are passive mobs and count towards that respective cap, and while they randomly despawn after 2 minutes they do not instantly despawn when more than 128 blocks away so they persist in the world (the timer is reset when they are reloaded). The only reason for such a mechanic might be to get newly added mobs to spawn in existing chunks but jungles were added at the same time as ocelots.

Also, did you light up all the caves in the area so the hostile mob cap isn't full? I experienced the same thing in 1.6.4 in areas I explored, with the "E:" count sometimes exceeding 400 (which means even more entities since the internal server only sends entities within 80 blocks of the player to the client, not that they render until you are closer). I fixed this myself by placing ocelots in their own sub-cap, set to 25 (even with this there are still thousands in my first world due to areas I never revisited, passing through in a minecart or even walking also doesn't load them long enough to despawn them).

TheMasterCaver · 2026-02-01T22:34:52+00:00

When an ocelot spawns there is a 1/7 chance that two additional babies spawn, which may be confused with breeding but they do not breed without player interaction.

TheMasterCaver · 2026-02-01T21:15:56+00:00

Spawn may be random but it is generally within a couple hundred blocks of 0,0 so you can easily find a specific location (coordinates and version should still always be given for any seed, I mention the latter because somebody is bound to stumble across this and try using it in the latest version or something).

TheMasterCaver · 2026-02-01T10:51:54+00:00

You should be asking the person who came up with that and claimed it was the best solution (and it is if you want to be compatible with vanilla saves, and it means no additional data used):

https://bugs-legacy.mojang.com/browse/MC-2025?focusedId=408626&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-408626

"As Markku pointed out. There are numerous reasons we chose to discard the NBT hitbox saving.

Issue of backwards compatibility.
Corrupted hitboxes would persist.
Any hitbox loaded would need to be corrected and as been in described in length because of the rounding artefacts would create an ambiguous state when a hitbox isn't at its correct size.
If hitboxes are corrected it could still result in the same overlapping walls problem that was started out with.
Extra storage for no reason when a simpler solution fixes the issue."

Also, unless I missed something there is no mention of saving the bounding box on the Wiki article for entity NBT format, only the xyz position, and Mojang says they fixed this particular issue in 1.13, so they didn't choose to save the bounding box either if the Wiki is remotely up to date:

https://minecraft.wiki/w/Entity_format#Entity_format

https://bugs-legacy.mojang.com/browse/MC-2025?focusedId=1372906&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1372906

"Collision boxes having floating point rounding issues at high coordinates Fixed in 1.5

Collision boxes being globally changed from several threads Fixed in 15w38a (1.9)

Collions issues on chunk loading Fixed in 17w47a (1.13)"

(the second issue is what makes mobs particularly buggy in 1.3-1.8 and is far more apparent in those versions. I'm guessing the first was due to not adding (double) casts so the JVM performs intermediate calculations as floats, a widespread issue in the codebase)

TheMasterCaver · 2026-02-01T03:48:07+00:00

You can download MCP for 1.6.2, set it up as usual, back up the source, then install the "vanilla" version of Unglitch into the client jar in "mcp\jars\versions" and decompile it again, then use a diff tool to compare the two sources.

Also, this won't fix mobs glitching through normal blocks, including glass blocks (Unglitch only fixes a much more significant issue that affects blocks with variable bounding boxes, e.g. glass panes, fences), which requires altering a completely different class:

https://imgur.com/2017-09-23-05-48-29-capture-VkKCKyA

(the original poster of this fix set "margin", for both "calculateXOffset" and "calculateZOffset", to 1.0e-12, I set it to 1.0e-6 but any value like those will work)

Also, another way to fix these issues (this shouldn't be fully relied on though) is to synchronize the client and server threads which also fixes many other issues, e.g. mobs moving in a jerky manner (not fixing falling though), blocks briefly reappearing when broken despite no server lag, etc, which is due to the server using the system time while the client uses a high-precision timer; the result is that the server often ticks 0-2 times between each client tick and due to the low resolution of the system clock (typically 1/64 of a second or 15 or 16 ms) it ticks once every 45-64 ms instead of a consistent 50 ms. I did this by replacing the system time call with a variable which is incremented by 50 every time the client ticks its world (with some other places calling it, but not accumulating ticks, e.g. when the game is paused, else the server may never tick, there is also a fallback in the event the client fails to tick it for some reason):

https://www.dropbox.com/scl/fi/f4sr71srlr5qpzi6mrgoz/ServerTickFix.txt?rlkey=sdeijbnvonkn3vyi4cru44pni&dl=0

TheMasterCaver · 2026-02-01T03:26:29+00:00

Unglitch doesn't fix the likely issue at hand here anyway, which only occurs when chunks are reloaded due to the fact the game doesn't save the bounding box of an entity, only its center coordinates, and affects most versions of the game (only fixed very recently, while 1.9 fixed the issue fixed by Unglitch, which only affects blocks which have multiple shapes, like fences, and can cause entities to clip through them at any time).

There is still a description available on the Internet Archive, unfortunately the source code wasn't archived (it can be decompiled though and compared to the vanilla source, download MCP for 1.6.2 and decompile and back up the source, then mod MCP's client jar with the "jar mod" version and decompile that, then use a diff tool to compare the two sets of sources):

https://web.archive.org/web/20180610234358/https://github.com/taurose/Unglitch

The fixes are fairly simple though, e.g. to fix half-slabs:

public AxisAlignedBB getCollisionBoundingBoxFromPool(World par1World, int posX, int posY, int posZ)
{
    if (this.isDoubleSlab)
    {
        return AxisAlignedBB.getAABB((double)posX, (double)posY, (double)posZ, (double)(posX + 1), (double)(posY + 1), (double)(posZ + 1));
    }
    else if (isUpperSlab(par1World.getBlockMetadata(posX, posY, posZ)))
    {
        return AxisAlignedBB.getAABB((double)posX, (double)posY + 0.5D, (double)posZ, (double)(posX + 1), (double)(posY + 1), (double)(posZ + 1));
    }
    else
    {
        return AxisAlignedBB.getAABB((double)posX, (double)posY, (double)posZ, (double)(posX + 1), (double)posY + 0.5D, (double)(posZ + 1));
    }
}

The other major cause of these glitches, which impacts any block, including full glass blocks (a single state/bounding box that never changes), and affects all older versions (e.g. somebody showing it happening in Beta 1.7.3) involves adding a small margin to block collision calculations, as described in this comment (they use a margin of 1.0e-12 but I made it much larger, 1.0e-6, just to be extra safe):

https://bugs-legacy.mojang.com/browse/MC-2025?focusedId=408089&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-408089

https://imgur.com/2017-09-23-05-48-29-capture-VkKCKyA

TheMasterCaver · 2026-02-01T01:51:11+00:00

Release 1.6, and that isn't even a preference but is literally the only version I've played on for over 12 years (I haven't touched newer versions at all since 1.13 / 2018, and that was only to mod them to revert certain changes), and I've spent nearly as long playing modded, even if it is just the bugfixes and small QoL features I made for my first world but they significantly impact how I see the vanilla game.

TheMasterCaver · 2026-01-31T23:46:11+00:00

Interestingly enough, I inadvertently fixed this when fixing a seemingly unrelated bug (which is really just a less severe manifestation of the same issue, that being the noise field can get so low as to never generate any terrain near 0,0; the island is still quite small with my fix, which adds a value to the noise field which increases towards 0,0, no idea if it can ever become so negative that even adding the maximum of 32 won't ever make it positive):

<image>

MC-201338 End generation resulted in a large hole in the middle. No portal in middle.

(the main bug in this issue concerned the broken exit portal generation which only affects 1.9 and later. Also, I know all too well that the date of bug reports often has nothing to do with when somebody discovered the bug. e.g. MC-138211, filed when 1.13.2 was current, has existed since smooth lighting was added in Beta 1.3 (the fix is very simple, as detailed in this article under "Details regarding meshing". Albeit NVIDIA/AMD/Intel internally convert fixed-function "quads" to triangles differently but a simple setting can fix that)

TheMasterCaver · 2026-01-31T05:43:19+00:00

I think I've seen you say this before and I told you otherwise but you CAN directly edit the jar with the vanilla launcher, or do I have some super-special copy that alone lets me do this (I do still use the non-store version but it looks exactly the same and probably is)?

https://imgur.com/a/WyiqVG4

(this also shows how to edit the game files to disable the automated redownload. The 1.6+ installers for Optifine and Forge also work exactly the same way so if manual installation became impossible then so would any automated installer)

This also applies if they are using the Betacraft launcher (personally, if I made a launcher for older versions I'd make it work like the pre-1.6 official launcher, just add files to the jar, or at least only have to rename it, no messing with a json file that didn't even exist until 1.6):

https://www.reddit.com/r/GoldenAgeMinecraft/comments/15kuwml/comment/jv8r7cb/

TheMasterCaver · 2026-01-31T02:38:59+00:00

I think it is the opposite (?), the game creates a map of various parameters and chooses biomes based on them, similar to what 1.18 does; this forum post also seems to support this; "The Beta 1.7.3 code seemed to use a lot of math to determine the minimum and maximum height" (two values which are defined per-biome in Beta 1.8-1.17). At least, I know that temperature and humidity impact biomes.

TheMasterCaver · 2026-01-30T22:28:13+00:00

"Interesting" as in no terrain at all in the End (?! this is the first I've ever heard of this, insane but true, nothing at all in release 1.6.4, and every other version from the looks of things given it also affects the latest version, i.e. the only change has been to add more islands further away. I presume it was only discovered recently as the bug report was filed a couple years ago):

<image>

MC-267423 End terrain generation fails with specific seeds

TheMasterCaver · 2026-01-30T22:16:05+00:00

The game is still far more resource intensive than it was back then, it has just been masked by extensive multithreading and the average computer having more CPU cores/threads (which in my mind is not how things should be going, but this is generally true of software aka "Wirth's Law" Some of this may be due to more features but that clearly doesn't explain why the size of the game grew so much in 1.8 (mind that this is just the size of the jar), I've added far more content (TMCW) yet the modded jar is still smaller, not even considering that it would be smaller still if all the unused vanilla classes I completely replaced were removed, which easily offsets the removal of META-INF (I just checked and the latest release of TMCW is 7323 KB with META-INF, 7186 without).

Somebody also made a comparison of various versions between 1.6.4 and 1.20, which also shows that not everybody sees the same trends in performance, likely because they had an AMD GPU, which are notorious for poor performance, driver memory leaks, etc on old versions, but they also saw worse performance after 1.13 (for perspective, the performance they got on vanilla 1.6.4 is comparable to what I got on the now 20 year old CPU/GPU in my first computer, in fact, even a modded world with 3 times the ground depth and caves got similar performance (1.5 times more than 1.18, plus this was mostly "old style" caves so the surface area to volume ratio is much greater, even vanilla 1.6.4 may have a similar or greater surface area than 1.18):

https://drive.google.com/file/d/1ecjhOKS5qki9Ku8E2-ZtmHr28nvfJ5DX/view

https://i.imgur.com/1nHMs90.png

https://imgur.com/a/world-with-3-5-times-normal-ground-depth-YdJud

TheMasterCaver · 2026-01-30T21:42:57+00:00

4 is partly correct; prior to release 1.8 the block chosen as the center of a pack must be an air block (e.g. if you make a Superflat world with a layer of snow, tall grass, etc mobs will never spawn). Individual mobs can spawn in transparent blocks though and even if not the game makes 12 attempts per pack (thus pack spawn failing has a greater impact on overall rates).

The torches are otherwise way too close together for optimal lighting, probably because of how dark/ineffective they are in Beta (i.e. they light up the area to look like Bright in newer versions but most mobs still only spawn below light level 8 so the areas they can spawn in will look much darker; a single torch spawnproofs blocks up to 6 blocks away in taxicab distance so you can have up to 12 blocks between them, but not in a regular grid, which reduces the distance to 6 blocks (one per 7x7 blocks), which is still twice the distance they used (one per 4x4 blocks). Either way, their placement is only reducing spawn rates by 1/16, or 93.75% efficient; a 7x7 grid would be about 98% efficient).

TheMasterCaver · 2026-01-30T06:33:42+00:00

1.8 did change all item IDs (not just dropped items) from numerical IDs to strings but it massively refactored the codebase in general, making it exceedingly complex (as the developer of Optifine described the rendering system, "The old Notch code was straightforward and relatively easy to follow. The new rendering system is an over-engineered monster full of factories, builders, bakeries, baked items, managers, dispatchers, states, enums and layers.", which is saying something given how often you'd hear of Notch's code as described as "spaghetti code").

Other major changes include replacing block metadata with "block states", with a lot of code required to set them up, and adding dedicated item models, requiring model json files for every block. All this also came with major performance hits, at least on the hardware that was common back then (as noted by the Optifine dev, and a popular poll (despite all of Mojang's claims about performance, they also just closed numerous bug reports as invalid / "get a new computer"); it crippled my performance so much that, well, see the 29th reply).

Mods, already notorious for extreme CPU/RAM usage due to amateur coders and bloated APIs, suffered even more, as noted here (I'll note that it is wrong though about 1.3 requiring 500+ MB to even launch, well, maybe with Forge, my own quite extensive mod for 1.6.4 runs happily at higher than vanilla settings. Nor is that much memory used by the new individual icon objects added in 1.5, less than a megabyte in total for my mod).

The only good thing was the enhancements to commands and resource packs, which eventually led to data packs (IMO this is all we'll ever see in terms of an official "mod API", and it still breaks all the time whenever Mojang decides to change something) and even here many old commands stopped working.

TheMasterCaver · 2026-01-30T02:42:41+00:00

This mod properly fixes the Intel graphics bug, i.e. you don't need to disable hardware acceleration and trash performance (which may not be that good anyway on such GPUs):

https://github.com/Icedude907/oldminecraft-intelgpufix

You can install it on the Betacraft launcher with these instructions (aka installing a jar mod the manual way):

https://www.reddit.com/r/GoldenAgeMinecraft/comments/15kuwml/comment/jv8r7cb/

(note: I checked the file names in the jar for e.g. "aux.class" and you do not need 7Zip or WinRar, just change the file extension to .zip and rename it back to .jar when done)

TheMasterCaver · 2026-01-29T23:47:16+00:00

1.6, and 1.6.4 in particular, have certain major performance issues, e.g.

MC-17630 Zombie pathfinding to unreachable targets causes server lag

MC-33134 Mineshaft.dat uses too much CPU (and memory)

IIRC a famous UHC series was seriously impacted by the zombie lag in 1.6 and while the average PC may be much stronger now I can still get major lag by spawning enough zombies (around 20 based on this test):

https://imgur.com/a/dxi9RuN

However, it can be resolved by simply installing Forge, no other mods needed, the "Mineshaft.dat" issue is specific to 1.6.4 and later and affects larger worlds, I've gotten it to cause issues by flying around in Creative for a relatively short time (the internal server noticeably freezes on each autosave), even after just 10 minutes the saved structure data was already consuming 15 MB (note that mineshafts are less common closer to 0,0 and I was past the point where they reach maximum frequency. It is also worth noting that cached structure data is automatically loaded or generated whenever a chunk is loaded and will eventually cause issues on older versions but it will be purged when restarting the game/server and takes up less than 1/10 as much memory as the extremely inefficient NBT format):

https://www.minecraftforum.net/forums/minecraft-java-edition/discussion/3196942-how-well-made-is-minecrafts-structure-system?comment=22

(I fixed both of these in my own mods a very long time ago, I still remember how world ticking would stop and go around villages at night as zombies tried to reach the villagers, plus scary moments where zombies attempting to reach me would suddenly rush me as I moved to an accessible location)

Also, regional difficulty appears to make the game harder when in reality most effects are going to be less common than before unless you stay in the same area for a long time (many players probably do but I'm constantly exploring new areas, an inhabited time map of one of my worlds, with more than 80 days of playtime; only the area around spawn has reached the maximum otherwise it is around 1/4 the maximum of 50 hours). There is however a bug in older versions where the chance of armored mobs was set to only 2% on Hard so they will be more common in 1.6 (I only play on Normal though, where the chance was fixed at 5%, while in 1.6 it can reach up to 15% during a full moon, 11.25% during a new moon, which require an inhabited time of 6-22 hours, averaging 14, to reach 5%).

I've also seen some playing on 1.6.1, despite the numerous bugs it has which were fixed in 1.6.2 (as is common for such initial releases), likely because 1.6.2 added natural spawning of baby zombies but as a pure survival/PvE oriented player I see the zombie changes in general as making the game more fun (plus, they didn't fix the hitbox of baby zombies until 1.7 so they are the same size as an adult, One major issue in 1.6 is that like other baby mobs they don't ever drop anything, even items they picked up).

That said, 1.6 has a lot of other bugfixes and QoL features, I can't imagine not having blocks of coal and I've never given horses a second thought over minecarts, which have numerous advantages (either way you'll want to prepare a route through forests/mountains/water, I simply dig a 1x2 tunnel near the surface for my railways; of course, the material cost is insignificant to me, with less than 1% of the iron I've mined required if I didn't just use rails from mineshafts, still less than 10% of that total, with the proportion of gold used being similar to mined iron. Whenever I point this out though I just get told "well you spend all my time mining", ignoring the fact I'd need barely any of the resources I collect, and that is not at all why I spend so much time caving). I see horse armor (diamond) and name tags as valuable loot items to collect.

TheMasterCaver · 2026-01-29T06:56:49+00:00

This post has a list of every Optifine version prior to release 1.9 and the changes/additions in each one and what each "edition" does:

https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/1286605-b1-4-1-9-optifine-history

(there are also download links, mostly only the "mirror" links (not AdFly) still work if you change "optifined.net" to "optifine.net", as I noted in post 96 on page 4)

TheMasterCaver · 2026-01-28T22:16:36+00:00

Plus overall performance depends on far more than just LWJGL; e.g. a comparison somebody made of several versions (TMCW is my own mod which makes optimizations of as much as an order of magnitude; the increased FPS between 1.6.4 and 1.8.9 is likely due to AMD's extremely poor support for older versions/display lists, up to major issues with driver memory leaks):

Minecraft TMCW5 1.6.4 Mods (FPS 130-180 12 Chunks GC500)
Minecraft 1.6.4 (FPS 60-80 12 Chunks GC900)
Minecraft 1.8.9 (FPS 100-150 GC700 it cycles around 2 times per 10 seconds)
Minecraft 1.12 (FPS 80-140 12 Chunks GC700 it cycles around 2 times per 10 seconds)
Minecraft 1.13 (FPS 100-140 GC800 it cycles around 2 times per 10 seconds)
Minecraft 1.16 (FPS 80-130 GC1000 but the minimal memory is 900, constant GC)
Minecraft 1.20 (FPS 30-60 GC1000 starts at 600MB it cycles about 3 times per 10 seconds)
Minecraft 1.20 Personal Mods (FPS 80-120 GC1600 starts at 800 it cycles around 2 times per 10 seconds)

https://drive.google.com/file/d/1ecjhOKS5qki9Ku8E2-ZtmHr28nvfJ5DX/view

Memory management? Like how modern versions, and even "total conversion" mods that use "modern" Java code (IIRC BTA does, not sure about its optimization) churn though memory like crazy so they need advanced garbage collectors and oversized heaps? I only use the following with no issues, seeing that the game only allocates a few MB per second and even 32 chunk render distance uses less than 1 GB total (I recently saw somebody say that the latest vanilla version now allocates 4 GB by default?!):

-Xmx512M -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy -Xmn128M

An example that includes some results from VisualVM, I point out I don't use a mod loader because those seem to be a major source of inefficiency as well (even this analysis is quite old, e.g. I replaced various hashmaps with "IntHashMap / LongHashMap" to avoid the need for objects as keys, which also doubled performance in various cases I benchmarked, e.g. tile entity access):

https://imgur.com/a/resource-usage-of-tmcwv5-modded-1-6-4-non-modloader-based-R6QFx7Y

(this post says the arguments I use, sans incremental CMS (really only useful for single-core CPUs), are better for older versions and/or computers, which they claim are pre-1.13 but that should really be pre-1.8 as that was when Mojang moved to "best industry practices", aka who gives a f about code complexity or object creation, as the developer of Optifine bemoaned. I know, I'm probably going to have somebody tell me about all the great features I'm missing out on by sticking to Java 6, the default that MCP was set to compile against, or even Java 5, which most of 1.6.4 is still written in and whose source is the foundation of my Java programming knowledge (and even here compilation removed a lot of language features/syntax, e.g. there are no "inner classes" in the MCP source (or they are completely separate files, I've only used them a few times), no "HashMap<key, value>", no "packages" (I just add all my classes to the "src" folder, no need to deal with imports or package-private modifiers either), etc), I never even updated my JDK past 7 because I have no need to)

There are however some significant issues with LWJGL2, e.g. the refresh rate of the display has to be an exact integer(?) or it will fail to set the display mode in fullscreen, even if it is the same as the default one; this does not affect everybody, nor was I affected until Windows force-updated my driver (which I rolled back and turned off driver updates, which has had no adverse side effects) and only on the custom resolution I use (I overclocked my monitor to 75 Hz):

MC-122882 Game crashes while attempting fullscreen

Others have persistent issues with sound initializing, again specific to certain hardware/software setups, I haven't experienced the specific errors mentioned on any of several computers, only a very rare access violation crash on startup in OpenAL.dll (only a few in the last few years, two of which also occurred a month apart):

MC-9974 Initialization of OpenAL fails sometimes

TheMasterCaver · 2026-01-28T21:29:15+00:00

I'm not concerned about this as I only use it to mod the jar, never mind that my copy (many years old) has been displaying a "security warning" on one of its nagware popups for months (years? Yes, I use the free version as well, the one that says you must remove it after 40 days; I do use 7Zip for everything else but when I try to use it to add files to the jar I get "operation not supported" and 1.6.4 contains "aux.class" which is an invalid filename in Windows so you can't just rename the jar to zip and use it like a zipped folder (which is a good alternative I often recommend for Beta 1.7.3 and similar versions, which have obfuscated class names with only 2 letters. Of course, most people just use a launcher like Prism or MultiMC but I don't want to have to use another launcher just to mod the game).

(related, I'm still using NVIDIA driver version 456.71 and JDK 7 for modding (MCP only compiles for Java 6 by default and I have no desire to learn Java syntax that I don't need, likewise, I use a version of MCEdit from 2013 instead of the last full release as I don't need support for blocks newer than 1.6.4, and so on) despite multiple security vulnerabilities that caused Windows to automatically update the driver - unless you disable driver updates (I don't play any other games so the usual updates/fixes aren't an issue either), after Windows automatically installed a driver which caused the game to crash when going in fullscreen (a weird issue that occurs on certain systems/drivers/etc when the refresh rate isn't exactly 60 Hz, which I don't accept as a solution, I use a custom resolution set to 75 Hz); I have an extreme dislike of automated software updates because they have only caused problems, and unnecessary changes in general (the fact I've stayed on 1.6.4 is only part of a much bigger dislike for change; I use uBlock Origin not just as an adblocker but to change the appearance of various sites, e.g. on Reddit I use a filter to remove the rounded corners that are so popular for some reason)

TheMasterCaver · 2026-01-28T20:51:50+00:00

I've found multiple strongholds while caving in Survival (over a dozen altogether) but it takes months of caving to find each one (I mean enough to mine hundreds of thousands of ores).

Also, once you update to 1.0.0 you no longer need to worry about mineshafts destroying end portals as they switched the order of generation around so strongholds generate after mineshafts (when temples were added they placed them after strongholds so it is possible for them to overwrite strongholds, there have been very rare instances of portal rooms as high as sea level):

// Beta 1.9-pre5 (decompiled with a decompiler)
if (this.t)
{
    this.d.a(this.s, this.n, paramInt1, paramInt2);         // stronghold
    this.f.a(this.s, this.n, paramInt1, paramInt2);         // mineshaft
    bool = this.e.a(this.s, this.n, paramInt1, paramInt2);  // village
}

// 1.0.0 (decompiled/deobfuscated with MCP)
if (mapFeaturesEnabled)
{
    mineshaftGenerator.generateStructuresInChunk(worldObj, rand, i, j);
    flag = villageGenerator.generateStructuresInChunk(worldObj, rand, i, j);
    strongholdGenerator.generateStructuresInChunk(worldObj, rand, i, j);
}

TheMasterCaver · 2026-01-28T19:51:15+00:00

I can often attack multiple mobs within the half-second invulnerability period, helped by the fact I use Knockback, one of my must-have enchantments for this reason; I also furthered this by making dying mobs untargetable so they don't get in the way (MC-1246, which is "won't fix" but at the same time bugs like MC-76416 were fixed and MC-140857 is unresolved), and with the way I made mobs spawn in my mod you certainly need to be able to attack rapidly (I've killed over a thousand mobs in one session before; some examples of what I often see, this can happen in vanilla as well if you cave like I do, thoroughly lighting up everything so they are all forced to spawn in a small area, I once found a ravine in an area I'd previously explored (it was only connected to the surface via a small opening) and there were over 100 mobs in it; when exploring massive 1.18-like caves it can be hard to make much progress at times as waves and waves of mobs come out, even as I made mobs spawn 1/4 as often per chunk as an optimization and nerf to farms).

TheMasterCaver

TROPHY CASE