I find two light level 7 spots here as well. This is a pic of one of the causative trees sets from underneath. You can see some light spots and that's the light tracker system blocking placements that would make things too dark. I suspect recursive decoration issues are causing this occasional problem. When I get to some smaller-treed forests (which don't have recursive generation) I'll do some more searches to try to pin down the cause. It is a fairly minor problem at present - five single blocks so far in render distance of my base with light level 7.
I think if you were working under 1.18 or above where a light level of 0 is needed for spawning, it would go a long way here.
I know you dislike daylight spawning as a principle, but I've never minded that the occasional mob could spawn in the day since it was generally so seldom, and can already happen even in some vanilla forests anyway (well, jungles and especially roofed forests).
I'm going to start with some river travel. RTG rivers are great for exploration and travel - although they curve, they continue going in roughly one direction for considerable distances; the banks are low and so you can see pretty well from them, and they are almost always wide enough for boating.
I don't really have any major reservations against modern rivers, and I like how they can sometimes cut into canyons, but I do see why you prefer them another way. They seem more useful for exploring when they wind less and tend in one direction, but I also like seeing them wind back and forth at times. Maybe if modern rivers did this some of the time instead of as the norm, and on a smaller scale instead of a larger one that disrupted one direction travel, it wouldn't be an issue, but I'm not sure if making those both coexist is possible.
The scenery (here from that map location) is great. You can see that the different temperate biomes are all pretty compatible with each other - here plains, forest, birch forest, and birch forest hills. It's really a pity that vanilla has biomes relatively large and segregated from each other (didn't we learn segregation was bad back in the 60's?) You're seeing them more mixed up here partly because of the increased sub-biome variety in the new Geographicraft, although I'm not sure exactly how much is that new variety and how much is biomes just happening to be jumbled up a bit. I think that's a good thing, though, because when it's less obvious what's going on in the generation system the terrain feels more organic and real.
Admittedly some of the benefit is from RTG, which increases the blending of biomes by having their terrain and flora effect extend further from their official boundaries, but I did some tests of Geographicraft sub-biome variety with vanilla terrain and I still thought it was an improvement.
I think 1.18 was a step in the right direction, but this is an example of why I think the next step of formally dropping biomes might be a necessary next step, and hopefully Minecraft explores that possibility in the future.
What is the "Tan" colored stone (?) on the hill in the second image?
A little further up the river the terrain shifts to cool zone biomes, Taiga and Roofed Forest (which I moved to cool in Geographicraft for more variety in the zone.) Roofed Forests are pretty dangerous in RTG, but this river happens to be running on its edge so I'm fine.
This is amusing. Back when the roofed forests were being announced and described, before I ever saw one, I was almost imagining they would be exactly as what you show here. Basically, taller than they ended up being, and with slightly different canopies. I didn't mind the way the canopies of the vanilla ones ended up, but I thought they trended towards the short side and it was a bit disappointing.
The existing tiny trees probably force everything else to conform or it doesn't fit in. The jungles existed beforehand so the large tree was sort of their exclusive "thing", and then the old growth tiaga came along but was rare and an exception. I wish they'd just go the full way and overhaul tree generation so all forests are much better.
I fear they're doing it due to anticipated complaints of those who want easy mass farming. *sigh* You'd spend more time on one tree but get more wood out of it, and yes I'd know it would still be a net increase in time due to having to spend time pillaring up in some cases, but the increased wood per tree still offsets it a little, and the increased visual benefit is worth it. If need be, just... include a new enchantment that works like the tree felling mods for those who want easy mass farming.
But I hope they're just not doing it since it's been that way from the start and they just never visited overhauling tree generation yet.
The views are - everything I hoped for. I've wanted to build an Extreme Hills base with great views from way back when 1.7 was released, with the new "high plateaus" obviously intended for base building. Then I wanted it even more once I started playing with RTG and then even *more* after I designed the new RTG ridged mountain system. But - I've never done it (although in my To the Edge of the World journal I had a great view of an RTG-style BoP mountain). Maybe this time? This is really quite a spot.
That second one is begging for a settlement.
During my troubleshooting for my PC issues, I started a new world, and... it's been something else. A lot of mountainous, and high hills and slopes. Multiple peaks extending above the first cloud layer at 192, and many relatively close. If I ever have a need for a new hardcore world, my next one will drop the "I have to go with a random seed and stay with whatever I'm given" and just going to use this seed for sure.
Your pictures are similar (well... as similar as modded 1.12 and vanilla modern can be) but in the case of this seed it is temperate/warm biomes, and there's some jungles along terrain like this that look gorgeous. Probably because the trees are taller. But I still haven't fully gotten over the novelty of biomes being uncoupled from terrain elevation so it's still a treat to see when it's all massive hills and slopes with savannas, regular forests, and whatever it wants to be overlaying it.
Using a structure system would be quite complicated, as the random number seeds would have to be saved somehow so the generation would be the same in the other chunks. Maybe the pieces could be generated in advance and saved but there isn't a place in the generation system to save a structure piece and then later guarantee the chunk will be generated and the piece placed. Again, it's possible in the abstract but again, I'm reluctant to tussle with Forge, which is playing a pretty complicated game with chunk loading these days.
This is pretty easy to do; if you know the maximum size of a structure you can scan a range of chunks around each chunk that is being decorated and place any parts that intersect the current chunk, no need to save anything since the seed is being set for every chunk within the "gen range", although this does mean that if there are any changes to the structure itself or world generation you'll end up with cut-off structures (this is unavoidable anyway for structures that start in new chunks; when I loaded a world created with my "double height terrain" mod in vanilla mineshafts generated sticking into vanilla chunks as the game remembered the attitude they were offset to; I've since disabled structure-saving for mineshafts so they will just get cut off but either way vanilla mineshafts will be cut off at the old-new chunk boundary since they can't generate in existing chunks (apparently, Mojang enabled ocean monuments to do so, and I know that mods have "retrogen" capability)
Caves are different from structures in that they act on whole chunks (technically, an array which represents the block data that will be used to initialize a chunk, which doesn't actually exist yet at this point) but use the same principle of iterating over a range of chunks around each chunk that will be carved out/decorated and only altering blocks within that chunk by checking if they intersect it; for each chunk within range a random number generator is seeded based on the coordinates of that chunk so it will always be the same for every chunk, regardless of what the current chunk is:
public class MapGenCavesRavines
{
public void generate(int chunkX, int chunkZ)
{
this.chunkX_16 = chunkX * 16;
this.chunkZ_16 = chunkZ * 16;
this.chunkCenterX = (double)(this.chunkX_16 + 8);
this.chunkCenterZ = (double)(this.chunkZ_16 + 8);
for (int x = -8; x <= 8; ++x)
{
int cx = chunkX + x;
for (int z = -8; z <= 8; ++z)
{
// Reduces number of chunks compared to a square range
if (x * x + z * z <= 65)
{
int cz = chunkZ + z;
long chunkSeed = ((long)cx * this.seedX) ^ ((long)cz * this.seedZ) ^ this.worldSeed;
this.rand.setSeed(chunkSeed);
this.generateCaves(cx, cz, x, z);
this.rand.setSeed(chunkSeed);
this.generateRavines(cx, cz);
}
}
}
}
private void generateCaveNode(long par1, double par6, double par8, double par10, float par12, float par13, float par14, int par15, int par16)
{
// Checked once per iteration of a loop which traces out a tunnel; var29 is the current radius of a tunnel
// and is used along with a margin to see if it intersects the current chunk being carved out
double var29_2 = var29 + 9.0D;
if (par6 >= this.chunkCenterX - var29_2 && par6 <= this.chunkCenterX + var29_2 && par10 >= this.chunkCenterZ - var29_2 && par10 <= this.chunkCenterZ + var29_2)
{
// Converts from absolute to chunk-relative coordinates
int var55 = MathHelper.floor_double(par6 - var29) - this.chunkX_16;
int var36 = MathHelper.floor_double(par6 + var29) - this.chunkX_16 + 1;
int var57 = (int)(par8 - var31);
int var38 = (int)(par8 + var31) + 1;
int var56 = MathHelper.floor_double(par10 - var29) - this.chunkZ_16;
int var40 = MathHelper.floor_double(par10 + var29) - this.chunkZ_16 + 1;
// Limits bounds to that of the array used to hold the data used to initialize a chunk
if (var55 < 0) var55 = 0;
if (var36 > 16) var36 = 16;
if (var57 < 1) var57 = 1;
if (var38 > 120) var38 = 120;
if (var56 < 0) var56 = 0;
if (var40 > 16) var40 = 16;
}
}
}
Structures use a list to cache the individual structure maps and are split into initial structure registration and the actual placement into the world (these can also be done at the same time, call the "generate" method right before "generateStructuresInChunk", or merge them); the "structure data" I refer to having removed here was only added in 1.6.4 and simply ensures that their bounding boxes are saved so structure-specific mobs can spawn in "old" structures after updating to 1.7, or other versions which alter structure locations (older versions simply recreate the bounding boxes based on the current version). There are other reasons to save data, including structures which generate at a specific altitude dependent on the terrain (you'll get structures split in half vertically if this data is not saved since it can only be recorded within the current chunk. This could happen before 1.6.4 but only if a structure was partly generated across multiple sessions as the in-memory objects would remember the altitude):
public class MapGenMineshaftTMCW extends MapGenStructure
{
public void generate(IChunkProvider par1IChunkProvider, World par2World, int chunkX, int chunkZ, byte[] par5ArrayOfByte)
{
this.worldObj = par2World;
// Reduced gen-range to 7 chunks since mineshafts reach a max of 100 blocks from the center (80 + 20, length of
// a corridor with 4 sections)
for (int x = -7; x <= 7; ++x)
{
for (int z = -7; z <= 7; ++z)
{
this.generateStructures(par2World, chunkX + x, chunkZ + z, chunkX, chunkZ);
}
}
}
// Removed saving of structure data for mineshafts
protected void generateStructures(World par1World, int chunkX, int chunkZ, int par4, int par5)
{
if (!this.structureMap.containsKey(Long.valueOf(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ))))
{
if (this.canSpawnStructureAtCoords(chunkX, chunkZ))
{
MineshaftStart var7 = new MineshaftStart(this.worldObj, this.rand, chunkX, chunkZ);
this.structureMap.put(Long.valueOf(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ)), var7);
}
}
}
public boolean generateStructuresInChunk(World par1World, Random par2Random, int chunkX, int chunkZ)
{
int blockX = chunkX << 4 | 8;
int blockZ = chunkZ << 4 | 8;
boolean var7 = false;
Iterator var8 = this.structureMap.values().iterator();
StructureBoundingBox bb = new StructureBoundingBox(blockX, blockZ, blockX + 15, blockZ + 15);
while (var8.hasNext())
{
MineshaftStart var9 = (MineshaftStart)var8.next();
if (var9.getBoundingBox().intersectsWith(blockX, blockZ, blockX + 15, blockZ + 15))
{
var9.generateStructure(par1World, par2Random, bb);
var7 = true;
}
}
return var7;
}
}
public class MineshaftStart
{
public void generateStructure(World par1World, Random par2Random, StructureBoundingBox par3StructureBoundingBox)
{
Iterator var4 = this.components.iterator();
while (var4.hasNext())
{
MineshaftComponent var5 = (MineshaftComponent)var4.next();
if (var5.getBoundingBox().intersectsWith(par3StructureBoundingBox))
{
var5.addComponentParts(par1World, par2Random, par3StructureBoundingBox);
}
}
}
}
The biggest issue in your case is that you'd need to know the altitude of the ground at the base of the tree; village buildings attempt to measure the average ground level but it can only do so for the first part to be placed, which can be as little as a single block in size (i.e. only one corner intersects the chunk currently being decorated; the method "isVecInside" checks if a position is within the bounding box, in this case, of the populated area):
protected int getAverageGroundLevel(World par1World, StructureBoundingBox par2StructureBoundingBox)
{
int var3 = 0;
int var4 = 0;
for (int var5 = this.boundingBox.minZ; var5 <= this.boundingBox.maxZ; ++var5)
{
for (int var6 = this.boundingBox.minX; var6 <= this.boundingBox.maxX; ++var6)
{
if (par2StructureBoundingBox.isVecInside(var6, 64, var5))
{
var3 += Math.max(par1World.getTopSolidOrLiquidBlock(var6, var5), par1World.provider.getAverageGroundLevel());
++var4;
}
}
}
if (var4 == 0)
{
return -1;
}
else
{
return var3 / var4;
}
}
Note that if "getAverageGroundLevel" returns -1 it will skip the piece (for now) but it can still result in as little as a single block being measured since as soon as the field is set to a valid value it won't check again (ensuring the average ground level is the same for each subsequent section, this is also what structure-saving saves to ensure consistency between sessions):
public class ComponentVillageChurch extends ComponentVillage
{
public boolean addComponentParts(World par1World, Random par2Random, StructureBoundingBox par3StructureBoundingBox)
{
if (this.field_143015_k < 0)
{
this.field_143015_k = this.getAverageGroundLevel(par1World, par3StructureBoundingBox);
if (this.field_143015_k < 0) return true;
this.boundingBox.offset(0, this.field_143015_k - this.boundingBox.maxY + 11, 0);
}
}
}
Another issue I've thought of - the game doesn't fully update lighting until a chunk's neighbors have been loaded, which is why you see a border of unlit chunks on this map (since 1.7 this is saved as "LightPopulated", I use a similar system to keep track of which chunks have been lit, I can even see where I've been in my first world since I added the NBT tag for it (green = relit, red = pending a relight, gray = no tag present); as I only process chunk relights within the chunk ticking area (a 15x15 chunk area prior to 1.9; example with the render distance set to 16) you still see lighting errors in chunks further away at higher render distances, mostly under overhangs, including trees. 1.7 probably does something else, I just use the sequential relight checks that vanilla has/had (in vanilla 1.6.4 you'll see lighting errors in newly generated chunks be fixed (very slowly) but if a chunk is unloaded before it has been fully checked it will be left incomplete, hence the persistent lighting errors and the need to save the progress, I also made the checks much faster; vanilla takes 25.6 seconds to fully check a chunk, and that is just server-side; the client is 22.5 times slower as it only checks 10 chunks per tick).
I think if you were working under 1.18 or above where a light level of 0 is needed for spawning, it would go a long way here.
I know you dislike daylight spawning as a principle, but I've never minded that the occasional mob could spawn in the day since it was generally so seldom, and can already happen even in some vanilla forests anyway (well, jungles and especially roofed forests).
Hardcore, basically. You can't do focused work in a forest if a Creeper can come up and blow you to smithereens. Roofed Forests I don't mind, because they're *supposed* to be dangerous, and Jungles are acceptable on similar principles.
What is the "Tan" colored stone (?) on the hill in the second image?
It's one of the Underground Biomes stone types. I didn't check which one, but I think it's Red Granite.
This is amusing. Back when the roofed forests were being announced and described, before I ever saw one, I was almost imagining they would be exactly as what you show here. Basically, taller than they ended up being, and with slightly different canopies. I didn't mind the way the canopies of the vanilla ones ended up, but I thought they trended towards the short side and it was a bit disappointing.
You're a lot more tolerant than I. I always thought the Roofed Forest trees looked cartoony and silly, totally inappropriate for the most dangerous day biome. They're tolerable in some texture packs, but in vanilla - yuck. And regardless of texture pack, having a 2x2 trunked tree so short is inexcusable - even the lazy aren't going to have any trouble with a Jungle Giant-style spiral staircase. I so sometimes think 2x2 Roofed Forest trees would be better, given their height, but not enough to write new tree routines.
That second one is begging for a settlement.
Those two shots are very close, almost a panorama. I couldn't get the whole bay and the ridge into the same shot.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Well no, I feel the same as you in that roof forests are as much in need of changes as most of the rest. I just think the low height was the real major issue with them. Being thicker, low height, mostly flat tops, and packed so close is what makes them "cartoony". Oh, and it's probably the giant mushrooms haha. But if they were taller I could forgive the rest (this would woodland mansions fit in better as well), even if they still weren't great.
I just found it interesting that when Mojang announced/described what they would be, I was imagining something close to what you pictured, and then those "cartoon" forests came.
That's why I made the other comment about how I think Mojang is constraining themselves to short height trees probably because it's what the game started as and what most of the tress (which are oak or birch) are. That, and the complaints it might cause changing them. Just imagine "the game just keeps getting worse, I have to spend so much time just to get wood" or "this feels like a mod, it isn't Mincrafty, can't Mojang come up with their own good idea". I'll admit it, sometimes I get why Mojang does stuff despite players acting like the existence/threat of their criticism should be the reason they don't do it. The community is too vast and full of wildly different desires now; Mojang is going to be criticized whether they do a lot, the safe amount, or nothing.
So I'd like to see the developers have room to experiment while still taking feedback into consideration. Problem with that approach is once they put the development effort in, straying from that might cause a huge waste of time and effort, and if they communicate it early, well... take a look at 1.19 getting poor reception not because it was bad, but just because it wasn't better because more stuff was teased (and people attached the chat criticism to it when it came in a later sub-version).
HOLY COW THIS IS FAST!!! I reach the unfrozen river astonishingly quickly and zoom off into the water, where I slow to the normal, although still brisk, vanilla boating speed. I don't remember ice boating being *this* fast, was it accelerated between 1.7 and 1.12? Or did I just forget?
I boat most of the way home, but get off at the Birch Forest M/ Flower Forest area for a couple of reasons. The first, here, is just to show the super-giant trees from underneath. The new RTG Birch Forest M inherits the regular RTG Birch Forest's characteristic of throwing in a few Oaks in some but not most forests, and here there's a supergiant Oak as a result. You can also see some of the weeping growth pattern the biggest RTG Birches have.
And doesn't everybody love a good Flower Forest shot? But maybe even more so with the RTG trees behind it.
Here, roughly, is the area we saw at a distance through a forest clearing in Episode 03.
If you look closely at the extra-big Oak there you can see a single branch block sticking off to the left about halfway down the trunks. That's the lighting tracker canceling a branch that would cause lighting trouble. This is a part of the reason the really big trees don't have as many long lower branches as you might expect - you can only put so many branches onto a Minecraft tree before getting lighting problems, and there are already plenty of branches higher up.
And, finally, here is a closeup of the new "medium" size RTG Oak, which might be considered more "oaky" than the big version. It's rounder, partly because since it's smaller, so it's not pushing on the limit of the number of branches.
Here's a view from beneath, showing the thicker limbs. The branches here are always connected orthogonally, which makes them more chunky looking. I wanted both an orthogonally connected and a diagonally connected Oak model, for variety.
Then I go home overland, checking for lighting issues as a I go. This is a vanilla lighting glitch, and disappears when I place and remove a torch. But I do find a similar looking glitch which is from RTG and doesn't disappear after a temporary torch. That's almost certainly from recursive generation confusing the light tracker system. That's not an easy fix and I'm not looking forward to it.
I do have a Creeper come at me at one point, so there are gameplay issues from lighting. I get away without trouble, but I don't know whether it was from a vanilla bug or from RTG.
By the time I reach home it's almost dark, so I quickly grab some Paperbark paper and then head down for some mining.
Some pretty successful mining!
I head up early hoping to catch some mobs to kill but
Foo. Can't chase mobs and drops with *him* around. But mysteriously:
When I check from the roof 30 seconds later, it's gone! I thought it was too close to despawn. And look, there's a spider! But - there's also some pillars that look Seljuk. I though I was well out of town. I hope I'm not going to have construction in my current base.
My first string! I'm going to pretend those Harvestcraft cobweb trees don't exist, because that's just *too* easy.
And then off to the south to take the river that way.
It goes almost no distance at all before running off the map to a map I don't have enough paper to make. So I get off the boat and continue on foot.
Near the corner of the map I encounter this mini-swamp. But - why are the leaves brown? Isn't it too soon for autumn? Hmm, in my last journal 82 episodes for four years; 82 divided by 4 years divided by 4 seasons is - 5 - oh.
Then this nice sweeping Plains view - but with a little variety to keep it interesting.
Around here I get informed of a Millenaire sheepherder - which could be very handy, because he sells wool, and I've only encountered 4 sheep so far in all my explorations, and I killed 3 of them for my bed so I can't breed any. I don't have any money or trade goods to buy them with at the moment, though. Unaccountably I neglect to get any pics.
Beyond his hut is a largish RTG Scenic lake, which I boat, getting this view of the Acacia tree cluster I saw in the distance in the first episode.
Then I visit the Seljuk village on the way home to see what I could sell them. They'll buy cobble, which I have lots of, but not for much. They'll pay more for paper, which I can generate pretty easily with my Paperbark trees, so maybe I'll plant a bunch more of them to produce trade goods.
They've been constructing, and they've built this wall around the town hall. It's a bit inconvenient for me, as the only opening faces away from my base area.
I do a round of paper collection, and plant my Autumn crops, once again pushing past dusk and once again getting away with it.
Then another round of mining during the night. Before I head up I convert 8 stacks of Soapstone cobble to vanilla cobble, amusingly getting the Stone Age achievement, which I hadn't gotten before because I was only mining modded stone.
Then a quick snooze before trying to catch some mobs in the morning.
Three creepers. So much for mobhunting in the morning! I check the other side to see if I have an exit:
Ooh. DEFINITELY Autumn. And it looks like I have a problem with the Seljuk village. That gateway wasn't there before, nor was that building (probably a house) to the right. So the village goes all the way to the fishing shack, which is an inconvenience for me as I was planning to build a base on the area to the right. This "village" is going to be HUGE when it's built out, which seems like it will happen relatively soon; they're getting a lot done with me here almost all the time.
Building a base on that Extreme Hills view spot is looking pretty appealing right now.
Next episode: finally trading with the Seljuks, and working towards a Smeltery
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Those medium oaks indeed look what I would consider ideal large oaks. They're similar to vanilla, but larger, and have some tweaks (thicker base of the trunk and different, less bunched up leave clusters). Only thing I'd say could be better is if they were slightly taller between the base of the trunk and when the branches start, but emphasis on slightly, because if it's too much taller, it would look odd with a canopy that is too small unless that as also increased. But even as they are, I think they work close to perfectly.
Though, I do also like the larger oak trees but they seem like a different type of tree almost.
I still think 1.18 needing a light level of 0 would allow you to not have to worry about lighting as much. A real forest should be a bit dark, after all. Also, I forgot to mention it back then but meant to, if this ever does get carried forward to 1.18+, I think right now 1.20 makes the most sense. Obviously yes that's partly because it's the newest, but there's a few other reasons.
Unless you totally dislike the deep dark, there's little reason to play 1.18+ and not play 1.19 over it, as it sort of adds a good part of what 1.18 was pitched to come with originally. Also, there's mangrove swamps (and I didn't notice it until recently but these have the same issue large oaks and jungle trees in older Minecraft versions do in that they seemingly generate beyond their allowance because I've seen them start decaying vines and/or leaves in newly generated ones).
But I feel 1.20 is better than 1.19 because it has some nice performance improvements (one of them is a new lighting system, but it certainly extends beyond this) and also includes another biome/tree with the cherry trees. Not sure what to do there as I feel these trees are alright and are fine not being overly large (but I think maybe they would need to be a bit larger to fit in with the rest of trees being larger?).
And the plains picture is welcome. Not everything needs to be varying terrain elevation with a ton of decoration. If anything plains were never flat and plain enough (the occasional water spot used to always ruins them too). If forests were improved, I think that would allow for plains to go the other way and be just flat grasslands as the norm 9while still having exceptions from that).
As for the village building itself... I'm still not sure how I feel about that. It's nice in concept, but I hope they never bring something like that to vanilla. I was wondering when you started if you were too close.
Also, I'd totally be taking those floating canopy parts down. They would bother me if I was sticking to the area.
HOLY COW THIS IS FAST!!! I reach the unfrozen river astonishingly quickly and zoom off into the water, where I slow to the normal, although still brisk, vanilla boating speed. I don't remember ice boating being *this* fast, was it accelerated between 1.7 and 1.12? Or did I just forget?
This is a case of "bug turned feature"; it was recognized as a bug for several years (2016-2019) until the relevant bug report was closed as "intended"; the root cause was the refactoring of boats in 1.9:
I think the speed is excessive though and doesn't make sense, then again, they are all but useless on ice in 1.6.4, and had many other significant issues which led to a complete rewrite of their code (I've made my own changes/improvements to boats, such as only breaking if they crash at nearly full speed (so I can just ram into land and pick it up without having to hit it, otherwise letting go of W a second or two before is enough) and dropping a boat instead of planks and sticks, and not crashing on lilypads or water mobs, and not killing you from fall damage if they run aground, and of course, a major desync issue where you'd crash into land server-side while appearing to be in the middle of the ocean client-side (if not running into unloaded chunks, that is, though I never experienced it to that degree, but I also don't generate new terrain when boating), fixable with a couple very simple changes, but Mojang just decided to completely rewrite them).
Those medium oaks indeed look what I would consider ideal large oaks. They're similar to vanilla, but larger, and have some tweaks (thicker base of the trunk and different, less bunched up leave clusters). Only thing I'd say could be better is if they were slightly taller between the base of the trunk and when the branches start, but emphasis on slightly, because if it's too much taller, it would look odd with a canopy that is too small unless that as also increased. But even as they are, I think they work close to perfectly.
Trunk height varies from tree to tree. These never end up with a small canopy.
Though, I do also like the larger oak trees but they seem like a different type of tree almost.
Well, there are lots of oak species and some do have a more upright habit, like pin oaks. It's not an option to have really tall trees spread as much proportionately because of the Minecraft decoration rules.
I still think 1.18 needing a light level of 0 would allow you to not have to worry about lighting as much.
As I understand it, 1.18 bars spawning with a *block* light of > 0, so that wouldn't help here, because there's no block lighting at all.
And the plains picture is welcome. Not everything needs to be varying terrain elevation with a ton of decoration. If anything plains were never flat and plain enough (the occasional water spot used to always ruins them too). If forests were improved, I think that would allow for plains to go the other way and be just flat grasslands as the norm 9while still having exceptions from that).
Well, most of the time Plains has sub-biomes and so it's not flat and featureless. This kind of thing is more the exception. I've thought about altering Geographicraft to vary the frequencies of sub-biomes along with the types, but I haven't gotten a good plan for it.
Also, I'd totally be taking those floating canopy parts down. They would bother me if I was sticking to the area.
Oh, they bug me too, but I'm racing to get exploration and some base basics before winter.
This is a case of "bug turned feature"; it was recognized as a bug for several years (2016-2019) until the relevant bug report was closed as "intended"; the root cause was the refactoring of boats in 1.9:
...Looked close to perfect, but that i think being slightly taller would be better. I was elaborating when I said the part about the canopies because I said if they were too much taller, they would start approaching the point where the canopy looked too small for the tree height.
But I'm sort of basing the "they would look a bit nicer slightly taller" remark on the two trees I see here, so if those are on the shorter side for medium oaks then they are probably close to perfect, but if those are average or worse on the taller side, I would probably think they would benefit from slightly taller trunks.
All of this is sort of splitting hairs over what is probably one to three blocks taller on average so even as are, they are fine. Sorry if that was too critical.
Well, there are lots of oak species and some do have a more upright habit, like pin oaks.
Yeah, I know. That's sort of what my comment meant. I was saying it was interesting how you used the different sizes to implement different types, even if that may have largely been a result to adhere to limits of the game, because it sort of came out better for it anyway by adding variety.
It's not an option to have really tall trees spread as much proportionately because of the Minecraft decoration rules.
And I think that's fine anyway. While the vanilla trees are definitely far too small, you don't want to just imitate reality for reality sake and make them too big for the game either. I think yours about hit the right balance, all things considered. They're probably the best I've seen anyway, though I also haven't researched into looking at all the new types of trees people have made in who knows how many mods that have existed for this game.
Well, most of the time Plains has sub-biomes and so it's not flat and featureless. This kind of thing is more the exception. I've thought about altering Geographicraft to vary the frequencies of sub-biomes along with the types, but I haven't gotten a good plan for it.
I think the thing vanilla does wrong with plains is that they were never flat nor plain enough. There's various types of plains in reality, and not all are truly flat or truly featureless, but they tend to be flat insofar as if elevation changes do exist, then they tend to be subtle (infrequent and gradual). Vanilla plains never were flat enough and the terrain changes were too frequent or not gradual enough. What they are is leaning more into a "subtle rolling hills grasslands" (and they push the subtle part). Those "subtle rolling hills grasslands" are nice and should exist... but as a mere infrequent variety and not the sole plains biome.
Oh, and none of this is talking about plains in 1.18+ since the biomes no longer control terrain since then, so when a plains occurs in 1.18, it's just a label being put in a spot to signify "low foliage decorator area". What I'm talking about is either plains prior to 1.1, or the flatter elevation areas that are plains after 1.18. They both fail. 1.18 gets the vast part right, but that's it.
Basically, what vanilla plains did/do is put too many elevation changes in, and they are more than gradual. So what I was saying is that your picture was something that I think plains should be more like. They should be more flat (or at least, far more subtle/gradual on the elevation changes) and more plain as a rule. The sub-biome in your example fine; it's neat and serves as an occasional break without changing plains themselves.
I get confused at the difference between the two a lot, but I figured since this doesn't seem to be an issue in 1.18 (?) then it might not be here.
I actually forgot about this myself, I indeed did not reduce the maximum sky light level for mob spawning either, still 7 or less, so those screenshots I showed with a light level 0f 7 can spawn mobs but the chance is still low; after all, if e.g. 1% of the area is at 7, which gives a failure rate of 7/8, then the relative probability of mobs spawning is 0.01 * 1/8 = 1/800 relative to a completely dark area. The fact that I split the hostile mob cap into "cave" and "surface" caps also makes daytime spawns more likely since in vanilla the entire mob cap can spawn underground during the day, limiting new spawns to what is needed to offset despawning, while I allow for as many as 60 "cave" mobs and 40 "surface" mobs (increased to 60 as the number underground drops to 40 or less; vanilla 1.6.4 has around half the mob cap (79) spawning on the surface at night in areas with no caves lit up).
Also, even at night the effective light level is still around 4 so the chance of a mob spawning on the surface is still only half the maximum - and the game applies yet another reduction factor based on sky light level for an overall spawn rate that is around 1/4 as high as a dark cave:
This is basically the same as vanilla except for the first check, which I use for mob spawners which ignore sky light (used in surface structures) and my backport of Beta 1.7.3' s "sleep spawning" mechanic (this nerfs being able to just put a bed down and sleep anywhere, you must ensure no mobs can reach it from up to 32 blocks away); and the one that checks if a mob was spawned from a mob spawner (the threshold is absolute so 7 will spawn mobs just as easily as 0):
public static final boolean isValidLightLevelForMonster(World par1World, int x, int y, int z, int spawnType)
{
// Only checks block light, maximum light level is defined by value of lightCheckType, and chance of spawning is not
// scaled (e.g. 100% for < 8); used by mob spawners which ignore sky light and sleep spawning
if (lightCheckType != NORMAL)
{
return par1World.getSavedLightValue(EnumSkyBlock.Block, x, y, z) < lightCheckType;
}
else
{
int skyLight = par1World.getSavedLightValue(EnumSkyBlock.Sky, x, y, z);
// Failure rate for skylight (independent of day) is x/32 (15/32 with a direct view of the sky)
if (skyLight > nextInt(32)) return false;
// Subtracts at least 10 from skylight when thundering, otherwise based on the time of day
skyLight -= (par1World.isThundering() ? Math.max(10, par1World.skylightSubtracted) : par1World.skylightSubtracted);
int blockLight = par1World.getSavedLightValue(EnumSkyBlock.Block, x, y, z);
if (spawnType == EntityLivingBase.SPAWNER)
{
// Mobs spawned from a spawner only check if the light level is less than 8
return Math.max(skyLight, blockLight) < 8;
}
else
{
// General mob spawning; block light must be less than 6 in the Overworld, 8 otherwise; in either case chance
// of failure below the limit is light/8 (starts at 62.5% in the Overworld, 87.5% otherwise).
return blockLight < (OVERWORLD ? 6 : 8) && Math.max(skyLight, blockLight) <= nextInt(8);
}
}
}
The village has indeed grown a lot. It had 10 residents when I got here. Now it has 25.
I sell my eight stacks of cobble. I had been planning to use the money for buying wool from the byzantine sheepherder to the southwest, but I notice they have a lot of sand for sale. I need a lot of sand for the Smeltery I want to build; it's not hard to get, but it's so easy to just buy it I yield to temptation and blow all my money on two stacks of sand. I would have bought a straw bed from them as well, obviating the need for wool, but they don't sell them.
Even this small amount of trading uncorks my ability to understand their Turkish.
My autumn crops are already starting to grow. I'm not sure how I'll use them yet, but variety does help with the better recipes.
I spend the rest of the day digging clay and a little gravel out of the river for the Smeltery.
Come evening I head down to start building the Smeltary. I don't calculate it exactly, but even my small Smeltery will need about 240 seared brick items, so I make two more Furnaces to work on that. Even with several furnaces, it's going to take a while, so I cut another mine branch while I'm waiting.
I brought my level 3 map - the one I want to use for the base area - but I don't really get all that far without souped-up equipment and storage. Right now I'm about where my lemon tree is and ahead is the wide river to my south.
After that I come back to construct the Smeltery, but I forgot to make screenshots. It wasn't all that eventful other than initially I forgot to put in a Smeltery Controller and there was some typically comic relief as I was trying to figure out what was wrong.
It's well into the day by the time I'm done. I'd been thinking about Winter exploration, but now I realize it will scramble the maps with snow. Should have left Serene Seasons out. I'm having fun with the modpack, but it's interfering with showing off scenery.
For the rest of the day I chop a fairly large Oak in the yard, plant a bunch of pumpkin seeds (here) and collect crops.
That evening I resume working on the Tinker's setup for making gear. I get most of the work blocks like the Stencil table for making patterns, a Tool Station for making tools, and pour and use a pickaxe head mold. I'm skipping the details because I already went over this in my last journal.
I head up a little early hoping to catch some mobs at dawn but I don't see any. Now back out for some more exploration.
For some reason horses are just EVERYWHERE in this world. There are at least two herds here, right next to my base. Couldn't some of them been sheep? I haven't even seen a saddle yet.
I start off heading southeast. I map out the scenic lake from which I saw the desert in Episode 03.
Then I explore a bit of the desert. But not much; my strategy right now is to walk next to where I've already explored to stretch out my map.
To the left is some of the Roofed Forest I boated past in Episode 04. The river is there, but not visible due to grass.
Past that, the place where the Forest yielded to Taiga, now seen from the other side. The trees here are smaller than around my base, giving a different feel to the forest. These trees are closer to the new RTG average; the ones around my base are unusually tall.
Continuing on next to my river exploration forces me into the Taiga, and then:
Not too promising for continuing alongside previous explorations. So, now I switch tacks. I have the "Mountains in Mountain Chains" option on for Geographicraft, so I'll try to skirt the edges of this mountain chain, to try to show it in action. So I turn back south.
Ooh, doggies! RTG forests are usually more open than vanilla forest, because I think it looks better. That does vary, and sometimes they're about as dense as vanilla, but not too often.
Embarassingly, I forgot to bring my bed, so I'm debating whether I should head back home for the night. But, soon enough, I exit the Taiga into plains and see:
Sheep! No shears, so I engage in a bit of off-screen butchery. I don't need these for breeding, because I can steal purchase some from the sheepherder SW of the village, which is closer than here.
The mountain range continues to force me south. Also, even more horses.
Next is another Seljuk village. I have the distance between Millenaire village doubled, reducing the frequency by something between a half and a quarter (because they can't spawn everywhere). At default IMO there would be entirely too many of them. Honestly, even at this frequency they feel too frequent.
Right next to the Seljuk village structures, and probably in the area that will get built on, is a vanilla village. I'll check out their trades, and consider how to harmonize the two village types, later.
Next to the dual villages a river starts up, heading south through hot terrain. I switch exploration tactics again and go back to boating. There is a fork, and I take the one that continues south, all the way to the edge of my map.
Geographicraft can get hot and cold zones *really* close, while still respecting climate separations. The two snowy blobs right above the hot zone are tall Extreme Hills, but the frozen river section is genuine cold zone. So here they're only about 500 blocks apart. That *is* really close, even for Geographicraft.
I turn west, and soon reach the sea. I'm facing roughly towards 0,0. Because I wanted to test this new generation on a really large continent, I set Geographicraft to generation *only* large continents, and there was evidently none anywhere near the origin. This spot is about -6500,-4500 and it's almost certainly all ocean from here to the origin. OTOH this continent probably extends something like 10,000 blocks to the west. We shall see if there's enough variety here to make that interesting.
It's started to rain, which is annoying, since it's getting dark and once again I don't know when to sleep.
Turning north-ish along the coast, I hit an Extreme Hills where the mountain chain reaches to the sea. For the Geographicraft increased sub-biome variety, I increase the temperature of Extreme Hills a bit to raise the snow level and keep the Extreme Hills sub-biomes from dumping snow on nearby trees (a pet peeve of mine). But Serene Seasons is lowering the temp for fall, and Extreme Hills is now snowy all the way to sea level.
Normally I don't approve of bed-plopping but I'm relaxing my stance for this journal. This time I time the bed placement really well and get to sleep right at dusk.
Next episode: more new vistas.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Past that, the place where the Forest yielded to Taiga, now seen from the other side. The trees here are smaller than around my base, giving a different feel to the forest. These trees are closer to the new RTG average; the ones around my base are unusually tall.
Yes, this gives a better idea than the two trees alone pictures before, but this looks somewhat how I imagined it. I think being a low number of blocks taller (like three to four?) on average would look better. Not enough to change the overall profile of the tree/forest and make it massively taller, but enough to get the canopies starting slightly higher up. For that canopy size, I think a slightly increased distance from base of trunk to where branches start would look more balanced.
They do look a million times better than vanilla forests even like this though. If vanilla forests looked like this instead, I wouldn't complain. I think the vanilla old growth birch forests (which would really resemble the opposite; a young forest) should be the smallest that a forest can be.
Yes, this gives a better idea than the two trees alone pictures before, but this looks somewhat how I imagined it. I think being a low number of blocks taller (like three to four?) on average would look better. Not enough to change the overall profile of the tree/forest and make it massively taller, but enough to get the canopies starting slightly higher up. For that canopy size, I think a slightly increased distance from base of trunk to where branches start would look more balanced.
3 or 4 blocks might be more that you realize; right now the trees are often at a 4 block minimum. I'll try altering my algorithm to make smaller trees have higher trunks.
I'm sort of surprised there's not something to prevent them from spawning so close together, especially with the one village being able to expand.
You and me both. It's not that hard to prohibit something near a (vanilla) village; Millenaire just doesn't do it.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Yes, I was hesitant to suggest too much since I know a little can go a long way. I was originally thinking 2 or so, maybe 3.
I guess I'm just so done with the tree canopies so close to the ground they block sight level and need hoes to clear (guess what I'm dealing with on my current adventure?) that I thought smaller trees on hills might still have this occur frequently, but I definitely yield to you being more familiar with the results you'll get based on how you configure them. Those are already a vast improvement over vanilla forests and would be close to a perfect balance between being realistic and fitting within Minecraft's limitations and gameplay needs.
I prevent this myself by checking if the 2x2 chunk area around a structure intersects the bounding box of a village, which will have already been registered in the structure map / data files as the game registers villages within a +/- 8 chunk range around each chunk that is populated, while my "scattered feature" structures are only registered when the chunk they are located in is populated (the range of the overriding structure must be larger in order for this to work properly).
Also, even in my first world I prevent mineshafts from generating in regions of higher cave density by counting the number of caves nearby, using a simplified version of the cave generator's main method; in TMCW there are many additional checks for various underground features, to the point where at one time the "what will generate here" check was taking at least half of the entire time spent by the cave generator until I developed a caching method to greatly reduce the number of calls to the "can spawn" method for each type of cave/feature (the main method checks a 11 chunk radius, which in turn may mean checking up to a 5 chunk radius for various type of caves/structures, for every single chunk within the 11 chunk radius, adding up to tens of thousands of innermost loop iterations per chunk generated. The time was reduced by more than an order of magnitude by caching the "can spawn" checks within the entire area covered by both radii; using a better RNG than Java's horribly slow Random doubled the speed of the entire cave generator yet again; overall, for all its complexity TMCW generates terrain about twice as fast as vanilla and this is one reason why I simply do not buy any claims of "the game is becoming more demanding/slower because it has more content", which may still be true but it can be optimized to be much faster than any slowdown from adding more content, same for memory usage, etc)
Also, the bug report makes an incorrect claim, a "village intersecting a lake", as if an area of land that is below sea level is the same thing as one of the small "lake" features, which vanilla actually restricts from generating within the boundaries of a village, at least it did before 1.13 broke the code (this was done by checking the return value of the method used to place a structure, or part of a structure, in the world; in order to prevent lakes from generating in strongholds or dungeons I modified the code that makes sure the blocks around a lake are valid by blacklisting blocks like stone bricks, mossy cobblestone, fences, and planks). As for villages generated on water, I improved them by making paths generate as wood planks on the surface (instead of on the ground underwater), and lowered the minimum altitude of buildings by one (in vanilla the doorways will be two blocks off the ground if it is at sea level).
I awaken to a refreshing vista of RTG Extreme Hills with a sprinkling of early snow. Very pretty. Maybe including Serene Seasons was a good idea after all.
I continue NE along the coast. Soon I come to some Savanna, so this section of Extreme Hills kind of protruded into the hot zone.
A wicked vanilla lighting bug.
The mountain chains pulls back from the coast, letting the Savanna "breathe" a bit. The Better Creatures birds add some nice atmosphere.
To the north the mountain chains comes back to the coast, and this time with tall mountains right to the water. I switch to boating since these steep mountain sides are a little annoying to walk on.
Past that is another forest. Except now it's not just "another forest". The trees here are on the small side for RTG, and give a completely different feel from the giants near my base.
I find a narrow strait between the mainland and a small offshore forest island.
Next is the shore of the pass where I took the pics at the end of episode 04. Actually I'm finding the fall color from Serene Seasons really nice. I really like the rugged mountain range from this angle.
I could get off the boat and head back home along the river, but my circumnavigation habits are kicking in and so I continue boating along the coast.
Next is a bit of forest again, and the trees are even shorter. This new system switches to vanilla trees for the shortest trees, so sometimes you can get a forest very close to vanilla. Not super pretty, but shrub forests do exist, and I like the variety. More to see, more to explore.
I cross a small peninsula, and then back to the boat.
The coast now starts heading west. The mountain chain continues, along witht the pattern of sometimes reaching the coast, and sometimes having a non-mountain biome in between. The Forest to my left is narrow, and ends up being a kind of hillside forest because the Extreme Hills are pulling up the height.
After the those blue peaks, the mountain chains finally strongly pulls back from the coast, and I come ashore to look at the trees in a relatively small-treed forest. Here a clearing gives me a good view.
Then a Taiga, also with smaller trees, and a river with its headwaters coming west out of the Extreme Hills. I get in my boat to take advantage of the speed.
So the mountain chain looks to be the arc of what I didn't explore, plus the rocky and snowy area I at least got on my map. The area at the end of the river where I took the view pics in Episode 04 is a particularly low pass. I designed the terrain to produce passes, partly for looks and partly for more interesing geography. They're usually tougher than that gentle one, though.
I spot another village, this one Norman, in the woods when the river comes to an end against a Extreme Hills sub-biome. That's one disadvantage of the increased sub-biome variety; the rivers can't go through Extreme Hills and so they stop more often. But I think it's worth it.
I'm exploring, not trading, so I ignore the Norman village for now.
Another river starts on the other side of the Extreme Hills sub-biome (really the same river) so I get in my boat and continue.
Soon I find another Roofed Forest, and this time the river goes *into* it. But, the river is wide, and I figure I can just fly through without trouble. Correctly.
The river briefly connects to the ocean, and then there's this appropriately low-lying swamp between the ocean and the river.
As I near the end of the map dusk is approaching but I find a conveniently place clearing to bed-plop in for the night.
Come morning I want to head south since I"m on the west edge of the map. Conveniently south of me is regular, not Roofed, Forest. This is pretty typical of the new RTG Forest, maybe with trees a bit on the short side.
Another little clearing helps appreciate it all.
I pass through some Taiga, and soon I'm on the edge of the great Plains just north of the big Savanna M rock formation.
I wander around a bit filling in my maps.
And, finally, home sweet home.
And here's the resulting map.
Next episode: Tinkering, then back out.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
I've been so used to doing level 3 maps that my initial reaction is always "the paths of terrain being uncovered are small" even though I know a level 4 map is twice the width and height, and four times the total area.
Those small forests are definitely small. That's sort of what I was thinking could happen (even ignoring the vanilla style shrub trees) with the smaller ones, which is why I thought making the just slightly taller would make that a bit better. Again, that could be my dislike for them speaking since I see them everywhere. Maybe as an exception instead of the norm, I would mind it less. But they seem (key word since I'm dealing with a sample size that's very low based on what you've showed) a bit more common than I think I'd like, hence the initial suggestion of simply padding the height.
Can the villages only build and expand while you're nearby with the chunks loaded, or only when you're away and they are unloaded, or both?
I think being a low number of blocks taller (like three to four?) on average would look better. Not enough to change the overall profile of the tree/forest and make it massively taller, but enough to get the canopies starting slightly higher up. For that canopy size, I think a slightly increased distance from base of trunk to where branches start would look more balanced.
I stretched out the trunks for these medium oaks (requiring a rejiggering of the Oak forest size which makes them on average somewhat taller) and here's what that looks like now, in a creative re-creation:
And here's a view inside that forest:
I do think that improves them. (Although there's a minor issue revealed in the next episode.)
Pretty much all I did was stretch out the medium oak trunks. The small oaks (which are very similar to the vanilla large oaks; they basically just tweak the code to allow more variability) were not changed other than they'll get slightly larger on average because of changes I had to make to the average oak size.
On the ground, small forests are definitely in the minority. I think you'd have a very different experience if you played in this generation system. I'm not snapping picks of the considerable stretches of medium-tree forest I'm going through proportionately to the time I spend in them; it's a journal and I snap what's remarkable. As with almost anything, you tend to become bored with what you see the most, and the medium forests are the most common, so in this world the small forests and even the occasional quasi-vanilla shrub forest become the interesting variety.
The Millenaire villages only operate when roughly in render distance. In retrospect, basing close to one of them was probably an error, because it will grow highly disproportionately from the others.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Oh my goodness! Yes! Haha, that makes them pretty much what my ideal vision of a perfect forest was when I made that suggestion. Your comment of a few blocks possibly overdoing it had me second guessing it, but the results basically match "perfect forest" for me... but that's totally subjective. If that was the "normal boring common type" in vanilla then sign me up, I'd probably have no complaints about forests ever again (or rather, any imperfections would be so small that the multitude of other more important things would have me not even complaining about them). Like all that needs is some deer and birds (mostly for sounds) to slightly liven it up and it would be absolutely perfect. I love that Mojang is adding ambiance but I'd like to see more.
And yeah, that's true; I try to keep in mind that what I'm seeing here is merely "sample size of one" and more specifically, sampling bias of what you decide to show, so I know it won't speak for the whole.
If this ever gets brought to 1.18+ (even if it's just 1.18) I'd definitely look at it. I don't often seek out mods that actually change much, but terrain generation is one area I'd like to try. This seems to be the year of new experiences for me (both of my hardcore worlds started this year), and while I'm certainly not abandoning my older worlds, I've definitely branched out from only playing the one. I've even considered trying Bedrock. (gasp!)
Sadly, my PC issues are making me reserved on that until I feel it's fully resolved, and with this being on 1.12, I have to settle for window shopping for now.
I think if you were working under 1.18 or above where a light level of 0 is needed for spawning, it would go a long way here.
I know you dislike daylight spawning as a principle, but I've never minded that the occasional mob could spawn in the day since it was generally so seldom, and can already happen even in some vanilla forests anyway (well, jungles and especially roofed forests).
I don't really have any major reservations against modern rivers, and I like how they can sometimes cut into canyons, but I do see why you prefer them another way. They seem more useful for exploring when they wind less and tend in one direction, but I also like seeing them wind back and forth at times. Maybe if modern rivers did this some of the time instead of as the norm, and on a smaller scale instead of a larger one that disrupted one direction travel, it wouldn't be an issue, but I'm not sure if making those both coexist is possible.
I think 1.18 was a step in the right direction, but this is an example of why I think the next step of formally dropping biomes might be a necessary next step, and hopefully Minecraft explores that possibility in the future.
What is the "Tan" colored stone (?) on the hill in the second image?
This is amusing. Back when the roofed forests were being announced and described, before I ever saw one, I was almost imagining they would be exactly as what you show here. Basically, taller than they ended up being, and with slightly different canopies. I didn't mind the way the canopies of the vanilla ones ended up, but I thought they trended towards the short side and it was a bit disappointing.
The existing tiny trees probably force everything else to conform or it doesn't fit in. The jungles existed beforehand so the large tree was sort of their exclusive "thing", and then the old growth tiaga came along but was rare and an exception. I wish they'd just go the full way and overhaul tree generation so all forests are much better.
I fear they're doing it due to anticipated complaints of those who want easy mass farming. *sigh* You'd spend more time on one tree but get more wood out of it, and yes I'd know it would still be a net increase in time due to having to spend time pillaring up in some cases, but the increased wood per tree still offsets it a little, and the increased visual benefit is worth it. If need be, just... include a new enchantment that works like the tree felling mods for those who want easy mass farming.
But I hope they're just not doing it since it's been that way from the start and they just never visited overhauling tree generation yet.
Who knows which it is though.
That second one is begging for a settlement.
During my troubleshooting for my PC issues, I started a new world, and... it's been something else. A lot of mountainous, and high hills and slopes. Multiple peaks extending above the first cloud layer at 192, and many relatively close. If I ever have a need for a new hardcore world, my next one will drop the "I have to go with a random seed and stay with whatever I'm given" and just going to use this seed for sure.
Your pictures are similar (well... as similar as modded 1.12 and vanilla modern can be) but in the case of this seed it is temperate/warm biomes, and there's some jungles along terrain like this that look gorgeous. Probably because the trees are taller. But I still haven't fully gotten over the novelty of biomes being uncoupled from terrain elevation so it's still a treat to see when it's all massive hills and slopes with savannas, regular forests, and whatever it wants to be overlaying it.
This is pretty easy to do; if you know the maximum size of a structure you can scan a range of chunks around each chunk that is being decorated and place any parts that intersect the current chunk, no need to save anything since the seed is being set for every chunk within the "gen range", although this does mean that if there are any changes to the structure itself or world generation you'll end up with cut-off structures (this is unavoidable anyway for structures that start in new chunks; when I loaded a world created with my "double height terrain" mod in vanilla mineshafts generated sticking into vanilla chunks as the game remembered the attitude they were offset to; I've since disabled structure-saving for mineshafts so they will just get cut off but either way vanilla mineshafts will be cut off at the old-new chunk boundary since they can't generate in existing chunks (apparently, Mojang enabled ocean monuments to do so, and I know that mods have "retrogen" capability)
public class MapGenCavesRavines { public void generate(int chunkX, int chunkZ) { this.chunkX_16 = chunkX * 16; this.chunkZ_16 = chunkZ * 16; this.chunkCenterX = (double)(this.chunkX_16 + 8); this.chunkCenterZ = (double)(this.chunkZ_16 + 8); for (int x = -8; x <= 8; ++x) { int cx = chunkX + x; for (int z = -8; z <= 8; ++z) { // Reduces number of chunks compared to a square range if (x * x + z * z <= 65) { int cz = chunkZ + z; long chunkSeed = ((long)cx * this.seedX) ^ ((long)cz * this.seedZ) ^ this.worldSeed; this.rand.setSeed(chunkSeed); this.generateCaves(cx, cz, x, z); this.rand.setSeed(chunkSeed); this.generateRavines(cx, cz); } } } } private void generateCaveNode(long par1, double par6, double par8, double par10, float par12, float par13, float par14, int par15, int par16) { // Checked once per iteration of a loop which traces out a tunnel; var29 is the current radius of a tunnel // and is used along with a margin to see if it intersects the current chunk being carved out double var29_2 = var29 + 9.0D; if (par6 >= this.chunkCenterX - var29_2 && par6 <= this.chunkCenterX + var29_2 && par10 >= this.chunkCenterZ - var29_2 && par10 <= this.chunkCenterZ + var29_2) { // Converts from absolute to chunk-relative coordinates int var55 = MathHelper.floor_double(par6 - var29) - this.chunkX_16; int var36 = MathHelper.floor_double(par6 + var29) - this.chunkX_16 + 1; int var57 = (int)(par8 - var31); int var38 = (int)(par8 + var31) + 1; int var56 = MathHelper.floor_double(par10 - var29) - this.chunkZ_16; int var40 = MathHelper.floor_double(par10 + var29) - this.chunkZ_16 + 1; // Limits bounds to that of the array used to hold the data used to initialize a chunk if (var55 < 0) var55 = 0; if (var36 > 16) var36 = 16; if (var57 < 1) var57 = 1; if (var38 > 120) var38 = 120; if (var56 < 0) var56 = 0; if (var40 > 16) var40 = 16; } } }Structures use a list to cache the individual structure maps and are split into initial structure registration and the actual placement into the world (these can also be done at the same time, call the "generate" method right before "generateStructuresInChunk", or merge them); the "structure data" I refer to having removed here was only added in 1.6.4 and simply ensures that their bounding boxes are saved so structure-specific mobs can spawn in "old" structures after updating to 1.7, or other versions which alter structure locations (older versions simply recreate the bounding boxes based on the current version). There are other reasons to save data, including structures which generate at a specific altitude dependent on the terrain (you'll get structures split in half vertically if this data is not saved since it can only be recorded within the current chunk. This could happen before 1.6.4 but only if a structure was partly generated across multiple sessions as the in-memory objects would remember the altitude):
public class MapGenMineshaftTMCW extends MapGenStructure { public void generate(IChunkProvider par1IChunkProvider, World par2World, int chunkX, int chunkZ, byte[] par5ArrayOfByte) { this.worldObj = par2World; // Reduced gen-range to 7 chunks since mineshafts reach a max of 100 blocks from the center (80 + 20, length of // a corridor with 4 sections) for (int x = -7; x <= 7; ++x) { for (int z = -7; z <= 7; ++z) { this.generateStructures(par2World, chunkX + x, chunkZ + z, chunkX, chunkZ); } } } // Removed saving of structure data for mineshafts protected void generateStructures(World par1World, int chunkX, int chunkZ, int par4, int par5) { if (!this.structureMap.containsKey(Long.valueOf(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ)))) { if (this.canSpawnStructureAtCoords(chunkX, chunkZ)) { MineshaftStart var7 = new MineshaftStart(this.worldObj, this.rand, chunkX, chunkZ); this.structureMap.put(Long.valueOf(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ)), var7); } } } public boolean generateStructuresInChunk(World par1World, Random par2Random, int chunkX, int chunkZ) { int blockX = chunkX << 4 | 8; int blockZ = chunkZ << 4 | 8; boolean var7 = false; Iterator var8 = this.structureMap.values().iterator(); StructureBoundingBox bb = new StructureBoundingBox(blockX, blockZ, blockX + 15, blockZ + 15); while (var8.hasNext()) { MineshaftStart var9 = (MineshaftStart)var8.next(); if (var9.getBoundingBox().intersectsWith(blockX, blockZ, blockX + 15, blockZ + 15)) { var9.generateStructure(par1World, par2Random, bb); var7 = true; } } return var7; } } public class MineshaftStart { public void generateStructure(World par1World, Random par2Random, StructureBoundingBox par3StructureBoundingBox) { Iterator var4 = this.components.iterator(); while (var4.hasNext()) { MineshaftComponent var5 = (MineshaftComponent)var4.next(); if (var5.getBoundingBox().intersectsWith(par3StructureBoundingBox)) { var5.addComponentParts(par1World, par2Random, par3StructureBoundingBox); } } } }The biggest issue in your case is that you'd need to know the altitude of the ground at the base of the tree; village buildings attempt to measure the average ground level but it can only do so for the first part to be placed, which can be as little as a single block in size (i.e. only one corner intersects the chunk currently being decorated; the method "isVecInside" checks if a position is within the bounding box, in this case, of the populated area):
protected int getAverageGroundLevel(World par1World, StructureBoundingBox par2StructureBoundingBox) { int var3 = 0; int var4 = 0; for (int var5 = this.boundingBox.minZ; var5 <= this.boundingBox.maxZ; ++var5) { for (int var6 = this.boundingBox.minX; var6 <= this.boundingBox.maxX; ++var6) { if (par2StructureBoundingBox.isVecInside(var6, 64, var5)) { var3 += Math.max(par1World.getTopSolidOrLiquidBlock(var6, var5), par1World.provider.getAverageGroundLevel()); ++var4; } } } if (var4 == 0) { return -1; } else { return var3 / var4; } }Note that if "getAverageGroundLevel" returns -1 it will skip the piece (for now) but it can still result in as little as a single block being measured since as soon as the field is set to a valid value it won't check again (ensuring the average ground level is the same for each subsequent section, this is also what structure-saving saves to ensure consistency between sessions):
public class ComponentVillageChurch extends ComponentVillage { public boolean addComponentParts(World par1World, Random par2Random, StructureBoundingBox par3StructureBoundingBox) { if (this.field_143015_k < 0) { this.field_143015_k = this.getAverageGroundLevel(par1World, par3StructureBoundingBox); if (this.field_143015_k < 0) return true; this.boundingBox.offset(0, this.field_143015_k - this.boundingBox.maxY + 11, 0); } } }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?
Another issue I've thought of - the game doesn't fully update lighting until a chunk's neighbors have been loaded, which is why you see a border of unlit chunks on this map (since 1.7 this is saved as "LightPopulated", I use a similar system to keep track of which chunks have been lit, I can even see where I've been in my first world since I added the NBT tag for it (green = relit, red = pending a relight, gray = no tag present); as I only process chunk relights within the chunk ticking area (a 15x15 chunk area prior to 1.9; example with the render distance set to 16) you still see lighting errors in chunks further away at higher render distances, mostly under overhangs, including trees. 1.7 probably does something else, I just use the sequential relight checks that vanilla has/had (in vanilla 1.6.4 you'll see lighting errors in newly generated chunks be fixed (very slowly) but if a chunk is unloaded before it has been fully checked it will be left incomplete, hence the persistent lighting errors and the need to save the progress, I also made the checks much faster; vanilla takes 25.6 seconds to fully check a chunk, and that is just server-side; the client is 22.5 times slower as it only checks 10 chunks per tick).
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?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHardcore, basically. You can't do focused work in a forest if a Creeper can come up and blow you to smithereens. Roofed Forests I don't mind, because they're *supposed* to be dangerous, and Jungles are acceptable on similar principles.
It's one of the Underground Biomes stone types. I didn't check which one, but I think it's Red Granite.
You're a lot more tolerant than I. I always thought the Roofed Forest trees looked cartoony and silly, totally inappropriate for the most dangerous day biome. They're tolerable in some texture packs, but in vanilla - yuck. And regardless of texture pack, having a 2x2 trunked tree so short is inexcusable - even the lazy aren't going to have any trouble with a Jungle Giant-style spiral staircase. I so sometimes think 2x2 Roofed Forest trees would be better, given their height, but not enough to write new tree routines.
Those two shots are very close, almost a panorama. I couldn't get the whole bay and the ridge into the same shot.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Well no, I feel the same as you in that roof forests are as much in need of changes as most of the rest. I just think the low height was the real major issue with them. Being thicker, low height, mostly flat tops, and packed so close is what makes them "cartoony". Oh, and it's probably the giant mushrooms haha. But if they were taller I could forgive the rest (this would woodland mansions fit in better as well), even if they still weren't great.
I just found it interesting that when Mojang announced/described what they would be, I was imagining something close to what you pictured, and then those "cartoon" forests came.
That's why I made the other comment about how I think Mojang is constraining themselves to short height trees probably because it's what the game started as and what most of the tress (which are oak or birch) are. That, and the complaints it might cause changing them. Just imagine "the game just keeps getting worse, I have to spend so much time just to get wood" or "this feels like a mod, it isn't Mincrafty, can't Mojang come up with their own good idea". I'll admit it, sometimes I get why Mojang does stuff despite players acting like the existence/threat of their criticism should be the reason they don't do it. The community is too vast and full of wildly different desires now; Mojang is going to be criticized whether they do a lot, the safe amount, or nothing.
So I'd like to see the developers have room to experiment while still taking feedback into consideration. Problem with that approach is once they put the development effort in, straying from that might cause a huge waste of time and effort, and if they communicate it early, well... take a look at 1.19 getting poor reception not because it was bad, but just because it wasn't better because more stuff was teased (and people attached the chat criticism to it when it came in a later sub-version).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEpisode 05: Seljuks and Seasons, Sooner
On the way back I try a bit of ice boating.
HOLY COW THIS IS FAST!!! I reach the unfrozen river astonishingly quickly and zoom off into the water, where I slow to the normal, although still brisk, vanilla boating speed. I don't remember ice boating being *this* fast, was it accelerated between 1.7 and 1.12? Or did I just forget?
I boat most of the way home, but get off at the Birch Forest M/ Flower Forest area for a couple of reasons. The first, here, is just to show the super-giant trees from underneath. The new RTG Birch Forest M inherits the regular RTG Birch Forest's characteristic of throwing in a few Oaks in some but not most forests, and here there's a supergiant Oak as a result. You can also see some of the weeping growth pattern the biggest RTG Birches have.
And doesn't everybody love a good Flower Forest shot? But maybe even more so with the RTG trees behind it.
Here, roughly, is the area we saw at a distance through a forest clearing in Episode 03.
If you look closely at the extra-big Oak there you can see a single branch block sticking off to the left about halfway down the trunks. That's the lighting tracker canceling a branch that would cause lighting trouble. This is a part of the reason the really big trees don't have as many long lower branches as you might expect - you can only put so many branches onto a Minecraft tree before getting lighting problems, and there are already plenty of branches higher up.
And, finally, here is a closeup of the new "medium" size RTG Oak, which might be considered more "oaky" than the big version. It's rounder, partly because since it's smaller, so it's not pushing on the limit of the number of branches.
Here's a view from beneath, showing the thicker limbs. The branches here are always connected orthogonally, which makes them more chunky looking. I wanted both an orthogonally connected and a diagonally connected Oak model, for variety.
Then I go home overland, checking for lighting issues as a I go. This is a vanilla lighting glitch, and disappears when I place and remove a torch. But I do find a similar looking glitch which is from RTG and doesn't disappear after a temporary torch. That's almost certainly from recursive generation confusing the light tracker system. That's not an easy fix and I'm not looking forward to it.
I do have a Creeper come at me at one point, so there are gameplay issues from lighting. I get away without trouble, but I don't know whether it was from a vanilla bug or from RTG.
By the time I reach home it's almost dark, so I quickly grab some Paperbark paper and then head down for some mining.
Some pretty successful mining!
I head up early hoping to catch some mobs to kill but
Foo. Can't chase mobs and drops with *him* around. But mysteriously:
When I check from the roof 30 seconds later, it's gone! I thought it was too close to despawn. And look, there's a spider! But - there's also some pillars that look Seljuk. I though I was well out of town. I hope I'm not going to have construction in my current base.
My first string! I'm going to pretend those Harvestcraft cobweb trees don't exist, because that's just *too* easy.
And then off to the south to take the river that way.
It goes almost no distance at all before running off the map to a map I don't have enough paper to make. So I get off the boat and continue on foot.
Near the corner of the map I encounter this mini-swamp. But - why are the leaves brown? Isn't it too soon for autumn? Hmm, in my last journal 82 episodes for four years; 82 divided by 4 years divided by 4 seasons is - 5 - oh.
Then this nice sweeping Plains view - but with a little variety to keep it interesting.
Around here I get informed of a Millenaire sheepherder - which could be very handy, because he sells wool, and I've only encountered 4 sheep so far in all my explorations, and I killed 3 of them for my bed so I can't breed any. I don't have any money or trade goods to buy them with at the moment, though. Unaccountably I neglect to get any pics.
Beyond his hut is a largish RTG Scenic lake, which I boat, getting this view of the Acacia tree cluster I saw in the distance in the first episode.
Then I visit the Seljuk village on the way home to see what I could sell them. They'll buy cobble, which I have lots of, but not for much. They'll pay more for paper, which I can generate pretty easily with my Paperbark trees, so maybe I'll plant a bunch more of them to produce trade goods.
They've been constructing, and they've built this wall around the town hall. It's a bit inconvenient for me, as the only opening faces away from my base area.
I do a round of paper collection, and plant my Autumn crops, once again pushing past dusk and once again getting away with it.
Then another round of mining during the night. Before I head up I convert 8 stacks of Soapstone cobble to vanilla cobble, amusingly getting the Stone Age achievement, which I hadn't gotten before because I was only mining modded stone.
Then a quick snooze before trying to catch some mobs in the morning.
Three creepers. So much for mobhunting in the morning! I check the other side to see if I have an exit:
Ooh. DEFINITELY Autumn. And it looks like I have a problem with the Seljuk village. That gateway wasn't there before, nor was that building (probably a house) to the right. So the village goes all the way to the fishing shack, which is an inconvenience for me as I was planning to build a base on the area to the right. This "village" is going to be HUGE when it's built out, which seems like it will happen relatively soon; they're getting a lot done with me here almost all the time.
Building a base on that Extreme Hills view spot is looking pretty appealing right now.
Next episode: finally trading with the Seljuks, and working towards a Smeltery
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Those medium oaks indeed look what I would consider ideal large oaks. They're similar to vanilla, but larger, and have some tweaks (thicker base of the trunk and different, less bunched up leave clusters). Only thing I'd say could be better is if they were slightly taller between the base of the trunk and when the branches start, but emphasis on slightly, because if it's too much taller, it would look odd with a canopy that is too small unless that as also increased. But even as they are, I think they work close to perfectly.
Though, I do also like the larger oak trees but they seem like a different type of tree almost.
I still think 1.18 needing a light level of 0 would allow you to not have to worry about lighting as much. A real forest should be a bit dark, after all. Also, I forgot to mention it back then but meant to, if this ever does get carried forward to 1.18+, I think right now 1.20 makes the most sense. Obviously yes that's partly because it's the newest, but there's a few other reasons.
Unless you totally dislike the deep dark, there's little reason to play 1.18+ and not play 1.19 over it, as it sort of adds a good part of what 1.18 was pitched to come with originally. Also, there's mangrove swamps (and I didn't notice it until recently but these have the same issue large oaks and jungle trees in older Minecraft versions do in that they seemingly generate beyond their allowance because I've seen them start decaying vines and/or leaves in newly generated ones).
But I feel 1.20 is better than 1.19 because it has some nice performance improvements (one of them is a new lighting system, but it certainly extends beyond this) and also includes another biome/tree with the cherry trees. Not sure what to do there as I feel these trees are alright and are fine not being overly large (but I think maybe they would need to be a bit larger to fit in with the rest of trees being larger?).
And the plains picture is welcome. Not everything needs to be varying terrain elevation with a ton of decoration. If anything plains were never flat and plain enough (the occasional water spot used to always ruins them too). If forests were improved, I think that would allow for plains to go the other way and be just flat grasslands as the norm 9while still having exceptions from that).
As for the village building itself... I'm still not sure how I feel about that. It's nice in concept, but I hope they never bring something like that to vanilla. I was wondering when you started if you were too close.
Also, I'd totally be taking those floating canopy parts down. They would bother me if I was sticking to the area.
This is a case of "bug turned feature"; it was recognized as a bug for several years (2016-2019) until the relevant bug report was closed as "intended"; the root cause was the refactoring of boats in 1.9:
MC-97803 Boats going faster on ice than in water
I think the speed is excessive though and doesn't make sense, then again, they are all but useless on ice in 1.6.4, and had many other significant issues which led to a complete rewrite of their code (I've made my own changes/improvements to boats, such as only breaking if they crash at nearly full speed (so I can just ram into land and pick it up without having to hit it, otherwise letting go of W a second or two before is enough) and dropping a boat instead of planks and sticks, and not crashing on lilypads or water mobs, and not killing you from fall damage if they run aground, and of course, a major desync issue where you'd crash into land server-side while appearing to be in the middle of the ocean client-side (if not running into unloaded chunks, that is, though I never experienced it to that degree, but I also don't generate new terrain when boating), fixable with a couple very simple changes, but Mojang just decided to completely rewrite them).
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?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTrunk height varies from tree to tree. These never end up with a small canopy.
Well, there are lots of oak species and some do have a more upright habit, like pin oaks. It's not an option to have really tall trees spread as much proportionately because of the Minecraft decoration rules.
As I understand it, 1.18 bars spawning with a *block* light of > 0, so that wouldn't help here, because there's no block lighting at all.
Well, most of the time Plains has sub-biomes and so it's not flat and featureless. This kind of thing is more the exception. I've thought about altering Geographicraft to vary the frequencies of sub-biomes along with the types, but I haven't gotten a good plan for it.
Oh, they bug me too, but I'm racing to get exploration and some base basics before winter.
Totally agree. It's pretty ridiculous.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
No no no. I wasn't saying they do. I was saying that these...
...Looked close to perfect, but that i think being slightly taller would be better. I was elaborating when I said the part about the canopies because I said if they were too much taller, they would start approaching the point where the canopy looked too small for the tree height.
But I'm sort of basing the "they would look a bit nicer slightly taller" remark on the two trees I see here, so if those are on the shorter side for medium oaks then they are probably close to perfect, but if those are average or worse on the taller side, I would probably think they would benefit from slightly taller trunks.
All of this is sort of splitting hairs over what is probably one to three blocks taller on average so even as are, they are fine. Sorry if that was too critical.
Yeah, I know. That's sort of what my comment meant. I was saying it was interesting how you used the different sizes to implement different types, even if that may have largely been a result to adhere to limits of the game, because it sort of came out better for it anyway by adding variety.
And I think that's fine anyway. While the vanilla trees are definitely far too small, you don't want to just imitate reality for reality sake and make them too big for the game either. I think yours about hit the right balance, all things considered. They're probably the best I've seen anyway, though I also haven't researched into looking at all the new types of trees people have made in who knows how many mods that have existed for this game.
I get confused at the difference between the two a lot, but I figured since this doesn't seem to be an issue in 1.18 (?) then it might not be here.
I think the thing vanilla does wrong with plains is that they were never flat nor plain enough. There's various types of plains in reality, and not all are truly flat or truly featureless, but they tend to be flat insofar as if elevation changes do exist, then they tend to be subtle (infrequent and gradual). Vanilla plains never were flat enough and the terrain changes were too frequent or not gradual enough. What they are is leaning more into a "subtle rolling hills grasslands" (and they push the subtle part). Those "subtle rolling hills grasslands" are nice and should exist... but as a mere infrequent variety and not the sole plains biome.
Oh, and none of this is talking about plains in 1.18+ since the biomes no longer control terrain since then, so when a plains occurs in 1.18, it's just a label being put in a spot to signify "low foliage decorator area". What I'm talking about is either plains prior to 1.1, or the flatter elevation areas that are plains after 1.18. They both fail. 1.18 gets the vast part right, but that's it.
Basically, what vanilla plains did/do is put too many elevation changes in, and they are more than gradual. So what I was saying is that your picture was something that I think plains should be more like. They should be more flat (or at least, far more subtle/gradual on the elevation changes) and more plain as a rule. The sub-biome in your example fine; it's neat and serves as an occasional break without changing plains themselves.
I actually forgot about this myself, I indeed did not reduce the maximum sky light level for mob spawning either, still 7 or less, so those screenshots I showed with a light level 0f 7 can spawn mobs but the chance is still low; after all, if e.g. 1% of the area is at 7, which gives a failure rate of 7/8, then the relative probability of mobs spawning is 0.01 * 1/8 = 1/800 relative to a completely dark area. The fact that I split the hostile mob cap into "cave" and "surface" caps also makes daytime spawns more likely since in vanilla the entire mob cap can spawn underground during the day, limiting new spawns to what is needed to offset despawning, while I allow for as many as 60 "cave" mobs and 40 "surface" mobs (increased to 60 as the number underground drops to 40 or less; vanilla 1.6.4 has around half the mob cap (79) spawning on the surface at night in areas with no caves lit up).
Also, even at night the effective light level is still around 4 so the chance of a mob spawning on the surface is still only half the maximum - and the game applies yet another reduction factor based on sky light level for an overall spawn rate that is around 1/4 as high as a dark cave:
public static final boolean isValidLightLevelForMonster(World par1World, int x, int y, int z, int spawnType) { // Only checks block light, maximum light level is defined by value of lightCheckType, and chance of spawning is not // scaled (e.g. 100% for < 8); used by mob spawners which ignore sky light and sleep spawning if (lightCheckType != NORMAL) { return par1World.getSavedLightValue(EnumSkyBlock.Block, x, y, z) < lightCheckType; } else { int skyLight = par1World.getSavedLightValue(EnumSkyBlock.Sky, x, y, z); // Failure rate for skylight (independent of day) is x/32 (15/32 with a direct view of the sky) if (skyLight > nextInt(32)) return false; // Subtracts at least 10 from skylight when thundering, otherwise based on the time of day skyLight -= (par1World.isThundering() ? Math.max(10, par1World.skylightSubtracted) : par1World.skylightSubtracted); int blockLight = par1World.getSavedLightValue(EnumSkyBlock.Block, x, y, z); if (spawnType == EntityLivingBase.SPAWNER) { // Mobs spawned from a spawner only check if the light level is less than 8 return Math.max(skyLight, blockLight) < 8; } else { // General mob spawning; block light must be less than 6 in the Overworld, 8 otherwise; in either case chance // of failure below the limit is light/8 (starts at 62.5% in the Overworld, 87.5% otherwise). return blockLight < (OVERWORLD ? 6 : 8) && Math.max(skyLight, blockLight) <= nextInt(8); } } }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?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEpisode 06:
The village has indeed grown a lot. It had 10 residents when I got here. Now it has 25.
I sell my eight stacks of cobble. I had been planning to use the money for buying wool from the byzantine sheepherder to the southwest, but I notice they have a lot of sand for sale. I need a lot of sand for the Smeltery I want to build; it's not hard to get, but it's so easy to just buy it I yield to temptation and blow all my money on two stacks of sand. I would have bought a straw bed from them as well, obviating the need for wool, but they don't sell them.
Even this small amount of trading uncorks my ability to understand their Turkish.
My autumn crops are already starting to grow. I'm not sure how I'll use them yet, but variety does help with the better recipes.
I spend the rest of the day digging clay and a little gravel out of the river for the Smeltery.
Come evening I head down to start building the Smeltary. I don't calculate it exactly, but even my small Smeltery will need about 240 seared brick items, so I make two more Furnaces to work on that. Even with several furnaces, it's going to take a while, so I cut another mine branch while I'm waiting.
I brought my level 3 map - the one I want to use for the base area - but I don't really get all that far without souped-up equipment and storage. Right now I'm about where my lemon tree is and ahead is the wide river to my south.
After that I come back to construct the Smeltery, but I forgot to make screenshots. It wasn't all that eventful other than initially I forgot to put in a Smeltery Controller and there was some typically comic relief as I was trying to figure out what was wrong.
It's well into the day by the time I'm done. I'd been thinking about Winter exploration, but now I realize it will scramble the maps with snow. Should have left Serene Seasons out. I'm having fun with the modpack, but it's interfering with showing off scenery.
For the rest of the day I chop a fairly large Oak in the yard, plant a bunch of pumpkin seeds (here) and collect crops.
That evening I resume working on the Tinker's setup for making gear. I get most of the work blocks like the Stencil table for making patterns, a Tool Station for making tools, and pour and use a pickaxe head mold. I'm skipping the details because I already went over this in my last journal.
I head up a little early hoping to catch some mobs at dawn but I don't see any. Now back out for some more exploration.
For some reason horses are just EVERYWHERE in this world. There are at least two herds here, right next to my base. Couldn't some of them been sheep? I haven't even seen a saddle yet.
I start off heading southeast. I map out the scenic lake from which I saw the desert in Episode 03.
Then I explore a bit of the desert. But not much; my strategy right now is to walk next to where I've already explored to stretch out my map.
To the left is some of the Roofed Forest I boated past in Episode 04. The river is there, but not visible due to grass.
Past that, the place where the Forest yielded to Taiga, now seen from the other side. The trees here are smaller than around my base, giving a different feel to the forest. These trees are closer to the new RTG average; the ones around my base are unusually tall.
Continuing on next to my river exploration forces me into the Taiga, and then:
Not too promising for continuing alongside previous explorations. So, now I switch tacks. I have the "Mountains in Mountain Chains" option on for Geographicraft, so I'll try to skirt the edges of this mountain chain, to try to show it in action. So I turn back south.
Ooh, doggies! RTG forests are usually more open than vanilla forest, because I think it looks better. That does vary, and sometimes they're about as dense as vanilla, but not too often.
Embarassingly, I forgot to bring my bed, so I'm debating whether I should head back home for the night. But, soon enough, I exit the Taiga into plains and see:
Sheep! No shears, so I engage in a bit of off-screen butchery. I don't need these for breeding, because I can
stealpurchase some from the sheepherder SW of the village, which is closer than here.The mountain range continues to force me south. Also, even more horses.
Next is another Seljuk village. I have the distance between Millenaire village doubled, reducing the frequency by something between a half and a quarter (because they can't spawn everywhere). At default IMO there would be entirely too many of them. Honestly, even at this frequency they feel too frequent.
Right next to the Seljuk village structures, and probably in the area that will get built on, is a vanilla village. I'll check out their trades, and consider how to harmonize the two village types, later.
Next to the dual villages a river starts up, heading south through hot terrain. I switch exploration tactics again and go back to boating. There is a fork, and I take the one that continues south, all the way to the edge of my map.
Geographicraft can get hot and cold zones *really* close, while still respecting climate separations. The two snowy blobs right above the hot zone are tall Extreme Hills, but the frozen river section is genuine cold zone. So here they're only about 500 blocks apart. That *is* really close, even for Geographicraft.
I turn west, and soon reach the sea. I'm facing roughly towards 0,0. Because I wanted to test this new generation on a really large continent, I set Geographicraft to generation *only* large continents, and there was evidently none anywhere near the origin. This spot is about -6500,-4500 and it's almost certainly all ocean from here to the origin. OTOH this continent probably extends something like 10,000 blocks to the west. We shall see if there's enough variety here to make that interesting.
It's started to rain, which is annoying, since it's getting dark and once again I don't know when to sleep.
Turning north-ish along the coast, I hit an Extreme Hills where the mountain chain reaches to the sea. For the Geographicraft increased sub-biome variety, I increase the temperature of Extreme Hills a bit to raise the snow level and keep the Extreme Hills sub-biomes from dumping snow on nearby trees (a pet peeve of mine). But Serene Seasons is lowering the temp for fall, and Extreme Hills is now snowy all the way to sea level.
Normally I don't approve of bed-plopping but I'm relaxing my stance for this journal. This time I time the bed placement really well and get to sleep right at dusk.
Next episode: more new vistas.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Yes, this gives a better idea than the two trees alone pictures before, but this looks somewhat how I imagined it. I think being a low number of blocks taller (like three to four?) on average would look better. Not enough to change the overall profile of the tree/forest and make it massively taller, but enough to get the canopies starting slightly higher up. For that canopy size, I think a slightly increased distance from base of trunk to where branches start would look more balanced.
They do look a million times better than vanilla forests even like this though. If vanilla forests looked like this instead, I wouldn't complain. I think the vanilla old growth birch forests (which would really resemble the opposite; a young forest) should be the smallest that a forest can be.
Coincidental, concerning what my next update in one of my worlds will entail.
I'm sort of surprised there's not something to prevent them from spawning so close together, especially with the one village being able to expand.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium3 or 4 blocks might be more that you realize; right now the trees are often at a 4 block minimum. I'll try altering my algorithm to make smaller trees have higher trunks.
You and me both. It's not that hard to prohibit something near a (vanilla) village; Millenaire just doesn't do it.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Yes, I was hesitant to suggest too much since I know a little can go a long way. I was originally thinking 2 or so, maybe 3.
I guess I'm just so done with the tree canopies so close to the ground they block sight level and need hoes to clear (guess what I'm dealing with on my current adventure?) that I thought smaller trees on hills might still have this occur frequently, but I definitely yield to you being more familiar with the results you'll get based on how you configure them. Those are already a vast improvement over vanilla forests and would be close to a perfect balance between being realistic and fitting within Minecraft's limitations and gameplay needs.
Or worse, overlapping, as can happen with vanilla structures like villages and desert temples but even Mojang doesn't care about that:
MC-59365 Overlapping Generated Structures
Resolution: Works As Intended
I prevent this myself by checking if the 2x2 chunk area around a structure intersects the bounding box of a village, which will have already been registered in the structure map / data files as the game registers villages within a +/- 8 chunk range around each chunk that is populated, while my "scattered feature" structures are only registered when the chunk they are located in is populated (the range of the overriding structure must be larger in order for this to work properly).
Also, even in my first world I prevent mineshafts from generating in regions of higher cave density by counting the number of caves nearby, using a simplified version of the cave generator's main method; in TMCW there are many additional checks for various underground features, to the point where at one time the "what will generate here" check was taking at least half of the entire time spent by the cave generator until I developed a caching method to greatly reduce the number of calls to the "can spawn" method for each type of cave/feature (the main method checks a 11 chunk radius, which in turn may mean checking up to a 5 chunk radius for various type of caves/structures, for every single chunk within the 11 chunk radius, adding up to tens of thousands of innermost loop iterations per chunk generated. The time was reduced by more than an order of magnitude by caching the "can spawn" checks within the entire area covered by both radii; using a better RNG than Java's horribly slow Random doubled the speed of the entire cave generator yet again; overall, for all its complexity TMCW generates terrain about twice as fast as vanilla and this is one reason why I simply do not buy any claims of "the game is becoming more demanding/slower because it has more content", which may still be true but it can be optimized to be much faster than any slowdown from adding more content, same for memory usage, etc)
Also, the bug report makes an incorrect claim, a "village intersecting a lake", as if an area of land that is below sea level is the same thing as one of the small "lake" features, which vanilla actually restricts from generating within the boundaries of a village, at least it did before 1.13 broke the code (this was done by checking the return value of the method used to place a structure, or part of a structure, in the world; in order to prevent lakes from generating in strongholds or dungeons I modified the code that makes sure the blocks around a lake are valid by blacklisting blocks like stone bricks, mossy cobblestone, fences, and planks). As for villages generated on water, I improved them by making paths generate as wood planks on the surface (instead of on the ground underwater), and lowered the minimum altitude of buildings by one (in vanilla the doorways will be two blocks off the ground if it is at sea level).
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?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEpisode 07: Some Seaside Sights
I awaken to a refreshing vista of RTG Extreme Hills with a sprinkling of early snow. Very pretty. Maybe including Serene Seasons was a good idea after all.
I continue NE along the coast. Soon I come to some Savanna, so this section of Extreme Hills kind of protruded into the hot zone.
A wicked vanilla lighting bug.
The mountain chains pulls back from the coast, letting the Savanna "breathe" a bit. The Better Creatures birds add some nice atmosphere.
To the north the mountain chains comes back to the coast, and this time with tall mountains right to the water. I switch to boating since these steep mountain sides are a little annoying to walk on.
Past that is another forest. Except now it's not just "another forest". The trees here are on the small side for RTG, and give a completely different feel from the giants near my base.
I find a narrow strait between the mainland and a small offshore forest island.
Next is the shore of the pass where I took the pics at the end of episode 04. Actually I'm finding the fall color from Serene Seasons really nice. I really like the rugged mountain range from this angle.
I could get off the boat and head back home along the river, but my circumnavigation habits are kicking in and so I continue boating along the coast.
Next is a bit of forest again, and the trees are even shorter. This new system switches to vanilla trees for the shortest trees, so sometimes you can get a forest very close to vanilla. Not super pretty, but shrub forests do exist, and I like the variety. More to see, more to explore.
I cross a small peninsula, and then back to the boat.
The coast now starts heading west. The mountain chain continues, along witht the pattern of sometimes reaching the coast, and sometimes having a non-mountain biome in between. The Forest to my left is narrow, and ends up being a kind of hillside forest because the Extreme Hills are pulling up the height.
After the those blue peaks, the mountain chains finally strongly pulls back from the coast, and I come ashore to look at the trees in a relatively small-treed forest. Here a clearing gives me a good view.
Then a Taiga, also with smaller trees, and a river with its headwaters coming west out of the Extreme Hills. I get in my boat to take advantage of the speed.
So the mountain chain looks to be the arc of what I didn't explore, plus the rocky and snowy area I at least got on my map. The area at the end of the river where I took the view pics in Episode 04 is a particularly low pass. I designed the terrain to produce passes, partly for looks and partly for more interesing geography. They're usually tougher than that gentle one, though.
I spot another village, this one Norman, in the woods when the river comes to an end against a Extreme Hills sub-biome. That's one disadvantage of the increased sub-biome variety; the rivers can't go through Extreme Hills and so they stop more often. But I think it's worth it.
I'm exploring, not trading, so I ignore the Norman village for now.
Another river starts on the other side of the Extreme Hills sub-biome (really the same river) so I get in my boat and continue.
Soon I find another Roofed Forest, and this time the river goes *into* it. But, the river is wide, and I figure I can just fly through without trouble. Correctly.
The river briefly connects to the ocean, and then there's this appropriately low-lying swamp between the ocean and the river.
As I near the end of the map dusk is approaching but I find a conveniently place clearing to bed-plop in for the night.
Come morning I want to head south since I"m on the west edge of the map. Conveniently south of me is regular, not Roofed, Forest. This is pretty typical of the new RTG Forest, maybe with trees a bit on the short side.
Another little clearing helps appreciate it all.
I pass through some Taiga, and soon I'm on the edge of the great Plains just north of the big Savanna M rock formation.
I wander around a bit filling in my maps.
And, finally, home sweet home.
And here's the resulting map.
Next episode: Tinkering, then back out.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
I've been so used to doing level 3 maps that my initial reaction is always "the paths of terrain being uncovered are small" even though I know a level 4 map is twice the width and height, and four times the total area.
Those small forests are definitely small. That's sort of what I was thinking could happen (even ignoring the vanilla style shrub trees) with the smaller ones, which is why I thought making the just slightly taller would make that a bit better. Again, that could be my dislike for them speaking since I see them everywhere. Maybe as an exception instead of the norm, I would mind it less. But they seem (key word since I'm dealing with a sample size that's very low based on what you've showed) a bit more common than I think I'd like, hence the initial suggestion of simply padding the height.
Can the villages only build and expand while you're nearby with the chunks loaded, or only when you're away and they are unloaded, or both?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumA followup to some of your tree comments:
I stretched out the trunks for these medium oaks (requiring a rejiggering of the Oak forest size which makes them on average somewhat taller) and here's what that looks like now, in a creative re-creation:
And here's a view inside that forest:
I do think that improves them. (Although there's a minor issue revealed in the next episode.)
Pretty much all I did was stretch out the medium oak trunks. The small oaks (which are very similar to the vanilla large oaks; they basically just tweak the code to allow more variability) were not changed other than they'll get slightly larger on average because of changes I had to make to the average oak size.
On the ground, small forests are definitely in the minority. I think you'd have a very different experience if you played in this generation system. I'm not snapping picks of the considerable stretches of medium-tree forest I'm going through proportionately to the time I spend in them; it's a journal and I snap what's remarkable. As with almost anything, you tend to become bored with what you see the most, and the medium forests are the most common, so in this world the small forests and even the occasional quasi-vanilla shrub forest become the interesting variety.
The Millenaire villages only operate when roughly in render distance. In retrospect, basing close to one of them was probably an error, because it will grow highly disproportionately from the others.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Better Forests Varied and beautiful trees and forests, in modern Minecraft.
Oh my goodness! Yes! Haha, that makes them pretty much what my ideal vision of a perfect forest was when I made that suggestion. Your comment of a few blocks possibly overdoing it had me second guessing it, but the results basically match "perfect forest" for me... but that's totally subjective. If that was the "normal boring common type" in vanilla then sign me up, I'd probably have no complaints about forests ever again (or rather, any imperfections would be so small that the multitude of other more important things would have me not even complaining about them). Like all that needs is some deer and birds (mostly for sounds) to slightly liven it up and it would be absolutely perfect. I love that Mojang is adding ambiance but I'd like to see more.
And yeah, that's true; I try to keep in mind that what I'm seeing here is merely "sample size of one" and more specifically, sampling bias of what you decide to show, so I know it won't speak for the whole.
If this ever gets brought to 1.18+ (even if it's just 1.18) I'd definitely look at it. I don't often seek out mods that actually change much, but terrain generation is one area I'd like to try. This seems to be the year of new experiences for me (both of my hardcore worlds started this year), and while I'm certainly not abandoning my older worlds, I've definitely branched out from only playing the one. I've even considered trying Bedrock. (gasp!)
Sadly, my PC issues are making me reserved on that until I feel it's fully resolved, and with this being on 1.12, I have to settle for window shopping for now.