I think planks abd slabs suffice for tables and counters, but it would be nice to have actual (functioning) chairs that villagers don't try to endlessly climb. I'd support it.
While I can make furniture using the above blocks, there is no real furniture in the game, and I'd like it a lot, too.
Full support!
We already have beds, if that counts, but they serve a purpose in the game, they set your spawn point and change night to day time, preventing further monster mob spawns in daylight.
what purpose would a sofa bring to the game? aesthetics while nice, some would not consider this to be enough.
Perhaps a sofa and chair could allow players to sit and slow the depletion of their hunger bar, but even then that would be boring and this issue can easily be circumvented by logging out if you want a break.
I agree with the other posters in saying these things can already be made (sort of) by using stair blocks and what not.
I'm not against the idea in principle, they can be made to look less ugly as a result, but we're not talking about decor blocks here, we're talking about adding in items that should serve a purpose for survival gameplay like the bed does.
Maybe an alternative is for there to be blocks that could be used to create more realistic looking furniture, but that could also be used for other purposes. I know some use trapdoors for some parts of chairs, and as thin wall dividers. A thin block, similar to an open trapdoor, but is fixed in place, could be useful.
Maybe an alternative is for there to be blocks that could be used to create more realistic looking furniture, but that could also be used for other purposes. I know some use trapdoors for some parts of chairs, and as thin wall dividers. A thin block, similar to an open trapdoor, but is fixed in place, could be useful.
And bed is already furniture which exists officially in the game, but it helps with countering monsters during survival gameplay by changing the time of the day and it sets your spawn in the over world.
There is however an annoying bug with beds that I want patched, they don't sit very well on top of half slabs if on the bottom half
the same could be done with other furniture if they were to be added so they don't just look like they're suspended in midair in a room full of half slabs.
Other than a haunted house design, floating furniture just doesn't look right to me.
Tables could be useful for providing a place to put bowls down, you know, the bowl of mushroom stew, and a table top could also serve as a place to put weapons down, kind of like an item frame but a different orientation. And they could be used to hold potions.
Tables if they were put in, should be craftable by different wood types, and have an aesthetic or texture dependent on the type of wood used.
I'm not sure what chairs would be used for, how about setting your spawn location in the over world, but not changing night to day? they would have one feature a bed has but not the other, making them not as useful as beds, but still have a purpose during gameplay, in addition to needing less resource types.
Chairs should also be made from wood, but not wool, and a texture dependent on the type of wood used, but be flammable, meaning players would have to exercise caution when placing chairs down to set their new spawn location, and if chairs get destroyed, the spawn defaults to origin.
A sofa could be craftable by wool and chairs in a row, and have a new feature that items don't yet have,
if all players use sofas in their houses while it is raining, it sets the weather to clear if day time, but change the time to night
meaning sloth would not be a good excuse to avoid fighting monsters.
Perhaps a sofa and chair could allow players to sit and slow the depletion of their hunger bar, but even then that would be boring and this issue can easily be circumvented by logging out if you want a break.
But hunger doesn't deplete at all if you don't move - even walking has no effect so you can walk around your base or AFK as long as you like without ever having to eat - so there is no point in adding something that slows/stops hunger loss when not moving (and even if they did make hunger very slowly deplete as a way to discourage AFKing it would defeat the purpose to add a way to stop it):
Any action not listed here does not increase exhaustion level. For example, normal walking doesn't increase exhaustion, and therefore does not decrease saturation or the food bar.
But hunger doesn't deplete at all if you don't move - even walking has no effect so you can walk around your base or AFK as long as you like without ever having to eat - so there is no point in adding something that slows/stops hunger loss when not moving (and even if they did make hunger very slowly deplete as a way to discourage AFKing it would defeat the purpose to add a way to stop it):
A mechanic that can be changed in an update, the game isn't static, it was literally made with the intention to be changed over time.
Currently when you don't move hunger doesn't deplete, and it depletes rather quickly if you sprint around and jump a lot, but if new furniture were to be added those things would need a useful purpose, otherwise it is adding in unnecessary bulk to the game.
I'm not sure what chairs would be used for, how about setting your spawn location in the over world, but not changing night to day? they would have one feature a bed has but not the other, making them not as useful as beds, but still have a purpose during gameplay, in addition to needing less resource types.
But you can set your spawn point without making it daytime by "sleeping" for less than 5 seconds.
Or, in 1.15 or later, trying to use a bed in the daytime. Which doesn't cure insomnia (keep phantoms away).
So if you're looking for a new bed-related function, how about curing insomnia and/or turning night to day without setting the spawn point.
I'd think it would make more sense to have something like a camp bed or sleeping bag for that but a sofa could work.
But you can set your spawn point without making it daytime by "sleeping" for less than 5 seconds.
Or, in 1.15 or later, trying to use a bed in the daytime. Which doesn't cure insomnia (keep phantoms away).
So if you're looking for a new bed-related function, how about curing insomnia and/or turning night to day without setting the spawn point.
I'd think it would make more sense to have something like a camp bed or sleeping bag for that but a sofa could work.
or introducing a hammock, which has the same function as beds, but requiring slightly different resources, it using 2 strings, left to right, and 3 wool blocks underneath, instead.
the hammock could then be required to have 5 blocks worth of space in between solid blocks to be placed.
We don't have hammocks yet, but in principle they could be introduced without breaking the game, since you would have to fight spiders, or find another source of string to get the materials for the hammock and couldn't simply acquire it by killing or shearing sheep then using a crafting table after chopping a tree down.
Whatever the case may be, it is clear to everyone that Minecraft doesn't have enough items and it is far too limited in what you can actually do in the game without mods involved.
You could craft a chair out of a stair block, sign posts and a trapdoor, technically, but it wouldn't be the sort of thing the original poster is asking for. You can't place wool on the seat to act as a cushion for a start.
You could make a pseudo sofa using wool blocks in a line, but it would be an eye sore.
Beds not being able to be placed at half block positions isn't a bug, it's an integral part of the game, beds, like most game objects, are made of blocks and blocks can only be placed at full block positions.
Allowing blocks to be placed between the normal block positions or turning beds into entities would add unnecessary complexity and lag for purely aestetic reasons.
Beds not being able to be placed at half block positions isn't a bug, it's an integral part of the game, beds, like most game objects, are made of blocks and blocks can only be placed at full block positions.
Allowing blocks to be placed between the normal block positions or turning beds into entities would add unnecessary complexity and lag for purely aestetic reasons.
Lag? how? by adding a feature which causes more CPU power required? they've already been doing this over the years with the various other updates they've been conjuring up, not to mention the ray tracing update intended for Microsoft's upcoming console, and on PC's with Nvidia's RTX video cards, which will no doubt be more demanding on both the CPU and GPU.
Like it or not, the game is going to become more advanced into the future, so get used to it.
Higher computational demands in themselves are not a good reason to allow a game to become stale.
the system requirements to run the game properly used to be 2gb of RAM and a single core CPU
but now you're expected to have a minimum of 4gb of RAM, if you play either the current Java version, or bedrock edition.
8gb of RAM and an Intel i7-6500U or AMD A8-6600K CPU are recommended to have the best experience according to Microsoft.
Lag? how? by adding a feature which causes more CPU power required? they've already been doing this over the years with the various other updates they've been conjuring up, not to mention the ray tracing update intended for Microsoft's upcoming console, and on PC's with Nvidia's RTX video cards, which will no doubt be more demanding on both the CPU and GPU.
Like it or not, the game is going to become more advanced into the future, so get used to it.
Higher computational demands in themselves are not a good reason to allow a game to become stale.
the system requirements to run the game properly used to be 2gb of RAM and a single core CPU
but now you're expected to have a minimum of 4gb of RAM, if you play either the current Java version, or bedrock edition.
8gb of RAM and an Intel i7-6500U or AMD A8-6600K CPU are recommended to have the best experience according to Microsoft.
Most of that is due to Mojang's horrific coding practices, not new features - in fact, I've added hundreds of new features and greatly reduced system requirements - for comparison, I used to play on a computer with a 14 year old CPU/GPU and didn't have any issues even in "mega forest" biomes with 64+ block tall trees as long as I didn't set leaves to Fancy (which was mainly due to a lack of VRAM, just 256 MB, not raw processing power).
True, this is not from TMCW but my own optimized version based on 1.6.4 (I call it "World1" since it is what I use to play on my first world) but I have not seen any difference with even TMCWv5, which actually has faster world generation due to completely changing how chunk decoration works (instead of indirectly accessing chunks through the "World" class it uses a chunk cache and all block updates are applied post-generation, as are light updates, rather than trying to do it as each individual block is placed):
Jungles cause lag? This is 1360 FPS, 1.25 ms server tick time, 0.39 ms client tick time, and only 101 MB of memory usage, allocated at 1-2 MB per second, on max settings - and it all runs on only two main threads (since 1.8 Mojang has greatly multithreaded the game, from rendering to world generation to mob AI to dimensions - yet somehow the game still runs worse and uses an order of magnitude more memory):
There is no need for fancy "loading screens" when you don't have to wait for the game to load or generate a world:
Client startup; the Mojang screen was only displayed for a second (this was within MCP; the launcher takes longer to "prepare" the game as it checks that every file has been downloaded and is up to date, and also extracts the "natives". Otherwise, the game itself starts up the same either way):
2020-03-26 19:52:33 [CLIENT] [INFO] Setting user: TheMasterCaver
2020-03-26 19:52:33 [CLIENT] [INFO] (Session ID is null)
2020-03-26 19:52:33 [CLIENT] [INFO] LWJGL Version: 2.9.0
2020-03-26 19:52:34 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
2020-03-26 19:52:34 [CLIENT] [SEVERE] Realms: Server not available!
World creation; a total of 3 seconds elapsed from server launch to the world loading in:
2020-03-24 17:01:41 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-03-24 17:01:41 [SERVER] [INFO] Generating keypair
2020-03-24 17:01:41 [SERVER] [INFO] Converting map!
2020-03-24 17:01:41 [SERVER] [INFO] Scanning folders...
2020-03-24 17:01:41 [SERVER] [INFO] Total conversion count is 0
2020-03-24 17:01:41 [SERVER] [INFO] Preparing start region for level 0
2020-03-24 17:01:42 [SERVER] [INFO] Preparing spawn area: 17%
2020-03-24 17:01:43 [SERVER] [INFO] Preparing spawn area: 49%
2020-03-24 17:01:44 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 129 at (-95.5, 65.0, 226.5)
World reload (from a "cold" start to ensure that the files weren't cached in memory; yes, it took less than a second to load the world, no fancy loading screen needed at all):
2020-04-04 15:46:02 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-04-04 15:46:02 [SERVER] [INFO] Generating keypair
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 15 at (-61.90341054123914, 65.000000001, 247.78940559636038)
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver joined the game
Here is something really amazing:
How does Beta use just as much memory despite having far less content? Even if you go by allocated (an indication of peak memory usage) it is not much lower, either way they could run with only 256 MB allocated, and the Beta image doesn't look like a very far render distance, or in a very complex area.
Also, here is a screenshot from TMCWv5, without the rendering and other optimizations I made, showing that even an entire world covered with flower pot tile entities has no major adverse impact on performance (note that memory usage is not higher mainly because of tile entities but because 1.6.4 generated all 16 chunk sections in Superflat even if they were air, which I didn't fix until after I took this, reducing memory usage to as little as 30 MB):
Not only that, you can even have miniature tree models in them, which are generated just like a normal tree - you also have to absolutely love the performance (taken after I added many of the optimizations from World1. Also while this is a Superflat world each tree has as many faces being rendered as an actual tree; in fact, the chunk section they are in is so complex it caused the tessellator to have to expand its buffer to accommodate all of the vertex data):
The main reason why tile entities are so often blamed for lag is because they may be rendered using a "tile entity special renderer" which renders them in the same manner as normal entities redrawing them every frame with at least one OpenGL call per entity - however, simple blocks do not need a TESR; for example, furnaces are rendered as a normal block, while mob spawners are rendered as both (using a TESR for the mob inside):
First, I created a completely empty Superflat world. Then, I filled an entire chunk (16x16x256, 65,536 blocks) with dirt, a block that does nothing. I got a small blip of lag and an increase of memory usage, as the /fill commands were executed and Minecraft saved the data, which quickly subsided. I then replaced that chunk with furnaces, a tile entity that does nothing when not burning fuel. Again, a small blip of lag and memory increase, but the performance quickly returned to normal. I then did the same thing with hoppers, which had a similar effect, but a small amount of my fps drop and increased memory usage lingered due to the hoppers constantly ticking and checking what was in each other's inventory.
So, in other words, even on potato machines like mine, tile entities that do nothing don't really contribute to performance loss all that much. And really, does the average person use more than 65k slabs in any build?
In any case, 1.13 completely removed any need for tile entities for basic blocks - beds and flowerpots are now all separate blocks since the number of blocks is now unlimited (if not entirely without any penalty; the more blocks there are the bigger the list will get and the longer it will take to look up entries, though a hashmap can alleviate this, but it still still consumes more memory and reduces CPU cache locality).
Also, it is entirely possible to render blocks outside of the normal bounds of a block, you can see this with blocks like tall grass, which have a random offset and can extend into adjacent block spaces; likewise, my large stalagmites are actually a single block that is rendered 2 blocks tall, as is their collision box (the second block is actually air but you can mine them from either block (not like a door, which is two separate blocks and the break timer resets if you move from one to the other) and can't place blocks in either space):
These are actually all a single block without a tile entity; the color of hardened clay stalagmites depends on the color of the hardened clay they are placed on (defaulting to normal if on a different block), same for stone variants, and they are flipped to render as stalactites if there is a valid block above (there are actually only 12 variants (data values/items), 6 each for small and large; I also recolor the texture for stained clay variants so only one texture is required for each sub-variant):
(the same texture-saving also applies to my "metadata ores", seen on the far left, where a single transparent overlay is overlaid onto a base texture taken from another block like stone - all of this saves on loading time and texture memory usage; of course, with a slight penalty in render speed due to having to render each face twice but that is negligible, especially with my other optimizations)
Also, another reason why 1.8+ is so awful is because every single block state requires its own json model, which each use quite a lot of memory and all but necessitates using a TESR for any sort of complex block (this is also a major reason why many mods took so long to update, if ever):
(I have to absolutely love the claim that 1.3 needs at least 500 MB to even run when I only see 1/5 of that, with 1.5+ needing even more (which is wrong - all the separate textures means is slightly increased load time as the game needs to load them one by one and stitch them together into an atlas, just like before) - indeed, World1/TMCW needs no more memory than Beta versions, with 256 MB being enough for most situations)
Most of that is due to Mojang's horrific coding practices, not new features - in fact, I've added hundreds of new features and greatly reduced system requirements - for comparison, I used to play on a computer with a 14 year old CPU/GPU and didn't have any issues even in "mega forest" biomes with 64+ block tall trees as long as I didn't set leaves to Fancy (which was mainly due to a lack of VRAM, just 256 MB, not raw processing power).
True, this is not from TMCW but my own optimized version based on 1.6.4 (I call it "World1" since it is what I use to play on my first world) but I have not seen any difference with even TMCWv5, which actually has faster world generation due to completely changing how chunk decoration works (instead of indirectly accessing chunks through the "World" class it uses a chunk cache and all block updates are applied post-generation, as are light updates, rather than trying to do it as each individual block is placed):
Jungles cause lag? This is 1360 FPS, 1.25 ms server tick time, 0.39 ms client tick time, and only 101 MB of memory usage, allocated at 1-2 MB per second, on max settings - and it all runs on only two main threads (since 1.8 Mojang has greatly multithreaded the game, from rendering to world generation to mob AI to dimensions - yet somehow the game still runs worse and uses an order of magnitude more memory):
There is no need for fancy "loading screens" when you don't have to wait for the game to load or generate a world:
Client startup; the Mojang screen was only displayed for a second (this was within MCP; the launcher takes longer to "prepare" the game as it checks that every file has been downloaded and is up to date, and also extracts the "natives". Otherwise, the game itself starts up the same either way):
2020-03-26 19:52:33 [CLIENT] [INFO] Setting user: TheMasterCaver
2020-03-26 19:52:33 [CLIENT] [INFO] (Session ID is null)
2020-03-26 19:52:33 [CLIENT] [INFO] LWJGL Version: 2.9.0
2020-03-26 19:52:34 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
2020-03-26 19:52:34 [CLIENT] [SEVERE] Realms: Server not available!
World creation; a total of 3 seconds elapsed from server launch to the world loading in:
2020-03-24 17:01:41 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-03-24 17:01:41 [SERVER] [INFO] Generating keypair
2020-03-24 17:01:41 [SERVER] [INFO] Converting map!
2020-03-24 17:01:41 [SERVER] [INFO] Scanning folders...
2020-03-24 17:01:41 [SERVER] [INFO] Total conversion count is 0
2020-03-24 17:01:41 [SERVER] [INFO] Preparing start region for level 0
2020-03-24 17:01:42 [SERVER] [INFO] Preparing spawn area: 17%
2020-03-24 17:01:43 [SERVER] [INFO] Preparing spawn area: 49%
2020-03-24 17:01:44 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 129 at (-95.5, 65.0, 226.5)
World reload (from a "cold" start to ensure that the files weren't cached in memory; yes, it took less than a second to load the world, no fancy loading screen needed at all):
2020-04-04 15:46:02 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-04-04 15:46:02 [SERVER] [INFO] Generating keypair
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 15 at (-61.90341054123914, 65.000000001, 247.78940559636038)
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver joined the game
Here is something really amazing:
How does Beta use just as much memory despite having far less content? Even if you go by allocated (an indication of peak memory usage) it is not much lower, either way they could run with only 256 MB allocated, and the Beta image doesn't look like a very far render distance, or in a very complex area.
Also, here is a screenshot from TMCWv5, without the rendering and other optimizations I made, showing that even an entire world covered with flower pot tile entities has no major adverse impact on performance (note that memory usage is not higher mainly because of tile entities but because 1.6.4 generated all 16 chunk sections in Superflat even if they were air, which I didn't fix until after I took this, reducing memory usage to as little as 30 MB):
Not only that, you can even have miniature tree models in them, which are generated just like a normal tree - you also have to absolutely love the performance (taken after I added many of the optimizations from World1. Also while this is a Superflat world each tree has as many faces being rendered as an actual tree; in fact, the chunk section they are in is so complex it caused the tessellator to have to expand its buffer to accommodate all of the vertex data):
The main reason why tile entities are so often blamed for lag is because they may be rendered using a "tile entity special renderer" which renders them in the same manner as normal entities redrawing them every frame with at least one OpenGL call per entity - however, simple blocks do not need a TESR; for example, furnaces are rendered as a normal block, while mob spawners are rendered as both (using a TESR for the mob inside):
In any case, 1.13 completely removed any need for tile entities for basic blocks - beds and flowerpots are now all separate blocks since the number of blocks is now unlimited (if not entirely without any penalty; the more blocks there are the bigger the list will get and the longer it will take to look up entries, though a hashmap can alleviate this, but it still still consumes more memory and reduces CPU cache locality).
Also, it is entirely possible to render blocks outside of the normal bounds of a block, you can see this with blocks like tall grass, which have a random offset and can extend into adjacent block spaces; likewise, my large stalagmites are actually a single block that is rendered 2 blocks tall, as is their collision box (the second block is actually air but you can mine them from either block (not like a door, which is two separate blocks and the break timer resets if you move from one to the other) and can't place blocks in either space):
These are actually all a single block without a tile entity; the color of hardened clay stalagmites depends on the color of the hardened clay they are placed on (defaulting to normal if on a different block), same for stone variants, and they are flipped to render as stalactites if there is a valid block above (there are actually only 12 variants (data values/items), 6 each for small and large; I also recolor the texture for stained clay variants so only one texture is required for each sub-variant):
(the same texture-saving also applies to my "metadata ores", seen on the far left, where a single transparent overlay is overlaid onto a base texture taken from another block like stone - all of this saves on loading time and texture memory usage; of course, with a slight penalty in render speed due to having to render each face twice but that is negligible, especially with my other optimizations)
Also, another reason why 1.8+ is so awful is because every single block state requires its own json model, which each use quite a lot of memory and all but necessitates using a TESR for any sort of complex block (this is also a major reason why many mods took so long to update, if ever):
(I have to absolutely love the claim that 1.3 needs at least 500 MB to even run when I only see 1/5 of that, with 1.5+ needing even more (which is wrong - all the separate textures means is slightly increased load time as the game needs to load them one by one and stitch them together into an atlas, just like before) - indeed, World1/TMCW needs no more memory than Beta versions, with 256 MB being enough for most situations)
It comes down to the render distance you're using also, I'm not sure what render distance the 3DS edition uses specifically, but by the looks of it, it isn't as far as the render distance on the current console editions of the game, on Xbox One bedrock edition is said to use 22 chunks render distance.
It is possible to run the game on a system with just 256mb of memory, or else Mojang wouldn't have been able to port the game to the New 3DS some time ago, but the experience may be inferior and you end up making a lot of sacrifices just to get it to work.
I've even seen a video of somebody who got Minecraft (Java obviously) to work on a PC with Windows 98 somehow, although it was very laggy, also the operating system was known to be unstable on computers with more than 512mb of RAM, second edition could be tweaked to be okish with 1gb of RAM.
We both know the current versions of Minecraft both Java and bedrock edition should be ran on a PC with 4gb of RAM at minimum, if using Windows 10. Note that bedrock edition isn't available for previous versions of Windows, but I would advise at least 8gb if people are using high render distances or mods.
Most of that is due to Mojang's horrific coding practices, not new features - in fact, I've added hundreds of new features and greatly reduced system requirements - for comparison, I used to play on a computer with a 14 year old CPU/GPU and didn't have any issues even in "mega forest" biomes with 64+ block tall trees as long as I didn't set leaves to Fancy (which was mainly due to a lack of VRAM, just 256 MB, not raw processing power).
True, this is not from TMCW but my own optimized version based on 1.6.4 (I call it "World1" since it is what I use to play on my first world) but I have not seen any difference with even TMCWv5, which actually has faster world generation due to completely changing how chunk decoration works (instead of indirectly accessing chunks through the "World" class it uses a chunk cache and all block updates are applied post-generation, as are light updates, rather than trying to do it as each individual block is placed):
Jungles cause lag? This is 1360 FPS, 1.25 ms server tick time, 0.39 ms client tick time, and only 101 MB of memory usage, allocated at 1-2 MB per second, on max settings - and it all runs on only two main threads (since 1.8 Mojang has greatly multithreaded the game, from rendering to world generation to mob AI to dimensions - yet somehow the game still runs worse and uses an order of magnitude more memory):
There is no need for fancy "loading screens" when you don't have to wait for the game to load or generate a world:
Client startup; the Mojang screen was only displayed for a second (this was within MCP; the launcher takes longer to "prepare" the game as it checks that every file has been downloaded and is up to date, and also extracts the "natives". Otherwise, the game itself starts up the same either way):
2020-03-26 19:52:33 [CLIENT] [INFO] Setting user: TheMasterCaver
2020-03-26 19:52:33 [CLIENT] [INFO] (Session ID is null)
2020-03-26 19:52:33 [CLIENT] [INFO] LWJGL Version: 2.9.0
2020-03-26 19:52:34 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
2020-03-26 19:52:34 [CLIENT] [SEVERE] Realms: Server not available!
World creation; a total of 3 seconds elapsed from server launch to the world loading in:
2020-03-24 17:01:41 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-03-24 17:01:41 [SERVER] [INFO] Generating keypair
2020-03-24 17:01:41 [SERVER] [INFO] Converting map!
2020-03-24 17:01:41 [SERVER] [INFO] Scanning folders...
2020-03-24 17:01:41 [SERVER] [INFO] Total conversion count is 0
2020-03-24 17:01:41 [SERVER] [INFO] Preparing start region for level 0
2020-03-24 17:01:42 [SERVER] [INFO] Preparing spawn area: 17%
2020-03-24 17:01:43 [SERVER] [INFO] Preparing spawn area: 49%
2020-03-24 17:01:44 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 129 at (-95.5, 65.0, 226.5)
World reload (from a "cold" start to ensure that the files weren't cached in memory; yes, it took less than a second to load the world, no fancy loading screen needed at all):
2020-04-04 15:46:02 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-04-04 15:46:02 [SERVER] [INFO] Generating keypair
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 15 at (-61.90341054123914, 65.000000001, 247.78940559636038)
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver joined the game
Here is something really amazing:
How does Beta use just as much memory despite having far less content? Even if you go by allocated (an indication of peak memory usage) it is not much lower, either way they could run with only 256 MB allocated, and the Beta image doesn't look like a very far render distance, or in a very complex area.
Also, here is a screenshot from TMCWv5, without the rendering and other optimizations I made, showing that even an entire world covered with flower pot tile entities has no major adverse impact on performance (note that memory usage is not higher mainly because of tile entities but because 1.6.4 generated all 16 chunk sections in Superflat even if they were air, which I didn't fix until after I took this, reducing memory usage to as little as 30 MB):
Not only that, you can even have miniature tree models in them, which are generated just like a normal tree - you also have to absolutely love the performance (taken after I added many of the optimizations from World1. Also while this is a Superflat world each tree has as many faces being rendered as an actual tree; in fact, the chunk section they are in is so complex it caused the tessellator to have to expand its buffer to accommodate all of the vertex data):
The main reason why tile entities are so often blamed for lag is because they may be rendered using a "tile entity special renderer" which renders them in the same manner as normal entities redrawing them every frame with at least one OpenGL call per entity - however, simple blocks do not need a TESR; for example, furnaces are rendered as a normal block, while mob spawners are rendered as both (using a TESR for the mob inside):
In any case, 1.13 completely removed any need for tile entities for basic blocks - beds and flowerpots are now all separate blocks since the number of blocks is now unlimited (if not entirely without any penalty; the more blocks there are the bigger the list will get and the longer it will take to look up entries, though a hashmap can alleviate this, but it still still consumes more memory and reduces CPU cache locality).
Also, it is entirely possible to render blocks outside of the normal bounds of a block, you can see this with blocks like tall grass, which have a random offset and can extend into adjacent block spaces; likewise, my large stalagmites are actually a single block that is rendered 2 blocks tall, as is their collision box (the second block is actually air but you can mine them from either block (not like a door, which is two separate blocks and the break timer resets if you move from one to the other) and can't place blocks in either space):
These are actually all a single block without a tile entity; the color of hardened clay stalagmites depends on the color of the hardened clay they are placed on (defaulting to normal if on a different block), same for stone variants, and they are flipped to render as stalactites if there is a valid block above (there are actually only 12 variants (data values/items), 6 each for small and large; I also recolor the texture for stained clay variants so only one texture is required for each sub-variant):
(the same texture-saving also applies to my "metadata ores", seen on the far left, where a single transparent overlay is overlaid onto a base texture taken from another block like stone - all of this saves on loading time and texture memory usage; of course, with a slight penalty in render speed due to having to render each face twice but that is negligible, especially with my other optimizations)
Also, another reason why 1.8+ is so awful is because every single block state requires its own json model, which each use quite a lot of memory and all but necessitates using a TESR for any sort of complex block (this is also a major reason why many mods took so long to update, if ever):
(I have to absolutely love the claim that 1.3 needs at least 500 MB to even run when I only see 1/5 of that, with 1.5+ needing even more (which is wrong - all the separate textures means is slightly increased load time as the game needs to load them one by one and stitch them together into an atlas, just like before) - indeed, World1/TMCW needs no more memory than Beta versions, with 256 MB being enough for most situations)
Are you saying I can download a mod which doesn't change the game in any way, just makes it run faster?
Are you saying I can download a mod which doesn't change the game in any way, just makes it run faster?
Yes, if you mean Optifine, since my own mods are only for 1.6.4 with absolutely no intent to ever update to a later version; eventually I'll release all of these optimizations as part of the biggest update ever to TMCW, which i started working on two years ago (there are over 300 other features being added with more planned once I finally integrate what has become nearly a total rewrite of much of the game, currently I just need to finish up the video settings, which include many things implemented by Optifine and/or vanilla 1.7+, such as a fine FPS slider (vsync, 30-200, unlimited), chunk update control (better than Optifine's "chunk updates per frame" as it changes the percentage of the frametime allotted to updates, rather than forcing a minimum number per frame), render distance in chunks, and multiple settings for controlling individual options like fast/fancy leaves and clouds (conversely, smooth lighting is now only on/off because there is no point in having min/max settings when there is no noticeable performance difference)..
This gives you an idea of the sheer amount of work that I've put into TMCW, with more than 6 years of development by a single person:
This is for all 5 versions of TMCW to date:
This is for version 5 only - which by itself represents over a third of all the files and file size:
Examples of how extensively I've modified the game can be seen here, including a class with over 12000 lines (8000 in vanilla) which is seen as being nearly completely rewritten by the diff tool I used (just 7 lines were not found to match, though the real number is higher):
I would like to add furniture to the game, specifically a table, chair and sofa. I remember a very long time the developers wanted to add furniture.
Table - wood planks, or a pressure plate on top of a fence
chair - stairs
sofa - multiple stairs put together
While I can make furniture using the above blocks, there is no real furniture in the game, and I'd like it a lot, too.
Full support!
[Avatar] A render of my skin
[Status] Doing absolutely nothing.
I'm Idelac. I'm a regular on the forum games.
https://www.youtube.com/watch?v=3b48-Z_ozdg
I think planks abd slabs suffice for tables and counters, but it would be nice to have actual (functioning) chairs that villagers don't try to endlessly climb. I'd support it.
Unfortunately, there's a list of features that they have confirmed will not be added, and furniture is on that list.
Christian artist. Here is my art page.
We already have beds, if that counts, but they serve a purpose in the game, they set your spawn point and change night to day time, preventing further monster mob spawns in daylight.
what purpose would a sofa bring to the game? aesthetics while nice, some would not consider this to be enough.
Perhaps a sofa and chair could allow players to sit and slow the depletion of their hunger bar, but even then that would be boring and this issue can easily be circumvented by logging out if you want a break.
I agree with the other posters in saying these things can already be made (sort of) by using stair blocks and what not.
I'm not against the idea in principle, they can be made to look less ugly as a result, but we're not talking about decor blocks here, we're talking about adding in items that should serve a purpose for survival gameplay like the bed does.
I'm sure there's a texture pack out that that swaps existing blocks for more aesthetic furniture
but that ends up changing the look of blocks that are already in the game, not something you want in survival gameplay.
I do agree with the suggestion to add in furniture, but with a catch, they must serve a useful purpose for players other than just the look.
Players need incentives to use items.
Maybe an alternative is for there to be blocks that could be used to create more realistic looking furniture, but that could also be used for other purposes. I know some use trapdoors for some parts of chairs, and as thin wall dividers. A thin block, similar to an open trapdoor, but is fixed in place, could be useful.
And bed is already furniture which exists officially in the game, but it helps with countering monsters during survival gameplay by changing the time of the day and it sets your spawn in the over world.
There is however an annoying bug with beds that I want patched, they don't sit very well on top of half slabs if on the bottom half
the same could be done with other furniture if they were to be added so they don't just look like they're suspended in midair in a room full of half slabs.
Other than a haunted house design, floating furniture just doesn't look right to me.
Tables could be useful for providing a place to put bowls down, you know, the bowl of mushroom stew, and a table top could also serve as a place to put weapons down, kind of like an item frame but a different orientation. And they could be used to hold potions.
Tables if they were put in, should be craftable by different wood types, and have an aesthetic or texture dependent on the type of wood used.
I'm not sure what chairs would be used for, how about setting your spawn location in the over world, but not changing night to day? they would have one feature a bed has but not the other, making them not as useful as beds, but still have a purpose during gameplay, in addition to needing less resource types.
Chairs should also be made from wood, but not wool, and a texture dependent on the type of wood used, but be flammable, meaning players would have to exercise caution when placing chairs down to set their new spawn location, and if chairs get destroyed, the spawn defaults to origin.
A sofa could be craftable by wool and chairs in a row, and have a new feature that items don't yet have,
if all players use sofas in their houses while it is raining, it sets the weather to clear if day time, but change the time to night
meaning sloth would not be a good excuse to avoid fighting monsters.
But hunger doesn't deplete at all if you don't move - even walking has no effect so you can walk around your base or AFK as long as you like without ever having to eat - so there is no point in adding something that slows/stops hunger loss when not moving (and even if they did make hunger very slowly deplete as a way to discourage AFKing it would defeat the purpose to add a way to stop it):
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?
A mechanic that can be changed in an update, the game isn't static, it was literally made with the intention to be changed over time.
Currently when you don't move hunger doesn't deplete, and it depletes rather quickly if you sprint around and jump a lot, but if new furniture were to be added those things would need a useful purpose, otherwise it is adding in unnecessary bulk to the game.
But you can set your spawn point without making it daytime by "sleeping" for less than 5 seconds.
Or, in 1.15 or later, trying to use a bed in the daytime. Which doesn't cure insomnia (keep phantoms away).
So if you're looking for a new bed-related function, how about curing insomnia and/or turning night to day without setting the spawn point.
I'd think it would make more sense to have something like a camp bed or sleeping bag for that but a sofa could work.
Just testing.
or introducing a hammock, which has the same function as beds, but requiring slightly different resources, it using 2 strings, left to right, and 3 wool blocks underneath, instead.
the hammock could then be required to have 5 blocks worth of space in between solid blocks to be placed.
We don't have hammocks yet, but in principle they could be introduced without breaking the game, since you would have to fight spiders, or find another source of string to get the materials for the hammock and couldn't simply acquire it by killing or shearing sheep then using a crafting table after chopping a tree down.
Whatever the case may be, it is clear to everyone that Minecraft doesn't have enough items and it is far too limited in what you can actually do in the game without mods involved.
You could craft a chair out of a stair block, sign posts and a trapdoor, technically, but it wouldn't be the sort of thing the original poster is asking for. You can't place wool on the seat to act as a cushion for a start.
You could make a pseudo sofa using wool blocks in a line, but it would be an eye sore.
Beds not being able to be placed at half block positions isn't a bug, it's an integral part of the game, beds, like most game objects, are made of blocks and blocks can only be placed at full block positions.
Allowing blocks to be placed between the normal block positions or turning beds into entities would add unnecessary complexity and lag for purely aestetic reasons.
Just testing.
Lag? how? by adding a feature which causes more CPU power required? they've already been doing this over the years with the various other updates they've been conjuring up, not to mention the ray tracing update intended for Microsoft's upcoming console, and on PC's with Nvidia's RTX video cards, which will no doubt be more demanding on both the CPU and GPU.
Like it or not, the game is going to become more advanced into the future, so get used to it.
Higher computational demands in themselves are not a good reason to allow a game to become stale.
the system requirements to run the game properly used to be 2gb of RAM and a single core CPU
but now you're expected to have a minimum of 4gb of RAM, if you play either the current Java version, or bedrock edition.
8gb of RAM and an Intel i7-6500U or AMD A8-6600K CPU are recommended to have the best experience according to Microsoft.
https://www.microsoft.com/en-us/p/minecraft-for-windows-10/9nblggh2jhxj?activetab=pivot:regionofsystemrequirementstab
Most of that is due to Mojang's horrific coding practices, not new features - in fact, I've added hundreds of new features and greatly reduced system requirements - for comparison, I used to play on a computer with a 14 year old CPU/GPU and didn't have any issues even in "mega forest" biomes with 64+ block tall trees as long as I didn't set leaves to Fancy (which was mainly due to a lack of VRAM, just 256 MB, not raw processing power).
https://www.reddit.com/r/Minecraft/comments/2js5j3/the_creator_of_optifine_sp614x_explains_the_18/
https://github.com/toolbox4minecraft/amidst/issues/506 ("the slowness is due to the changes in the Minecraft code for biome generation, which is much less efficient")
https://www.reddit.com/r/Minecraft/comments/95wfd0/why_am_i_experiencing_lag_spikes_sometimes_even/e3vzakv ("sp614x showed us how much worse their object allocations are in 1.13 compared to 1.12")
https://www.reddit.com/user/sliced_lime/comments/e00ohm/a_word_or_two_about_performance_in_minecraft/f8d9q0x/ ("My benchmarking code is quickly improving and the numbers are only preliminary, but it already indicates a very concerning trend that supports subjective/general observations by others")
True, this is not from TMCW but my own optimized version based on 1.6.4 (I call it "World1" since it is what I use to play on my first world) but I have not seen any difference with even TMCWv5, which actually has faster world generation due to completely changing how chunk decoration works (instead of indirectly accessing chunks through the "World" class it uses a chunk cache and all block updates are applied post-generation, as are light updates, rather than trying to do it as each individual block is placed):
There is no need for fancy "loading screens" when you don't have to wait for the game to load or generate a world:
Client startup; the Mojang screen was only displayed for a second (this was within MCP; the launcher takes longer to "prepare" the game as it checks that every file has been downloaded and is up to date, and also extracts the "natives". Otherwise, the game itself starts up the same either way):
2020-03-26 19:52:33 [CLIENT] [INFO] Setting user: TheMasterCaver
2020-03-26 19:52:33 [CLIENT] [INFO] (Session ID is null)
2020-03-26 19:52:33 [CLIENT] [INFO] LWJGL Version: 2.9.0
2020-03-26 19:52:34 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
2020-03-26 19:52:34 [CLIENT] [SEVERE] Realms: Server not available!
World creation; a total of 3 seconds elapsed from server launch to the world loading in:
2020-03-24 17:01:41 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-03-24 17:01:41 [SERVER] [INFO] Generating keypair
2020-03-24 17:01:41 [SERVER] [INFO] Converting map!
2020-03-24 17:01:41 [SERVER] [INFO] Scanning folders...
2020-03-24 17:01:41 [SERVER] [INFO] Total conversion count is 0
2020-03-24 17:01:41 [SERVER] [INFO] Preparing start region for level 0
2020-03-24 17:01:42 [SERVER] [INFO] Preparing spawn area: 17%
2020-03-24 17:01:43 [SERVER] [INFO] Preparing spawn area: 49%
2020-03-24 17:01:44 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 129 at (-95.5, 65.0, 226.5)
World reload (from a "cold" start to ensure that the files weren't cached in memory; yes, it took less than a second to load the world, no fancy loading screen needed at all):
2020-04-04 15:46:02 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2020-04-04 15:46:02 [SERVER] [INFO] Generating keypair
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 15 at (-61.90341054123914, 65.000000001, 247.78940559636038)
2020-04-04 15:46:02 [SERVER] [INFO] TheMasterCaver joined the game
Here is something really amazing:
How does Beta use just as much memory despite having far less content? Even if you go by allocated (an indication of peak memory usage) it is not much lower, either way they could run with only 256 MB allocated, and the Beta image doesn't look like a very far render distance, or in a very complex area.
Also, here is a screenshot from TMCWv5, without the rendering and other optimizations I made, showing that even an entire world covered with flower pot tile entities has no major adverse impact on performance (note that memory usage is not higher mainly because of tile entities but because 1.6.4 generated all 16 chunk sections in Superflat even if they were air, which I didn't fix until after I took this, reducing memory usage to as little as 30 MB):
Not only that, you can even have miniature tree models in them, which are generated just like a normal tree - you also have to absolutely love the performance (taken after I added many of the optimizations from World1. Also while this is a Superflat world each tree has as many faces being rendered as an actual tree; in fact, the chunk section they are in is so complex it caused the tessellator to have to expand its buffer to accommodate all of the vertex data):
The main reason why tile entities are so often blamed for lag is because they may be rendered using a "tile entity special renderer" which renders them in the same manner as normal entities redrawing them every frame with at least one OpenGL call per entity - however, simple blocks do not need a TESR; for example, furnaces are rendered as a normal block, while mob spawners are rendered as both (using a TESR for the mob inside):
In any case, 1.13 completely removed any need for tile entities for basic blocks - beds and flowerpots are now all separate blocks since the number of blocks is now unlimited (if not entirely without any penalty; the more blocks there are the bigger the list will get and the longer it will take to look up entries, though a hashmap can alleviate this, but it still still consumes more memory and reduces CPU cache locality).
Also, it is entirely possible to render blocks outside of the normal bounds of a block, you can see this with blocks like tall grass, which have a random offset and can extend into adjacent block spaces; likewise, my large stalagmites are actually a single block that is rendered 2 blocks tall, as is their collision box (the second block is actually air but you can mine them from either block (not like a door, which is two separate blocks and the break timer resets if you move from one to the other) and can't place blocks in either space):
These are actually all a single block without a tile entity; the color of hardened clay stalagmites depends on the color of the hardened clay they are placed on (defaulting to normal if on a different block), same for stone variants, and they are flipped to render as stalactites if there is a valid block above (there are actually only 12 variants (data values/items), 6 each for small and large; I also recolor the texture for stained clay variants so only one texture is required for each sub-variant):
(the same texture-saving also applies to my "metadata ores", seen on the far left, where a single transparent overlay is overlaid onto a base texture taken from another block like stone - all of this saves on loading time and texture memory usage; of course, with a slight penalty in render speed due to having to render each face twice but that is negligible, especially with my other optimizations)
Also, another reason why 1.8+ is so awful is because every single block state requires its own json model, which each use quite a lot of memory and all but necessitates using a TESR for any sort of complex block (this is also a major reason why many mods took so long to update, if ever):
https://www.reddit.com/r/feedthebeast/comments/5jhuk9/modded_mc_and_memory_usage_a_history_with_a/
(I have to absolutely love the claim that 1.3 needs at least 500 MB to even run when I only see 1/5 of that, with 1.5+ needing even more (which is wrong - all the separate textures means is slightly increased load time as the game needs to load them one by one and stitch them together into an atlas, just like before) - indeed, World1/TMCW needs no more memory than Beta versions, with 256 MB being enough for most situations)
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?
It comes down to the render distance you're using also, I'm not sure what render distance the 3DS edition uses specifically, but by the looks of it, it isn't as far as the render distance on the current console editions of the game, on Xbox One bedrock edition is said to use 22 chunks render distance.
It is possible to run the game on a system with just 256mb of memory, or else Mojang wouldn't have been able to port the game to the New 3DS some time ago, but the experience may be inferior and you end up making a lot of sacrifices just to get it to work.
I've even seen a video of somebody who got Minecraft (Java obviously) to work on a PC with Windows 98 somehow, although it was very laggy, also the operating system was known to be unstable on computers with more than 512mb of RAM, second edition could be tweaked to be okish with 1gb of RAM.
We both know the current versions of Minecraft both Java and bedrock edition should be ran on a PC with 4gb of RAM at minimum, if using Windows 10. Note that bedrock edition isn't available for previous versions of Windows, but I would advise at least 8gb if people are using high render distances or mods.
Are you saying I can download a mod which doesn't change the game in any way, just makes it run faster?
Yes, if you mean Optifine, since my own mods are only for 1.6.4 with absolutely no intent to ever update to a later version; eventually I'll release all of these optimizations as part of the biggest update ever to TMCW, which i started working on two years ago (there are over 300 other features being added with more planned once I finally integrate what has become nearly a total rewrite of much of the game, currently I just need to finish up the video settings, which include many things implemented by Optifine and/or vanilla 1.7+, such as a fine FPS slider (vsync, 30-200, unlimited), chunk update control (better than Optifine's "chunk updates per frame" as it changes the percentage of the frametime allotted to updates, rather than forcing a minimum number per frame), render distance in chunks, and multiple settings for controlling individual options like fast/fancy leaves and clouds (conversely, smooth lighting is now only on/off because there is no point in having min/max settings when there is no noticeable performance difference)..
This gives you an idea of the sheer amount of work that I've put into TMCW, with more than 6 years of development by a single person:
This is for version 5 only - which by itself represents over a third of all the files and file size:
Examples of how extensively I've modified the game can be seen here, including a class with over 12000 lines (8000 in vanilla) which is seen as being nearly completely rewritten by the diff tool I used (just 7 lines were not found to match, though the real number is higher):
https://imgur.com/a/lFWfqYw
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?