Minecraft Wiki
Advertisement
Minecraft Wiki

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.

Fluid changes[]

Technical split[]

While assumed to be underway, there hasn't been anything back regarding this since 2018, when Dinnerbone tweeted[1] 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.[2] 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 a few blocks: beds where it would be used to determine whether Water Breathing/Conduit Power would be neccessary for sleeping, sea pickles to handle their activity and light emission if not replaced with another state, and sculk sensors to control whether they are silent.

Lavalogging[]

Example lavalogging.png

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[]

Example flowing waterlogging.png

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[]

Example flowing lavalogging.png

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.[3]

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 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 new, invisible, immobile fluid called "minecraft:waterproof" 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 fluid 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 much like with waxed or oxidised copper blocks, or the block can be broken. Both will drop the coating as an item, and the "waterproof" fluid would be removed from the block.

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.

Chunk format rewrite - multiple blocks per space[]

Overview[]

As of 1.17.1, Java Edition's chunk format strictly defines positions as having only one block able to be assigned to it. While this makes sense for many situations, this implementation is rather limiting in the long run - blocks which from a visual and functional standpoint should clearly be able to occupy the exact same space are by definition forbidden from coexistence as a result. For cases where "multiple blocks" are allowed to exist in the same space, these are usually very specialised cases and seldom involve distinct blocks.

While also a highly nontrivial rewrite, redoing the world format such that one space can be occupied by multiple distinct blocks would allow for more than a handful of new possibilities, make other elements of the game functionally much cleaner, and bring parity between the Java and Bedrock editions of the game.

Item frame parity[]

A well-known functional difference between Java Edition and Bedrock Edition is the fact that item frames, while an entity in Java Edition, are instead blocks in Bedrock Edition. The block implementation of the latter brings with it a notable, often-pointed-out disadvantage in contrast to its Java Edition counterpart: only one item frame can occupy a given block space in Bedrock Edition, and an item frame cannot exist within the same block space as a block such as a pressure plate or torch.

This disadvantage, as can be rather clearly seen, arises solely due to the fact that blocks cannot occupy the same space as other blocks. As the general suggestion here is to jettison this paradigm in favor of a newer format allowing of said cases, which would result in Java Edition item frames being allowed to be converted over to blocks while still allowing for the multiple-in-one-space functionality demonstrated by its current entity form (although cases where the item frame outright physically intersects another block would likely end up being removed as a result).

This conversion also comes with its own set of benefits:

  • Item frames are already defined via block models and block states, with their texture and model files being outright placed in block asset directories. When converted to a proper block, this could allow for item frames to take further advantages of model features such as cullface.
  • Converting item frames to blocks would likely result in them being given breaking particles like other blocks. [4]
  • They would also likely be given proper outlines like other blocks, also causing them to be more consistent.[5]
  • It may allow smooth lighting to properly affect them.[6]

As paintings are similarly entities which are nonetheless programmed to be eternally stationary, it may even be feasible to convert these to blocks and reap the benefits of block mechanics here as well.

Deprecation of certain block states[]

As was previously stated, certain cases of multiple blocks existing in one block space do exist, but these have mildly hacky implementations through the use (and debatable abuse) of block states.

For example, vines can be placed on the four orthogonal sides of a block, as well as their undersides. As vines can also combine in the same block space, this allows for up to five of them to exist in said block space - one for each orthogonal direction as well as one for the very top. While visually and to an extent functionally this implementation does work, further examination reveals significant functional flaws:

  • Despite each vine being implied to be a distinct unit, it is completely impossible to directly break individual vines within a block space. Directly breaking such an instance will break every single present vine,[7] requiring all others to be replaced in said region if the breaking of only one was desired. Individual vines can only be broken via indirect means, namely removing one of their supporting blocks, and even this demonstrates a flaw in that, for cases where one or more vines would still remain, said breaking action produces no particles nor breaking sound as is typical of almost all other block breaking actions.[8]
  • A further flaw of this can be found in its loot implementation; breaking vines will always drop a single vine item, regardless of how many vines were in that space when it was broken.[9]
  • A final issue manifests as a bug which affects other non-multipart blocks,[10] but could nonetheless be avoided were vines to be considered individual units - particles are always generated at the outer bounds of the block's cubical bounding box, disregarding any concavities, which can be seen on several vine combinations when in the process of being broken.

