At least you gave them a name lol... I've never really named my Tools before
You're very brave to summon the Wither In Hardcore I must say, and the "ancient city" also... Good luck with that Princess.
Naming tools just makes them more expensive to repair further...I never see a use in doing this except to mark a 'maxed out enchanted item' so I don't try to enchant it any further and know it's ready for someone to use.
Rollback Post to RevisionRollBack
Quote me if you need me to reply to something. DM me if I don't answer that.
Naming tools just makes them more expensive to repair further...I never see a use in doing this except to mark a 'maxed out enchanted item' so I don't try to enchant it any further and know it's ready for someone to use.
Yes, that a point...
I generally dont max out Tools, I have 4 enchants each.
I mainly name my items because in 1.6.4 (1.4-1.7) this lets you repair them indefinitely by keeping the prior work penalty at 2 (one working), with armor simply having the space removed (e.g. DiamondChestplate), while I give held items bit more descriptive names, e.g. "Mining Pickaxe" for my main pickaxe and "Ender Pickaxe" for my Silk Touch pickaxe (as it is primarily used for ender chests). In my modded world I also made a "Smelting Pickaxe" (with a "smelting" enchantment I modded in) and "Super Pickaxe" for one with Vein Miner, itself a reference to what I named my pickaxe back when I used Fortune (I no longer do so since it is absurd to multiply drops when you mine over 3,000 ores per play session and only hinders my gameplay due to running out of space much faster, back then I also used a backpack mod with double-chest sized backpacks for each major resource so it wasn't an issue). My sword is "Monster Slayer", bow is "Super Bow", axe is "Tree Killer", hoe is "Potato Harvester" (or pickaxe in vanilla since you can't put Fortune on a hoe in 1.6.4, in TMCW only hoes can apply Fortune to crops as a balance measure and incentive to use better hoes, as unlike vanilla they lose durability when breaking crops).
I also don't rename my armor at all in modded worlds since I added my own Mending enchantment which is functionally identical to renaming, and I only have one set of armor so there is no point in differentiating between items, I also rename my shears twice so they are just "Shears", which is still considered to be a custom name (as seen by the italicized font. Note that simply clearing the text box, which resets it to the default name, does not work as it also removes the NBT tag), except again, in modded worlds.
Also, since 1.9 renaming does not affect the prior work penalty, and otherwise if you rename an item at the same time you do something else the anvil only counts it as a single use, and prior to 1.8, only factors the "base value" in once, greatly reducing the level cost:
1.9 15w42a Renaming an item while using anvils no longer incurs a prior work penalty.
while I give held items bit more descriptive names, e.g. "Mining Pickaxe" for my main pickaxe and "Ender Pickaxe" for my Silk Touch pickaxe (as it is primarily used for ender chests). In my modded world I also made a "Smelting Pickaxe" (with a "smelting" enchantment I modded in) and "Super Pickaxe" for one with Vein Miner, itself a reference to what I named my pickaxe back when I used Fortune (I no longer do so since it is absurd to multiply drops when you mine over 3,000 ores per play session and only hinders my gameplay due to running out of space much faster,
I always use my Silk Touch to Mine, I like to store my Ores until I need them, then I use my Fortune Pickaxe.
Naming tools just makes them more expensive to repair further...I never see a use in doing this except to mark a 'maxed out enchanted item' so I don't try to enchant it any further and know it's ready for someone to use.
It just costs one extra level if you rename it with the last enchanted book you put on it.
Mending means repair costs aren't a thing as well.
I always use my Silk Touch to Mine, I like to store my Ores until I need them, then I use my Fortune Pickaxe.
It is much more efficient to directly mine them on the spot though since you can craft resources into blocks and this saves space in every case except for lapis when mined with Fortune and it is generally a small portion of the total ores you'll collect. For example, this is my ender chest after a session where a net yield of 4,932 resources, or about 77 stacks, were compacted into only 12 slots (or about 8.5 full stacks), you may also notice that I collected 741 rails yet I only have 2 in my inventory, since I modded in "rail blocks" that let me craft 9 rails into a block to save space in the same manner as ores, which are next to the diamonds in the last row (mineshafts are unbelievably common in vanilla 1.6.4 (this is from my first world, where I use such modded blocks while caving, but not for permanent storage), I've collected over 1,000 rails on each of several consecutive days before):
Also, you double tool wear since you have to first mine the ores with Silk Touch, which also gives no XP, then again to get the actual drops, in addition to the time spent on placing and mining them again, and unless you bring enough coal with you you'll need to bring a second pickaxe anyway in order to mine it for the coal (in the case of iron and gold ore I accumulate it in my ender chest and inventory until I need more space, then I find an easy to find again area, like the main room of a mineshaft or one of my "return points", and set up a bank of furnaces and continue exploring nearby while it smelts)..
It is much more efficient to directly mine them on the spot though since you can craft resources into blocks and this saves space in every case except for lapis when mined with Fortune and it is generally a small portion of the total ores you'll collect. For example, this is my ender chest after a session where a net yield of 4,932 resources, or about 77 stacks, were compacted into only 12 slots (or about 8.5 full stacks), you may also notice that I collected 741 rails yet I only have 2 in my inventory, since I modded in "rail blocks" that let me craft 9 rails into a block to save space in the same manner as ores, which are next to the diamonds in the last row (mineshafts are unbelievably common in vanilla 1.6.4 (this is from my first world, where I use such modded blocks while caving, but not for permanent storage), I've collected over 1,000 rails on each of several consecutive days before):
Also, you double tool wear since you have to first mine the ores with Silk Touch, which also gives no XP, then again to get the actual drops, in addition to the time spent on placing and mining them again, and unless you bring enough coal with you you'll need to bring a second pickaxe anyway in order to mine it for the coal (in the case of iron and gold ore I accumulate it in my ender chest and inventory until I need more space, then I find an easy to find again area, like the main room of a mineshaft or one of my "return points", and set up a bank of furnaces and continue exploring nearby while it smelts)..
It's usually only worth storing them in that manner if they are Fortuned however, if without a Fortune pickaxe you get much less resources and you need 9 diamonds, coal or iron to make a block to then condense the items into chests for efficient storage.
I like using Silk Touch enchant to store ores until I need them as well. It's rare that I obtain enough of something to need to break the ore then condense the items into blocks. I'm sure the longer I keep the same world the need to do this will increase, but for now Silk Touch is doing me fine.
What I do obtain a large sum of however are things like Stone, Diorite, Granite and Andesite, these are common blocks which necessitated me building warehouse full of chests to store them. I suppose this explains the reduction in FPS I've been getting lately when going to the factory that has these massive storage rooms. But I do need them, especially since I share a server with other people to play on who need to store their gear too.
It's usually only worth storing them in that manner if they are Fortuned however, if without a Fortune pickaxe you get much less resources and you need 9 diamonds, coal or iron to make a block to then condense the items into chests for efficient storage.
Well, I often do say that I do more caving/mining in a single session than most players do in the entire lifetime of a world but surely even the average player can collect a few hundred resources in a single trip, Fortune or not (which only roughly doubles drops, so not that "much less", redstone is only multiplied by 1.33 and even without Fortune you get an average of 9 resources from two ores). For example, somebody got all of this in one hour of branch-mining:
846 redstone dust (= 94 blocks)
498 coal (= 55.33 blocks, not including coal used for torches or smelting)
218 lapis (= 3.40 blocks)
111 iron ingots (= 12.33 blocks, none needed for repairs)
26 gold ingots (= 2.88 blocks)
25 diamonds (three used subsequently for repairs)
13 emeralds
Total: 1,737 resources (about 1,114 without Fortune)
I suppose this explains the reduction in FPS I've been getting lately when going to the factory that has these massive storage rooms. But I do need them, especially since I share a server with other people to play on who need to store their gear too.
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
Yeah I should have thought about that at the time, I guess I didn't want to risk randomly causing Villagers in the trading system to change to Fishermen after failing to remember their job-site blocks which is closest to them, but the performance issue is a much bigger problem, I could amend the decision at a later time but I'd need to farm an enormous load of wood first.
But chests being entities is the reason I am getting my frame rate cut in half to what it usually is, under normal circumstances it would be in the 100fps range, even whilst traveling, but when I am in the factory with the warehouses, it goes down to about 50fps or sometimes even less because of the redstone I use for the semi automated stone and basalt generators.
Why chests count as entities in the game I don't know, barrels are just as good as chests space wise.
It is true you cannot make a double chest variant of the barrels, but what you can do with barrels is place them side by side making the total capacity of them about the same. Additionally barrels can be opened even when there is a block directly above them.
Why chests count as entities in the game I don't know, barrels are just as good as chests space wise.
Both chests and barrels are "tile entities" or "block entities" and are pretty much identical in code except that chests are dynamically rendered in the same way as regular entities are since normal block rendering doesn't support smooth animations like the lid opening and closing (barrels do change their top texture but it only switches between open and closed, similar to furnaces and burning furnaces).
They could however optimize them by rendering closed chests as a single piece instead of 3 separate pieces (base, lid, and latch), as I do for about twice the performance (the reason why shulker boxes aren't as bad is because they only have 2 separate pieces to render), and I've even thought of adding a setting to make chests render like a normal block without an opening/closing animation:
if (lidAngle > 0.001F)
{
// Normal rendering used when chest is opened
lidAngle = 1.0F - lidAngle;
lidAngle = 1.0F - lidAngle * lidAngle * lidAngle;
chestModel.chestLid.rotateAngleX = -(lidAngle * MathHelper.HALF_PI);
chestModel.renderAll();
}
else
{
// Renders closed chests (including items) as a single unit for improved performance
renderClosedChest(chestModel instanceof ModelLargeChest);
}
// ModelChest; note that three separate draw calls are used to render each piece; each also applies various rotations and translations to OpenGL state, which all add even more to the render time
public void renderAll()
{
this.chestKnob.rotateAngleX = this.chestLid.rotateAngleX;
this.chestLid.render(0.0625F);
this.chestKnob.render(0.0625F);
this.chestBelow.render(0.0625F);
}
// renderClosedChest; uses a custom model which only requires a single draw call, and also culls hidden faces (top of
// base, bottom of lid, and back of latch)
public static void renderClosedChest(boolean isLargeChest)
{
if (!compiled) compileDisplayLists();
if (isLargeChest)
{
GL11.glCallList(largeChestDisplayList);
}
else
{
GL11.glCallList(chestDisplayList);
}
}
That said, the 500+ chests in my storage area in my first world still cause FPS to drop by a factor of 3 but I still get about 4 times the capped FPS so the effect is unnoticeable, and the layout means that it is large enough that when standing at one end the other end is so far away that chests are no longer rendering (they have a render distance of 64 blocks, and chests outside the field of view aren't rendered so even when standing in the middle only half are being rendered). It does mean that I have to walk around a lot to get to the chests further way but I only have to make a couple trips to put everything away.
For comparison, I turned flower pots into a tile entity so they can contain any number of plants, but they use standard block rendering for very little impact on performance, even memory usage is not significantly impacted in the example shown, a Superflat world with a layer of flowerpots (each tile entity uses additional memory, which is 32 bytes if I calculated it correctly, but for the number that were loaded this only amounts to about 7 MB on both the client and server; this screenshot was also taken before I made various optimizations to rendering and memory usage in general):
(there is however an issue with even a small number of flower pots with full-size tree models, like these, due to the complexity of the model causing a chunk update to take a long time and cause a lag spike when updated, but steady-state FPS is not affected any more than the same number of real blocks would. Barrels could cause similar lag spikes when opened/closed as they need a chunk update to change their texture)
Both chests and barrels are "tile entities" or "block entities" and are pretty much identical in code except that chests are dynamically rendered in the same way as regular entities are since normal block rendering doesn't support smooth animations like the lid opening and closing (barrels do change their top texture but it only switches between open and closed, similar to furnaces and burning furnaces).
They could however optimize them by rendering closed chests as a single piece instead of 3 separate pieces (base, lid, and latch), as I do for about twice the performance (the reason why shulker boxes aren't as bad is because they only have 2 separate pieces to render), and I've even thought of adding a setting to make chests render like a normal block without an opening/closing animation:
if (lidAngle > 0.001F)
{
// Normal rendering used when chest is opened
lidAngle = 1.0F - lidAngle;
lidAngle = 1.0F - lidAngle * lidAngle * lidAngle;
chestModel.chestLid.rotateAngleX = -(lidAngle * MathHelper.HALF_PI);
chestModel.renderAll();
}
else
{
// Renders closed chests (including items) as a single unit for improved performance
renderClosedChest(chestModel instanceof ModelLargeChest);
}
// ModelChest; note that three separate draw calls are used to render each piece; each also applies various rotations and translations to OpenGL state, which all add even more to the render time
public void renderAll()
{
this.chestKnob.rotateAngleX = this.chestLid.rotateAngleX;
this.chestLid.render(0.0625F);
this.chestKnob.render(0.0625F);
this.chestBelow.render(0.0625F);
}
// renderClosedChest; uses a custom model which only requires a single draw call, and also culls hidden faces (top of
// base, bottom of lid, and back of latch)
public static void renderClosedChest(boolean isLargeChest)
{
if (!compiled) compileDisplayLists();
if (isLargeChest)
{
GL11.glCallList(largeChestDisplayList);
}
else
{
GL11.glCallList(chestDisplayList);
}
}
That said, the 500+ chests in my storage area in my first world still cause FPS to drop by a factor of 3 but I still get about 4 times the capped FPS so the effect is unnoticeable, and the layout means that it is large enough that when standing at one end the other end is so far away that chests are no longer rendering (they have a render distance of 64 blocks, and chests outside the field of view aren't rendered so even when standing in the middle only half are being rendered). It does mean that I have to walk around a lot to get to the chests further way but I only have to make a couple trips to put everything away.
For comparison, I turned flower pots into a tile entity so they can contain any number of plants, but they use standard block rendering for very little impact on performance, even memory usage is not significantly impacted in the example shown, a Superflat world with a layer of flowerpots (each tile entity uses additional memory, which is 32 bytes if I calculated it correctly, but for the number that were loaded this only amounts to about 7 MB on both the client and server; this screenshot was also taken before I made various optimizations to rendering and memory usage in general):
(there is however an issue with even a small number of flower pots with full-size tree models, like these, due to the complexity of the model causing a chunk update to take a long time and cause a lag spike when updated, but steady-state FPS is not affected any more than the same number of real blocks would. Barrels could cause similar lag spikes when opened/closed as they need a chunk update to change their texture)
I have about 500+ chests myself so this explains where the performance issues are coming from, the entities and their chunk updates are putting increased strain on the CPU even with my newer PC that has an AMD Ryzen CPU, no doubt they cause lag on your PC too.
On topic of the thread what me and a friend have done recently is visited the End, beaten Ender Dragon and obtained some Elytras each and Shulker boxes, and he obtained a Dragon Head, something I forgot to get.
Now that I have Shulker boxes large scale builds are feasible, as I can carry supplies back and forth across territory without having to rely on an expensive minecart system.
I would have built a minecart system on my current world to use for transportation of those resources if Mojang hadn't removed Gold Ingot drops from Drowned Zombies, now that they're gone since 1.17 I don't have as much luxury to do this. I could obtain Gold from the Nether, but it is a considerable grind, and I found it wasn't worth my time.
In this case I have to transport items from a Mushroom Island roughly 384 blocks away across a lake surrounded by mainland, which only becomes partially visible with a 24 chunk render distance although I play with 32 chunks render distance most of the time, and this links to a Forest biome, and this is only for the initial project, when the city becomes large enough it would span 1,000 blocks away from the Mushroom Island and all the resources used to build it would need to be transported. I find Shulker boxes to be more efficient for this.
Mojang isn't going to care about what I say though, I am only one person out of the millions who play this game.
My refusal to use mods and cheats also limits what I can do in vanilla Minecraft.
I play survival with friends because we enjoy the thrill of collecting resources then use them to build things,
like the city I have planned, but because of the way Mojang designs their game out of fear of it becoming too broken or cheaty,
build style players like myself don't have a lot of options in what we can do when it involves a time consuming project.
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
Barrels (19w06a): ~280 FPS
Chests: ~5 FPS
Oh my goodness, really!? that much of a difference!?
This made me think of something. I started playing with shaders in 1.16, and after the game updated to 1.18, performance was a lot lower, specifically just around my village. Now I don't have a ton of chests, but collectively there's probably enough entities I guess? Chests, barrels, other job site blocks (not sure how much these matter), item frames, villagers, iron golems, birds, cats, and who knows what else.
Now my first thought was 1.18 was just performance demanding, as it is. But this only happened specifically when playing with shaders, so it wasn't fully explaining it. Nor was "shaders are demanding" as they were fine in 1.16.
I started wondering if it was related to entities and/or shadows. Unfortunately, reducing the shadow texture size did almost nothing.
I was curious and noticed turning the new entity distance setting from 100% to 50% improved it (oddly, turning it from 100% to 500% barely degraded it further), but it was still lower than before. That, and entities weren't rendering from as far as I wanted in many situations. But my guesses were being partly confirmed by this.
BSL updated a bit later and an "entity shadows" setting was added within the shaders. What a difference maker.
The only difference is "entity shadows" on versus off in BSL's settings.
It took a short while to adjust to the lack of shadows from entities but I did, and it is noooooot worth that massive of a performance drop from having them on.
Thankfully my fairly new gaming rig laughs at the face of Minecraft so I don't need to consider blocks based on performance
This build is taking forever..
Didn't find blocks to make the upper walls and towers white, as I wanted to, so ended up using stone colors instead. At least there are many block alternatives in that color.. But the build is looking a bit too gray.. Will see if I can add more details and improve walls later.. But at least now I have outer walls, and can potentially leave them alone while starting to build village within instead..
The bottom part of the wall will definitively get more mossy cobblestone variants later, but tired of messing with walls for now.. Though I guess I should complete the bridge over the water, so the entrance part looks ok..
Three redstone gates in here now, splitting up the 3 areas within, and I think the whole area should be mob proof now.. Used a ton of blocks though. Got empty of cobblestone, stone and dirt at some point, so have digged within the structure to get more blocks, so pretty large areas of hollowed out space within here too now.. Where I'll put up some more auto-farms I think...
Thankfully my fairly new gaming rig laughs at the face of Minecraft so I don't need to consider blocks based on performance
Mine does fine with vanilla Minecraft at normal render distances and such too. I don't think even modern versions demand much there.
It's when you get into shaders, resource packs, higher render distances, or some combination that can cause large performance degradation.
If there's one thing I learned with this game over the last decade, it's that it doesn't care what CPU or graphics card you have if you push certain things too far. This game can and will humble it.
I'm glad to see your hardcore world has progressed into the "building" parts. Those are my favorite parts.
The reason is because every part of an entity requires a separate draw call and these are expensive; a chest requires that the game tell the GPU to render three separate pieces; a chicken has 8 separate pieces, and so on. Worse, the game needs to switch between textures, which is also expensive, when rendering an entity and its shadow, as well as any equipment it has (the game stitches all block textures into a single texture atlas precisely because each draw call can only reference one texture at a time).
To illustrate just how different block and entity rendering is, all blocks can be rendered in as little as 3 draw calls (at least in 1.6.4, when Fancy graphics, or translucent blocks/water are enabled; Fast graphics only requires 2 draw calls, plus a handful of OpenGL state changes):
This code mostly decides if a chunk section is to be rendered and adds it to a list, when is then sent to the GPU to be render everything on screen - using just one draw call (glCallLists) and three OpenGL calls in total (glTranslatef, all at the end of the method). Translucent blocks are similar except they have an additional draw call to render a "mask" which is used to eliminate graphical artifacts like those described by MC-38022 on Fancy graphics (the only issue is that you can't see translucent blocks behind other translucent blocks but that doesn't bother me anywhere near as much as the very obvious artifacts as described in the link, which are also less severe in 1.6.4):
private int renderSortedRenderers(int par1, int par2, double playerX, double playerY, double playerZ)
{
if (!this.fastRender) return renderSortedRenderers_old(par1, par2, playerX, playerY, playerZ);
this.glListBuffer.clear();
int var6 = 0;
boolean var7 = this.mc.gameSettings.showDebugInfo;
int x = MathHelper.floor_double(playerX) - 8;
int z = MathHelper.floor_double(playerZ) - 8;
for (int var8 = par1; var8 < par2; ++var8)
{
ChunkRenderer var9 = this.sortedChunkRenderers[var8];
if (var7)
{
if (var9.skipRenderPass0 && var9.skipRenderPass1)
{
++this.renderersSkippingRenderPass;
}
else if (!var9.isInFrustum)
{
++this.renderersBeingClipped;
}
else if (this.advancedOpengl && !var9.isVisible)
{
++this.renderersBeingOccluded;
}
else
{
++this.renderersBeingRendered;
}
}
if (var9.isInFrustum && !var9.skipRenderPass0 && (!this.advancedOpengl || var9.isVisible))
{
if (var9.shouldRender(x, this.playerHeight, z, this.renderRadius1, this.renderRadius2))
{
int var10 = var9.getGLCallListForPass0();
if (var10 >= 0)
{
this.glListBuffer.put(var10);
++var6;
if (var6 >= MAX_GL_LISTS) break;
}
}
else if (var7)
{
++this.renderersBeingOccluded;
--this.renderersBeingRendered;
}
}
}
if (var6 > 0)
{
this.glListBuffer.flip();
GL11.glTranslatef((float)(-playerX), (float)(-playerY), (float)(-playerZ));
GL11.glCallLists(this.glListBuffer);
GL11.glTranslatef((float)playerX, (float)playerY, (float)playerZ);
}
return var6;
}
By contrast, this is what the game calls to render every single piece of an entity - in the extreme case, horses have 39 pieces (and were likely simplified in part because of how demanding such a complex model is - one of the only times I experience a lag spike while playing is when a horse renders for the first time, due to the cost of constructing its model (it doesn't help that it combines multiple layers of textures), which isn't compiled until an entity is rendered for the first time):
As an illustration of just how costly entity rendering is, 100 chickens has a bigger impact on FPS than going from a default Superflat world, with only a few chunks in view, to a normal world at maximum (16 chunks) render distance, or even in a "mega forest" biome:
This is also why the game is fairly aggressive on entity culling; chickens only render up to 28 blocks away (the distance is based on their size) and the server doesn't send most entities to the client unless they are within 80 blocks (does the "entity distance" slider affect either of these?); in the last two examples above the client isn't rendering any entities despite there being around 400 loaded server-side and around 100 client-side (the "mob counts" is server-side while "E:" is client-side).
Naming tools just makes them more expensive to repair further...I never see a use in doing this except to mark a 'maxed out enchanted item' so I don't try to enchant it any further and know it's ready for someone to use.
Quote me if you need me to reply to something. DM me if I don't answer that.
Yes, that a point...
I generally dont max out Tools, I have 4 enchants each.
Sword - Looting, Mending, Sharpness, Unbreaking
Pic, Axe & Shovel - Efficiency, mending, Unbreaking, Fortune or Silk Touch
These are not too expensive, so I guess I could name them I think.
ᛁᚨᚾ ᚷᛖᛞᛞᛖᛋ
PIckaxes generally need mending-and-looting/silk + efficiency + unbreaking to be uber tier.
Quote me if you need me to reply to something. DM me if I don't answer that.
I mainly name my items because in 1.6.4 (1.4-1.7) this lets you repair them indefinitely by keeping the prior work penalty at 2 (one working), with armor simply having the space removed (e.g. DiamondChestplate), while I give held items bit more descriptive names, e.g. "Mining Pickaxe" for my main pickaxe and "Ender Pickaxe" for my Silk Touch pickaxe (as it is primarily used for ender chests). In my modded world I also made a "Smelting Pickaxe" (with a "smelting" enchantment I modded in) and "Super Pickaxe" for one with Vein Miner, itself a reference to what I named my pickaxe back when I used Fortune (I no longer do so since it is absurd to multiply drops when you mine over 3,000 ores per play session and only hinders my gameplay due to running out of space much faster, back then I also used a backpack mod with double-chest sized backpacks for each major resource so it wasn't an issue). My sword is "Monster Slayer", bow is "Super Bow", axe is "Tree Killer", hoe is "Potato Harvester" (or pickaxe in vanilla since you can't put Fortune on a hoe in 1.6.4, in TMCW only hoes can apply Fortune to crops as a balance measure and incentive to use better hoes, as unlike vanilla they lose durability when breaking crops).
I also don't rename my armor at all in modded worlds since I added my own Mending enchantment which is functionally identical to renaming, and I only have one set of armor so there is no point in differentiating between items, I also rename my shears twice so they are just "Shears", which is still considered to be a custom name (as seen by the italicized font. Note that simply clearing the text box, which resets it to the default name, does not work as it also removes the NBT tag), except again, in modded worlds.
Also, since 1.9 renaming does not affect the prior work penalty, and otherwise if you rename an item at the same time you do something else the anvil only counts it as a single use, and prior to 1.8, only factors the "base value" in once, greatly reducing the level cost:
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?
I always use my Silk Touch to Mine, I like to store my Ores until I need them, then I use my Fortune Pickaxe.
ᛁᚨᚾ ᚷᛖᛞᛞᛖᛋ
It just costs one extra level if you rename it with the last enchanted book you put on it.
Mending means repair costs aren't a thing as well.
It is much more efficient to directly mine them on the spot though since you can craft resources into blocks and this saves space in every case except for lapis when mined with Fortune and it is generally a small portion of the total ores you'll collect. For example, this is my ender chest after a session where a net yield of 4,932 resources, or about 77 stacks, were compacted into only 12 slots (or about 8.5 full stacks), you may also notice that I collected 741 rails yet I only have 2 in my inventory, since I modded in "rail blocks" that let me craft 9 rails into a block to save space in the same manner as ores, which are next to the diamonds in the last row (mineshafts are unbelievably common in vanilla 1.6.4 (this is from my first world, where I use such modded blocks while caving, but not for permanent storage), I've collected over 1,000 rails on each of several consecutive days before):
Also, you double tool wear since you have to first mine the ores with Silk Touch, which also gives no XP, then again to get the actual drops, in addition to the time spent on placing and mining them again, and unless you bring enough coal with you you'll need to bring a second pickaxe anyway in order to mine it for the coal (in the case of iron and gold ore I accumulate it in my ender chest and inventory until I need more space, then I find an easy to find again area, like the main room of a mineshaft or one of my "return points", and set up a bank of furnaces and continue exploring nearby while it smelts)..
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?
Well I misspoke, and should've said 'repair or further enchant'. If you add the name before the last book, the last book costs more.
Quote me if you need me to reply to something. DM me if I don't answer that.
Nothing
It's usually only worth storing them in that manner if they are Fortuned however, if without a Fortune pickaxe you get much less resources and you need 9 diamonds, coal or iron to make a block to then condense the items into chests for efficient storage.
I like using Silk Touch enchant to store ores until I need them as well. It's rare that I obtain enough of something to need to break the ore then condense the items into blocks. I'm sure the longer I keep the same world the need to do this will increase, but for now Silk Touch is doing me fine.
What I do obtain a large sum of however are things like Stone, Diorite, Granite and Andesite, these are common blocks which necessitated me building warehouse full of chests to store them. I suppose this explains the reduction in FPS I've been getting lately when going to the factory that has these massive storage rooms. But I do need them, especially since I share a server with other people to play on who need to store their gear too.
Well, I often do say that I do more caving/mining in a single session than most players do in the entire lifetime of a world but surely even the average player can collect a few hundred resources in a single trip, Fortune or not (which only roughly doubles drops, so not that "much less", redstone is only multiplied by 1.33 and even without Fortune you get an average of 9 resources from two ores). For example, somebody got all of this in one hour of branch-mining:
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
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?
Yeah I should have thought about that at the time, I guess I didn't want to risk randomly causing Villagers in the trading system to change to Fishermen after failing to remember their job-site blocks which is closest to them, but the performance issue is a much bigger problem, I could amend the decision at a later time but I'd need to farm an enormous load of wood first.
But chests being entities is the reason I am getting my frame rate cut in half to what it usually is, under normal circumstances it would be in the 100fps range, even whilst traveling, but when I am in the factory with the warehouses, it goes down to about 50fps or sometimes even less because of the redstone I use for the semi automated stone and basalt generators.
Why chests count as entities in the game I don't know, barrels are just as good as chests space wise.
It is true you cannot make a double chest variant of the barrels, but what you can do with barrels is place them side by side making the total capacity of them about the same. Additionally barrels can be opened even when there is a block directly above them.
Both chests and barrels are "tile entities" or "block entities" and are pretty much identical in code except that chests are dynamically rendered in the same way as regular entities are since normal block rendering doesn't support smooth animations like the lid opening and closing (barrels do change their top texture but it only switches between open and closed, similar to furnaces and burning furnaces).
They could however optimize them by rendering closed chests as a single piece instead of 3 separate pieces (base, lid, and latch), as I do for about twice the performance (the reason why shulker boxes aren't as bad is because they only have 2 separate pieces to render), and I've even thought of adding a setting to make chests render like a normal block without an opening/closing animation:
if (lidAngle > 0.001F) { // Normal rendering used when chest is opened lidAngle = 1.0F - lidAngle; lidAngle = 1.0F - lidAngle * lidAngle * lidAngle; chestModel.chestLid.rotateAngleX = -(lidAngle * MathHelper.HALF_PI); chestModel.renderAll(); } else { // Renders closed chests (including items) as a single unit for improved performance renderClosedChest(chestModel instanceof ModelLargeChest); } // ModelChest; note that three separate draw calls are used to render each piece; each also applies various rotations and translations to OpenGL state, which all add even more to the render time public void renderAll() { this.chestKnob.rotateAngleX = this.chestLid.rotateAngleX; this.chestLid.render(0.0625F); this.chestKnob.render(0.0625F); this.chestBelow.render(0.0625F); } // renderClosedChest; uses a custom model which only requires a single draw call, and also culls hidden faces (top of // base, bottom of lid, and back of latch) public static void renderClosedChest(boolean isLargeChest) { if (!compiled) compileDisplayLists(); if (isLargeChest) { GL11.glCallList(largeChestDisplayList); } else { GL11.glCallList(chestDisplayList); } }That said, the 500+ chests in my storage area in my first world still cause FPS to drop by a factor of 3 but I still get about 4 times the capped FPS so the effect is unnoticeable, and the layout means that it is large enough that when standing at one end the other end is so far away that chests are no longer rendering (they have a render distance of 64 blocks, and chests outside the field of view aren't rendered so even when standing in the middle only half are being rendered). It does mean that I have to walk around a lot to get to the chests further way but I only have to make a couple trips to put everything away.
For comparison, I turned flower pots into a tile entity so they can contain any number of plants, but they use standard block rendering for very little impact on performance, even memory usage is not significantly impacted in the example shown, a Superflat world with a layer of flowerpots (each tile entity uses additional memory, which is 32 bytes if I calculated it correctly, but for the number that were loaded this only amounts to about 7 MB on both the client and server; this screenshot was also taken before I made various optimizations to rendering and memory usage in general):
(there is however an issue with even a small number of flower pots with full-size tree models, like these, due to the complexity of the model causing a chunk update to take a long time and cause a lag spike when updated, but steady-state FPS is not affected any more than the same number of real blocks would. Barrels could cause similar lag spikes when opened/closed as they need a chunk update to change their texture)
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?
I have about 500+ chests myself so this explains where the performance issues are coming from, the entities and their chunk updates are putting increased strain on the CPU even with my newer PC that has an AMD Ryzen CPU, no doubt they cause lag on your PC too.
On topic of the thread what me and a friend have done recently is visited the End, beaten Ender Dragon and obtained some Elytras each and Shulker boxes, and he obtained a Dragon Head, something I forgot to get.
Now that I have Shulker boxes large scale builds are feasible, as I can carry supplies back and forth across territory without having to rely on an expensive minecart system.
I would have built a minecart system on my current world to use for transportation of those resources if Mojang hadn't removed Gold Ingot drops from Drowned Zombies, now that they're gone since 1.17 I don't have as much luxury to do this. I could obtain Gold from the Nether, but it is a considerable grind, and I found it wasn't worth my time.
In this case I have to transport items from a Mushroom Island roughly 384 blocks away across a lake surrounded by mainland, which only becomes partially visible with a 24 chunk render distance although I play with 32 chunks render distance most of the time, and this links to a Forest biome, and this is only for the initial project, when the city becomes large enough it would span 1,000 blocks away from the Mushroom Island and all the resources used to build it would need to be transported. I find Shulker boxes to be more efficient for this.
Mojang isn't going to care about what I say though, I am only one person out of the millions who play this game.
My refusal to use mods and cheats also limits what I can do in vanilla Minecraft.
I play survival with friends because we enjoy the thrill of collecting resources then use them to build things,
like the city I have planned, but because of the way Mojang designs their game out of fear of it becoming too broken or cheaty,
build style players like myself don't have a lot of options in what we can do when it involves a time consuming project.
Wow!
Quote me if you need me to reply to something. DM me if I don't answer that.
Oh my goodness, really!? that much of a difference!?
This made me think of something. I started playing with shaders in 1.16, and after the game updated to 1.18, performance was a lot lower, specifically just around my village. Now I don't have a ton of chests, but collectively there's probably enough entities I guess? Chests, barrels, other job site blocks (not sure how much these matter), item frames, villagers, iron golems, birds, cats, and who knows what else.
Now my first thought was 1.18 was just performance demanding, as it is. But this only happened specifically when playing with shaders, so it wasn't fully explaining it. Nor was "shaders are demanding" as they were fine in 1.16.
I started wondering if it was related to entities and/or shadows. Unfortunately, reducing the shadow texture size did almost nothing.
I was curious and noticed turning the new entity distance setting from 100% to 50% improved it (oddly, turning it from 100% to 500% barely degraded it further), but it was still lower than before. That, and entities weren't rendering from as far as I wanted in many situations. But my guesses were being partly confirmed by this.
BSL updated a bit later and an "entity shadows" setting was added within the shaders. What a difference maker.
It took a short while to adjust to the lack of shadows from entities but I did, and it is noooooot worth that massive of a performance drop from having them on.
Why is it always entities!?
Thankfully my fairly new gaming rig laughs at the face of Minecraft so I don't need to consider blocks based on performance
This build is taking forever..
Didn't find blocks to make the upper walls and towers white, as I wanted to, so ended up using stone colors instead. At least there are many block alternatives in that color.. But the build is looking a bit too gray.. Will see if I can add more details and improve walls later.. But at least now I have outer walls, and can potentially leave them alone while starting to build village within instead..
The bottom part of the wall will definitively get more mossy cobblestone variants later, but tired of messing with walls for now.. Though I guess I should complete the bridge over the water, so the entrance part looks ok..
Three redstone gates in here now, splitting up the 3 areas within, and I think the whole area should be mob proof now.. Used a ton of blocks though. Got empty of cobblestone, stone and dirt at some point, so have digged within the structure to get more blocks, so pretty large areas of hollowed out space within here too now.. Where I'll put up some more auto-farms I think...
Hi I’m bao/Azkamenk42 I made a village and an an island home working on a small mansion anyone have any ideas for what I should do to the inside
I like fantasy pirates pvp building and destroying
Mine does fine with vanilla Minecraft at normal render distances and such too. I don't think even modern versions demand much there.
It's when you get into shaders, resource packs, higher render distances, or some combination that can cause large performance degradation.
If there's one thing I learned with this game over the last decade, it's that it doesn't care what CPU or graphics card you have if you push certain things too far. This game can and will humble it.
I'm glad to see your hardcore world has progressed into the "building" parts. Those are my favorite parts.
The reason is because every part of an entity requires a separate draw call and these are expensive; a chest requires that the game tell the GPU to render three separate pieces; a chicken has 8 separate pieces, and so on. Worse, the game needs to switch between textures, which is also expensive, when rendering an entity and its shadow, as well as any equipment it has (the game stitches all block textures into a single texture atlas precisely because each draw call can only reference one texture at a time).
To illustrate just how different block and entity rendering is, all blocks can be rendered in as little as 3 draw calls (at least in 1.6.4, when Fancy graphics, or translucent blocks/water are enabled; Fast graphics only requires 2 draw calls, plus a handful of OpenGL state changes):
private int renderSortedRenderers(int par1, int par2, double playerX, double playerY, double playerZ) { if (!this.fastRender) return renderSortedRenderers_old(par1, par2, playerX, playerY, playerZ); this.glListBuffer.clear(); int var6 = 0; boolean var7 = this.mc.gameSettings.showDebugInfo; int x = MathHelper.floor_double(playerX) - 8; int z = MathHelper.floor_double(playerZ) - 8; for (int var8 = par1; var8 < par2; ++var8) { ChunkRenderer var9 = this.sortedChunkRenderers[var8]; if (var7) { if (var9.skipRenderPass0 && var9.skipRenderPass1) { ++this.renderersSkippingRenderPass; } else if (!var9.isInFrustum) { ++this.renderersBeingClipped; } else if (this.advancedOpengl && !var9.isVisible) { ++this.renderersBeingOccluded; } else { ++this.renderersBeingRendered; } } if (var9.isInFrustum && !var9.skipRenderPass0 && (!this.advancedOpengl || var9.isVisible)) { if (var9.shouldRender(x, this.playerHeight, z, this.renderRadius1, this.renderRadius2)) { int var10 = var9.getGLCallListForPass0(); if (var10 >= 0) { this.glListBuffer.put(var10); ++var6; if (var6 >= MAX_GL_LISTS) break; } } else if (var7) { ++this.renderersBeingOccluded; --this.renderersBeingRendered; } } } if (var6 > 0) { this.glListBuffer.flip(); GL11.glTranslatef((float)(-playerX), (float)(-playerY), (float)(-playerZ)); GL11.glCallLists(this.glListBuffer); GL11.glTranslatef((float)playerX, (float)playerY, (float)playerZ); } return var6; }By contrast, this is what the game calls to render every single piece of an entity - in the extreme case, horses have 39 pieces (and were likely simplified in part because of how demanding such a complex model is - one of the only times I experience a lag spike while playing is when a horse renders for the first time, due to the cost of constructing its model (it doesn't help that it combines multiple layers of textures), which isn't compiled until an entity is rendered for the first time):
public void render(float par1) { if (!this.isHidden) { if (this.showModel) { if (!this.compiled) { this.compileDisplayList(par1); } GL11.glTranslatef(this.offsetX, this.offsetY, this.offsetZ); int var2; if (this.rotateAngleX == 0.0F && this.rotateAngleY == 0.0F && this.rotateAngleZ == 0.0F) { if (this.rotationPointX == 0.0F && this.rotationPointY == 0.0F && this.rotationPointZ == 0.0F) { GL11.glCallList(this.displayList); if (this.childModels != null) { for (var2 = 0; var2 < this.childModels.size(); ++var2) { ((ModelRenderer)this.childModels.get(var2)).render(par1); } } } else { GL11.glTranslatef(this.rotationPointX * par1, this.rotationPointY * par1, this.rotationPointZ * par1); GL11.glCallList(this.displayList); if (this.childModels != null) { for (var2 = 0; var2 < this.childModels.size(); ++var2) { ((ModelRenderer)this.childModels.get(var2)).render(par1); } } GL11.glTranslatef(-this.rotationPointX * par1, -this.rotationPointY * par1, -this.rotationPointZ * par1); } } else { GL11.glPushMatrix(); GL11.glTranslatef(this.rotationPointX * par1, this.rotationPointY * par1, this.rotationPointZ * par1); if (this.rotateAngleZ != 0.0F) { GL11.glRotatef(this.rotateAngleZ * (180F / (float)Math.PI), 0.0F, 0.0F, 1.0F); } if (this.rotateAngleY != 0.0F) { GL11.glRotatef(this.rotateAngleY * (180F / (float)Math.PI), 0.0F, 1.0F, 0.0F); } if (this.rotateAngleX != 0.0F) { GL11.glRotatef(this.rotateAngleX * (180F / (float)Math.PI), 1.0F, 0.0F, 0.0F); } GL11.glCallList(this.displayList); if (this.childModels != null) { for (var2 = 0; var2 < this.childModels.size(); ++var2) { ((ModelRenderer)this.childModels.get(var2)).render(par1); } } GL11.glPopMatrix(); } GL11.glTranslatef(-this.offsetX, -this.offsetY, -this.offsetZ); } } }As an illustration of just how costly entity rendering is, 100 chickens has a bigger impact on FPS than going from a default Superflat world, with only a few chunks in view, to a normal world at maximum (16 chunks) render distance, or even in a "mega forest" biome:
This is also why the game is fairly aggressive on entity culling; chickens only render up to 28 blocks away (the distance is based on their size) and the server doesn't send most entities to the client unless they are within 80 blocks (does the "entity distance" slider affect either of these?); in the last two examples above the client isn't rendering any entities despite there being around 400 loaded server-side and around 100 client-side (the "mob counts" is server-side while "E:" is client-side).
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?