User:User-12316399

This page serves as a list of major features I want to see in Java Edition in the future. See /Technical changes for a list of minor to moderate technical changes.

Technical split
While assumed to be underway, there hasn't been anything back regarding this since 2018, when Dinnerbone tweeted a screenshot regarding a technical split removing minecraft:water as a block from the game. One can only assume that progress is being made.

Further waterlogging
There still remain many blocks in Java Edition that cannot be waterlogged under any circumstances. Support for waterlogging should be extended to all non-full blocks, alongside select full blocks such as leaves and monster spawners which can be assumed to not actually block water, and excluding honey blocks, fire and snow layers.

The ability to place more blocks underwater could allow for more building possibilities than ever before - for example, placing normal land-based vegetation underwater could allow for the creation of scenes reminiscent of Grüner See in Austria. Also, this would also patch out several exploits used for underwater breathing, notably the door trick.

For cases like torches, this behaviour could be reasonably considered odd, as fire kind of doesn't exist underwater. This could serve as a perfect opportunity to implement burned-out torches - instead of them burning out over time, they would act more like campfires in that being waterlogged (as well as right-clicked, in analogy of using a shovel to smother lit campfires) would put the torch out, allowing them to be placed underwater like any other block while not actually functioning as a torch.

The waterlogged block state would be completely removed, except for beds, where it would be used to determine whether Water Breathing/Conduit Power would be neccessary for sleeping.

Lavalogging


Why this wasn't implemented with the Nether Update is a mystery.

Lavalogging is the obvious lava analogue for waterlogging - lava would gain the ability to occupy the same space as a non-full block and overall behave just as one would suspect. Lava would probably be more destructive to many blocks than water, and certain cases such as waterlogged wooden fences would end up burning as if in air and next to lava, leaving a lava block behind as neccessary. Lava would probably also instantly destroy most vegetation such as flowers and grass, whereas water would be completely compatible with all of them. Lava would also instantly kill submerged corals, turning them into their dead versions.

While people perhaps don't build around lava to the same extent that they do water, this feature would fill in a major gap in gameplay mechanics and soften the look of lava-themed builds nonetheless, and potentially allow for brand new gameplay mechanics and possibilities on the side.

Flowing waterlogging


Perhaps a more controversial feature, but it'd be a welcome addition either way.

This mechanic was originally shown off during MINECON Earth 2017, but has yet to see a proper debut in-game. The concept is relatively simple: if a block reasonably has enough gaps for water to pass through, then water will pass through it. This would, among other things, make working around redstone for safer than it otherwise would be. However, this comes with a possibility to break several farms which utilise water to break blocks such as crops. In the interests of maintaining consistency, crops would allow water to flow through them without breaking, like any other block, unless the farmland block beneath them is treated with a special item as mentioned below. Crops grown on such a block would then have a special block state set causing water to force them to pop off as before.

Flowing lavalogging


An obvious lava analogue to flowing waterlogging. The mechanics would be as expected, with lava destroying all incompatible blocks it flows into and simply going through ones it is compatible with.

Bubble column-logging
Bubble columns would also allow for blocks to be placed inside of them and still allow bubbles to pass through where it would make sense for them to.

Preventing unwanted waterlogging
It may become undesirable for water to flow through certain blocks, with them being broken by the water or blocking it being the behaviour expected.

To mitigate this, it should be possible to "treat" blocks with a hydrophobic coating in order to stop water from flowing through them. This item could be honeycombs, or a material crafted from honeycombs and phantom membranes, giving a large amount of them as a result. When applied to a block that could be waterlogged, a block state would be set on that block which would prevent water and lava from being able to pass through the block. Farmland treated with this item will also set the block state for any crops grown on top of it, making them be destroyed by flowing water (flowing lava would destroy them regardless).

In order to remove this coating, an axe can be used to scrape it off, or the block can be broken. Both will drop the coating as an item.

Credits
The demonstration screenshots above were taken with the Towelette mod. This mod allows for the waterlogging of several more blocks, as well as lavalogging, and, if enabled via config, flowing waterlogging and flowing lavalogging. The mod uses a system of block states to accomplish this, however, as opposed to an actual complete splitting of fluids from blocks, and an intense amount of RAM is required for starting up the game with flowing fluidlogging enabled.


 * Download Towelette (Fabric): https://www.curseforge.com/minecraft/mc-mods/towelette

Horizontal expansion


The maximum Minecraft: Java Edition world size, from Beta 1.8 Pre-release through to release version 1.16.2, is 30 million blocks from the center to an edge, a 2 million decrease from the playable solid area from March 13th Infdev through Beta 1.7.3 of 32 million blocks from the center to an edge. With some very simple modification, though, it is possible to see that the game is completely capable of handling blocks, entities and basically all other game mechanics all the way out to the 32-bit signed integer limit of 2,147,483,647 blocks.

The 32 million limit was likely put in place in order to stop the player from encountering a vast array of precision-loss bugs which would manifest with increasing distance from the center of the world. However, as of 1.16.2, no such significant bugs exist in the game anymore (a full list of all historical effects can be seen here). The only bugs which would impact gameplay to a detrimental degree is light no longer functioning beyond 33,554,432 blocks (due to a lighting rewrite which happened in 1.14), and the player getting stuck in the sides of blocks beyond 1,073,741,824 blocks. (Neither of these bugs appeared in 1.12.2.) While the latter may be a simple fix, the former may end up being far from trivial and may require significant changes to allow for light to work out to the 2 billion limit (although two bits could be borrowed from the y-axis and dedicated to the x and z axes, allowing for light to work fine out to 67,108,864 blocks).

These aside, extending the world limit outwards to make new terrain accessible would be an extremely easy task, and would come with no more major issues. The world border could be extended out to a few thousand blocks before 2,147,483,648 blocks (or, if round numbers are preferred, exactly 2 billion), allowing for far more world area to be playable in than previously.

Attempting to rewrite the game to allow generation and functionality beyond the 32 bit integer limit would likely bring more problems than it would solve.

Vertical expansion


The current world height, as of 12w07a, is exactly 256 blocks (from 0 to 255), a doubling of the previous world height of 128 (from 0 to 127). Three quarters of this space is reserved for surface terrain generation, leaving only 64 blocks worth of height for underground and ocean generation - which for a game called Minecraft does not lend itself particularly well to underground features.

Increasing the height of the world while keeping the game in a playable state would be a considerably more difficult task than just expanding it on the x and z axes. The world format would need a complete rewrite for this world, as to allow for chunks to unload vertically as they currently do horizontally. The size of chunks is currently 16x256x16 blocks - this could be changed to 16x16x16, 32x32x32 or 64x64x64 for a perfectly cubic chunk, whichever size is desired. This would have some further implications for other game mechanics - notably sky lighting - although solutions for this will be proposed later.