Were the vines' current block state implementation of having a boolean for each of the five applicable faces it can be attached to to be deprecated, with it instead having a single facing direction state with each of the five directions being a permitted value instead, these vine issues would more than likely be completely eliminated as a result, as they all stem from multiple vines per space being considered a single unit.

In a less extreme but far more widespread example, slabs utilise a three-state value determining whether they occupy the bottom half of the block, top half of the block or are composed of two slabs. Were double slabs to be considered two individual slab blocks of differing half instead, not only could the aforementioned three-state value be changed to two-state, but they could be acted upon differently: pistons could gain the ability to combine two slabs or pull them apart, and the player would gain the ability to mine constituent slabs separately, resulting in both functional parity with the case of two vertically connected slabs spanning two different block spaces and the removal of the loot table entry required for double slabs to drop two slabs. Importantly, the slabs would no longer necessarily have to be of the same type (see section #Other opportunities).

List of changed block states[]

Unchanged and irrelevant block states of the blocks listed here are excluded for brevity.

Snowlogging / potentially icelogging?[]

A notable feature of Bedrock Edition is that in snowy biomes, plants such as grass and flowers can occupy the same space as snow layers. This is completely absent in Java Edition, where said plants just replace the snow layers outright, resulting in ugly square gaps around them where there is no snow. Bedrock Edition's implementation is, however, flawed in several aspects, both due to bugs and the way it's implemented:

  • Blocks can only become snowlogged if an existing plant has a snow layer placed on it, or is exposed when snowing. Placing a plant into snow will not work, nor will a snow golem snowlog plants.
  • Snowlogging is exclusive to only one-block-tall flowers, grass, ferns, roots, mushrooms, fungus and nether sprouts. All other plants are excluded, as are all non-full blocks in general like fences and chests.
  • Plants cannot be targeted at all when snowlogged, and the snow must be broken first.

A related functionality, "Better Snow", exists in the Optifine mod, which applies to considerably more blocks. However, as this is purely visual (based on adjacent blocks which are snow), thsi is arguably even worse than Bedrock Edition's implementation: the snow in question does not even exist, breaking visually snowlogged blocks causes the snow to disappear as well, blocks adjacent to snow become visually snowlogged even when this is undesirable, blocks below these do not appear snowy, and so on.

Were blocks allowed to occupy the same space as one another, a snowlogging system would come naturally without any of the flaws of either Bedrock Edition or Optifine's implementations. The snow and snowlogged block in question are both real, can be targeted, have collision, can be broken independently of each other, can be created in any order, can be created in any way desired, and only blocks for which being snowlogged is desired may be snowlogged.

Example no icelogging.png

A related concept to snowlogging would be "icelogging", in which a block can be fully encased in ice. Currently, this functionality does not exist, resulting in several flaws in gameplay:

  • When generating naturally, seagrass can replace ice in cold biomes, resulting in ugly and unnatural patches of water where there should not be any.
  • Waterlogged blocks in cold biomes are completely incapable of freezing, even if the water is completely exposed and should otherwise freeze.
  • Frost Walker also cannot turn waterlogged blocks into frosted ice.

While one could argue along these lines that it may be desirable to add "stonelogging", "cobblestonelogging" and "obsidianlogging" for waterlogged/lavalogged blocks which become involved with the opposite fluid, it may be better in this case to just break the logged blocks in question and replace them with the formed stone type, due to the generally destructive nature of the formation of these blocks.

Other opportunities[]

Example plants in fences.png

Alongside bringing parity between the game's editions, fixing bugs and making game functionality more intuitive, a wide variety of possibilities arise from having multiple blocks in the same space.

A simple example, shown to the right, could involve non-full blocks not deleting certain other non-full blocks in the same space, but rather coexisting. For example, plants such as grass and flowers could exist in the same block as a fence, softening the look of fences that run through grassy areas rather than having the grass abruptly and unnaturally stop at them, and making them feel more connected to the ground.

Another example, discussed earlier, would allow for the implementation of the frequently-requested mixing of slabs in a block space. Any two slabs could be placed within a block, and unlike with modern double slab blocks, they can be mined independently, no longer forcing the player to have too mine out the whole block and replace it in the case of a mistake. This may make mining large amounts of slabs more tedious, however.

Another frequently requested feature that this would allow for would be the ability for carpets to conform to stairs. A way this could be implemented would be to add, for each carpet, a separate "stair carpet" block ID, which has the exact same block states as a stair block (possibly except for upside-down). When a carpet item is placed on a stair block, a stair carpet block would be created in the same space as that stair block, covering the stair portion of it. As a result, instead of requiring a unique block ID for each different type of stair covered by each different type of carpet, as the current implementation of blocks would require, all that is needed is a single extra block ID corresponding to each carpet type. A "slab carpet", with no block states (or as a block state variant of normal carpets), could be similarly added for placement on top of slabs as well.

Along the lines of stair carpets, this could also allow for the very easy implementation of snowy stairs and slabs, using the exact same principles: a new, dedicated "stair snow" block with all the needed block states, which combines with stair blocks, as well as a "slab snow' block.

Another annoying aspect of the current game this could solve involves flammable blocks. For blocks such as fences, plants and slabs, fire generally visually and unrealistically floats on top of these blocks when burning. If instead fire took up the same space as non-full blocks it burned, fires would look a lot less wonky as a result.

Alongside these more decorative examples, such a change could allow for more practical uses as well. A one-block-wide shaft containing a ladder would normally have no room for torches to keep it lit, and climbing down such a ladder in the dark is often not desirable. Most get around this by periodically digging one block into the wall to place a torch, however with this new change a torch could be placed in the same block as a ladder, getting rid of the need for this extra mining.

Changes to commands[]

As commands currently assume that only a single type of block can occupy a space at a given time, such a change would render commands which can detect or manipulate blocks in the world crippled. As such, changes would need to be made to the command syntax as to work better with such a new system.

World size changes[]

Horizontal expansion[]

32-bit[]

Example extreme distance 32.png

The maximum Minecraft: Java Edition world size, from Beta 1.8 Pre-release through to release version 1.17.1, 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.17.1, 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. Alternatively, the world could be allowed to generate out to exactly 2,147,483,647 blocks, and any attempt to go past this point would wrap them to -2,147,483,648, and vice versa, allowing for a truly unbounded (but still technically finite) world to exist.

64-bit[]

Example extreme distance 64.png

While an expansion of the current standard world size to the 32-bit limit of 2 billion is considerably large, this is only the beginning of the story.

If we want to take things to the extremes, it's worth noting that Java Edition at its core is a 64-bit game designed for 64-bit platforms. While labour-intensive, it is entirely possible to convert several 32-bit values pertaining to blocks, chunks and rendering to 64-bit, to more than square the radius of the current playable game.

As of 2021, there are effectively no 32-bit desktop computers remain in common use in 2021, with Windows 11 planned to only come in a 64-bit version. Making all positions 64-bit instead of 32-bit would make the game inaccessible to effectively nobody compared to its current playerbase.

The playable area (as opposed to the absolute area) opened up by making the game 64-bit is truly vast. Even at a trillion blocks out, the precision of a double is comparable to the precision of a float at 1024 blocks out, meaning that any precision loss here is effectively unnoticeable without ridiculously precise testing, and harmful effects such as falling out of the world are virtually nonexistent (especially considering reaching 1 trillion blocks is a bit more tricky than reaching 1024). Placing the world boundary at such a round number, much larger than the current mere 30 million, would still give a massive playable range for survival while avoiding all harmful double precision loss bugs.

Example stripe lands.png

Placing the world border at 1 trillion blocks is likely optimal, as it would prevent Survival mode players from entering potentially hazardous terrain and the border could be set beyond this in Creative if desired. The world boundary could either be set a bit beyond the world border, such that a simple mod would be all that is needed to expand it, or scrapped entirely, with restrictions such as how far nether portals can go controlled by the world border instead.

The world at 1 trillion blocks is still playable normally, however at distances like 1 quadrillion blocks precision loss is already at a point where only values which are multiples of ⅛ are considered valid. Several game mechanics will likely no longer work properly at all, blocks render oddly, and the risk of falling out of the world here is rather high. While terrain subject to this would be perfectly accessible to players with cheats (even if gameplay beyond here are not supported by Mojang for obvious reasons), regular Survival players would be blocked from it by the world border for safety purposes.

Beyond just over 9 quadrillion blocks, for example, precision loss considers only even numbers as valid, resulting in the famous Stripe Lands. Traversing these in survival is basically impossible, with the world border set far before them to bar access, whereas creative mode players may be willing to experiment here, which is completely allowable.

Vertical expansion[]

Example extreme depth.png

The current world height, as of 1.18 Experimental Snapshot 1, is exactly 384 blocks (from -64 to 319), a 1.5-fold increase from the prior standard set in 12w07a onwards of 256 blocks (from 0 to 255), which is in turn a doubling of the previous world height of 128 (from 0 to 127). Two thirds of this space is reserved for surface terrain generation, leaving only 128 blocks worth of height for underground and ocean generation - which for a game called Minecraft does not lend itself as best it can 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 fully 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 are proposed below. For weather, a good way to deal with infinite height would to make it only exist where the clouds are and below.

An effectively infinite vertical axis could allow for vertical boundaries to be made to act more like the current horizontal boundaries, which will be detailed in a dedicated section below the next one.

Adjusting world generation to account for infinite height[]

With a world height increase, it would be wise to make changes to world generation such that it generates terrain to take advantage of said space. This section only lists changes that could be made while still retaining an experience similar to current vanilla. Such changes to world height could pave for exciting new updates which add wealths of content based on terrain found at great depths and heights - one need only look at Terraria to see the potential that comes with greater world height.

For starters, generation of the Overworld and the Nether would be adjusted such that the sea level of each biome exists at y=0, rather than y=64. Old worlds converted to the new format would be shifted downwards accordingly. The generation of the End could also be similarly moved downwards to have the exit fountain at y=0.

For the Overworld, changes would be relatively minimal at the surface, although underground generation would obviously be able to continue downwards practically indefinitely. It would also be a wise decision to remove the "lava layer" from caves, such that they can be reasonably explored as deep down as desired. Alternatively this layer could vary from cave to cave (with most not having one at all), such that bubble column underwater ravines would still be a feature that could be encountered in oceans. Some underwater caves would still only generate with water down to the bottom of the world. Oceans themselves could also be made considerably deeper.

For the Nether, changes would be more significant. Caves would now also be able to extend upwards as far as possible, and lava oceans could be just as deep.

For the End, the outer island layout around the central island could be changed to be more spherical. A cheap, but effective, way to do this would be to make outer islands spawn in layers, separated by perhaps 512 blocks on the Y axis. The central layer would be the same as the current End in vanilla, with all other sheets being continuous islands even near x/z 0. This would also solve the problem of void damage in this dimension - eventually a player will have to die of fall damage after falling off an island. Falling off will therefore no longer be a death sentence for the player's resources, with a careful expedition to the lower layers of islands allowing for a full recovery. Clever players may also be able to save doomed mobs by exploiting unloaded chunks.

For the true bottom of the End, maybe a few thousand blocks above the world border, the terrain could be made to generate in a more traditional, Overworld-like terrain shape, rather than as islands, as to prevent any potential softlocks from surviving a fall onto the bottom world border and being unable to place blocks on it.

World boundary changes and custom dimension parameters[]

What exists for world boundaries horizontally could also be made to exist vertically as a result, to bring closer parity between the three axes.

Firstly, the damage applied by falling more than 64 blocks below the bottom of the world would be removed, as there would be no way to reasonably access the new bottom of the world in survival. Instead, the world border itself would be reworked: it would exist at the absolute top and bottom of the world, just like it does at the four horizontal edges. Moreover, instead of being strictly a square (excluding world boundary restrictions which allow for limited rectangles), it could be set to be any cuboid shape: the diameter on the X, Y and Z axes could all be changed independently, and it would also be able to be offset vertically.

Custom dimensions are capable of defining the height of the world in 1.17.1. While vanilla world generation being changed to utilise infinite height would likely imply the removal of this feature, it could very well still be kept. Again, for the sake of functional parity on all three axes, the dimension's size on the x axis and z axis would also be newly configurable options. With this, physically restricted "pocket dimensions" could be implemented via a data pack, perhaps for storage, the emulation of the inside of a block, and so on.

Credits[]

The 32-bit horizontal world expansion is achievable through simple modding, some of which are linked below. The vertical world expansion was made possible by the Cubic Chunks mod, which can also be found linked below.

The 64-bit horizontal expansion mod for 1.2.5 was created by Daniel "314rft" Ryan, which also fixes all 32-bit float precision bugs (excluding end portal rendering, which vanilla fixes in 1.11 already, and the sounds from sheep eating grass).

A video has also been created by AntVenom highlighting all that would need to be done in order to have the game be playable at extreme 32-bit horizontal distances.

Lighting changes[]

Make smooth lighting... actually smooth?[]

Smooth lighting in the current version (Java Edition 1.17) is frankly an absolute joke, and finding sharp discontinuities and other ugly effects takes little to no effort. Here is a showcase of several examples of smooth lighting doing anything but what it says on the tin:

Here are examples of expected situations:

Changes to lighting with infinite world height[]

As mentioned before, an increase in world height (especially making it infinite) would have major implications for lighting, and these would need to be taken into serious consideration were such a change to be implemented.

A cheap, but nasty, solution would be to assume that all blocks receive full sky light until it can be confirmed that an opaque block exists above it at some point. This would obviously work, but would cause problems in structures such as massive naturally-generated caves whose heights are greater than the chunk loading distance. Also, if structures or terrain existed in the sky, for example if a layer of floating islands were added to the Overworld a few thousand blocks above the regular terrain, generating these would cause massive and ugly shadows on the surface of the world, which would also provide ample opportunity for hostile mob spawning.

A solution for this latter problem could be to make sky lighting spread laterally somewhat as it travels downwards; an implementation of this could make one-block columns of transparent blocks with sky light values between 1 and 14 inclusive increase by one every vertical chunk border crossed, and columns with light level zero change to one if adjacent to at least one column with a light level greater than one.

Coloured lighting[]

Example colored light.png

This would be an amazing change, and allow for not only diverse presentations for builds but exciting new mechanics for generated structures to take advantage of.

The implementation of such light could vary, although most methods would likely come with a major performance and memory impact.

One way would be to use sixteen bits for lighting, by having separate channels for invisible (used for ice and snow, plant growth and mob spawning and burning), red, green and blue lighting, which themselves use four bits each as to range from 0 to 15. A more expensive approach, which would stop certain mixed light colors from looking weird as they fade, could be to have eight different colors and 32-bit lighting: a channel each for infrared (used for handling the formation and melting of ice and snow, and plant growth), red, green, blue, cyan, magenta, yellow and ultraviolet (for handling mob spawning and burning), which would all still have 4 bits each.

Different blocks would outright forbid the passage of some colors of light, while allowing for others to pass through. For example, if we were to use the 16-bit implementation, blue stained glass allows blue light through, blocking all other channels. Cyan stained glass would allow both blue and green light through, blocking only red and "invisible" light. These could be generalised to the 32-bit case with some experimentation. Light gray and gray and black stained glass would significantly decrease all light passing through, but not completely block it. Tinted glass would still block all light from passing, allowing for the observation of a dark room from a well-lit one without any fear of interfering with it. Assuming the 32-bit implementation, normal glass as well as white stained glass, in order to reflect reality somewhat, could allow all visible and ultraviolet light to pass, but block the passage of infrared. As such, an area where the player intends to build with snow and ice, or farm it, could be lit up for visibility and spawn-proofing without fear of hampering their generation, simply by making sure all light emitted passes through said glass blocks.

Many vanilla blocks could themselves be changed to emit colored light. For example, the light fire, lava, torches, lanterns and jack o' lanterns emit could be slightly reddish, nether portals could emit purple light, soul fire, soul torches and soul lanterns could emit blue light, and redstone ore and redstone torches emit deeper red light.

Structures could be added to the game which utilise colored light in their design - the original stained glass suggestion from 2012 features some potential structures such as glowing crystal formations.[11]

It seems an official implementation of colored lighting by Ryan Holtz was extremely close to fruition, but ultimately never made it.[12][13]

Directional light emission[]

In snapshot 12w39a furnaces were tweaked as to only emit light from their front face, rather than nonsensically emitting it from all faces. This change was reverted in the following week, and has not returned.

Fixing this would involve making furnaces, blast furnaces, smokers and jack o'lanterns emit light exclusively from the direction they're facing, rather than from everywhere on the block. With the support added for directional block emission in snapshot 18w46a this shouldn't be particularly difficult.

Directional opacity should also be extended to carpets, shulker boxes, composters, cauldrons and hoppers.

Dynamic lighting[]

This would involve light not being handled on a per-block basis, and allow entities to emit real light. This could allow for held torches and dropped torch items, or indeed any held or dropped light emitting block, to emit light. Further applications could for example be to add a "Minecart with Glowstone" which can be added to minecart trains to illuminate dark tunnels on the fly. Implementing real dynamic lighting would itself require a ridiculous overhaul of lighting.

Credits[]

The fixes for smooth lighting were taken with the Sodium mod, which among other things makes smooth lighting considerably better than it currently is in vanilla.

The colored lighting example was taken with the Colored Light mod for 1.7.10. While the fact that this mod is only available up to 1.7.10 may be disappointing for some, the only truly disappointing thing is that it needs to be a mod in the first place, rather than a vanilla feature.

References[]

Advertisement