Even 1.18 doesn't appear to be able to produce such caves as I decompiled the cave generator class (djm.class or "net.minecraft.world.level.levelgen.carver.CaveWorldCarver" in 1.20.1) and it still appears to use the same values as since release 1.7 (by which I mean for the "old caves" / tunnels and rooms):
public boolean a(final djk $0, final djl $1, final ddx $2, final Function<gu, he<cnk>> $3, final apf $4, final dgw $5, final clt $6, final ddw $7)
{
final int $8 = hx.c(this.d() * 2 - 1);
for (int $9 = $4.a($4.a($4.a(this.a()) + 1) + 1), $10 = 0; $10 < $9; ++$10)
protected int a()
{
return 15;
}
While this is very hard to read I am certain that this is defining the "size" of a cave system, which ranges from 0-14, with the method that returns 15 setting the range (which ends up being one less because of how Random.nextInt works, it is passed through 3 random calls so the average is 1/8 of the maximum, or 1.75); this can be compared to the (deobfuscated) source code from 1.6 and 1.7, where this value is 40 in 1.6 and 15 in 1.7 (i.e. cave systems can be nearly 3 times denser in 1.6, with a range of 0-39 and average of 4.875, and don't forget that the ground is twice as deep in 1.18, so you really need twice the volume of caves to maintain the same density, even more if you want to maintain the aspect ratio (depth x width), which is why cave systems were so colossal in my "double/triple height terrain" mods):
I checked on one of my 1.20.1 dev envs and this seems to be correct; the method that returns 15 is called CaveCarver.getMaxCaveCount in Yarn:
public boolean carve(
CarverContext carverContext,
CaveCarverConfig caveCarverConfig,
Chunk chunk,
Function<BlockPos, RegistryEntry<Biome>> function,
Random random,
AquiferSampler aquiferSampler,
ChunkPos chunkPos,
CarvingMask carvingMask
) {
int i = ChunkSectionPos.getBlockCoord(this.getBranchFactor() * 2 - 1);
int j = random.nextInt(random.nextInt(random.nextInt(this.getMaxCaveCount()) + 1) + 1);
for(int k = 0; k < j; ++k) {
// ...
}
return true;
}
protected int getMaxCaveCount() {
return 15;
}
This actually brings an interesting idea to mind. Why not condense all of the levels into one trade? What I mean is, instead of having all levels of efficiency as a possibility, have just efficiency offered, and then it starts at the lowest level and goes up as the villager's profession level goes up. This might also allow you to cut down on having villagers offer up to three books (which can sometimes be duplicates, if not outright than at least of the same enchantment with a different level).
You could even have it so that you can choose to buy a lower-level enchanted book by paying only the price that the villager demanded for the book at that level. For example, an enchanted book trade for Efficiency could evolve like this:
Novice: book + 10 emeralds → Efficiency I
Apprentice: book + 10 emeralds → Eff I, + 17 emeralds → Eff II
Journeyman: book + 10 emeralds → Eff I, + 17 emeralds → Eff II, + 25 emeralds → Eff III
Expert: book + 10 emeralds → Eff I, + 17 emeralds → Eff II, + 25 emeralds → Eff III, + 33 emeralds → Eff IV
Master book + 10 emeralds → Eff I, + 17 emeralds → Eff II, + 25 emeralds → Eff III, + 33 emeralds → Eff IV, + 41 emeralds → Eff V. If a mod added an enchantment that could go beyond level V, then these levels would be unlocked as well.
Currently, Minecraft doesn’t support these types of dynamic trades, but it could be made to do so. Further possibilities for these kinds of offers could include:
salvaging equipment by toolsmiths, weaponsmiths, and armorers, where the amount of material you get back is randomly determined
making the enchantments on sold equipment, as well as the color of leather armor, randomly generated for each trade
There's, what, a couple dozen books in total though, considering the various levels of them all? That would require lot of trades, if you wanted to make it on par with with other professions of trying to offer most or all trades through one villager. In such a case, the time gating would be very high even for the more common ones.
Not saying it couldn't be changed with them, too, but they definitely stuck out as an issue if the change was made as-is, which is why the easy suggestion was to just leave them as-is (part of it might be my own bias of thinking villager trading halls with librarians is sort of a neat project to build).
True. You could also allow multiple enchantments on librarian-sold books to make it more likely for you to get a trade you want, but that’s yet another change, and the chance of getting the right enchantment is still slim.
Oh, I wasn't referring to the total time played itself.
I was referring to the disparity between time played and time with world open (which I never would have guessed were separately tracked things until I saw this).
In your world, the times just about match. You probably don't have the game open, but paused, often? In my world, the world has opened almost twice as long as it has been played, which I presume means I have it paused a lot. I do tend to pause it and multi-task at times, but... I didn't know there was that much of a disparity.
So I was just commenting on how your two times almost being equal had me wondering if my results were indeed abnormal.
I was referring to why I tended to AFK without pausing the game. I don’t know if the difference between “Time Played” and “Total World Time” in your world is unusual, though; does anyone else with a 1.17 or later world want to pitch in with their own stats?
The exception to this would be librarians. Due to the sheer number of books, they should remain static (or if they cycle, it should be a limited pool of two or three books on repeat). Even if you made the book entirely random, people would just keep a lot of them around (maybe more than they already do) to maximize chances of a given book, so making this change to librarians would impact them negatively.
Meant to reply to this but forgot last time. Another option could be to increase the number of trades that librarians will have at once, with a bias toward enchanted book trades, in order to compensate for the lower number of times these are available for.
Edit: Random thought, but I guess I have my game open but either paused or in a menu far more than I thought? My hardcore world seems to have a discrepancy yours doesn't between time played and time with world open. Now I'm wondering if mine is unusual?
I’ve built a portal-based zombified piglin farm in that world, so I usually go there to AFK.
In my current world (1.20 amplified + permanent night), I have a zombie spawner farm instead, since there was one that generated quite high up.
I think the fix with Mending without removing it (which should not happen, in my opinion) or making it too costly that it's almost not worth it (ditto), is to rebalance trading in the numbers.
I was just thinking about this the other day as I was trading with my villagers. One day I was allowed to do four trades in a day. On other days, it's two. I was thinking that trades should just be a one a day thing, and maybe some trades (like Mending) are one every X amount of days.
What does this accomplish?
It limits them by time instead of by asking cost, and this is important because a higher asking cost just makes it not worth it for those who "play the game naturally" and just rewards those who automate.
This could work, but you have to be careful, since waiting is an easy task and you’re getting something that’ll set you for the rest of your playthrough (assuming that you don’t die). “Once every X days” means “once every 20X minutes”. Assuming you want Mending on 14 items (a full set of armor, a sword, 2 pickaxes, an axe, a shovel, a hoe, a bow, a shield, a trident, and an elytra), you can get enough books with 280X minutes of waiting time, or about 4.7X hours. In my 1.19 no-armor world, I have 4.35 days of playtime, or 104.4 hours. That means that assuming I time my purchases perfectly, I can get all the Mending books I want in that time as long as X is less than 22.37. In reality, though, you could set the number of days needed a bit lower, since you might not use the trade immediately after it unlocks again, and you might travel somewhere so that your villagers are in unloaded chunks.
I wonder how you all think about having villagers sometimes swap out their trades for new ones (depending on how much the previous trade was used).
If a villager gives you a trade you don’t want, then you only have to wait for them to replace it with a new trade rather than replacing their workstation or replacing them with another one.
On the other hand, this makes it harder to get all the Mending books you want (if the enchanted book trade is also nerfed to allow one trade per restock).
This also makes villager trading feel more like trading rather than a funny type of resource farm. A larger variety of trades for each profession would help with this as well.
Another gripe I have is that with professions that have trades that you use a lot, you’ll inevitably max out the villagers’ level quickly. I think villagers should require some additional actions to advance to the next level, such as completing a quest.
I disliked the grind required for the pre-1.8 anvil mechanics when they existed, but a version with it with lower costs I could live with.
Another idea I’ve suggested is to make combining two items set the prior work penalty of the new item to (item 1 WP) + (item 2 WP) + 1 instead of max(item 1 WP, item 2 WP) + 1. This makes strategic combining of enchanted books (e.g. (book 1 + book 2) + (book 3 + book 4) pointless and encourages using the enchanting table, which can give multiple enchantments on one item, over villager book trades, which are limited to one enchantment each. To compensate, the prior work penalty would add a cost that scales linearly and exponentially.
All you have to do is to explore new chunks once 1.18 comes out. Any chunks that haven't already been generated in an earlier version will have the deeper layers.
We don't know what will happen with old chunks, but if the Bedrock betas are correct, the deeper layers of old chunks would be filled with bedrock.
I'd say no, because you're supposed to wear leather boots for that. Having Frost Walker let players walk on powdered snow would take away the use for leather boots.
Minecraft wouldn't display uncommon Unicode characters like that in the normal Minecraft font. The Minecraft font mainly sticks to what you can type on your keyboard. (The Unicode font can be forced on (Options -> Language -> Force Unicode Font), too) It looks like this:
As of 1.13, the default Minecraft font has a lot of Unicode characters such as the small capital letters that IllagerLabs is talking about. Plus, server plugins can't make clients render something that they couldn't already.
I'll start with graphics. Java Edition is written in Java (Who would've guessed!?), and Bedrock is in C#
Bedrock Edition is written in C++, not C#.
For my own opinion, Java Edition is my only choice as a Linux user. Mod support helps make it more attractive, although the Texture Update kind of ruined that for me (very few mods from 1.14 on have Programmer Art textures), and I personally find it easier to find other JE players than BE players.
On the other hand, Bedrock wins over Java in performance, although there are some Java Edition mods that help improve it. I do miss the Bedrock-style bridging, though (at least as much as I can without actually playing it).
0
I checked on one of my 1.20.1 dev envs and this seems to be correct; the method that returns 15 is called CaveCarver.getMaxCaveCount in Yarn:
public boolean carve( CarverContext carverContext, CaveCarverConfig caveCarverConfig, Chunk chunk, Function<BlockPos, RegistryEntry<Biome>> function, Random random, AquiferSampler aquiferSampler, ChunkPos chunkPos, CarvingMask carvingMask ) { int i = ChunkSectionPos.getBlockCoord(this.getBranchFactor() * 2 - 1); int j = random.nextInt(random.nextInt(random.nextInt(this.getMaxCaveCount()) + 1) + 1); for(int k = 0; k < j; ++k) { // ... } return true; } protected int getMaxCaveCount() { return 15; }0
This is a skin that I made in the beginning of 2023.
0
Overall, it’s okay, but it’s not an update that added much for my playstyle, even for Minecraft update standards.
0
Caxton is a Fabric mod that adds improved TrueType / OpenType font support.
Features
Read more info and download on Modrinth
Source code & issue tracker (GitLab)
0
You could even have it so that you can choose to buy a lower-level enchanted book by paying only the price that the villager demanded for the book at that level. For example, an enchanted book trade for Efficiency could evolve like this:
Currently, Minecraft doesn’t support these types of dynamic trades, but it could be made to do so. Further possibilities for these kinds of offers could include:
0
True. You could also allow multiple enchantments on librarian-sold books to make it more likely for you to get a trade you want, but that’s yet another change, and the chance of getting the right enchantment is still slim.
I was referring to why I tended to AFK without pausing the game. I don’t know if the difference between “Time Played” and “Total World Time” in your world is unusual, though; does anyone else with a 1.17 or later world want to pitch in with their own stats?
1
Meant to reply to this but forgot last time. Another option could be to increase the number of trades that librarians will have at once, with a bias toward enchanted book trades, in order to compensate for the lower number of times these are available for.
I’ve built a portal-based zombified piglin farm in that world, so I usually go there to AFK.
In my current world (1.20 amplified + permanent night), I have a zombie spawner farm instead, since there was one that generated quite high up.
1
This could work, but you have to be careful, since waiting is an easy task and you’re getting something that’ll set you for the rest of your playthrough (assuming that you don’t die). “Once every X days” means “once every 20X minutes”. Assuming you want Mending on 14 items (a full set of armor, a sword, 2 pickaxes, an axe, a shovel, a hoe, a bow, a shield, a trident, and an elytra), you can get enough books with 280X minutes of waiting time, or about 4.7X hours. In my 1.19 no-armor world, I have 4.35 days of playtime, or 104.4 hours. That means that assuming I time my purchases perfectly, I can get all the Mending books I want in that time as long as X is less than 22.37. In reality, though, you could set the number of days needed a bit lower, since you might not use the trade immediately after it unlocks again, and you might travel somewhere so that your villagers are in unloaded chunks.
1
I think the frequency of structures is okay (if a bit low), but the world needs more variety in structures.
1
I wonder how you all think about having villagers sometimes swap out their trades for new ones (depending on how much the previous trade was used).
Another gripe I have is that with professions that have trades that you use a lot, you’ll inevitably max out the villagers’ level quickly. I think villagers should require some additional actions to advance to the next level, such as completing a quest.
0
I disliked the grind required for the pre-1.8 anvil mechanics when they existed, but a version with it with lower costs I could live with.
Another idea I’ve suggested is to make combining two items set the prior work penalty of the new item to (item 1 WP) + (item 2 WP) + 1 instead of max(item 1 WP, item 2 WP) + 1. This makes strategic combining of enchanted books (e.g. (book 1 + book 2) + (book 3 + book 4) pointless and encourages using the enchanting table, which can give multiple enchantments on one item, over villager book trades, which are limited to one enchantment each. To compensate, the prior work penalty would add a cost that scales linearly and exponentially.
0
All you have to do is to explore new chunks once 1.18 comes out. Any chunks that haven't already been generated in an earlier version will have the deeper layers.
We don't know what will happen with old chunks, but if the Bedrock betas are correct, the deeper layers of old chunks would be filled with bedrock.
0
I'd say no, because you're supposed to wear leather boots for that. Having Frost Walker let players walk on powdered snow would take away the use for leather boots.
0
As of 1.13, the default Minecraft font has a lot of Unicode characters such as the small capital letters that IllagerLabs is talking about. Plus, server plugins can't make clients render something that they couldn't already.
1
Bedrock Edition is written in C++, not C#.
For my own opinion, Java Edition is my only choice as a Linux user. Mod support helps make it more attractive, although the Texture Update kind of ruined that for me (very few mods from 1.14 on have Programmer Art textures), and I personally find it easier to find other JE players than BE players.
On the other hand, Bedrock wins over Java in performance, although there are some Java Edition mods that help improve it. I do miss the Bedrock-style bridging, though (at least as much as I can without actually playing it).