1.7.10 has the best mods but it is also the laggiest modded version GTNH is so laggy at times even on good computers many of the other kitchen packs for 1.7 are laggy too and NEI in this version was really bad. Exutil Drums are a bad source of NEI lag and overall the performance in this version is really bad once you start gong over like 200 mods it sucks because this version has the best mods.
There is an alternative to NEI which is called "Too Many Items". It shows all items, can be turned off/on in game by pressing "O".
There is an alternative to NEI which is called "Too Many Items". It shows all items, can be turned off/on in game by pressing "O".
Some mods (NEI) might be more problematic but it is a fact that something was broken in 1.7.10, I recall that that it had lots of lag spikes/freezes (just vanilla) and there is a bug report regarding the issue (I did see a lot of warnings about "client side chunk ticking" taking too long); maybe there is a mod that fixes this issue (FoamFix, which I should note claims that even with just itself Forge runs worse than vanilla, so Forge is also the problem):
Exploring a large cave system that my strip mine encountered around y:40 began to induce severe framerate drops and freezes. A unique 'slow-motion' effect takes place as the framerates and memory return to normal, only to be affected again shortly after if I were still in the area. Framerates would drop from 120 to 40 to 0 (readable in between screen freezes), CPU utilization on one (of eight) cores would spike from ~20% to ~90%, in-game memory would spike from 200 mb to 900 mb when this occurs.
Almost all of FoamFix focuses on optimizations particular to modded environments. Porting it to vanilla would have very few benefits, as vanilla by itself is more efficient than even Forge+FoamFix.
Otherwise, IMO most mods are extremely sloppily coded, just as bad or worse than newer vanilla versions; "it works" is enough with no time spent on optimizations unless they are absolutely necessary, in addition to how modloaders work (this can be the only reason why I've been able to add at least 500+ features to 1.6.4 with no performance impact (aside from stuff like biomes of massive trees, which are harder to render, but not the actual game/Java code itself, and if a computer from 2005-6 (system specs, and yes, 1.8 ran that badly) could render them at 100 FPS (no Optifine, otherwise only leaves had to be Fast) then any recent computer shouldn't have a problem) - in fact, despite being more complex than 1.19 world generation is twice as fast as vanilla 1.6.4).
World generation mods are particularly notorious for "cascading worldgen", an issue which is nonexistent, and can't even actually happen in TMCW, outside of a few remaining vanilla classes which don't have the issue:
This could easily be avoided with some basic knowledge of how world generation works; all small features/decorations must be generated entirely within a 2x2 chunk area, centered on the innermost 16x16 blocks and extending no more than 8 blocks outside of it (this is why the vanilla code adds 8 to the chunk coordinates times 16); some of the larger trees in TMCW require an additional margin ("chunkCache" is a cache of the 2x2 chunks being populated, with block accesses that go outside of it wrapping around, along with bounds-checking code that can be enabled when debugging):
// Makes 5 attempts per chunk of generating one mega tree
for (int i = 0; i < 5; ++i)
{
// Offset gives 3 blocks of extra space around trees; is normally nextInt(16) + 8
int x = blockX + decoratorRNG.nextInt(10) + 3;
int z = blockZ + decoratorRNG.nextInt(10) + 3;
int y = this.getTopBlock(chunkCache, x, z, true);
if (y > 0 && this.megaTreeGen.generate(chunkCache, x, y, z)) break;
}
Large structures, or something like a huge vein of ore, are generated chunk-by chunk by creating a map of the structure in memory and placing parts that intersect the current populated area (16x16 blocks, which is constrained via a bounding box that is passed in; as usual, the vanilla source is the best way to see how this works); cave generation works in a similar manner and this is how I can generate features over 300 blocks across with no issues (the cave generator actually carves through the raw terrain data used to initialize a chunk, i.e. the chunk doesn't even exist yet, nor may neighboring chunks).
Likewise, there is absolutely no sane reason for even the biggest modpack to require multiple gigabytes of RAM, simply none, unless you are using a mod with extreme render distance (TMCW uses less than 30 MB as a baseline and runs with only 512 MB allocated (note the charts of allocation rate and memory usage by object), a max-height Superflat world (256 layers) might benefit from more but that isn't a usual situation). Mods that add so many items that they run out of IDs? If you actually are adding that many blocks/items then most of them surely can't be unique enough to justify their existence (I can't picture more than 5-6 tiers of armor and tools; if you want unique properties that's what enchantments and NBT tags are for).
Some mods (NEI) might be more problematic but it is a fact that something was broken in 1.7.10, I recall that that it had lots of lag spikes/freezes (just vanilla) and there is a bug report regarding the issue (I did see a lot of warnings about "client side chunk ticking" taking too long); maybe there is a mod that fixes this issue (FoamFix, which I should note claims that even with just itself Forge runs worse than vanilla, so Forge is also the problem):
Otherwise, IMO most mods are extremely sloppily coded, just as bad or worse than newer vanilla versions; "it works" is enough with no time spent on optimizations unless they are absolutely necessary, in addition to how modloaders work (this can be the only reason why I've been able to add at least 500+ features to 1.6.4 with no performance impact (aside from stuff like biomes of massive trees, which are harder to render, but not the actual game/Java code itself, and if a computer from 2005-6 (system specs, and yes, 1.8 ran that badly) could render them at 100 FPS (no Optifine, otherwise only leaves had to be Fast) then any recent computer shouldn't have a problem) - in fact, despite being more complex than 1.19 world generation is twice as fast as vanilla 1.6.4).
World generation mods are particularly notorious for "cascading worldgen", an issue which is nonexistent, and can't even actually happen in TMCW, outside of a few remaining vanilla classes which don't have the issue:
This could easily be avoided with some basic knowledge of how world generation works; all small features/decorations must be generated entirely within a 2x2 chunk area, centered on the innermost 16x16 blocks and extending no more than 8 blocks outside of it (this is why the vanilla code adds 8 to the chunk coordinates times 16); some of the larger trees in TMCW require an additional margin ("chunkCache" is a cache of the 2x2 chunks being populated, with block accesses that go outside of it wrapping around, along with bounds-checking code that can be enabled when debugging):
// Makes 5 attempts per chunk of generating one mega tree
for (int i = 0; i < 5; ++i)
{
// Offset gives 3 blocks of extra space around trees; is normally nextInt(16) + 8
int x = blockX + decoratorRNG.nextInt(10) + 3;
int z = blockZ + decoratorRNG.nextInt(10) + 3;
int y = this.getTopBlock(chunkCache, x, z, true);
if (y > 0 && this.megaTreeGen.generate(chunkCache, x, y, z)) break;
}
Large structures, or something like a huge vein of ore, are generated chunk-by chunk by creating a map of the structure in memory and placing parts that intersect the current populated area (16x16 blocks, which is constrained via a bounding box that is passed in; as usual, the vanilla source is the best way to see how this works); cave generation works in a similar manner and this is how I can generate features over 300 blocks across with no issues (the cave generator actually carves through the raw terrain data used to initialize a chunk, i.e. the chunk doesn't even exist yet, nor may neighboring chunks).
Likewise, there is absolutely no sane reason for even the biggest modpack to require multiple gigabytes of RAM, simply none, unless you are using a mod with extreme render distance (TMCW uses less than 30 MB as a baseline and runs with only 512 MB allocated (note the charts of allocation rate and memory usage by object), a max-height Superflat world (256 layers) might benefit from more but that isn't a usual situation). Mods that add so many items that they run out of IDs? If you actually are adding that many blocks/items then most of them surely can't be unique enough to justify their existence (I can't picture more than 5-6 tiers of armor and tools; if you want unique properties that's what enchantments and NBT tags are for).
And even when people are using extreme render distances they shouldn't be requiring people own high end AMD Threadripper CPU's or anything similar, just to maintain stability or good frame rates in them. In older editions of the game people got by with just 2 cores, now to have a somewhat playable experience people are expected to have at least a quad core CPU that meets the current recommended requirement.
render distance and simulation distance are entirely separate settings, simulation affects the ticking radius of redstone and farms, as well as mob activity and dropped items and simulation is more dependent on how fast your CPU is.
The only thing the render distance should be affecting are objects visible to the player, mostly static or non moving objects, not the behaviour or the physics of the objects, redstone is what affects the movements of things like pistons and redstone lamps.
And whether blocks are solid or not are dependant on the type of block in question, is it a water or ice block? is it a lava or obsidian/basalt/cobblestone block? those are physics based and have nothing to do with the render distance and those are largely unaffected by mods, unless the mod is designed to mess with the physics of the game, possibly to troll a player.
I'm curious to know what the exact reasons are why people prefer versions as early as 1.6 or alpha 1
Sometimes people run older versions of the game for practicality, the game did become more demanding as updates changed the inner workings of it over time and even the system requirements did change over the years and we even saw the default memory cache increase from 1gb to 2gb in Java, which tells us Mojang is aware of this.
This may not seem like much until you take into consideration the amount of memory the OS uses and background apps, then the issue stacks up and Windows 11 reportedly is using about 4.5gb of RAM out of the box for many users on their PC's, which means people who only have 8gb of total RAM will not be having a good time, it will work but it will not perform as well as computers that have more memory, no matter how fast the GPU or CPU is, if the amount of memory is insufficient it will underperform and slow down and even on an Nmve SSD pagefile is not going to be as fast as RAM.
TheMasterCaver's concerns about the game using multi gigabytes of RAM are valid, the cases where a game would actually need to use this amount of RAM not including video memory which holds the frame buffer, texture, pixel, colour and filter information, shouldn't be very common. It is true that current gen consoles now have up to 16 gigabytes of RAM but on the Xbox series consoles this memory is shared, and it holds some of that information for the GPU to render and even then part of the RAM on consoles is reserved for the OS reducing the total available memory for the games. Not the case with PC's that have dedicated video cards that have their own set of memory called VRAM/GDDR5/6, where the majority of graphics related information is done on the video card.
And even when people are using extreme render distances they shouldn't be requiring people own high end AMD Threadripper CPU's or anything similar, just to maintain stability or good frame rates in them. In older editions of the game people got by with just 2 cores, now to have a somewhat playable experience people are expected to have at least a quad core CPU that meets the current recommended requirement.
Anything over 4 cores is still a big waste of money for the average user; the game uses a single main thread to process most game logic, and another main thread to actually render to the screen; true, there are more threads, even versions as old as 1.6.4 used over a dozen threads (see the lower-right graph) for the entire Java process, including garbage collection, file I/O, networking, etc but most of those threads do relatively little work or don't run all the time:
This is also why people (still) recommend CPUs with higher single-thread performance over more cores for gaming in general (plus, with hyperthreading you can get more use out of each core, if not the same as turning a quad-core CPU into an 8-core CPU):
I'm curious to know what the exact reasons are why people prefer versions as early as 1.6 or alpha 1
A big reason is the simplicity of the game; I've stated myself that I don't care for any of the additions since 1.6, and even of what 1.6 added (the first major update since I started playing) only coal blocks are indispensable (prior to 1.6 I only mined what coal I needed, as otherwise there is no practical way to cave for hours at a time while mining every bit of coal, averaging about 9 stacks per hour)
Here is a Reddit post from r/GoldenAgeMinecraft, focused on older versions, especially pre-release:
Many people also dislike changes in newer versions; a big sore point with many players is the splitting of the game into a separate client and server in singleplayer, which is why r/GoldenAgeMinecraft technically only allows up to 1.2.5, the last version before this apparently game-breaking change (yet before then the game was truly single-threaded (ignoring Java's own GC and other threads) and had issues like the "lag spike of death" because of this - even my first computer, with a CPU from 2005, had a dual-core CPU so there is no excuse for any large program, especially a game which requires stable performance, to only use a single thread. Many of the issues with the client-server model stem from Mojang never having fixed various bugs before then, such as lack of sending server-side data to the client, most of which I've fixed, otherwise, entity movement is not as smooth since they only update every 3 ticks, with the client extrapolating their movement).
Actually, a big issue with the client-server model is the fact that they don't run on the same timings, even in the same process; the internal server uses "System.currentTimeMillis", which is extremely crude, with a resolution of 1/64 of a second (15.625 ms, this may vary with the system) - the server will tick at 0 ms, 62.5 ms, 109.375 ms, 156.25 ms, etc (note that each tick took 62.5, 46.875, 46.875 ms when they should take 50 ms). The client uses a high-resolution timer (which is how it can keep a steady framerate) which ticks once every 50 ms with high stability (it uses "System.nanoTime", which appears to have a resolution of 100 ns or 0.0001 ms on my system). This desync and tick jitter manifests as variations in entity movement, most noticeable in a boat or minecart (the speed appears to increase and decrease at a regular interval and may come and go) and "block lag", where blocks briefly flicker in and out before breaking, which also comes and goes (it also seems to affect cobblestone more than other blocks, indicative of a timing issue; it is not actual server lag since the tick time is only 1-2 ms).
I fixed this by effectively ticking the server from the client, while still keeping it on a separate thread (i.e. the client increments the value formerly incremented by System.currentTimeMillis, which the server checks in an idle loop; this only works well of the client can maintain at least 20 FPS, otherwise the server can ticks twice per game tick, but so does the client, but that isn't an issue when your baseline FPS is 1000; likewise, average tick time for the client and server combined must not exceed 50 but it is only 2-3).
Of course, the game also needs more memory since the world is loaded on both the server and client but that isn't an issue since even at maximum settings the game runs fine with only 512 MB allocated, which is only half the default even back in 2013, and I've reduced it despite adding hundreds of new features (a common excuse for the game becoming more resource-intensive is more content but they don't understand how the game works or how much memory is actually needed for a block, item, entity, biome; the link shows what uses the most memory, loaded chunks (80% of a total of about 150 MB, meaning everything else uses only 30 MB), which is independent of how many unique blocks there are, only the loaded section height (blocks are stored as an 8 bit ID and 4 bit data, 12 bits per block, no matter what it is, whether air (0:0), stone (1:0), granite (1:1), etc. More block variants does affect compression efficiency when saving to disk; worlds created with TMCW are much larger than vanilla 1.6.4).
Also, while I've never run newer versions, especially the last few, which Mojang has made many claims of significant optimizations (overhauled rendering to use newer OpenGL features, much greater use of multithreading, etc) I have confirmation from others who have played TMCW that they still run much worse - even with performance mods (your mileage may vary, a long-standing issue with Java Edition is its use of OpenGL, which is not supported very well by non-NVIDIA GPUs, especially for older versions; Apple has even deprecated OpenGL entirely and may remove it, rendering the game unplayable on Macs without an emulator. This is also the cause of the biggest performance issue for any version - lag spikes/reduced FPS due to chunk updates, as even newer versions can't multithread the uploading of data to OpenGL (Optifine did try to force it but it was notorious for visual bugs, a fix even tells you to disable "threaded optimization", which seems like the exact thing you wouldn't want to do as this helps improve performance by using multiple threads in the driver):
Amazing work falls very short, I'm completely impressed at what you accomplished with TMCW, the game runs at 180+ fps on max settings (1.18 barely hits 40 on modest settings, 1.16.5 with a lot of performance mods gets close to that but with choppier feel) with all that extra content of incredible quality.
Anything over 4 cores is still a big waste of money for the average user; the game uses a single main thread to process most game logic, and another main thread to actually render to the screen; true, there are more threads, even versions as old as 1.6.4 used over a dozen threads (see the lower-right graph) for the entire Java process, including garbage collection, file I/O, networking, etc but most of those threads do relatively little work or don't run all the time:
This is also why people (still) recommend CPUs with higher single-thread performance over more cores for gaming in general (plus, with hyperthreading you can get more use out of each core, if not the same as turning a quad-core CPU into an 8-core CPU):
A big reason is the simplicity of the game; I've stated myself that I don't care for any of the additions since 1.6, and even of what 1.6 added (the first major update since I started playing) only coal blocks are indispensable (prior to 1.6 I only mined what coal I needed, as otherwise there is no practical way to cave for hours at a time while mining every bit of coal, averaging about 9 stacks per hour)
Here is a Reddit post from r/GoldenAgeMinecraft, focused on older versions, especially pre-release:
Many people also dislike changes in newer versions; a big sore point with many players is the splitting of the game into a separate client and server in singleplayer, which is why r/GoldenAgeMinecraft technically only allows up to 1.2.5, the last version before this apparently game-breaking change (yet before then the game was truly single-threaded (ignoring Java's own GC and other threads) and had issues like the "lag spike of death" because of this - even my first computer, with a CPU from 2005, had a dual-core CPU so there is no excuse for any large program, especially a game which requires stable performance, to only use a single thread. Many of the issues with the client-server model stem from Mojang never having fixed various bugs before then, such as lack of sending server-side data to the client, most of which I've fixed, otherwise, entity movement is not as smooth since they only update every 3 ticks, with the client extrapolating their movement).
Actually, a big issue with the client-server model is the fact that they don't run on the same timings, even in the same process; the internal server uses "System.currentTimeMillis", which is extremely crude, with a resolution of 1/64 of a second (15.625 ms, this may vary with the system) - the server will tick at 0 ms, 62.5 ms, 109.375 ms, 156.25 ms, etc (note that each tick took 62.5, 46.875, 46.875 ms when they should take 50 ms). The client uses a high-resolution timer (which is how it can keep a steady framerate) which ticks once every 50 ms with high stability (it uses "System.nanoTime", which appears to have a resolution of 100 ns or 0.0001 ms on my system). This desync and tick jitter manifests as variations in entity movement, most noticeable in a boat or minecart (the speed appears to increase and decrease at a regular interval and may come and go) and "block lag", where blocks briefly flicker in and out before breaking, which also comes and goes (it also seems to affect cobblestone more than other blocks, indicative of a timing issue; it is not actual server lag since the tick time is only 1-2 ms).
I fixed this by effectively ticking the server from the client, while still keeping it on a separate thread (i.e. the client increments the value formerly incremented by System.currentTimeMillis, which the server checks in an idle loop; this only works well of the client can maintain at least 20 FPS, otherwise the server can ticks twice per game tick, but so does the client, but that isn't an issue when your baseline FPS is 1000; likewise, average tick time for the client and server combined must not exceed 50 but it is only 2-3).
Of course, the game also needs more memory since the world is loaded on both the server and client but that isn't an issue since even at maximum settings the game runs fine with only 512 MB allocated, which is only half the default even back in 2013, and I've reduced it despite adding hundreds of new features (a common excuse for the game becoming more resource-intensive is more content but they don't understand how the game works or how much memory is actually needed for a block, item, entity, biome; the link shows what uses the most memory, loaded chunks (80% of a total of about 150 MB, meaning everything else uses only 30 MB), which is independent of how many unique blocks there are, only the loaded section height (blocks are stored as an 8 bit ID and 4 bit data, 12 bits per block, no matter what it is, whether air (0:0), stone (1:0), granite (1:1), etc. More block variants does affect compression efficiency when saving to disk; worlds created with TMCW are much larger than vanilla 1.6.4).
Also, while I've never run newer versions, especially the last few, which Mojang has made many claims of significant optimizations (overhauled rendering to use newer OpenGL features, much greater use of multithreading, etc) I have confirmation from others who have played TMCW that they still run much worse - even with performance mods (your mileage may vary, a long-standing issue with Java Edition is its use of OpenGL, which is not supported very well by non-NVIDIA GPUs, especially for older versions; Apple has even deprecated OpenGL entirely and may remove it, rendering the game unplayable on Macs without an emulator. This is also the cause of the biggest performance issue for any version - lag spikes/reduced FPS due to chunk updates, as even newer versions can't multithread the uploading of data to OpenGL (Optifine did try to force it but it was notorious for visual bugs, a fix even tells you to disable "threaded optimization", which seems like the exact thing you wouldn't want to do as this helps improve performance by using multiple threads in the driver):
Updating the game to run efficiently with a memory allocation of 512 megabytes could help but it all depends on render distances used, higher render distances mean more memory is needed to keep chunks loaded and active for players to interact with.
Even then it does make sense to not give the processor too much information to process at once otherwise that only worsens the lag spike issue and I would suspect this is regardless of the API used, OpenGL or not, you've said it yourself that chunk updates is one of the biggest reasons why lag spikes happen with Minecraft, it is a necessary function but it does need to be done more efficiently.
You are well aware of this, you do programming which means you're more knowledgeable about this than I am. But other people too often forget the significance of this, no matter how powerful and high end our hardware is, they still have limits and that is one of the fundamental reasons why it's fair and logical to expect software developers to optimize their programs to run smoothly even on some old hardware. It is also important to ensure people get the most use out of their hardware before it eventually breaks, to reduce the ewaste problem.
I can see why people would like older versions of the game, it is true that some of them do it because they prefer not having as many additions to the game and for some of them they may appreciate the challenge, as in some ways the game has gotten easier, especially with the addition of things like Shulker boxes and tridents.
But I would imagine some other people do it because they want the game to work on older or weaker than average computers, perhaps they cannot afford an upgrade, or perhaps they do not care and just want the game to work smoothly on the hardware they already have.
The Meaning of Life, the Universe, and Everything.
Join Date:
8/20/2015
Posts:
58
Member Details
There are a lot of cutoff points in Minecraft's version history that people tend to stick around. For a really simplistic and nostalgic playstyle, there are the Alpha versions. For ultimate nostalgia survivalists, there's Beta 1.2_02, the last update before beds were added. Beta 1.7.3 is the last update before the adventure update, for those who didn't like the additions of hunger and the world gen changes. Official release 1.2.5 is seen as the last version of the Golden Age. 1.5 is kinda when I hopped into Java, so for me that's sort of the definitive edition of the game. 1.8 is for those that prefer the old combat system and don't like Microsoft. 1.12 is for modders, because 1.13 kinda screwed a lot of the modding community and a lot of big modpacks stopped development at that version. I've seen another big cutoff point with players saying they won't play past 1.16 for a lot of reasons, like the new versions are too laggy or change the game too much. 1.19 is obviously another huge cutoff point because certain Microsoft-related reasons. Personally I still play the modern versions, but I have been enjoying beta 1.7.3 a lot recently. 1.8 is another favorite of mine. And the version that TheMasterCaver plays.
Don't forget about 1.7, which actually caused quite a bit of complaints back in the day, even if most players got used to the world generation changes, specifically, the way biomes now generate in large areas of the same few biomes with similar properties:
Likewise, seeds for "all biomes within 2000 blocks", or some other reasonably small distance, were extremely popular (given that I explore about 100 chunks per play session this means it would take close to two years to explore everything within a 4000x4000 area, so even this may be considered to be too much for some players). Even if you relax the requirements and just include at least one of every major biome category you'd be hard-pressed to find a suitable seed due to the way biomes clump together:
Over half a million views. I guess it's safe to say that this has become the most popular seed in the 1.7+ era.
The desert areas are 4000-5000 blocks across, larger than any of my worlds other than my first world (World1, about 6600x6600 blocks), with 180 days of playtime, even the smaller snowy areas are still around 2000 blocks across, and at least as large as two-thirds of the worlds I've played on (this is about the same size as the large snowy area to the west in in my first world, which are actually an early form of "climate zone" and 1.7 used the same code, modified to add "hot" areas) - and each only has 2-3 common biomes, plus the occasional rare variant if you are lucky; for comparison, I've found 48 "regular" biomes in my current world (TMCWv5), many more than once (even then, I've found far from every biome, in fact, I haven't even found an Extreme Hills, despite being one of the most common biomes, but there are plenty of similar biomes (terrain or emeralds):
The Meaning of Life, the Universe, and Everything.
Join Date:
8/20/2015
Posts:
58
Member Details
And I remember they reduced the amount of caves in the world at 1.7, correct? I remember you showing me something like that a week or two ago. I thought amplified worlds were really cool, and the new biomes and wood types, at the time. Although certain biomes were impossible to find and caves were lessened.
And I remember they reduced the amount of caves in the world, correct? I remember you showing me something like that a week or two ago.
Indeed, that is a major reason why I never updated past 1.6.4, though I didn't mention it since most players didn't seem to be bothered (if anything I saw more people saying that they liked the changes; example). Even after 1.18 I doubt that caving is something many players spend much time at all doing so they are more likely to get in the way of building and traveling, and even branch-mining (even I branch-mine to get resources early on because it is more efficient for rarer resources and I want to save caving until the "end game", but I've never had issues mining at bedrock level, example, and this is a modded world with over twice the volume of caves of vanilla 1.6.4 (if not the same as just doubling vanilla cave generation).
The Meaning of Life, the Universe, and Everything.
Join Date:
8/20/2015
Posts:
58
Member Details
You're probably right about players not spending much time caving in these new versions. There's really not much need for mining coal often with fortune III, iron can be easily farmed, redstone is easily obtained enough so that most people will never take many trips to get it, and diamonds can be found in near every structure on the surface. I think Mojang tried to make caving more interesting by adding the new variants, but I have noticed myself in my current-update survival world that I have never really seen them myself despite them being out for two years or so, and that's because it's not necessary.
Personally I enjoy the old caves just fine and found it very fun to go caving, especially in beta.
Sure it has its flaws but there is something about this version I just like
The villages without villagers give a strange abandoned vibe to the game and makes you feel like youre not fully alone
Heck sometimes I even turn around to see if anybodys out there, yeah I sound dumb but the human mind works really weirdly
Beta 1.8 is often regarded as one of the best and most significant versions of Minecraft. It introduced several notable features and improvements to the game, making it a favorite among many players.
There is an alternative to NEI which is called "Too Many Items". It shows all items, can be turned off/on in game by pressing "O".
Somehow i missed this comment only seeing it now.
Nobody uses Too Many Items in 1.7.10 because NEI was the far improved successor to Too Many Items. TMI was good from like 1.2.5 to around 1.4 modded Minecraft but when NEI came it was the best one of its time its just that it gets laggy by how it stores information when you start going over a certain threshold of mods.
i mentioned previously exutils drums store bad information and cause the dictionary to become slow. I talked to the creator of Gregtech about this. This is not NEI's fault its exutils fault and is only one example.
NEI has its short comings but everything modded in 1.7.10 is centered around NEI not TMI and NEI has the most compat with the biggest modded version to date.
There is a mod that improves its lag i forget the name atm.
GTNH have been maintaining the actual mod NEI itself with their own modernized continuation of the mod which is highly bug fixed and very performant because the original dev long since abandoned it. Even if you don't play GTNH you can download the GTNH port of NEI and use it in any 1.7.10 modpack which i highly recommend due to its performance.
They even added bookmark like features to the GTNH version of NEI inspired by NEI's more modern successor JEI which came in Minecraft 1.8 and traditional NEI does not have this ability.
Side note seeing as i am on a tangent JEI never really took of until around 1.12 either because NEI was still popular in 1.8 and beyond that it got continued on be several different people all the big packs still had it,
Because 1.8 broke the game so people interested in modded Minecraft stayed on 1.7.10 for a long time until 1.12 came as we were in a massive lull at this period of time.
Outside of some small packs or making your own but there was a dry period for quite a while where most of the modded populace stayed in 1.7 until we started recovering from 1.8 breaking the game when 1.12 came and gained traction again.
Rollback Post to RevisionRollBack
''If you don't dig straight down in Minecraft then you're doing it wrong.''
i like 1.16.5, because it uses java 8, but its pretty modern
For me it is 1.7.10 because it is easier to make mods for 1.7.10
My mod with manually registered ItemBlocks of technical blocks:
[mod]obtain-blocks-mod[/mod
there is no "best" version of minecraft, but people can have opinions about it
NamePerson was_taken
Minecraft Alpha it added redstone, nether, ghasts,chickens, cows. Added real meat and much more
There is an alternative to NEI which is called "Too Many Items". It shows all items, can be turned off/on in game by pressing "O".
My mod with manually registered ItemBlocks of technical blocks:
[mod]obtain-blocks-mod[/mod
Some mods (NEI) might be more problematic but it is a fact that something was broken in 1.7.10, I recall that that it had lots of lag spikes/freezes (just vanilla) and there is a bug report regarding the issue (I did see a lot of warnings about "client side chunk ticking" taking too long); maybe there is a mod that fixes this issue (FoamFix, which I should note claims that even with just itself Forge runs worse than vanilla, so Forge is also the problem):
Otherwise, IMO most mods are extremely sloppily coded, just as bad or worse than newer vanilla versions; "it works" is enough with no time spent on optimizations unless they are absolutely necessary, in addition to how modloaders work (this can be the only reason why I've been able to add at least 500+ features to 1.6.4 with no performance impact (aside from stuff like biomes of massive trees, which are harder to render, but not the actual game/Java code itself, and if a computer from 2005-6 (system specs, and yes, 1.8 ran that badly) could render them at 100 FPS (no Optifine, otherwise only leaves had to be Fast) then any recent computer shouldn't have a problem) - in fact, despite being more complex than 1.19 world generation is twice as fast as vanilla 1.6.4).
World generation mods are particularly notorious for "cascading worldgen", an issue which is nonexistent, and can't even actually happen in TMCW, outside of a few remaining vanilla classes which don't have the issue:
https://www.reddit.com/r/feedthebeast/comments/5x0twz/investigating_extreme_worldgen_lag/
This could easily be avoided with some basic knowledge of how world generation works; all small features/decorations must be generated entirely within a 2x2 chunk area, centered on the innermost 16x16 blocks and extending no more than 8 blocks outside of it (this is why the vanilla code adds 8 to the chunk coordinates times 16); some of the larger trees in TMCW require an additional margin ("chunkCache" is a cache of the 2x2 chunks being populated, with block accesses that go outside of it wrapping around, along with bounds-checking code that can be enabled when debugging):
Large structures, or something like a huge vein of ore, are generated chunk-by chunk by creating a map of the structure in memory and placing parts that intersect the current populated area (16x16 blocks, which is constrained via a bounding box that is passed in; as usual, the vanilla source is the best way to see how this works); cave generation works in a similar manner and this is how I can generate features over 300 blocks across with no issues (the cave generator actually carves through the raw terrain data used to initialize a chunk, i.e. the chunk doesn't even exist yet, nor may neighboring chunks).
Likewise, there is absolutely no sane reason for even the biggest modpack to require multiple gigabytes of RAM, simply none, unless you are using a mod with extreme render distance (TMCW uses less than 30 MB as a baseline and runs with only 512 MB allocated (note the charts of allocation rate and memory usage by object), a max-height Superflat world (256 layers) might benefit from more but that isn't a usual situation). Mods that add so many items that they run out of IDs? If you actually are adding that many blocks/items then most of them surely can't be unique enough to justify their existence (I can't picture more than 5-6 tiers of armor and tools; if you want unique properties that's what enchantments and NBT tags are for).
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?
And even when people are using extreme render distances they shouldn't be requiring people own high end AMD Threadripper CPU's or anything similar, just to maintain stability or good frame rates in them. In older editions of the game people got by with just 2 cores, now to have a somewhat playable experience people are expected to have at least a quad core CPU that meets the current recommended requirement.
render distance and simulation distance are entirely separate settings, simulation affects the ticking radius of redstone and farms, as well as mob activity and dropped items and simulation is more dependent on how fast your CPU is.
The only thing the render distance should be affecting are objects visible to the player, mostly static or non moving objects, not the behaviour or the physics of the objects, redstone is what affects the movements of things like pistons and redstone lamps.
And whether blocks are solid or not are dependant on the type of block in question, is it a water or ice block? is it a lava or obsidian/basalt/cobblestone block? those are physics based and have nothing to do with the render distance and those are largely unaffected by mods, unless the mod is designed to mess with the physics of the game, possibly to troll a player.
For me I like 1.6.4
1.7.10, 1.6.4, Beta 1.7.3 and Alpha 1.1.1
I'm curious to know what the exact reasons are why people prefer versions as early as 1.6 or alpha 1
Sometimes people run older versions of the game for practicality, the game did become more demanding as updates changed the inner workings of it over time and even the system requirements did change over the years and we even saw the default memory cache increase from 1gb to 2gb in Java, which tells us Mojang is aware of this.
This may not seem like much until you take into consideration the amount of memory the OS uses and background apps, then the issue stacks up and Windows 11 reportedly is using about 4.5gb of RAM out of the box for many users on their PC's, which means people who only have 8gb of total RAM will not be having a good time, it will work but it will not perform as well as computers that have more memory, no matter how fast the GPU or CPU is, if the amount of memory is insufficient it will underperform and slow down and even on an Nmve SSD pagefile is not going to be as fast as RAM.
TheMasterCaver's concerns about the game using multi gigabytes of RAM are valid, the cases where a game would actually need to use this amount of RAM not including video memory which holds the frame buffer, texture, pixel, colour and filter information, shouldn't be very common. It is true that current gen consoles now have up to 16 gigabytes of RAM but on the Xbox series consoles this memory is shared, and it holds some of that information for the GPU to render and even then part of the RAM on consoles is reserved for the OS reducing the total available memory for the games. Not the case with PC's that have dedicated video cards that have their own set of memory called VRAM/GDDR5/6, where the majority of graphics related information is done on the video card.
Anything over 4 cores is still a big waste of money for the average user; the game uses a single main thread to process most game logic, and another main thread to actually render to the screen; true, there are more threads, even versions as old as 1.6.4 used over a dozen threads (see the lower-right graph) for the entire Java process, including garbage collection, file I/O, networking, etc but most of those threads do relatively little work or don't run all the time:
This is also why people (still) recommend CPUs with higher single-thread performance over more cores for gaming in general (plus, with hyperthreading you can get more use out of each core, if not the same as turning a quad-core CPU into an 8-core CPU):
https://www.reddit.com/r/buildapc/comments/tf3d7g/is_the_6_cores_are_enough_for_gaming_era_over/
A big reason is the simplicity of the game; I've stated myself that I don't care for any of the additions since 1.6, and even of what 1.6 added (the first major update since I started playing) only coal blocks are indispensable (prior to 1.6 I only mined what coal I needed, as otherwise there is no practical way to cave for hours at a time while mining every bit of coal, averaging about 9 stacks per hour)
Here is a Reddit post from r/GoldenAgeMinecraft, focused on older versions, especially pre-release:
https://www.reddit.com/r/GoldenAgeMinecraft/comments/uynfhh/whats_the_appeal_of_golden_age_minecraft_what_do/
Many people also dislike changes in newer versions; a big sore point with many players is the splitting of the game into a separate client and server in singleplayer, which is why r/GoldenAgeMinecraft technically only allows up to 1.2.5, the last version before this apparently game-breaking change (yet before then the game was truly single-threaded (ignoring Java's own GC and other threads) and had issues like the "lag spike of death" because of this - even my first computer, with a CPU from 2005, had a dual-core CPU so there is no excuse for any large program, especially a game which requires stable performance, to only use a single thread. Many of the issues with the client-server model stem from Mojang never having fixed various bugs before then, such as lack of sending server-side data to the client, most of which I've fixed, otherwise, entity movement is not as smooth since they only update every 3 ticks, with the client extrapolating their movement).
Actually, a big issue with the client-server model is the fact that they don't run on the same timings, even in the same process; the internal server uses "System.currentTimeMillis", which is extremely crude, with a resolution of 1/64 of a second (15.625 ms, this may vary with the system) - the server will tick at 0 ms, 62.5 ms, 109.375 ms, 156.25 ms, etc (note that each tick took 62.5, 46.875, 46.875 ms when they should take 50 ms). The client uses a high-resolution timer (which is how it can keep a steady framerate) which ticks once every 50 ms with high stability (it uses "System.nanoTime", which appears to have a resolution of 100 ns or 0.0001 ms on my system). This desync and tick jitter manifests as variations in entity movement, most noticeable in a boat or minecart (the speed appears to increase and decrease at a regular interval and may come and go) and "block lag", where blocks briefly flicker in and out before breaking, which also comes and goes (it also seems to affect cobblestone more than other blocks, indicative of a timing issue; it is not actual server lag since the tick time is only 1-2 ms).
I fixed this by effectively ticking the server from the client, while still keeping it on a separate thread (i.e. the client increments the value formerly incremented by System.currentTimeMillis, which the server checks in an idle loop; this only works well of the client can maintain at least 20 FPS, otherwise the server can ticks twice per game tick, but so does the client, but that isn't an issue when your baseline FPS is 1000; likewise, average tick time for the client and server combined must not exceed 50 but it is only 2-3).
Of course, the game also needs more memory since the world is loaded on both the server and client but that isn't an issue since even at maximum settings the game runs fine with only 512 MB allocated, which is only half the default even back in 2013, and I've reduced it despite adding hundreds of new features (a common excuse for the game becoming more resource-intensive is more content but they don't understand how the game works or how much memory is actually needed for a block, item, entity, biome; the link shows what uses the most memory, loaded chunks (80% of a total of about 150 MB, meaning everything else uses only 30 MB), which is independent of how many unique blocks there are, only the loaded section height (blocks are stored as an 8 bit ID and 4 bit data, 12 bits per block, no matter what it is, whether air (0:0), stone (1:0), granite (1:1), etc. More block variants does affect compression efficiency when saving to disk; worlds created with TMCW are much larger than vanilla 1.6.4).
Also, while I've never run newer versions, especially the last few, which Mojang has made many claims of significant optimizations (overhauled rendering to use newer OpenGL features, much greater use of multithreading, etc) I have confirmation from others who have played TMCW that they still run much worse - even with performance mods (your mileage may vary, a long-standing issue with Java Edition is its use of OpenGL, which is not supported very well by non-NVIDIA GPUs, especially for older versions; Apple has even deprecated OpenGL entirely and may remove it, rendering the game unplayable on Macs without an emulator. This is also the cause of the biggest performance issue for any version - lag spikes/reduced FPS due to chunk updates, as even newer versions can't multithread the uploading of data to OpenGL (Optifine did try to force it but it was notorious for visual bugs, a fix even tells you to disable "threaded optimization", which seems like the exact thing you wouldn't want to do as this helps improve performance by using multiple threads in the driver):
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?
Updating the game to run efficiently with a memory allocation of 512 megabytes could help but it all depends on render distances used, higher render distances mean more memory is needed to keep chunks loaded and active for players to interact with.
Even then it does make sense to not give the processor too much information to process at once otherwise that only worsens the lag spike issue and I would suspect this is regardless of the API used, OpenGL or not, you've said it yourself that chunk updates is one of the biggest reasons why lag spikes happen with Minecraft, it is a necessary function but it does need to be done more efficiently.
You are well aware of this, you do programming which means you're more knowledgeable about this than I am. But other people too often forget the significance of this, no matter how powerful and high end our hardware is, they still have limits and that is one of the fundamental reasons why it's fair and logical to expect software developers to optimize their programs to run smoothly even on some old hardware. It is also important to ensure people get the most use out of their hardware before it eventually breaks, to reduce the ewaste problem.
I can see why people would like older versions of the game, it is true that some of them do it because they prefer not having as many additions to the game and for some of them they may appreciate the challenge, as in some ways the game has gotten easier, especially with the addition of things like Shulker boxes and tridents.
But I would imagine some other people do it because they want the game to work on older or weaker than average computers, perhaps they cannot afford an upgrade, or perhaps they do not care and just want the game to work smoothly on the hardware they already have.
There are a lot of cutoff points in Minecraft's version history that people tend to stick around. For a really simplistic and nostalgic playstyle, there are the Alpha versions. For ultimate nostalgia survivalists, there's Beta 1.2_02, the last update before beds were added. Beta 1.7.3 is the last update before the adventure update, for those who didn't like the additions of hunger and the world gen changes. Official release 1.2.5 is seen as the last version of the Golden Age. 1.5 is kinda when I hopped into Java, so for me that's sort of the definitive edition of the game. 1.8 is for those that prefer the old combat system and don't like Microsoft. 1.12 is for modders, because 1.13 kinda screwed a lot of the modding community and a lot of big modpacks stopped development at that version. I've seen another big cutoff point with players saying they won't play past 1.16 for a lot of reasons, like the new versions are too laggy or change the game too much. 1.19 is obviously another huge cutoff point because certain Microsoft-related reasons. Personally I still play the modern versions, but I have been enjoying beta 1.7.3 a lot recently. 1.8 is another favorite of mine. And the version that TheMasterCaver plays.
Don't forget about 1.7, which actually caused quite a bit of complaints back in the day, even if most players got used to the world generation changes, specifically, the way biomes now generate in large areas of the same few biomes with similar properties:
https://www.minecraftforum.net/forums/minecraft-java-edition/recent-updates-and-snapshots/382597-1-7-horrid-world-generation
The number of replies is comparable to the "1.17 update opinion thread", actually, probably more since 1/3 of all posts were deleted in 2019.
Likewise, seeds for "all biomes within 2000 blocks", or some other reasonably small distance, were extremely popular (given that I explore about 100 chunks per play session this means it would take close to two years to explore everything within a 4000x4000 area, so even this may be considered to be too much for some players). Even if you relax the requirements and just include at least one of every major biome category you'd be hard-pressed to find a suitable seed due to the way biomes clump together:
Of course, 1.18 is no better, or even worse:
The desert areas are 4000-5000 blocks across, larger than any of my worlds other than my first world (World1, about 6600x6600 blocks), with 180 days of playtime, even the smaller snowy areas are still around 2000 blocks across, and at least as large as two-thirds of the worlds I've played on (this is about the same size as the large snowy area to the west in in my first world, which are actually an early form of "climate zone" and 1.7 used the same code, modified to add "hot" areas) - and each only has 2-3 common biomes, plus the occasional rare variant if you are lucky; for comparison, I've found 48 "regular" biomes in my current world (TMCWv5), many more than once (even then, I've found far from every biome, in fact, I haven't even found an Extreme Hills, despite being one of the most common biomes, but there are plenty of similar biomes (terrain or emeralds):
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?
And I remember they reduced the amount of caves in the world at 1.7, correct? I remember you showing me something like that a week or two ago. I thought amplified worlds were really cool, and the new biomes and wood types, at the time. Although certain biomes were impossible to find and caves were lessened.
Indeed, that is a major reason why I never updated past 1.6.4, though I didn't mention it since most players didn't seem to be bothered (if anything I saw more people saying that they liked the changes; example). Even after 1.18 I doubt that caving is something many players spend much time at all doing so they are more likely to get in the way of building and traveling, and even branch-mining (even I branch-mine to get resources early on because it is more efficient for rarer resources and I want to save caving until the "end game", but I've never had issues mining at bedrock level, example, and this is a modded world with over twice the volume of caves of vanilla 1.6.4 (if not the same as just doubling vanilla cave generation).
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?
You're probably right about players not spending much time caving in these new versions. There's really not much need for mining coal often with fortune III, iron can be easily farmed, redstone is easily obtained enough so that most people will never take many trips to get it, and diamonds can be found in near every structure on the surface. I think Mojang tried to make caving more interesting by adding the new variants, but I have noticed myself in my current-update survival world that I have never really seen them myself despite them being out for two years or so, and that's because it's not necessary.
Personally I enjoy the old caves just fine and found it very fun to go caving, especially in beta.
Beta 1.8 is often regarded as one of the best and most significant versions of Minecraft. It introduced several notable features and improvements to the game, making it a favorite among many players.
i gotta give it to old_alpha rd-132211
NamePerson was_taken
Somehow i missed this comment only seeing it now.
Nobody uses Too Many Items in 1.7.10 because NEI was the far improved successor to Too Many Items. TMI was good from like 1.2.5 to around 1.4 modded Minecraft but when NEI came it was the best one of its time its just that it gets laggy by how it stores information when you start going over a certain threshold of mods.
i mentioned previously exutils drums store bad information and cause the dictionary to become slow. I talked to the creator of Gregtech about this. This is not NEI's fault its exutils fault and is only one example.
NEI has its short comings but everything modded in 1.7.10 is centered around NEI not TMI and NEI has the most compat with the biggest modded version to date.
There is a mod that improves its lag i forget the name atm.
GTNH have been maintaining the actual mod NEI itself with their own modernized continuation of the mod which is highly bug fixed and very performant because the original dev long since abandoned it. Even if you don't play GTNH you can download the GTNH port of NEI and use it in any 1.7.10 modpack which i highly recommend due to its performance.
They even added bookmark like features to the GTNH version of NEI inspired by NEI's more modern successor JEI which came in Minecraft 1.8 and traditional NEI does not have this ability.
Side note seeing as i am on a tangent JEI never really took of until around 1.12 either because NEI was still popular in 1.8 and beyond that it got continued on be several different people all the big packs still had it,
Because 1.8 broke the game so people interested in modded Minecraft stayed on 1.7.10 for a long time until 1.12 came as we were in a massive lull at this period of time.
Outside of some small packs or making your own but there was a dry period for quite a while where most of the modded populace stayed in 1.7 until we started recovering from 1.8 breaking the game when 1.12 came and gained traction again.