So I found out the reason why the Fractionating Stills making Refined Fuel were so expensive to run - they are meant to be balanced with Compression Dynamos. I took the 4 Generators (the Integrated Dynamics ones) and upgraded them to the dynamos, added Hardened, Reinforced and Signalum upgrades to them, Fuel Catalyzer (produces more energy per unit of fuel burned) and Closed Loop Cooling augments, plus 4 Auxiliary Transmission Coils. This makes each Dynamo produce 5625 RF/t max, and with the except of around 100 mB, does not consume any coolant. For this I made enough buckets of Gelid Cryotheum to fill each dynamo's coolant tank (each holds 4000 mB).
This fluid is made in a Magma Crucible by melting Cryotheum Dust, which is made with 2 Blizz Powder, 1 Redstone and 1 Snowball. The powder is obtained by pulverizing the rods, which in this case you get by running the Pristine Thermal Elemental Matter through the Loot Fabricator. In a normal pack you would need to either go and hunt Blizzes at night in snow and ice biomes, or fluid transpose snowballs with TE's version of XP, Essence of Knowledge.
After letting the dynamos' power storage buffers fill up completely, I switched the entire line of Fractionating Stills back on. I am currently standing on top of the dynamos, watching their power outputs gradually ramp up to their max at 5625 RF/t each. They just hit 2000 RF/t. So I can definitely handle running all 4 of them now. I plan on building more of the dynamos, up to a max of 8, which will put the total output to 45000 RF/t. Adding one more will put the total over 50K, and a small amount (625 RF/t) will be lost.
With the recent download release of my main world, I am finally getting to grips with MCA and getting used to using it. Areas I've only visited once/corrupted chunks I have finally been able to remove, though keeping some alpha beta chunk walls as they tell a story of the world as I was reminded by a friend on discord.
Long story short, I turned my 7GB world to s 1.56Gb world, but don't worry, I still have a "before copy".
They also suggested after I showed it, abut merging in my original world, world1; that pre-dates the main world by a month. I was reluctant though. I've played this world for slightly longer - but a lot less frequently. It's always been an on/off world. Less resources therefore for an idea which originally was to build a home on several mountain tops and connect them with sky bridges. I gave up after three to start what is now my main world. Returning several months later to only work on turning the huge cavernous crater hole between mountains ~1 & #2 into an underground home, done so on/off for the last 13 years when I felt an urge only.
From the top of the very cube-sized 2010 fort, built on a mountain exactly as it was, the next day I built a wooden bridge across to the next mountain top,
The next home being very 2010 basic, a elongated wooden hut with a dirt roof with glass blocks here and there as skyiights, Nothing inside except a mock stove, a double chest and the cobble floor it sits on.
The next mountain was far way so I built a cobble skybridge, though I wanted it to be glass. Why I didn't think to have in-between rings to put the lighta I knew wopuldn't stick to glass, I'll never know. In hindsight the next fort was just as ill-though out with little space inside.
After several months of giving up and now starting what would become my main world, I returned to the world concentrating on that huge cavernous hole mentioned turning it into an underground home on/off until this day.
I wasn't familiar with how to copy chunks from one world to paste in another in MCA, at first it seemed not to work. Today after watching a tutorial and realising what I did wrong, I did so on a COPY of the optimized world. Carefully selecting a region I could put it, considering the existing terrain and be near my main world work but still further enough to travel. (For the underground home I had to do layer by latyer, there were mistakes and a few re-tries.)
After several tries the last time I had the exact co-ords, unlike last time and flew until it came into view:
In the underground home on level #1 there was a little bit more room in the storage area:
Everything is more or less there, there are a few anomolies such as a blank wall instead of the corridor that led to the "nice room" as it was called back then:
(Original pics):
That can always be re-created though.
The question now is do I make this permanent? The only maybe illegal aspect is just the buildings existing in this world. All the buildingd and resources are still legit and were gained over years in survival, they were all still built in survival. But in this , a copy of my main world I have all the resources I could ever need to make this world 1 inside world 2 the best it can ever be?!
Or, do I just keep it as a separate world that just happens to have buildings from my original worl;d in?
Either way, I took a screenshot in my main world for co-ords of where the castle portal comes out in the nether, so that in the copy I can build a porta and connect the two areas. In the copy world, although not in the exact same spot, i re-made the portal in the same general area however, in the underground home:
I came out at level 36 had to be at level 95., then dug a tunnel to the castle portal, which actually wasn't that far away. It's one longish flight of dug steps, then just one tunnel:
And that right there is the portal to the castle at the main part of my world.
So I'm undecided. Even though it's a world copy it seems strange to have these original world builds on my main world, yet the prospect of maybe doing what I always dreamed with them with so much resource resources of my main world makes it irrisistable. Instead of leaving the overland original builds as they were in 2010 for nostalgia (WHich they still can on the actual world1) I could make them what I wanted, not have a cube fort beceuse that was the limit of my skills in 2010. Maybe even have that glass tunnel and improve the wooden hut?
So do I keep this change permanently or just as a separate world that happens to also have my main world..
Sounds like your world went through something similar to what mine did? I took it from 1.10 to 1.19 and let the chunk blending of 1.18 allow me to purge a lot of the central region away (which was previously pre-generated to avoid chunk border transitions between pre-1.6 and post-1.7 terrain). Likewise, my world went down from around a dozen GB to somewhere between 1 GB and 2 GB. Which was a culture shock because both of my hardcore worlds are also about that size, so it made my decade-plus running world seem... less accomplished? I don't know, haha.
Anyway, I hope you have fun breaking new ground! I was, at least in the short time I was at it. Then my hardcore worlds took my attention away from that world for now. So I guess I'm still always breaking new ground, haha.
As for keeping the old world in the new world or not, that's up to you. I think when you've got a world as long running and established and resource rich as this, the stance of "it's cheating" might be technically correct, but sometimes that's not the most important thing. The material cost and time setback versus the rest of the world is probably approaching nothing? Meaning outside the different terrain you're not gaining something you couldn't easily have gained, so you're just doing it to link two worlds. If you want to feel fair for survival/resource sake, discard some resources as a compensation cost. It can be a "rough guess" of similar things that are being added to the world, or maybe it's just an ore cost. Up to you. When 1.7 released, my then-much younger world was one where I went into McEdit and added very long tunnels in the nether. This was, formally speaking, cheating for a world where I only ever played "legit" (meaning all blocks obtained and placed were done so in survival gameplay). I did this because I didn't like the chunk walls between 1.6 and 1.7, so I pre-generated a large area around spawn (see why my world was over 10 GB?), and then updated, with the idea being I'd use the nether to access the 1.7 lands. Problem was... it was so far away. So I used this as a workaround of sorts to "link two worlds together as one" world. See also why I loved 1.18's chunk blending feature so much? It removed the need for this entirely.
Of course, keep the original separate backups, but yeah once you start moving forward with it this way you'll be tied to it. I'd say do whichever you prefer.
Oh, and it's easy to look back on past decisions and go "why didn't I just do it this way instead" when hindsight is 20-20 as they say. There's actually multiple ways to do things and sometimes we just go with whatever one we feel like in the given moment, and sometimes there's no deeper reason to that so no point on dwelling on it. So don't beat your past self up too much.
Seeing those older locations sort of makes me want to start a new world (gasp!) in an older version. It's funny how my whole thing used to be not starting new worlds and sticking with one, but this has sort of been the year where I've started new worlds.
I still have fond memories of when I first tried the game, maybe because it was with the PC Gamer demo (based on beta 1.3?) and that's the only stuff I don't still have so it only exists in memories. My first world from when I formally got the game at release version 1.2.5 shortly after I still have. I recall three or four houses I tried making in the demo, but the time limit meant I never finished any of them (I'm aware of ways to get around it now, but back then I was only using it to try the game and I was set on buying it if I liked it, and not buying it if I didn't, so there was no need). But it'd be interesting to find that seed and create it in beta 1.3 and see if I can find the locations for all of the houses I attempted (two were very near spawn). Not that any of them got very far.
One in particular was barely started and I was killed by a skeleton trying to lay the foundation and porch after nightfall started coming, and I believe it was outside my render distance shooting me? That might have been the first time I died to a mob in Minecraft.
The two that made it farthest had walls but I never had a completed house.
So I'm undecided. Even though it's a world copy it seems strange to have these original world builds on my main world, yet the prospect of maybe doing what I always dreamed with them with so much resource resources of my main world makes it irrisistable. Instead of leaving the overland original builds as they were in 2010 for nostalgia (WHich they still can on the actual world1) I could make them what I wanted, not have a cube fort beceuse that was the limit of my skills in 2010. Maybe even have that glass tunnel and improve the wooden hut?
So do I keep this change permanently or just as a separate world that happens to also have my main world..
I've dealt with similar situations although I couldn't directly copy the relevant structures into my main world as they were originally made in modded worlds. My approach has been to either reconstruct the structure as close to 1:1 accuracy as possible, or to build something similar in layout and appearance for an "inspired by" sort of thing.
Anyway, I hope you have fun breaking new ground! I was, at least in the short time I was at it. Then my hardcore worlds took my attention away from that world for now. So I guess I'm still always breaking new ground, haha.
As for keeping the old world in the new world or not, that's up to you. I think when you've got a world as long running and established and resource rich as this, the stance of "it's cheating" might be technically correct, but sometimes that's not the most important thing. The material cost and time setback versus the rest of the world is probably approaching nothing? Meaning outside the different terrain you're not gaining something you couldn't easily have gained, so you're just doing it to link two worlds. If you want to feel fair for survival/resource sake, discard some resources as a compensation cost. It can be a "rough guess" of similar things that are being added to the world, or maybe it's just an ore cost. Up to you.
I personally don't agree with the technically correct aspect, all I'm really gaining is the tools and armor I already had from my main world. I still grinded, built and earnt every one of the structures I built in survival. The structures being in this mworld is more of a "Technicality" as I see it.
For the moment I think I'm leaning more to keeping it as a "separate world" for now and just see what I can do with it, still in survival, with more advanced tools/equipment. I did find some nice diamond equipment in a chest, but not enchanted though, just regular so that was nice.
Oh, and it's easy to look back on past decisions and go "why didn't I just do it this way instead" when hindsight is 20-20 as they say. There's actually multiple ways to do things and sometimes we just go with whatever one we feel like in the given moment, and sometimes there's no deeper reason to that so no point on dwelling on it. So don't beat your past self up too much.
Oh I don't, it was just a much simpler time, with a lot less blocks and ways of building back then in alpha/beta.
I still have fond memories of when I first tried the game, maybe because it was with the PC Gamer demo (based on beta 1.3?) and that's the only stuff I don't still have so it only exists in memories. My first world from when I formally got the game at release version 1.2.5 shortly after I still have. I recall three or four houses I tried making in the demo, but the time limit meant I never finished any of them (I'm aware of ways to get around it now, but back then I was only using it to try the game and I was set on buying it if I liked it, and not buying it if I didn't, so there was no need). But it'd be interesting to find that seed and create it in beta 1.3 and see if I can find the locations for all of the houses I attempted (two were very near spawn). Not that any of them got very far.
One in particular was barely started and I was killed by a skeleton trying to lay the foundation and porch after nightfall started coming, and I believe it was outside my render distance shooting me? That might have been the first time I died to a mob in Minecraft.
The two that made it farthest had walls but I never had a completed house.
I think I've done similar with a few late BETA worlds, in that using the seed and seeing how I would build it differently ; now knowing what I know.
I've dealt with similar situations although I couldn't directly copy the relevant structures into my main world as they were originally made in modded worlds. My approach has been to either reconstruct the structure as close to 1:1 accuracy as possible, or to build something similar in layout and appearance for an "inspired by" sort of thing.
Given that it's modded. I think reconstruction is fair game given the limitations of vanilla.
Small changes already, from this:
To this:
Also fixing up this very dilapidated corridor:
Just re-installing the redstone lamps and reconnecting the redstone above the ceiling and making sure it all works, and a tidy up of the ceiling and floor in general for now until re-decoration:
Round the corner from this corridor was the entrance to another area, but it doesn't exists here so I had to dig out the little lobby before the room again. I gave myself a slight change, instead of the one width step down to a small landing and then a few steps to the lobby floor I dug myself a more generous three wide staircase down.
I also found a slither of the original room!
Original:
Found!:
Original:
Re-dug:
I'm already trying to picture how I can re-magine these old areas.
The olf farm area, with the kitchen overhang above, for context; originally I found this bit of the cave with an overlook and threw up a wall with a gap looking down:
This access area on the way down, water shoots added in 2020/2021:
Lava way (Access corridor):
Lobby down to final living area (Which would be Y level 11 back then):
I personally don't agree with the technically correct aspect, all I'm really gaining is the tools and armor I already had from my main world. I still grinded, built and earnt every one of the structures I built in survival. The structures being in this mworld is more of a "Technicality" as I see it.
No no no, I understand that the source world was also done legit. I was referring to the fact that this source world was being transplanted to another world and not being done manually in game, so that's sort of what I meant by "technically". In strict terms, some might consider that any modification to a survival world beyond the start of it, or done from outside the world, could be seen as "cheating something in". But I contrasted that myself by saying "compared to the age of the world you might move it into to, and what you've obtained in that world, do you see transplanting a tiny part of another world as a big deal" and my own opinion is that maybe it's not. It only is if you think it is.
That's why I suggested doing it if you wanted to despite the technicality, because something in a single player world, it's only cheating if you feel like you're cheating yourself. I made the suggestion that if you still felt some small level of reservation because it was "technically cheating" then just pay a tax of sorts by discarding some items. That's how I'd probably see it.
While I have multiple worlds now, my others are all relatively recent compared to my old world, so i have no situation where I'd need to transplant something. But if I were in your position, I might consider it (and since I've gone with the whole "time" manipulation nonsense between my two main worlds, I'd probably even find a lore way to tie the whole event together).
That's why I gave an example of where I did this too by inserting the nether tunnels into the world, though I never discarded any items as a cost, and that's because I never saw it as cheating because the tunnel was meant as a workaround for a technical symptom of an update, rather than as a build itself. The need to spend nearly ten minutes on horse running through that tunnel, and that was just one way, each time was enough of a "cost". It resulted in those "new lands" never seeing much use (besides obtaining some of the initial samplings to bring back to the main areas), so the world felt stuck in 1.6 even if it was actually updated beyond that (up until 1.10, and a brief attempt in 1.14 that didn't end well).
In other words, I was just weighing in with my opinions based on you presenting it as being something you were unsure of, and I figured the "is this proper" question was part of your decision not being made. Though, maybe I'm wrong on that.
Either way, it sounded to me like you didn't see as cheating in an accomplishment, and I might not either, which is why I suggested you to do it if you want. But I don't want to push you to do it if you have any reservations.
What I did lately was I mess around a bit in some older versions. Namely, some of those versions were release 1.6, release 1.7, and beta 1.7.3, but I also started a fresh 1.20.2 profile to compare some aspects to a modern vanilla version (without OptiFine, since I typically use this in modern versions when i actually play).
The initial reason was to test for visual texture issues due to so many people supposedly having them on certain old versions, but I lucked out and didn't run into any issues with it, even with whatever Java versions were involved which would have no doubt been newer than what was around for these versions. Then it became something I was doing just to play around with them for a bit, and in doing so I did notice other things, and they started adding up, and honestly the experience made me appreciate modern versions more. None of this is meant to insult these older versions, but they definitely have some serious quality of life issues (at least on my hardware and software combination).
The first thing I noticed with all three versions was the incredibly low chunk loading speed (made much worse with v-sync enabled), even on what are pathetic render distances compared to the norms of today. I've been running up to 32 (or even 48 in fringe cases), and usually at least 24, and it's something else when 1.20 this loads faster than whatever these various older versions' definition of "far" is.
I can only imagine this is because modern versions are more multi-threaded with chunk loading? I don't know. But these older versions were loading chunks in so slow, and at least in the case of beta 1.7.3 I could walk around and it couldn't keep up at a pace that kept me from seeing chunk edges closer than the fog line, and even 1.20 doesn't have that issue anywhere near as much on way higher render distances (after it's finished loading them in, of course).
The trade-off, or course, is that these older versions are more free of the stutters modern versions have when loading new chunks (mostly just when generating fresh ones), and while it was a bit nice, I'd definitely take the much faster burst chunk loading.
The main thing these older versions had going for them was much faster new world loading. But that's only something you see once.
The other things that stuck out to me were the following...
The lighting errors... my goodness, they were everywhere in release 1.6 and release 1.7 (I didn't notice this in beta 1.7.3 though?).
The fog starts much closer. This isn't necessarily a bad thing and it's a bit nostalgic, but OptiFine has an option for this at least in newer versions and I like the choice. The older versions don't totally hide the chunk edges, at least not on far (though this might be because the chunks just never seem to finish loading). 1.6 in particular had an issue if I was using far (but not on normal or below) where if I looked behind me while moving in the opposiute direction, I would sometimes observe chunks closer than the fog limit just... unload after a while. This didn't happen on normal so I presume this is because the fog is anticipating a render distance of 12 or 16 but it's bugged to 10 in versions from 1.3 through 1.6.
Not being able to fly faster in creative was off-putting.
Beta 1.7.3 not having creative was off-putting.
Not being able to rebind sprinting to a key (I usually prefer to use the "r" key for this) and having to double tap forward was off-putting.
Not having v-sync in beta 1.7.3 and having to force it through the drivers was off-putting.
Not having a way to disable clouds in beta 1.7.3 was off-putting.
Not having my skin work in beta 1.7.3 or release 1.6 at all was off-putting. While it worked in release 1.7, there were issues (seemingly because my skin uses a thinner arm model and I guess 1.7 might not have yet had that).
The old harm sounds in beta 1.7.3 were off-putting (sorry to those who find them nostalgic, but I'd much prefer to be able to use the newer ones).
Not having mip-mapping below release 1.7 was off-putting, despite me disliking this feature being on even at level 1 before (nVidia seemingly does this overly aggressive on tree leaves it seems, which may be why I used to feel that way about it).
Not having round fog in any of these versions was off-putting (they use an nVidia specific function for it).
Not an "issue", but interestingly Advanced OpenGL lowered my performance (I only tested it in beta 1.7.3). I expected it to just not work or do nothing unless on nVidia hardware, but it actually made things worse (it was still consistently above refresh rate even with it on, but it was still lower than if it was off when I checked with v-sync off). Interesting. In the past the game was nearly unplayable for me with this feature turned off in versions 1.2.5 through 1.7, and the loss of it was part of what 1.8 perform so much worse for me back then.
Many of these I expected, and others I forgot about, but wow there's more quality of life issues with older versions I forgot about.
I'm sorry if this comes off as just calling old versions bad. That's not my intent, as I like these versions innately, but there were glaring quality of life things that stuck out to me going back to them and I can't say they don't matter.
The only other "issues" I ran into which weren't necessarily the fault of these versions was being unable to get any combination of anti-aliasing working without the infamous White lines (only tested with beta 1.7.3 since at least release 1.7 would be expected to be broken with it since that was when FBO rendering was added which broke it). This was admittedly disappointing because I almost consider this necessary (I achieve this with shaders in modern versions). Setting a desktop resolution of twice my native and then down-scaling works, but it's not a perfect solution as it minimized the aliasing more than removes it, and the UI size in beta 1.7.3 is limited to jumping from large to auto, whereas at that resolution something in-between would feel better.
All of this honestly made me appreciate modern versions more. I wonder if there's any mods or methods to work around any of these issues, but I'll admit I sort of lost my desire to playing them after seeing many of these things. I know there's a lot of things like "better than adventure" and players of these old versions so maybe there's some workarounds that have been made and some quality of life injections to some of these?
I also found the seed for the old demo version and looked around in it in beta 1.7.3 (I had no idea the demo used the seed "glacier") and found and revisited some old places I originally built in. The novelty wore off rather fast though, but it was still fun to do overall.
Also, I unfortunately didn't save the image (I wanted to show a few with this post but I got rid of them all...), but with release 1.6 I had a seed that gave me two desert temples within the same desert (and both simultaneously visible even on "normal" from above them looking down). Also, seeing snow biomes next to deserts was a classic one, haha. While I'm not a fan of that anymore, it was nice to see.
The old harm sounds in beta 1.7.3 were off-putting (sorry to those who find them nostalgic, but I'd much prefer to be able to use the newer ones).
I will fight you IRL on that one! (not really). Player gets hurt, player goes OOAH, get outta here with that weird little "smack" noise. An alpha sounds resource pack is indispensable to me primarily for the OOAH (though I'm also very attached to the old door slam and old chest sound).
---
I've never seen much difference in overall chunkloading performance between older and newer, but I'm not asking the game to do anything like what you're asking visually. Still find myself shaking my head whenever you're talking about 24 render distances plus shaders! There is a specific exception: I do notice that my laptop really hates generating chunks in the huge tree LOTR biomes like Mirkwood, Lorien and Fangorn in 1.7.10, and gets a bit grumpy about the vanilla jungle biome in Tekkit Classic 1.2.5. Leaf light/decay calculations got a lot of back-end improvement at some point.
I don't generally perceive the endemic lighting glitches because they're so "normal" in my Tekkit Classic world and the 1.7 modpacks that I don't think about them.
One visual improvement I have observed is the disappearance of this
This screenshot was taken in 1.4 I believe, and I saved it because the world hole showing up at that precise spot at that moment gave me a glimpse of the stronghold I was looking for. I don't even remember the last time I saw a world hole post 1.7... actually, wait I do remember, one showed up while I was exploring in a 1.19 test world! But it's such a rare occurrence now that it really stood out and stuck in my mind.
I wonder if there's any mods or methods to work around any of these issues,
A certain mod I named after myself does most of those; ever wonder why TMCWv5 took 4-5 years to release (an explanation here. "a year to refactor much of the codebase" - sound familiar? e.g. 1.8), or why TMCWv4.5 (mainly a bugfix / optimization / QoL update which added many features originally slated for TMCWv5) is so much larger than TMCWv4 and even my "World1_custom_client" is significantly larger than TMCWv4 despite not being a content update / mod?
(the size of the 1.6.4 jar is for comparison; when combined the total size is between the two alone as many classes are directly replaced)
(and yes, in terms of file size TMCWv5's source code is nearly as large as all of vanilla 1.6.4, the "backup source" at the bottom)
In fact, the source code for TMCWv5's cave generator alone is larger than TMCWv1 (although this is not a fair comparison since the zip files are compressed class files and even uncompressed class files are smaller, this also shows how small the vanilla code actually is, as seen for "World1", which combines 3 classes into one. This also does include some bugfixes but they have no impact on the size):
Here is a list of some of the QoL changes and bugfixes I've made for the next update of TMCW, (most of these have actually already been added to the public release of "World1", available in the thread for my first world, it can be called "enhanced vanilla" as opposed to an outright total overhaul mod):
Added two new world types; Medium Biomes, which has twice the biome size of Default and half that of Large Biomes (scale: 4, 5, 6), and Oceanic, which has a much higher proportion of oceans, higher than in vanilla 1.6.4, but with smaller landmasses and more frequent islands.
Hoppers can now interact with composters, adding items to a composter below them and extracting dirt from a composter above them (note that only hopper blocks, not minecarts, work). Also added an optimization for hoppers which failed to move any items to/from an inventory (they will wait 8-16 ticks before running again, instead of every tick like in vanilla), also extended collision box for picking up items into the hopper itself (MC-89125).
Sleeping now only resets weather if it is raining or thundering (only rain time is reset), or there is less than 1 minute left before a thunderstorm (only thunder time is reset), avoiding a near-complete lack of weather if you regularly sleep at night (MC-63340).
Fixed MC-3626 (mobs unable to see through transparent blocks like tall grass and cobwebs, or attack the player if their or the player's head is in such a block; in the case of creepers/skeletons/witches/snow golems their sight range for attacking was halved when transparent blocks are in the way).
Fixed MC-26678 (screen not tilting based on direction damage came from).
Fixed MC-1246 (dying mobs are still targeted when attacking, blocking attacks; this also affects most other collision checks. A few mobs override "canBeCollidedWith", including the Ender Dragon and Wither, so they are still affected).
Fixed/reduced MC-145 and MC-59425 (explosions not dealing much damage or destroying blocks when centered within a transparent block; the center will be moved up to the next whole block if it is in a non-air, non-liquid block and the block above is air or liquid; e.g. creepers standing on snow layers).
Fixed MC-174759 (dragon eggs can teleport into or over the void).
Improved how the game determines if the camera is in water (MC-3615), as well as the player itself when reducing their air supply (the shape of the rendered liquid is used instead of its "height" property), as well as when effects are applied (the tinted overlay was not applied in third person, conversely, FOV was reduced, which are now reversed).
Fixed MC-135164 (mobs not visually dropping armor or held items on death).
Mobs now drop XP immediately when they die, instead of when they despawn; this was partly changed to ensure dropped equipment still counts towards XP dropped, and removes the main disadvantage of Knockback and Punch and enables the full duration of the "recently hit" timer to apply to XP drops (otherwise, a second is lost due to the death animation taking that long).
Fixed MC-5585 (Ender Dragon not taking additional damage from Sharpness enchantment).
Fixed various issues where leads would not drop when mobs died or despawned (MC-15084), or a bucket was used to pick up a leashed fish.
Boats now produce breaking particles and sound when they crash.
Increased output of firework recipe from 1 to 3; also added to Creative inventory and statistics.
Improved validation of attack reach so Giants can consistently attack and be attacked above their feet (it was previously dependent on where their feet were within a chunk section, most noticeable when near the top).
Dispensers can now shear sheep, mooshrooms, and snow golems; the shears will not be ejected if there is no valid mob and this behavior was also applied to buckets if they fail to place/remove liquids (filled buckets will still be ejected if there isn't enough room).
Improved spider AI (MC-151054, most notable with cave spiders in a 1x1 space in the ceiling); they will now jump down (climbing disabled) if they are directly above a target or have a direct line of sight to a target below them; falling through cobwebs also now negates fall damage.
Hostile endermen no longer become neutral almost immediately when exposed to sunlight, taking at least 10 seconds to do so (similar to how spiders were changed).
1 deep snow layers are no longer solid (you fall through them).
Changed carpet recipe to give 4 carpets instead of 3, matching the efficiency of snow layers, themselves changed to give 4 layers from 2 snow blocks (instead of 6 layers from 3 blocks), enabling them to be crafted without a crafting table.
Modified End generation to fix seeds like 3761987256467393916 in vanilla (generates an abnormally small and fragmented island); obsidian pillars can also generate on more uneven terrain.
I've even fixed many bugs which apparently still affect current versions; mobs glitching through fences/walls? Various errors with smooth lighting (a bug which has actually worsened, the only form that appears to have been fixed is smooth lighting underwater, and I also consider a lack of complete darkness to be a major bug)? Or even some of the ones listed above (e.g. the broken End generation. Giants? Mojang gave up on them as a lost cause in 1.8, completely removing their AI, while they are a naturally spawning mob in my modded versions, even in World1 (along with actual cave spiders and witches). Explosions are more dangerous when they aren't blocked so easily (creeper explodes on lower half.slabs, only the block it is on is destroyed because explosions don't consider the actual shape of a block; even snow layers will negate nearly all damage to entities nearby). Why do i still have boats able to crash when it annoyed so many (mainly because of lily pads and squid, neither of which cause them to crash)? Convenience, I also made it so they only break if crashing at near full speed so I can just ram into land and pick up the boat (dropped as itself, not planks and sticks).
That said, I do not experience some of the issues you mention in vanilla; as long as Vsync is not enabled (which I fixed) chunk loading is too fast if anything, often exceeding 500 chunk updates and causing stutters (the method the game uses to calculate how much free time there is for chunk updates between frames is suboptimal; I improved this to more accurately track the time, and added a slider to let you change it. Optifine attempts to do the same with a "chunk updates per frame" setting but that is not optimal either since the time take for an update depends on the complexity of a chunk section). With the default framerate limit of "balanced", or 120 FPS, vanilla 1.6.4 drops to 80-90 FPS when updates are high (it does remain locked at Vsync but only does 1 update per frame, and Vsync doesn't get enabled on game startup, you must toggle it off and on). Even modern versions still prioritize chunk updates, allowing FPS to drop to as low as 30, which is totally unacceptable - I still do, as they claim was the issue, treat the FPS limit as a minimum target to maintain at all times).
Also, the issue with Advanced OpenGL is that it works best when your GPU is significantly weaker than your CPU, as was the case on my old computer, where it doubled FPS when enabled and was needed to make my "double / triple height" terrain mods playable (the amount of rendered geometry due to all the caves underground being rendered would cause the GPU to run out of VRAM, resulting in severe lag down to single digit FPS, or even "Minecraft has run out of memory" as the process size exceeded the 32 bit limit. This may also give a clue as to why caves were nerfed to be much more uniformly distributed and mineshafts much rarer in 1.7, as the size of complexes in 1.6.4 can get quite extreme, to the point where I had issues without occlusion culling even on normal worlds (this may explain comments I got on my mod's thread back in the day like "I get barely 8 FPS when running this mod", which I found hard to believe given I got 10x that on an already very old computer). then again, the CPU-based culling method that replaced it in 1.8 was far less effective at culling hidden chunks; it shouldn't still be rendering 130 sections in this screenshot, but a few dozen at the most).
I also blame AMD and Intel for not properly using the hardware for it, instead implementing it (and I assume other OpenGL features) in software:
Having said that, it doesn't have much of an impact on my current system, with an NVIDIA GPU, presumably since it is more powerful relative to the CPU, I get 1000 FPS anyway even without it (at 8 chunks, vanilla gets 400-500 on "far" / 10 chunks, and my modded versions get about the same at 16 chunks. Also, I've seen people, including yourself, claim that the game barely uses the GPU but this is not true, in fact, Task Manager shows a much higher percentage of the GPU being used and the performance increase since my first computer would be only 3x based on the CPU alone (per-thread), not the 10x that I actually see, and is close to the difference in GPU performance). I also reduced the amount of rendered geometry by about 20% by making chunks render in a circle instead of square (they are still loaded in a square, at least as of now, random block ticks also still occur in a 15x15 chunk square instead of an 8 chunk radius, like since 1.9, which is about 10% smaller in area).
Note that until recently (due to fixes to the drivers, not game itself, mentioned in the comments) even newer versions had issues with animated textures / mipmaps on AMD hardware, most apparent with modpacks or resource packs with a lot of animated textures:
Apple has even given up on OpenGL entirely and the game in general could become unplayable on Macs if they decide to drop it completely (unless an emulator is used, or Mojang rewrites java Edition to use a more modern API like Vulkan, or a native OpenGL to Metal wrapper):
That said, the issue that some have with bugged textures on older versions is caused by a bug in the game itself, according to somebody who claimed to fix the issue for a mod for Beta 1.7.3 which had backported some rendering code from Beta 1.9+ (when they refactored some code they omitted an OpenGL call to set the "active texture", which seemed to be unnecessary at the time but GPU drivers are known for ignoring programming errors until specs are tightened):
Also, I should note that I never noticed many of the "quirks" in the game until I fixed them; as I only started playing in 1.5 I never understood all the hate for 1.3 until I fixed the issues it caused (a large percentage of my bugfixes are directly related to that version, e.g. the lack of directional damage tilt; and the latency issues caused by running an internal server (not lag per se as it is usually described as; a major issue is that the client and server do not sync their ticks, causing jitter, which I fixed by having the client tell the server when it can tick. Of course, there is still a round-trip latency of 2 ticks between an action performed on the client and the client receiving the result from the server; because of this, some people have made mods that revert the game back to the way it was before 1.3, but this does make a lot of sacrifices, such as no multithreading at all (the game has to tick the world, update chunks, generate chunks, save data, etc all within a single frame in order to be smooth, hence why versions like Beta 1.7.3 perform so poorly, and why I do not understand why "true singleplayer " is such a good thing).
I will fight you IRL on that one! (not really). Player gets hurt, player goes OOAH, get outta here with that weird little "smack" noise. An alpha sounds resource pack is indispensable to me primarily for the OOAH (though I'm also very attached to the old door slam and old chest sound).
Haha! Yes, I know they are nostalgic for older players, but when you're playing as a girl it doesn't match up and takes you out of the experience a bit. That wasn't me saying "the old ones are bad". That was me saying "having the newer ones back-ported as an option would be preferred by me".
I've never seen much difference in overall chunkloading performance between older and newer, but I'm not asking the game to do anything like what you're asking visually.
That's the thing; I'm asking these older versions to do less (not as far of a render distance) and they're slower despite it.
If my method of recording didn't lower my performance, I could take a video of loading 1.20.2 (without OptiFine, mind you) and show you that even a render distance of 32 will load the chunks in much faster than any of these versions did whatever values of 10/12/16 chunks they were trying to do. 1.6 in particular was acting like 1.14 where it'd sort of have missing spots at times.
The newer version certainly will stutter more while loading chunks, no question... but it's also doing it so much faster.
As for the chunk glitches, the only one I see in modern versions is what I believe is a known OptiFine issue. An empty sub-chunk with a block placed in it may be invisible until it updates, and yes this lets you partially see though terrain (at least mobs show up but there's just empty sky otherwise); zooming into it forces it to render.
There was also one 1.8+ introduced because its occlusion culling wasn't perfect so sometimes you'd also see missing spots (and these were consistent so once you found a spot/angle that it happened it was always like this), but I'm not sure if it's still there in modern versions. I suppose I could find out since I know one spot/angle in my oldest world that did it at least up to 1.14.
I did, however, see a thin strip (one chunk line) like in your image in 1.6. Once some chunks unloaded right in view (god limit of 16 versus internal server distance of 10 issue I guess) it loaded that strip in. I don't remember seeing that back when I actually played 1.6 though so maybe it's down to modern Java or modern software or something.
The really dark spots annoyed me though. I couldn't live with those anymore. It's one of those things that once you haven't seen it, you'll see it and go "how did we used to tolerate that?"
A certain mod I named after myself does most of those.
I'm aware of that, but your mod is practically its own version of the game, so I'm not sure how that would help me with only addressing specific issues but otherwise staying with the classic vanilla versions, especially in the case of beta 1.7.3.
I'm not naive to what you've accomplished with your mod, and I applaud it. But when I'm talking about issues in these older versions, I'm talking specifically about the vanilla older versions, not your mod which happens to be based on one of them and most likely fixed it.
That said, I do not experience some of the issues you mention in vanilla; as long as Vsync is not enabled (which I fixed) chunk loading is too fast if anything, often exceeding 500 chunk updates and causing stutters (the method the game uses to calculate how much free time there is for chunk updates between frames is suboptimal; I improved this to more accurately track the time, and added a slider to let you change it. Optifine attempts to do the same with a "chunk updates per frame" setting but that is not optimal either since the time take for an update depends on the complexity of a chunk section).
Interesting, and I suspected this to a point. Modern versions are loading faster for me, but stutter more as a result. They go hand in hand. So maybe older versions weren't so much as immune to the issue (even if they may have been better) so much as they were avoiding it I guess.
My CPU is able to minimize the stutters in modern versions rather well (fresh chunk generation or playing high render distances will recording are where it's a bit of an issues though), but there was no mistaking it was almost (but not entirely) gone in these older versions. But they were loading chunks rather slow as a result.
Disabling v-sync certainly helped a little, but not completely, and I would find that it unacceptable to have to play without it in order to get faster but still not acceptable chunk loading speed.
I think I have the chunk updates set to 3 in OptiFine these days? I'd have to check. I used to run 5 back on my old CPU in old versions but I did eventually find this was sometimes a "less is more" setting. Higher values speed up chunk loading but it's already rather fast at 3 updates. I basically have to raise render distance to 48 to make it take longer than ~10 or 15 seconds to load it all (and even then, once it does, it's able to load chunks at a speed before you notice it showing up before the god line when not generating new terrain or flying).
I still do, as they claim was the issue, treat the FPS limit as a minimum target to maintain at all times).
This is a good solution I think. Delaying chunk updates to keep the frame rate up to the set target is the way it should be, even if that means slower chunk loading/updates.
Also, the issue with Advanced OpenGL is that it works best when your GPU is significantly weaker than your CPU...
I figured it might due to my non-nVidia GPU, because the setting was supposedly nVidia specific (or at least in results, based on what you later say on nVidia being the only one to do this in hardware). The old CPU I had was a 2500K and the old GPU I had was a GTX 560 Ti, and the differences between my current CPU and current GPU is far greater on the GPU side (given CPUs have advanced more slowly than GPUs in that time), so if it was already CPU favored back then it should be more so now and I should be seeing more of an increase, but instead it's a decrease. So I figured it was down to "not nVidia".
Back then, disabling Advanced OpenGL meant I wasn't even holding 60 FPS all the time if I'm remembering right, and I can't remember the exact game version but it was definitely 1.6 or older so that would have meant it wasn't even able to hold that on the lower render distance limits from back then (10 in the case of anything but 1.2.5, since that's where I started, and for most of my time on 1.2.5 I was actually playing at short [4 chunks] anyway since I was on a much weaker PC before that).
Yet, without Advanced OpenGL in modern versions since it's gone of course, I'm now able to load up 48 chunks and hold 60 FPS. It's going to stutter loading them, and it's not going to keep up flying... but the steady frame rate is there, when it wasn't back then even on substantially lower render distances.
Stuff like this makes me question how much lighter those older versions actually were, if at all, or if much of it was instead down to "we were asking less of it/had less standards/didn't notice".
But I'm sure modern Java versions and drivers might actually be hurting performance and behavior in these older versions as well so it's hard to compare.
I also blame AMD and Intel for not properly using the hardware for it, instead implementing it (and I assume other OpenGL features) in software:
Unfortunately, part of that is increasingly the fault of software too though. Even back then, I think the round fog was one such example? Modern versions seem to do this just fine on AMD, and I believe you said this was always possible but they used an nVidia specific instruction. nVidia graphics hardware has increasingly taken most of the market in the last ten or fifteen years, so it's reached the point it's become a feedback loop (or a self fulfilling prophecy of sorts) where software just sort of targets it by default because that's what the vast majority of the market is. Currently nVidia has anywhere between a 75% to 80% market share hold depending on source. You're seeing the same thing on Chrome versus Firefox again in recent years because Firefox has shrunk back to a minority of the market, even though Firefox certainly does most things properly (way back when, Firefox did things right and Internet Explorer did not, yet things rendered "properly" in the latter specifically because it was written to do so). So part of this is stuff targeting specific stuff and not always the alternatives doing something wrong.
Also, I've seen people, including yourself, claim that the game barely uses the GPU but this is not true, in fact, Task Manager shows a much higher percentage of the GPU being used.
If I'm ever making statements along the lines that the GPU is barely being used in Minecraft, it's not that I'm saying it can't ever use it. Certainly if you disable v-sync especially, the game will run to the limits of whatever bottlenecks it first, and that will usually be the CPU or GPU, but even if it's the CPU, the GPU use will certainly rise relative to if playing with v-sync. That's just normal.
When I ever say something like that, it's more in reference to the fact that in most games, you'll almost always be GPU bottlenecked, but Minecraft doesn't have anywhere near that much GPU demand. Instead, you're almost always CPU bottlenecked instead.
You can get by with much less of a GPU in Minecraft relative to most other games is what I'm saying.
The laptop I had before the current one had the W key break right off the keyboard, hinge and all, and I entirely blame old Minecraft for that.
Okay, maybe it was my fault for playing too much Minecraft.
I will fight you IRL on that one! (not really). Player gets hurt, player goes OOAH, get outta here with that weird little "smack" noise. An alpha sounds resource pack is indispensable to me primarily for the OOAH (though I'm also very attached to the old door slam and old chest sound).
---
I've never seen much difference in overall chunkloading performance between older and newer, but I'm not asking the game to do anything like what you're asking visually. Still find myself shaking my head whenever you're talking about 24 render distances plus shaders! There is a specific exception: I do notice that my laptop really hates generating chunks in the huge tree LOTR biomes like Mirkwood, Lorien and Fangorn in 1.7.10, and gets a bit grumpy about the vanilla jungle biome in Tekkit Classic 1.2.5. Leaf light/decay calculations got a lot of back-end improvement at some point.
I don't generally perceive the endemic lighting glitches because they're so "normal" in my Tekkit Classic world and the 1.7 modpacks that I don't think about them.
One visual improvement I have observed is the disappearance of this
This screenshot was taken in 1.4 I believe, and I saved it because the world hole showing up at that precise spot at that moment gave me a glimpse of the stronghold I was looking for. I don't even remember the last time I saw a world hole post 1.7... actually, wait I do remember, one showed up while I was exploring in a 1.19 test world! But it's such a rare occurrence now that it really stood out and stuck in my mind.
The chunk loading performance is still a problem in the game even on modern hardware and across different vanilla versions
That's not even mine and Chaptmc's biggest problem with the game anymore though, it used to be, but now it's the ludicrous changes that happened in version 1.20 and 1.21 that players are forced to put up with on bedrock edition. And why I and friends are no longer active on the game, I briefly only revisit to check if the server is working in case anybody else in the whitelist did decide to join, but as a normal gameplay experience? forget it, I'm not wasting my time if Mojang are just going to parasitically impose their elitist design choices on everyone. For people who don't even like the newer versions we don't even get the option to switch back outside of mods if we want to continue playing in multiplayer, so it sucks for people like us, as the sandbox experience is now gone.
I've got many other games in my collection that I do frequent including what's on my Steam account, and I have a friend who plays with me on Streets of Rage 4 since we enjoy playing beat em ups.
The "lines of missing chunks" was not due to poor chunk loading per se but a bug in the game where it didn't properly flag chunks as "dirty" if it happened to update a chunk while it was empty of data, then got filled right after, which is one of the things I fixed (this is especially common when using Far render distance because the client allocates enough sections for a render distance of 12 but they are only loaded up to a distance of 10 so there is a 2 chunk wide strip that is empty).
Also, wondering how easy it was to fix?
public boolean skipAllRenderPasses()
{
return !this.isInitialized ? false : (this.skipRenderPass[0] && this.skipRenderPass[1]
&& !this.needsUpdate); // This second line is the fix!
}
Yes, that's it - you'd never believe just how simple so many bugfixes are (the hardest part is figuring out how to fix them). Here is a screenshot I took while flying into new terrain with the render distance set to 16 - no unrendered chunks anywhere and a stable 75 FPS with up to 600 chunk updates, the server was only using 1/5 of its allotted tick time, so even 32-48 chunks would be no issue (the area increases by the square but the increase in generated terrain, and required chunk updates to keep up, is linear. A 33 chunk wide strip averaging 6 sections deep is 198 sections, then double that as decorations spill over into the next chunk and you get an average of 272 chunk updates per second while flying at 11 m/s):
Setting FPS to unlimited does lower chunk updates (or more accurately, with less variation as only one can be done per frame now) but still enough to keep up (there will always be at least one update per frame, which is also true of vanilla; Optifine's setting forces the game to do at least the specified number):
Another thing that helps is making the game more aggressive at NOT updating chunks off-screen (I believe that 1.8 may not do this at all, so you turn around after moving backwards and see chunks render in, or I seem to recall that happening), it (vanilla as well) also prioritizes chunks within a 3x3x3 volume around the player, and otherwise within a diamond-shaped area centered on the y-level of the player. Newer version also treat world generation in a similar manner; if you move too fast only a narrow strip of chunks will be generated, while 1.6 always generates the entire width, so at after a point it will be slower (this did annoy me though when I wanted to generate some terrain in 1.8, 1.9(?) and Unmined showed gaps, whereas in 1.6 it was always enough to be within 2x the render distance of the last pass).
Also, I experienced some rendering oddities with Optifine as well when chunk loading was set to "smooth", I'd place a block and sometimes it wouldn't render, or there would be rendering artifacts (lighting) along some chunk borders when moving around (fixed by triggering an update). However, the much smoother chunk loading performance was worth it (the cause appears to be due to the fact that the "smooth" setting splits chunk updates into smaller pieces if they took too long and it didn't flag the whole chunk as dirty if any block changes occurred between incremental updates. I actually experimented with a similar idea but never implemented it due to various issues, like tile entities not rendering, although I did end up changing TE rendering so instead of registering their renderers during a chunk update they are registered when the client receives the title entity, helping to simplify the chunk update loop, which doesn't need to check if a block has a TE).
Unfortunately, part of that is increasingly the fault of software too though. Even back then, I think the round fog was one such example? Modern versions seem to do this just fine on AMD, and I believe you said this was always possible but they used an nVidia specific instruction
This is true, and somebody even replied to a bug report claiming that the fix was "really easy" but they unfortunately never posted it, nor have I been able to find any results on how to make OpenGL use "eye radial" fog (without using modern shader-based rendering, that is. I assume that this was not what they were thinking of if the fix was as simple as they claimed):
Oh by the way I've fixed the Radial Fog rendering with AMD or Intel GPU's.
Just Reply back here if your interested its really easy to fix.
On the subject of missing chunks, there have been two such issues that have occurred, one in Alpha and up to 1.3 Beta where if you traveled more than 300 chunks or so in a short amount of time (such as going into the Nether), random chunks would reset their generation back to default, erasing any changes made. I had a part of my house get erased in such a manner after coming back from the Nether. The other one occurred in 1.6.4 and in 1.7.10 where entire swaths of one chunk wide sections (usually around 6-8 chunks long) of the world would not render. If you were mining, you would suddenly encounter zero lighting. You could correct this by logging off and back on, but there was another issue that could occur if you saved the game with the chunk error on the screen. It made a large part of my base just disappear, in much the same way the other chunk error in Alpha reverted the terrain in part of my house. The trick to avoiding this was to travel outside of the chunk loading range of the affected chunks and then re-enter the range. This fixed the lighting and rendering problem. I never ran into this in 1.12.2, in any of the packs I've played (Stoneblock, Direwolf20 and Feed The Factory)/
Now to what I have done recently. I unlocked plastic production, which leads to chemical science and ultimately to nuclear power. I have already obtained substantial amounts of the ores from the Creeper Data Model, and both it and the Wither Skeleton one have reached self aware tier. I have about 13-14 K of Boron, Lithium and Magnesium, all of which are needed for Nuclear Reactors. At first, Nuclearcraft Reactors are not that powerful, and you just burn the fuel away, so it is best to supplement it with other forms of power like oil until more powerful fuels can be made. The highest tier fuel appears to be HECf-251 Oxide Fuel, which generates 8400 RF/t and has a base process time of 45 minutes (I'm assuming this means how long it takes to burn one unit of fuel). In a normal version of Nuclearcraft where the radiation mechanic is enabled by default, all of the fuels are radioactive, with the higher tier ones being more likely to kill you in seconds without some form of radiation shielding. And there are nuclear wasteland biomes which are radioactive and spawn a hostile zombie-like mob called a Feral Ghoul. These shamble about like zombies, but when they get close to you, they jump at you like spiders, and irradiate you when they attack.
To make liquid plastic (essentially polyethylene), you take Naptha and combine it with Hydrogen in a Salt Mixer to get Ethylene gas. This is then combined with Oxygen to get liquid plastic, which is then made into ingots in a Fractionating Still at a cost of 200mB per ingot. I have so far made around 75 plastic ingots. Hydrogen and Oxygen are obtained by running water through an Electrolyzer to break it down into H, O and a little bit of Deuterium. This machine is the single most power hungry one I have made at a base 4000 RF/t, and a process time of 240 seconds. This is as long as making Nuclear Pasta in Satisfactory, an end game component for that game. It can be sped up, with every speed and energy upgrade put into it together will increase power and speed by N+1, so 1 will be x2, 2 x3, 3 x4 and so on. I have found that 3 of these at 16,000 RF/t brings my total power usage to around 25,000 RF/t, about 55.5% of the max output of 8 dynamos. And I have decided to add a 9th one, even though I will not be able to use the additional 625 RF/t that the HV conduits cannot carry.
All of gases, which include O, H, Deuterium and Ethylene make a hissing sound like gas being released when you empty or fill a bucket, and the 'fluid' rises to the top of any tank you put it into. The buckets when you look at them in JEI or have one in your inventory are rendered upside down, and any item with an upside down bucket like this is almost always going to be a gas rather than a fluid.
The Salt Mixers are less expensive to run, with a base power of 1000 RF/t and process time of 30 seconds. I increased these to 3K RF/t and reduced the process time to 10 seconds. The Fractionating Still uses 1000 RF/t to produce the plastic ingots. In addition, I made some electric motors, machine chassis and basic plating, as well as Ferroboron Alloy (steel and boron) and Tough Alloy (ferroboron and lithium). There's also a Nuclear Furnace I can now make that smelts items almost instantaneously using uranium or thorium ingots or dusts.
Just spent the morning, or at least some of it; restoring my kelp farm to a "factory setting".
The only initial changes long ago was swapping the furnace for a smoker, but it was pretty self sufficient at not only keeping itself going but enough kelp blocks for the furnaces in storage AND the super-smelters. Then I got greedy. I changed the shoot to the smoker to a two wide shoot installing another hopper into smoker at the bottom and extended the opening at the top for double efficiency.
Now whether this is me letting it run dry or it just not being as effective, it's just not as self dufficient anymore, I barely get the turn-over I used too. So as a result, I've had to nick the stacks of kelp blocks from the furnaces in storage to sustain it, and reduce the two shoot back to a single shoot-smoker. Now I have 8 out of 9 furnces to replnish, but it's at least back to how it was.
It's been like this for a while, I should never have meddled.
This is true, and somebody even replied to a bug report claiming that the fix was "really easy" but they unfortunately never posted it, nor have I been able to find any results on how to make OpenGL use "eye radial" fog (without using modern shader-based rendering, that is. I assume that this was not what they were thinking of if the fix was as simple as they claimed)
Doing some checking, Mojang seems to have changed this with 1.17 (I only checked formal first release versions, and 1.16 still has the old "line fog" and 1.17 has the rounded fog, so likely one of the snapshots for 1.17 would be when this changed). Since the OpenGL requirements increased for 1.17 I think, they probably went with that as their method as opposed to whatever the quoted fix you found claimed.
My friend recently built towers of cherry and bamboo wood. Those are unique I guess. I am going to keep building mine of amethyst and its related rocks, which blend with both woods decently well.
Most things from a similar biome (or using the log with its planks) tend to work well, but I like playing with things and seeing what else they work with.
Black colored stones seem to work good with the new cherry wood.
I wish we had White stone... (no, not diorite; I mean something like marble or a new end stone or wherever it comes from as long as it's White and gives a smooth, brick, and other variant type like normal stone and deep slate has.)
I wish we had White stone... (no, not diorite; I mean something like marble or a new end stone or wherever it comes from as long as it's White and gives a smooth, brick, and other variant type like normal stone and deep slate has.)
Agreed, it's not like white concrete or terracotta has slab and stairs. I only polished diorite (Sparingly) because of my resource pack because it's either that or quartz. Calcite is okay but again I don't think it has slab/stairs(?) We've got plenty of dark blocks, black blocks/grey blocks, so some more white stone/marble or brick would be most welcome.
So I found out the reason why the Fractionating Stills making Refined Fuel were so expensive to run - they are meant to be balanced with Compression Dynamos. I took the 4 Generators (the Integrated Dynamics ones) and upgraded them to the dynamos, added Hardened, Reinforced and Signalum upgrades to them, Fuel Catalyzer (produces more energy per unit of fuel burned) and Closed Loop Cooling augments, plus 4 Auxiliary Transmission Coils. This makes each Dynamo produce 5625 RF/t max, and with the except of around 100 mB, does not consume any coolant. For this I made enough buckets of Gelid Cryotheum to fill each dynamo's coolant tank (each holds 4000 mB).
This fluid is made in a Magma Crucible by melting Cryotheum Dust, which is made with 2 Blizz Powder, 1 Redstone and 1 Snowball. The powder is obtained by pulverizing the rods, which in this case you get by running the Pristine Thermal Elemental Matter through the Loot Fabricator. In a normal pack you would need to either go and hunt Blizzes at night in snow and ice biomes, or fluid transpose snowballs with TE's version of XP, Essence of Knowledge.
After letting the dynamos' power storage buffers fill up completely, I switched the entire line of Fractionating Stills back on. I am currently standing on top of the dynamos, watching their power outputs gradually ramp up to their max at 5625 RF/t each. They just hit 2000 RF/t. So I can definitely handle running all 4 of them now. I plan on building more of the dynamos, up to a max of 8, which will put the total output to 45000 RF/t. Adding one more will put the total over 50K, and a small amount (625 RF/t) will be lost.
Any chance of some screenshots of your setups? I have a ton of vital automation to do in GTNH and I want to steal good ideas!
Journals - Gregtech New Horizons | Tree Spirit Challenge [current]
I am breaking new ground.
With the recent download release of my main world, I am finally getting to grips with MCA and getting used to using it. Areas I've only visited once/corrupted chunks I have finally been able to remove, though keeping some alpha beta chunk walls as they tell a story of the world as I was reminded by a friend on discord.
Long story short, I turned my 7GB world to s 1.56Gb world, but don't worry, I still have a "before copy".
They also suggested after I showed it, abut merging in my original world, world1; that pre-dates the main world by a month. I was reluctant though. I've played this world for slightly longer - but a lot less frequently. It's always been an on/off world. Less resources therefore for an idea which originally was to build a home on several mountain tops and connect them with sky bridges. I gave up after three to start what is now my main world. Returning several months later to only work on turning the huge cavernous crater hole between mountains ~1 & #2 into an underground home, done so on/off for the last 13 years when I felt an urge only.
From the top of the very cube-sized 2010 fort, built on a mountain exactly as it was, the next day I built a wooden bridge across to the next mountain top,
The next home being very 2010 basic, a elongated wooden hut with a dirt roof with glass blocks here and there as skyiights, Nothing inside except a mock stove, a double chest and the cobble floor it sits on.
The next mountain was far way so I built a cobble skybridge, though I wanted it to be glass. Why I didn't think to have in-between rings to put the lighta I knew wopuldn't stick to glass, I'll never know. In hindsight the next fort was just as ill-though out with little space inside.
After several months of giving up and now starting what would become my main world, I returned to the world concentrating on that huge cavernous hole mentioned turning it into an underground home on/off until this day.
I wasn't familiar with how to copy chunks from one world to paste in another in MCA, at first it seemed not to work. Today after watching a tutorial and realising what I did wrong, I did so on a COPY of the optimized world. Carefully selecting a region I could put it, considering the existing terrain and be near my main world work but still further enough to travel. (For the underground home I had to do layer by latyer, there were mistakes and a few re-tries.)
After several tries the last time I had the exact co-ords, unlike last time and flew until it came into view:
In the underground home on level #1 there was a little bit more room in the storage area:
Everything is more or less there, there are a few anomolies such as a blank wall instead of the corridor that led to the "nice room" as it was called back then:
(Original pics):
That can always be re-created though.
The question now is do I make this permanent? The only maybe illegal aspect is just the buildings existing in this world. All the buildingd and resources are still legit and were gained over years in survival, they were all still built in survival. But in this , a copy of my main world I have all the resources I could ever need to make this world 1 inside world 2 the best it can ever be?!
Or, do I just keep it as a separate world that just happens to have buildings from my original worl;d in?
Either way, I took a screenshot in my main world for co-ords of where the castle portal comes out in the nether, so that in the copy I can build a porta and connect the two areas. In the copy world, although not in the exact same spot, i re-made the portal in the same general area however, in the underground home:
I came out at level 36 had to be at level 95., then dug a tunnel to the castle portal, which actually wasn't that far away. It's one longish flight of dug steps, then just one tunnel:
And that right there is the portal to the castle at the main part of my world.
So I'm undecided. Even though it's a world copy it seems strange to have these original world builds on my main world, yet the prospect of maybe doing what I always dreamed with them with so much resource resources of my main world makes it irrisistable. Instead of leaving the overland original builds as they were in 2010 for nostalgia (WHich they still can on the actual world1) I could make them what I wanted, not have a cube fort beceuse that was the limit of my skills in 2010. Maybe even have that glass tunnel and improve the wooden hut?
So do I keep this change permanently or just as a separate world that happens to also have my main world..
Closed old thread
16yrs+ only
Sounds like your world went through something similar to what mine did? I took it from 1.10 to 1.19 and let the chunk blending of 1.18 allow me to purge a lot of the central region away (which was previously pre-generated to avoid chunk border transitions between pre-1.6 and post-1.7 terrain). Likewise, my world went down from around a dozen GB to somewhere between 1 GB and 2 GB. Which was a culture shock because both of my hardcore worlds are also about that size, so it made my decade-plus running world seem... less accomplished? I don't know, haha.
Anyway, I hope you have fun breaking new ground! I was, at least in the short time I was at it. Then my hardcore worlds took my attention away from that world for now. So I guess I'm still always breaking new ground, haha.
As for keeping the old world in the new world or not, that's up to you. I think when you've got a world as long running and established and resource rich as this, the stance of "it's cheating" might be technically correct, but sometimes that's not the most important thing. The material cost and time setback versus the rest of the world is probably approaching nothing? Meaning outside the different terrain you're not gaining something you couldn't easily have gained, so you're just doing it to link two worlds. If you want to feel fair for survival/resource sake, discard some resources as a compensation cost. It can be a "rough guess" of similar things that are being added to the world, or maybe it's just an ore cost. Up to you. When 1.7 released, my then-much younger world was one where I went into McEdit and added very long tunnels in the nether. This was, formally speaking, cheating for a world where I only ever played "legit" (meaning all blocks obtained and placed were done so in survival gameplay). I did this because I didn't like the chunk walls between 1.6 and 1.7, so I pre-generated a large area around spawn (see why my world was over 10 GB?), and then updated, with the idea being I'd use the nether to access the 1.7 lands. Problem was... it was so far away. So I used this as a workaround of sorts to "link two worlds together as one" world. See also why I loved 1.18's chunk blending feature so much? It removed the need for this entirely.
Of course, keep the original separate backups, but yeah once you start moving forward with it this way you'll be tied to it. I'd say do whichever you prefer.
Oh, and it's easy to look back on past decisions and go "why didn't I just do it this way instead" when hindsight is 20-20 as they say. There's actually multiple ways to do things and sometimes we just go with whatever one we feel like in the given moment, and sometimes there's no deeper reason to that so no point on dwelling on it. So don't beat your past self up too much.
Seeing those older locations sort of makes me want to start a new world (gasp!) in an older version. It's funny how my whole thing used to be not starting new worlds and sticking with one, but this has sort of been the year where I've started new worlds.
I still have fond memories of when I first tried the game, maybe because it was with the PC Gamer demo (based on beta 1.3?) and that's the only stuff I don't still have so it only exists in memories. My first world from when I formally got the game at release version 1.2.5 shortly after I still have. I recall three or four houses I tried making in the demo, but the time limit meant I never finished any of them (I'm aware of ways to get around it now, but back then I was only using it to try the game and I was set on buying it if I liked it, and not buying it if I didn't, so there was no need). But it'd be interesting to find that seed and create it in beta 1.3 and see if I can find the locations for all of the houses I attempted (two were very near spawn). Not that any of them got very far.
One in particular was barely started and I was killed by a skeleton trying to lay the foundation and porch after nightfall started coming, and I believe it was outside my render distance shooting me? That might have been the first time I died to a mob in Minecraft.
The two that made it farthest had walls but I never had a completed house.
I've dealt with similar situations although I couldn't directly copy the relevant structures into my main world as they were originally made in modded worlds. My approach has been to either reconstruct the structure as close to 1:1 accuracy as possible, or to build something similar in layout and appearance for an "inspired by" sort of thing.
Journals - Gregtech New Horizons | Tree Spirit Challenge [current]
I personally don't agree with the technically correct aspect, all I'm really gaining is the tools and armor I already had from my main world. I still grinded, built and earnt every one of the structures I built in survival. The structures being in this mworld is more of a "Technicality" as I see it.
For the moment I think I'm leaning more to keeping it as a "separate world" for now and just see what I can do with it, still in survival, with more advanced tools/equipment. I did find some nice diamond equipment in a chest, but not enchanted though, just regular so that was nice.
Oh I don't, it was just a much simpler time, with a lot less blocks and ways of building back then in alpha/beta.
I think I've done similar with a few late BETA worlds, in that using the seed and seeing how I would build it differently ; now knowing what I know.
Given that it's modded. I think reconstruction is fair game given the limitations of vanilla.
Small changes already, from this:
To this:
Also fixing up this very dilapidated corridor:
Just re-installing the redstone lamps and reconnecting the redstone above the ceiling and making sure it all works, and a tidy up of the ceiling and floor in general for now until re-decoration:
Round the corner from this corridor was the entrance to another area, but it doesn't exists here so I had to dig out the little lobby before the room again. I gave myself a slight change, instead of the one width step down to a small landing and then a few steps to the lobby floor I dug myself a more generous three wide staircase down.
I also found a slither of the original room!
Original:
Found!:
Original:
Re-dug:
I'm already trying to picture how I can re-magine these old areas.
The olf farm area, with the kitchen overhang above, for context; originally I found this bit of the cave with an overlook and threw up a wall with a gap looking down:
This access area on the way down, water shoots added in 2020/2021:
Lava way (Access corridor):
Lobby down to final living area (Which would be Y level 11 back then):
Closed old thread
16yrs+ only
No no no, I understand that the source world was also done legit. I was referring to the fact that this source world was being transplanted to another world and not being done manually in game, so that's sort of what I meant by "technically". In strict terms, some might consider that any modification to a survival world beyond the start of it, or done from outside the world, could be seen as "cheating something in". But I contrasted that myself by saying "compared to the age of the world you might move it into to, and what you've obtained in that world, do you see transplanting a tiny part of another world as a big deal" and my own opinion is that maybe it's not. It only is if you think it is.
That's why I suggested doing it if you wanted to despite the technicality, because something in a single player world, it's only cheating if you feel like you're cheating yourself. I made the suggestion that if you still felt some small level of reservation because it was "technically cheating" then just pay a tax of sorts by discarding some items. That's how I'd probably see it.
While I have multiple worlds now, my others are all relatively recent compared to my old world, so i have no situation where I'd need to transplant something. But if I were in your position, I might consider it (and since I've gone with the whole "time" manipulation nonsense between my two main worlds, I'd probably even find a lore way to tie the whole event together).
That's why I gave an example of where I did this too by inserting the nether tunnels into the world, though I never discarded any items as a cost, and that's because I never saw it as cheating because the tunnel was meant as a workaround for a technical symptom of an update, rather than as a build itself. The need to spend nearly ten minutes on horse running through that tunnel, and that was just one way, each time was enough of a "cost". It resulted in those "new lands" never seeing much use (besides obtaining some of the initial samplings to bring back to the main areas), so the world felt stuck in 1.6 even if it was actually updated beyond that (up until 1.10, and a brief attempt in 1.14 that didn't end well).
In other words, I was just weighing in with my opinions based on you presenting it as being something you were unsure of, and I figured the "is this proper" question was part of your decision not being made. Though, maybe I'm wrong on that.
Either way, it sounded to me like you didn't see as cheating in an accomplishment, and I might not either, which is why I suggested you to do it if you want. But I don't want to push you to do it if you have any reservations.
What I did lately was I mess around a bit in some older versions. Namely, some of those versions were release 1.6, release 1.7, and beta 1.7.3, but I also started a fresh 1.20.2 profile to compare some aspects to a modern vanilla version (without OptiFine, since I typically use this in modern versions when i actually play).
The initial reason was to test for visual texture issues due to so many people supposedly having them on certain old versions, but I lucked out and didn't run into any issues with it, even with whatever Java versions were involved which would have no doubt been newer than what was around for these versions. Then it became something I was doing just to play around with them for a bit, and in doing so I did notice other things, and they started adding up, and honestly the experience made me appreciate modern versions more. None of this is meant to insult these older versions, but they definitely have some serious quality of life issues (at least on my hardware and software combination).
The first thing I noticed with all three versions was the incredibly low chunk loading speed (made much worse with v-sync enabled), even on what are pathetic render distances compared to the norms of today. I've been running up to 32 (or even 48 in fringe cases), and usually at least 24, and it's something else when 1.20 this loads faster than whatever these various older versions' definition of "far" is.
I can only imagine this is because modern versions are more multi-threaded with chunk loading? I don't know. But these older versions were loading chunks in so slow, and at least in the case of beta 1.7.3 I could walk around and it couldn't keep up at a pace that kept me from seeing chunk edges closer than the fog line, and even 1.20 doesn't have that issue anywhere near as much on way higher render distances (after it's finished loading them in, of course).
The trade-off, or course, is that these older versions are more free of the stutters modern versions have when loading new chunks (mostly just when generating fresh ones), and while it was a bit nice, I'd definitely take the much faster burst chunk loading.
The main thing these older versions had going for them was much faster new world loading. But that's only something you see once.
The other things that stuck out to me were the following...
The lighting errors... my goodness, they were everywhere in release 1.6 and release 1.7 (I didn't notice this in beta 1.7.3 though?).
The fog starts much closer. This isn't necessarily a bad thing and it's a bit nostalgic, but OptiFine has an option for this at least in newer versions and I like the choice. The older versions don't totally hide the chunk edges, at least not on far (though this might be because the chunks just never seem to finish loading). 1.6 in particular had an issue if I was using far (but not on normal or below) where if I looked behind me while moving in the opposiute direction, I would sometimes observe chunks closer than the fog limit just... unload after a while. This didn't happen on normal so I presume this is because the fog is anticipating a render distance of 12 or 16 but it's bugged to 10 in versions from 1.3 through 1.6.
Not being able to fly faster in creative was off-putting.
Beta 1.7.3 not having creative was off-putting.
Not being able to rebind sprinting to a key (I usually prefer to use the "r" key for this) and having to double tap forward was off-putting.
Not having v-sync in beta 1.7.3 and having to force it through the drivers was off-putting.
Not having a way to disable clouds in beta 1.7.3 was off-putting.
Not having my skin work in beta 1.7.3 or release 1.6 at all was off-putting. While it worked in release 1.7, there were issues (seemingly because my skin uses a thinner arm model and I guess 1.7 might not have yet had that).
The old harm sounds in beta 1.7.3 were off-putting (sorry to those who find them nostalgic, but I'd much prefer to be able to use the newer ones).
Not having mip-mapping below release 1.7 was off-putting, despite me disliking this feature being on even at level 1 before (nVidia seemingly does this overly aggressive on tree leaves it seems, which may be why I used to feel that way about it).
Not having round fog in any of these versions was off-putting (they use an nVidia specific function for it).
Not an "issue", but interestingly Advanced OpenGL lowered my performance (I only tested it in beta 1.7.3). I expected it to just not work or do nothing unless on nVidia hardware, but it actually made things worse (it was still consistently above refresh rate even with it on, but it was still lower than if it was off when I checked with v-sync off). Interesting. In the past the game was nearly unplayable for me with this feature turned off in versions 1.2.5 through 1.7, and the loss of it was part of what 1.8 perform so much worse for me back then.
Many of these I expected, and others I forgot about, but wow there's more quality of life issues with older versions I forgot about.
I'm sorry if this comes off as just calling old versions bad. That's not my intent, as I like these versions innately, but there were glaring quality of life things that stuck out to me going back to them and I can't say they don't matter.
The only other "issues" I ran into which weren't necessarily the fault of these versions was being unable to get any combination of anti-aliasing working without the infamous White lines (only tested with beta 1.7.3 since at least release 1.7 would be expected to be broken with it since that was when FBO rendering was added which broke it). This was admittedly disappointing because I almost consider this necessary (I achieve this with shaders in modern versions). Setting a desktop resolution of twice my native and then down-scaling works, but it's not a perfect solution as it minimized the aliasing more than removes it, and the UI size in beta 1.7.3 is limited to jumping from large to auto, whereas at that resolution something in-between would feel better.
All of this honestly made me appreciate modern versions more. I wonder if there's any mods or methods to work around any of these issues, but I'll admit I sort of lost my desire to playing them after seeing many of these things. I know there's a lot of things like "better than adventure" and players of these old versions so maybe there's some workarounds that have been made and some quality of life injections to some of these?
I also found the seed for the old demo version and looked around in it in beta 1.7.3 (I had no idea the demo used the seed "glacier") and found and revisited some old places I originally built in. The novelty wore off rather fast though, but it was still fun to do overall.
Also, I unfortunately didn't save the image (I wanted to show a few with this post but I got rid of them all...), but with release 1.6 I had a seed that gave me two desert temples within the same desert (and both simultaneously visible even on "normal" from above them looking down). Also, seeing snow biomes next to deserts was a classic one, haha. While I'm not a fan of that anymore, it was nice to see.
The laptop I had before the current one had the W key break right off the keyboard, hinge and all, and I entirely blame old Minecraft for that.
Okay, maybe it was my fault for playing too much Minecraft.
I will fight you IRL on that one! (not really). Player gets hurt, player goes OOAH, get outta here with that weird little "smack" noise. An alpha sounds resource pack is indispensable to me primarily for the OOAH (though I'm also very attached to the old door slam and old chest sound).
---
I've never seen much difference in overall chunkloading performance between older and newer, but I'm not asking the game to do anything like what you're asking visually. Still find myself shaking my head whenever you're talking about 24 render distances plus shaders! There is a specific exception: I do notice that my laptop really hates generating chunks in the huge tree LOTR biomes like Mirkwood, Lorien and Fangorn in 1.7.10, and gets a bit grumpy about the vanilla jungle biome in Tekkit Classic 1.2.5. Leaf light/decay calculations got a lot of back-end improvement at some point.
I don't generally perceive the endemic lighting glitches because they're so "normal" in my Tekkit Classic world and the 1.7 modpacks that I don't think about them.
One visual improvement I have observed is the disappearance of this
This screenshot was taken in 1.4 I believe, and I saved it because the world hole showing up at that precise spot at that moment gave me a glimpse of the stronghold I was looking for. I don't even remember the last time I saw a world hole post 1.7... actually, wait I do remember, one showed up while I was exploring in a 1.19 test world! But it's such a rare occurrence now that it really stood out and stuck in my mind.
Journals - Gregtech New Horizons | Tree Spirit Challenge [current]
A certain mod I named after myself does most of those; ever wonder why TMCWv5 took 4-5 years to release (an explanation here. "a year to refactor much of the codebase" - sound familiar? e.g. 1.8), or why TMCWv4.5 (mainly a bugfix / optimization / QoL update which added many features originally slated for TMCWv5) is so much larger than TMCWv4 and even my "World1_custom_client" is significantly larger than TMCWv4 despite not being a content update / mod?
(the size of the 1.6.4 jar is for comparison; when combined the total size is between the two alone as many classes are directly replaced)
(and yes, in terms of file size TMCWv5's source code is nearly as large as all of vanilla 1.6.4, the "backup source" at the bottom)
In fact, the source code for TMCWv5's cave generator alone is larger than TMCWv1 (although this is not a fair comparison since the zip files are compressed class files and even uncompressed class files are smaller, this also shows how small the vanilla code actually is, as seen for "World1", which combines 3 classes into one. This also does include some bugfixes but they have no impact on the size):
Here is a list of some of the QoL changes and bugfixes I've made for the next update of TMCW, (most of these have actually already been added to the public release of "World1", available in the thread for my first world, it can be called "enhanced vanilla" as opposed to an outright total overhaul mod):
Hoppers can now interact with composters, adding items to a composter below them and extracting dirt from a composter above them (note that only hopper blocks, not minecarts, work). Also added an optimization for hoppers which failed to move any items to/from an inventory (they will wait 8-16 ticks before running again, instead of every tick like in vanilla), also extended collision box for picking up items into the hopper itself (MC-89125).
Sleeping now only resets weather if it is raining or thundering (only rain time is reset), or there is less than 1 minute left before a thunderstorm (only thunder time is reset), avoiding a near-complete lack of weather if you regularly sleep at night (MC-63340).
Fixed MC-3626 (mobs unable to see through transparent blocks like tall grass and cobwebs, or attack the player if their or the player's head is in such a block; in the case of creepers/skeletons/witches/snow golems their sight range for attacking was halved when transparent blocks are in the way).
Fixed MC-26678 (screen not tilting based on direction damage came from).
Fixed MC-1246 (dying mobs are still targeted when attacking, blocking attacks; this also affects most other collision checks. A few mobs override "canBeCollidedWith", including the Ender Dragon and Wither, so they are still affected).
Fixed/reduced MC-145 and MC-59425 (explosions not dealing much damage or destroying blocks when centered within a transparent block; the center will be moved up to the next whole block if it is in a non-air, non-liquid block and the block above is air or liquid; e.g. creepers standing on snow layers).
Fixed MC-174759 (dragon eggs can teleport into or over the void).
Improved how the game determines if the camera is in water (MC-3615), as well as the player itself when reducing their air supply (the shape of the rendered liquid is used instead of its "height" property), as well as when effects are applied (the tinted overlay was not applied in third person, conversely, FOV was reduced, which are now reversed).
Fixed MC-135164 (mobs not visually dropping armor or held items on death).
Mobs now drop XP immediately when they die, instead of when they despawn; this was partly changed to ensure dropped equipment still counts towards XP dropped, and removes the main disadvantage of Knockback and Punch and enables the full duration of the "recently hit" timer to apply to XP drops (otherwise, a second is lost due to the death animation taking that long).
Fixed MC-5585 (Ender Dragon not taking additional damage from Sharpness enchantment).
Fixed various issues where leads would not drop when mobs died or despawned (MC-15084), or a bucket was used to pick up a leashed fish.
Boats now produce breaking particles and sound when they crash.
Increased output of firework recipe from 1 to 3; also added to Creative inventory and statistics.
Improved validation of attack reach so Giants can consistently attack and be attacked above their feet (it was previously dependent on where their feet were within a chunk section, most noticeable when near the top).
Dispensers can now shear sheep, mooshrooms, and snow golems; the shears will not be ejected if there is no valid mob and this behavior was also applied to buckets if they fail to place/remove liquids (filled buckets will still be ejected if there isn't enough room).
Improved spider AI (MC-151054, most notable with cave spiders in a 1x1 space in the ceiling); they will now jump down (climbing disabled) if they are directly above a target or have a direct line of sight to a target below them; falling through cobwebs also now negates fall damage.
Hostile endermen no longer become neutral almost immediately when exposed to sunlight, taking at least 10 seconds to do so (similar to how spiders were changed).
1 deep snow layers are no longer solid (you fall through them).
Changed carpet recipe to give 4 carpets instead of 3, matching the efficiency of snow layers, themselves changed to give 4 layers from 2 snow blocks (instead of 6 layers from 3 blocks), enabling them to be crafted without a crafting table.
Modified End generation to fix seeds like 3761987256467393916 in vanilla (generates an abnormally small and fragmented island); obsidian pillars can also generate on more uneven terrain.
I've even fixed many bugs which apparently still affect current versions; mobs glitching through fences/walls? Various errors with smooth lighting (a bug which has actually worsened, the only form that appears to have been fixed is smooth lighting underwater, and I also consider a lack of complete darkness to be a major bug)? Or even some of the ones listed above (e.g. the broken End generation. Giants? Mojang gave up on them as a lost cause in 1.8, completely removing their AI, while they are a naturally spawning mob in my modded versions, even in World1 (along with actual cave spiders and witches). Explosions are more dangerous when they aren't blocked so easily (creeper explodes on lower half.slabs, only the block it is on is destroyed because explosions don't consider the actual shape of a block; even snow layers will negate nearly all damage to entities nearby). Why do i still have boats able to crash when it annoyed so many (mainly because of lily pads and squid, neither of which cause them to crash)? Convenience, I also made it so they only break if crashing at near full speed so I can just ram into land and pick up the boat (dropped as itself, not planks and sticks).
That said, I do not experience some of the issues you mention in vanilla; as long as Vsync is not enabled (which I fixed) chunk loading is too fast if anything, often exceeding 500 chunk updates and causing stutters (the method the game uses to calculate how much free time there is for chunk updates between frames is suboptimal; I improved this to more accurately track the time, and added a slider to let you change it. Optifine attempts to do the same with a "chunk updates per frame" setting but that is not optimal either since the time take for an update depends on the complexity of a chunk section). With the default framerate limit of "balanced", or 120 FPS, vanilla 1.6.4 drops to 80-90 FPS when updates are high (it does remain locked at Vsync but only does 1 update per frame, and Vsync doesn't get enabled on game startup, you must toggle it off and on). Even modern versions still prioritize chunk updates, allowing FPS to drop to as low as 30, which is totally unacceptable - I still do, as they claim was the issue, treat the FPS limit as a minimum target to maintain at all times).
Also, the issue with Advanced OpenGL is that it works best when your GPU is significantly weaker than your CPU, as was the case on my old computer, where it doubled FPS when enabled and was needed to make my "double / triple height" terrain mods playable (the amount of rendered geometry due to all the caves underground being rendered would cause the GPU to run out of VRAM, resulting in severe lag down to single digit FPS, or even "Minecraft has run out of memory" as the process size exceeded the 32 bit limit. This may also give a clue as to why caves were nerfed to be much more uniformly distributed and mineshafts much rarer in 1.7, as the size of complexes in 1.6.4 can get quite extreme, to the point where I had issues without occlusion culling even on normal worlds (this may explain comments I got on my mod's thread back in the day like "I get barely 8 FPS when running this mod", which I found hard to believe given I got 10x that on an already very old computer). then again, the CPU-based culling method that replaced it in 1.8 was far less effective at culling hidden chunks; it shouldn't still be rendering 130 sections in this screenshot, but a few dozen at the most).
I also blame AMD and Intel for not properly using the hardware for it, instead implementing it (and I assume other OpenGL features) in software:
https://www.reddit.com/r/Minecraft/comments/28ydua/how_much_does_your_frame_rate_benefit_from/
Having said that, it doesn't have much of an impact on my current system, with an NVIDIA GPU, presumably since it is more powerful relative to the CPU, I get 1000 FPS anyway even without it (at 8 chunks, vanilla gets 400-500 on "far" / 10 chunks, and my modded versions get about the same at 16 chunks. Also, I've seen people, including yourself, claim that the game barely uses the GPU but this is not true, in fact, Task Manager shows a much higher percentage of the GPU being used and the performance increase since my first computer would be only 3x based on the CPU alone (per-thread), not the 10x that I actually see, and is close to the difference in GPU performance). I also reduced the amount of rendered geometry by about 20% by making chunks render in a circle instead of square (they are still loaded in a square, at least as of now, random block ticks also still occur in a 15x15 chunk square instead of an 8 chunk radius, like since 1.9, which is about 10% smaller in area).
Note that until recently (due to fixes to the drivers, not game itself, mentioned in the comments) even newer versions had issues with animated textures / mipmaps on AMD hardware, most apparent with modpacks or resource packs with a lot of animated textures:
https://www.reddit.com/r/feedthebeast/comments/12so510/is_an_amd_graphics_card_bad_for_modded_minecraft/
Apple has even given up on OpenGL entirely and the game in general could become unplayable on Macs if they decide to drop it completely (unless an emulator is used, or Mojang rewrites java Edition to use a more modern API like Vulkan, or a native OpenGL to Metal wrapper):
https://venturebeat.com/games/apple-defends-end-of-opengl-as-mac-game-developers-threaten-to-leave/
That said, the issue that some have with bugged textures on older versions is caused by a bug in the game itself, according to somebody who claimed to fix the issue for a mod for Beta 1.7.3 which had backported some rendering code from Beta 1.9+ (when they refactored some code they omitted an OpenGL call to set the "active texture", which seemed to be unnecessary at the time but GPU drivers are known for ignoring programming errors until specs are tightened):
https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/1294926-themastercavers-world?comment=294
Also, I should note that I never noticed many of the "quirks" in the game until I fixed them; as I only started playing in 1.5 I never understood all the hate for 1.3 until I fixed the issues it caused (a large percentage of my bugfixes are directly related to that version, e.g. the lack of directional damage tilt; and the latency issues caused by running an internal server (not lag per se as it is usually described as; a major issue is that the client and server do not sync their ticks, causing jitter, which I fixed by having the client tell the server when it can tick. Of course, there is still a round-trip latency of 2 ticks between an action performed on the client and the client receiving the result from the server; because of this, some people have made mods that revert the game back to the way it was before 1.3, but this does make a lot of sacrifices, such as no multithreading at all (the game has to tick the world, update chunks, generate chunks, save data, etc all within a single frame in order to be smooth, hence why versions like Beta 1.7.3 perform so poorly, and why I do not understand why "true singleplayer " is such a good thing).
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?
Haha! Yes, I know they are nostalgic for older players, but when you're playing as a girl it doesn't match up and takes you out of the experience a bit. That wasn't me saying "the old ones are bad". That was me saying "having the newer ones back-ported as an option would be preferred by me".
That's the thing; I'm asking these older versions to do less (not as far of a render distance) and they're slower despite it.
If my method of recording didn't lower my performance, I could take a video of loading 1.20.2 (without OptiFine, mind you) and show you that even a render distance of 32 will load the chunks in much faster than any of these versions did whatever values of 10/12/16 chunks they were trying to do. 1.6 in particular was acting like 1.14 where it'd sort of have missing spots at times.
The newer version certainly will stutter more while loading chunks, no question... but it's also doing it so much faster.
As for the chunk glitches, the only one I see in modern versions is what I believe is a known OptiFine issue. An empty sub-chunk with a block placed in it may be invisible until it updates, and yes this lets you partially see though terrain (at least mobs show up but there's just empty sky otherwise); zooming into it forces it to render.
There was also one 1.8+ introduced because its occlusion culling wasn't perfect so sometimes you'd also see missing spots (and these were consistent so once you found a spot/angle that it happened it was always like this), but I'm not sure if it's still there in modern versions. I suppose I could find out since I know one spot/angle in my oldest world that did it at least up to 1.14.
I did, however, see a thin strip (one chunk line) like in your image in 1.6. Once some chunks unloaded right in view (god limit of 16 versus internal server distance of 10 issue I guess) it loaded that strip in. I don't remember seeing that back when I actually played 1.6 though so maybe it's down to modern Java or modern software or something.
The really dark spots annoyed me though. I couldn't live with those anymore. It's one of those things that once you haven't seen it, you'll see it and go "how did we used to tolerate that?"
I'm aware of that, but your mod is practically its own version of the game, so I'm not sure how that would help me with only addressing specific issues but otherwise staying with the classic vanilla versions, especially in the case of beta 1.7.3.
I'm not naive to what you've accomplished with your mod, and I applaud it. But when I'm talking about issues in these older versions, I'm talking specifically about the vanilla older versions, not your mod which happens to be based on one of them and most likely fixed it.
Interesting, and I suspected this to a point. Modern versions are loading faster for me, but stutter more as a result. They go hand in hand. So maybe older versions weren't so much as immune to the issue (even if they may have been better) so much as they were avoiding it I guess.
My CPU is able to minimize the stutters in modern versions rather well (fresh chunk generation or playing high render distances will recording are where it's a bit of an issues though), but there was no mistaking it was almost (but not entirely) gone in these older versions. But they were loading chunks rather slow as a result.
Disabling v-sync certainly helped a little, but not completely, and I would find that it unacceptable to have to play without it in order to get faster but still not acceptable chunk loading speed.
I think I have the chunk updates set to 3 in OptiFine these days? I'd have to check. I used to run 5 back on my old CPU in old versions but I did eventually find this was sometimes a "less is more" setting. Higher values speed up chunk loading but it's already rather fast at 3 updates. I basically have to raise render distance to 48 to make it take longer than ~10 or 15 seconds to load it all (and even then, once it does, it's able to load chunks at a speed before you notice it showing up before the god line when not generating new terrain or flying).
This is a good solution I think. Delaying chunk updates to keep the frame rate up to the set target is the way it should be, even if that means slower chunk loading/updates.
I figured it might due to my non-nVidia GPU, because the setting was supposedly nVidia specific (or at least in results, based on what you later say on nVidia being the only one to do this in hardware). The old CPU I had was a 2500K and the old GPU I had was a GTX 560 Ti, and the differences between my current CPU and current GPU is far greater on the GPU side (given CPUs have advanced more slowly than GPUs in that time), so if it was already CPU favored back then it should be more so now and I should be seeing more of an increase, but instead it's a decrease. So I figured it was down to "not nVidia".
Back then, disabling Advanced OpenGL meant I wasn't even holding 60 FPS all the time if I'm remembering right, and I can't remember the exact game version but it was definitely 1.6 or older so that would have meant it wasn't even able to hold that on the lower render distance limits from back then (10 in the case of anything but 1.2.5, since that's where I started, and for most of my time on 1.2.5 I was actually playing at short [4 chunks] anyway since I was on a much weaker PC before that).
Yet, without Advanced OpenGL in modern versions since it's gone of course, I'm now able to load up 48 chunks and hold 60 FPS. It's going to stutter loading them, and it's not going to keep up flying... but the steady frame rate is there, when it wasn't back then even on substantially lower render distances.
Stuff like this makes me question how much lighter those older versions actually were, if at all, or if much of it was instead down to "we were asking less of it/had less standards/didn't notice".
But I'm sure modern Java versions and drivers might actually be hurting performance and behavior in these older versions as well so it's hard to compare.
Unfortunately, part of that is increasingly the fault of software too though. Even back then, I think the round fog was one such example? Modern versions seem to do this just fine on AMD, and I believe you said this was always possible but they used an nVidia specific instruction. nVidia graphics hardware has increasingly taken most of the market in the last ten or fifteen years, so it's reached the point it's become a feedback loop (or a self fulfilling prophecy of sorts) where software just sort of targets it by default because that's what the vast majority of the market is. Currently nVidia has anywhere between a 75% to 80% market share hold depending on source. You're seeing the same thing on Chrome versus Firefox again in recent years because Firefox has shrunk back to a minority of the market, even though Firefox certainly does most things properly (way back when, Firefox did things right and Internet Explorer did not, yet things rendered "properly" in the latter specifically because it was written to do so). So part of this is stuff targeting specific stuff and not always the alternatives doing something wrong.
If I'm ever making statements along the lines that the GPU is barely being used in Minecraft, it's not that I'm saying it can't ever use it. Certainly if you disable v-sync especially, the game will run to the limits of whatever bottlenecks it first, and that will usually be the CPU or GPU, but even if it's the CPU, the GPU use will certainly rise relative to if playing with v-sync. That's just normal.
When I ever say something like that, it's more in reference to the fact that in most games, you'll almost always be GPU bottlenecked, but Minecraft doesn't have anywhere near that much GPU demand. Instead, you're almost always CPU bottlenecked instead.
You can get by with much less of a GPU in Minecraft relative to most other games is what I'm saying.
The chunk loading performance is still a problem in the game even on modern hardware and across different vanilla versions
That's not even mine and Chaptmc's biggest problem with the game anymore though, it used to be, but now it's the ludicrous changes that happened in version 1.20 and 1.21 that players are forced to put up with on bedrock edition. And why I and friends are no longer active on the game, I briefly only revisit to check if the server is working in case anybody else in the whitelist did decide to join, but as a normal gameplay experience? forget it, I'm not wasting my time if Mojang are just going to parasitically impose their elitist design choices on everyone. For people who don't even like the newer versions we don't even get the option to switch back outside of mods if we want to continue playing in multiplayer, so it sucks for people like us, as the sandbox experience is now gone.
I've got many other games in my collection that I do frequent including what's on my Steam account, and I have a friend who plays with me on Streets of Rage 4 since we enjoy playing beat em ups.
The "lines of missing chunks" was not due to poor chunk loading per se but a bug in the game where it didn't properly flag chunks as "dirty" if it happened to update a chunk while it was empty of data, then got filled right after, which is one of the things I fixed (this is especially common when using Far render distance because the client allocates enough sections for a render distance of 12 but they are only loaded up to a distance of 10 so there is a 2 chunk wide strip that is empty).
Also, wondering how easy it was to fix?
public boolean skipAllRenderPasses() { return !this.isInitialized ? false : (this.skipRenderPass[0] && this.skipRenderPass[1] && !this.needsUpdate); // This second line is the fix! }https://bugs.mojang.com/browse/MC-129?focusedId=152320&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-152320
Yes, that's it - you'd never believe just how simple so many bugfixes are (the hardest part is figuring out how to fix them). Here is a screenshot I took while flying into new terrain with the render distance set to 16 - no unrendered chunks anywhere and a stable 75 FPS with up to 600 chunk updates, the server was only using 1/5 of its allotted tick time, so even 32-48 chunks would be no issue (the area increases by the square but the increase in generated terrain, and required chunk updates to keep up, is linear. A 33 chunk wide strip averaging 6 sections deep is 198 sections, then double that as decorations spill over into the next chunk and you get an average of 272 chunk updates per second while flying at 11 m/s):
Setting FPS to unlimited does lower chunk updates (or more accurately, with less variation as only one can be done per frame now) but still enough to keep up (there will always be at least one update per frame, which is also true of vanilla; Optifine's setting forces the game to do at least the specified number):
Another thing that helps is making the game more aggressive at NOT updating chunks off-screen (I believe that 1.8 may not do this at all, so you turn around after moving backwards and see chunks render in, or I seem to recall that happening), it (vanilla as well) also prioritizes chunks within a 3x3x3 volume around the player, and otherwise within a diamond-shaped area centered on the y-level of the player. Newer version also treat world generation in a similar manner; if you move too fast only a narrow strip of chunks will be generated, while 1.6 always generates the entire width, so at after a point it will be slower (this did annoy me though when I wanted to generate some terrain in 1.8, 1.9(?) and Unmined showed gaps, whereas in 1.6 it was always enough to be within 2x the render distance of the last pass).
Also, I experienced some rendering oddities with Optifine as well when chunk loading was set to "smooth", I'd place a block and sometimes it wouldn't render, or there would be rendering artifacts (lighting) along some chunk borders when moving around (fixed by triggering an update). However, the much smoother chunk loading performance was worth it (the cause appears to be due to the fact that the "smooth" setting splits chunk updates into smaller pieces if they took too long and it didn't flag the whole chunk as dirty if any block changes occurred between incremental updates. I actually experimented with a similar idea but never implemented it due to various issues, like tile entities not rendering, although I did end up changing TE rendering so instead of registering their renderers during a chunk update they are registered when the client receives the title entity, helping to simplify the chunk update loop, which doesn't need to check if a block has a TE).
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?
This is true, and somebody even replied to a bug report claiming that the fix was "really easy" but they unfortunately never posted it, nor have I been able to find any results on how to make OpenGL use "eye radial" fog (without using modern shader-based rendering, that is. I assume that this was not what they were thinking of if the fix was as simple as they claimed):
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?
On the subject of missing chunks, there have been two such issues that have occurred, one in Alpha and up to 1.3 Beta where if you traveled more than 300 chunks or so in a short amount of time (such as going into the Nether), random chunks would reset their generation back to default, erasing any changes made. I had a part of my house get erased in such a manner after coming back from the Nether. The other one occurred in 1.6.4 and in 1.7.10 where entire swaths of one chunk wide sections (usually around 6-8 chunks long) of the world would not render. If you were mining, you would suddenly encounter zero lighting. You could correct this by logging off and back on, but there was another issue that could occur if you saved the game with the chunk error on the screen. It made a large part of my base just disappear, in much the same way the other chunk error in Alpha reverted the terrain in part of my house. The trick to avoiding this was to travel outside of the chunk loading range of the affected chunks and then re-enter the range. This fixed the lighting and rendering problem. I never ran into this in 1.12.2, in any of the packs I've played (Stoneblock, Direwolf20 and Feed The Factory)/
Now to what I have done recently. I unlocked plastic production, which leads to chemical science and ultimately to nuclear power. I have already obtained substantial amounts of the ores from the Creeper Data Model, and both it and the Wither Skeleton one have reached self aware tier. I have about 13-14 K of Boron, Lithium and Magnesium, all of which are needed for Nuclear Reactors. At first, Nuclearcraft Reactors are not that powerful, and you just burn the fuel away, so it is best to supplement it with other forms of power like oil until more powerful fuels can be made. The highest tier fuel appears to be HECf-251 Oxide Fuel, which generates 8400 RF/t and has a base process time of 45 minutes (I'm assuming this means how long it takes to burn one unit of fuel). In a normal version of Nuclearcraft where the radiation mechanic is enabled by default, all of the fuels are radioactive, with the higher tier ones being more likely to kill you in seconds without some form of radiation shielding. And there are nuclear wasteland biomes which are radioactive and spawn a hostile zombie-like mob called a Feral Ghoul. These shamble about like zombies, but when they get close to you, they jump at you like spiders, and irradiate you when they attack.
To make liquid plastic (essentially polyethylene), you take Naptha and combine it with Hydrogen in a Salt Mixer to get Ethylene gas. This is then combined with Oxygen to get liquid plastic, which is then made into ingots in a Fractionating Still at a cost of 200mB per ingot. I have so far made around 75 plastic ingots. Hydrogen and Oxygen are obtained by running water through an Electrolyzer to break it down into H, O and a little bit of Deuterium. This machine is the single most power hungry one I have made at a base 4000 RF/t, and a process time of 240 seconds. This is as long as making Nuclear Pasta in Satisfactory, an end game component for that game. It can be sped up, with every speed and energy upgrade put into it together will increase power and speed by N+1, so 1 will be x2, 2 x3, 3 x4 and so on. I have found that 3 of these at 16,000 RF/t brings my total power usage to around 25,000 RF/t, about 55.5% of the max output of 8 dynamos. And I have decided to add a 9th one, even though I will not be able to use the additional 625 RF/t that the HV conduits cannot carry.
All of gases, which include O, H, Deuterium and Ethylene make a hissing sound like gas being released when you empty or fill a bucket, and the 'fluid' rises to the top of any tank you put it into. The buckets when you look at them in JEI or have one in your inventory are rendered upside down, and any item with an upside down bucket like this is almost always going to be a gas rather than a fluid.
The Salt Mixers are less expensive to run, with a base power of 1000 RF/t and process time of 30 seconds. I increased these to 3K RF/t and reduced the process time to 10 seconds. The Fractionating Still uses 1000 RF/t to produce the plastic ingots. In addition, I made some electric motors, machine chassis and basic plating, as well as Ferroboron Alloy (steel and boron) and Tough Alloy (ferroboron and lithium). There's also a Nuclear Furnace I can now make that smelts items almost instantaneously using uranium or thorium ingots or dusts.
Just spent the morning, or at least some of it; restoring my kelp farm to a "factory setting".
The only initial changes long ago was swapping the furnace for a smoker, but it was pretty self sufficient at not only keeping itself going but enough kelp blocks for the furnaces in storage AND the super-smelters. Then I got greedy. I changed the shoot to the smoker to a two wide shoot installing another hopper into smoker at the bottom and extended the opening at the top for double efficiency.
Now whether this is me letting it run dry or it just not being as effective, it's just not as self dufficient anymore, I barely get the turn-over I used too. So as a result, I've had to nick the stacks of kelp blocks from the furnaces in storage to sustain it, and reduce the two shoot back to a single shoot-smoker. Now I have 8 out of 9 furnces to replnish, but it's at least back to how it was.
It's been like this for a while, I should never have meddled.
Closed old thread
16yrs+ only
Doing some checking, Mojang seems to have changed this with 1.17 (I only checked formal first release versions, and 1.16 still has the old "line fog" and 1.17 has the rounded fog, so likely one of the snapshots for 1.17 would be when this changed). Since the OpenGL requirements increased for 1.17 I think, they probably went with that as their method as opposed to whatever the quoted fix you found claimed.
My friend recently built towers of cherry and bamboo wood. Those are unique I guess. I am going to keep building mine of amethyst and its related rocks, which blend with both woods decently well.
Most things from a similar biome (or using the log with its planks) tend to work well, but I like playing with things and seeing what else they work with.
Black colored stones seem to work good with the new cherry wood.
I wish we had White stone... (no, not diorite; I mean something like marble or a new end stone or wherever it comes from as long as it's White and gives a smooth, brick, and other variant type like normal stone and deep slate has.)
Agreed, it's not like white concrete or terracotta has slab and stairs. I only polished diorite (Sparingly) because of my resource pack because it's either that or quartz. Calcite is okay but again I don't think it has slab/stairs(?) We've got plenty of dark blocks, black blocks/grey blocks, so some more white stone/marble or brick would be most welcome.
Closed old thread
16yrs+ only