Minecraft worlds are humongous. As in, dazzlingly not small.

Which is why finite world requests are common. But people want finite worlds with no boundaries, where polar extremes of X and Z meet each other, adding lots of painful code writing for teleportation and harmonization. This is not what I propose here.

Discworld

Instead, see this: worlds limited by a circular boundary (world generation when x²+z² is smaller than r) after which biome generation stops completely.

One could then build on the sides, risking to fall their death in the Void

The size is given as a slider in custom world creation (given in minecraft maps):

• zoom 0 (8² chunks) for one smallest map size (well, hey, tiny can do the job too!)
• zoom 1 (16² chunks) for one second smallest map size
• zoom 2 (32² chunks) for one medium map size
• zoom 3 (64² chunks) for one second biggest map size
• zoom 4 (128² chunks) for one biggest map size
• 3² zoom 4 (384² chunks) for 9 biggest map size
• 5² zoom 4 (640² chunks) for 25 biggest map size
• 7² zoom 4 (896² chunks) for 49 biggest map size
• 9² zoom 4 (1152² chunks) for 81 biggest map size
• Infinite - which is the default setting, as this is optional.

Upsides:

• Computer: Many chunks by many players makes a world heavy. Keep things closer and your world files are not so heavy anymore.
• Calculation: One could have the whole world ready, downloadable and all. That can make custom world creation with mods and everything even more interesting to share.
• Gameplay mentality: Give infinity and the world gets rekt until rekt further away. Give finity (?) and people will hopefully be more careful.
• Gameplay life: Still, other worlds can be accessed in the universe (slime block flying machine or through portals in far nether) or in the multiverse (by stargate portal or items), for discovery, harvest, or a new home.
• Portability: No added block, item, texture, or much coding required. Yet a whole new vibe.

Downside:

• Much clearer rarity of certain biomes/structures - but that can be arranged by forcing more chance of getting things like frozen biomes.
• It may look as if the rest of the world has to be generated as if simply lagging, especially close to the 4 poles. That could be made more clear by adding an edge variant to biomes.

Multiverse

So the world is truly finite eh? What do you do when the world is hollowed out but you still want to go on?

First presented on this suggestion by Ouatcheur but based off the suggestion from AThingWithAThing, there should be a way to create dimension in Creative mode.

I believe we should access these worlds through creative-mode created portals making access to these other worlds limited, but an item could do as well as in whatever bukkit add-on they exist.

If you like the idea of a multiverse, please discuss how it should work in this neat Multiple Dimension suggestion.

Still want a finite and boundless world?

A world that you can walk your way back to start is the only thing that will make you happy? I fully understand. Unfortunately it will require a bit more work than the option I present here. I do think both options could coexist in the future, and it's likely that this idea will be supplanted by torus worlds. But I think because this option is much easier to code, it should come first for finite worlds to become an actual thing.

Show your Support!

Come show your support on Reddit where the greats of the world look at ideas!

Link RemovedImage Removed

<a href="Link Removed"><img src='Link Removed /></a>

Link RemovedImage Removed

<a href="Link Removed"><img src='Link Removed /></a>

You may not have done...

/setblock ~0 ~1 ~0 minecraft:wooden_slab 12

Which is why whoever tried to make a mod or simply use commands to place blocks had to look with care at Minecraft Wiki and blocks to find how to place a 'north inverted acacia stairs' or whatever mix of block ID and data value that will make you pull your hair.

Fortunately, we can already have it easier with names such as minecraft:log for example. Nevertheless, data value makes it that we still have to verify how to write it.

But, how?

Yes, how can we make the program recognize human writable names like 'big east cocoa', 'double oak slab' and the likes?

Well, with for example "east acacia log", "red wool" and "polished granite", the program would:

• Segment analyze each different words (east, oak, log; red, wool; polished, granite)
• Find the word(s) describing the model ("log"; "wool"; "granite")
• Get the list of block id(s) associated with that model (log, log2; cloth; stone)
• If more than one id, Narrow the block id with specific words (acacia: log2)
• Form the data value associated with the block ID with the words (east acacia: 4; red: 15, polished granite: 1)

These 5 steps are relatively hyper-fast for a computer to do as opposed to a human having to read through documentation.

Relativity

As well as using absolute positions (North, South, East, West), we can use relative position, that is to say, front, left, right, back, that will be translated into the correct ones according to block faced.

Show your support!

Link RemovedImage Removed

<a href="Link Removed"><img src='Link Removed /></a>

<a href="Link Removed"><img src='Link Removed /></a>

Have you ever...
- Stumbled on a cave.
- Killed all of the terrible creatures and hope not to die of an arrow to the knee, magma-gefallen or a heart attack.
- Waited. Left turn or right turn now? or in that small whole a little up?
- Oh my god was that a spider?? ACK-wha-was-that-its-one-block-high-and-grey!
- Hey!! Diamonds!! [tssss] Goshdarnit a mourner-fleeking creeper of my ace just killed me FROG! Quick! Get back all the stuff!
Sadly, once you've seen a cave, you've seen them all.

So people go for the other option. Branch Mining.
Nothing wrong about that. But Gain/Effort is not currently well balanced.

Well, let's make cave exploration more appealing with a Spelunking Update.

By the way, all proposed "event-like" idea must have a rare chance of happening so to keep the surprise great.

Harder stone near bottom
Original idea of the thread. Either a question of physique or a new stone altogether to force people to go in caves.

Obsidian pocket near bottom
Goshdarnit I can't strip mine properly. I guess I should go in caves instead.

Stalactites
What says cave more than this? No use, just decoration. You're just not nice to Mother Cubic Earth when you break them.
They grow overtime where water drops from stone ceiling.
Walking on/touching small stalagmites/stalactites breaks them.
Data value wise, they have 0 to 7 for height and girth, and +8 represents a stalagmite (the one at the bottom growing up).

New minerals at cave sides
What are you waiting for, just mine me!
I may be only for decoration, or in a potion recipe,
But what is certain, is that I am pretty!

Harlp marh!
Was that a villager surrounded by fences I heard?
"Yearh! Stehrve!"
Well, there is a fleet of zombies around you I must get rid of,
Before seeing if your exchanges were worth this rotten flesh gathering.

Nether-gate ballroom
Ok maybe forget the ball, but a rare well guarded room with a already working portal to the nether could be nice!

Better disaffected mines
More chests, occasional resting room with a bed or two.
Something that gives the feel that somebody worked there fifty years ago.

It's a secret to everybody!
The rare passive aggressive mob.
Exactly the same look as their zombie, pigman, creeper, skeleton, enderman friends, aside from friendly googley eyes.
They have the heart and exchanges of a villager, in their own little room aside from the caves. They whistle sometimes.
Nowhere else found than in darn caves.

Mazes and dungeons
Why so much obsidian right here? What is this the entry of? Left or right now? FROG I'm lost. Mommy

Poisonous gas in stone
Pwah! What's with the this air oh gosh I'm dizzy. Or dying. Not sure.
Poison-effect-causing air in small pockets to hinder strip mining.
Data value of 1 to 7 for dissipation to air block until 0 where it becomes fresh air again,
The 8 bit on or off for a light (upward) or heavy (downward) poisonous air.
Green with envy.

Change Diamond spawn rate
So it's common but small veins in hard stone and rare but big veins in caves.
Both the strip miner and the cave explorer are much merrier!
Or only found near lava
Or well no change at all

Silverfish, you're stronger than before!
Yeah, I'm a badass now. You might as well stick to caves and leave me alone dear.

More decorative stones
You can almost feel with your fingers the humid and porous rock from the thousand years old walls with the new limestone variant.

More cave shapes
What about thin ravines? Sharp pits? Senotes?

Please vote for the ideas you like and propose your own ones!

Show your support

Link Removed

<a href="Link Removed"><img src='http://i.imgur.com/8QCQ9Bh.png' /></a>

<a href="Link Removed"><img src='http://i.imgur.com/3CcBWmh.png' /></a>

Quote from reaverofdarknes1»

Thank you for calling it spelunking! Caving is completely different, it is the process of creating caves, not of exploring them, and I will defy TheMasterCaver on this one. But please also fix the parts about branch mining. Strip mining is not branch mining!! Strip mining involves stripping off all of the rock and sorting it out later. This is generally not done in minecraft as it is inefficient. Real-world mining often involves strip mining because they use very large equipment to strip off the soil and rocks quickly in large amounts, and then send it off to processing stations to sort it all out. Branch mining in minecraft involves making small paths through the rock spaced a short distance apart in a pattern intended to minimize total blocks broken without significantly reducing ore found.

Please fix!!

Thanks for the information, just fixed it If you see other things to be fixed let me know!

Simple, effective, and consistent with already existing behaviour.

Not having implemented this already is illogical.

Full support.

In such vast worlds, have you ever found yourself a little... disoriented?
Or have you ever created a map wanting people simply to know where they are?

The Region Marker

Whatever the goal is, let's give a name to areas with a block using what is existent in the /title command.

Simply crafted from a sign and 1 to 8 emeralds [as if land "paid"] defining the cubic radius of effect,
It will show upon placement a two-lined GUI (title and subtitle).

Using the same texture as the Sign it's made from (but paler?),
It would be placated onto blocks and never on a stick (Block side or block top).

Simple, powerful and, most importantly, immersive - at least that's my opinion.

To avoid abuse, the program would break the sign on the spot if there is more than 2 overlapping region markers (if this is possible).
Why 2? Because certain places are embedded in other places.
Or could be uncraftable in survival.

The biggest radius cannot be too big, but multiple Region Markers with same name won't show multiple times.
Let's say 1 cubic chunks for smallest, 3³ for second, 5³ for third, all the way to 15³.
That is to say, where ever the person placed the marker, it's the chunk in which it has been placed that is affected for performance reason. Spherical radius may hinder performance.
(For comparison, a smallest map contains 8² chunks and the second, 16² so it gives a quite big range of effect)

Here as an example of the four first level of effects with a smallest map.

Why not in commands instead of a new block?

More than one seemed to wonder why not do it with commands. Well, I tried, and here is how I could do it:

1. A loop checking if a player is close enough - if so start 2
2. Call subtitle and title, then start 3 and cancel 1.
3. A loop checking if a player is no more close enough - if so start 1.
But. It will not work for multiplayer.

Hence the need for this simplified block that would be gracefully placed by command-experts and command-dummies alike.

Textured /title

A side but still important aspect of this would be to allow the /title command looks to be customized through ressource packs.
You like a different font? On the top left instead of the middle? Ressource packs should be allowed to grant users a different style than the squarish white ascii like characters by which we are greeted with the normal font. Let's end this monopoly!

Named Beacon

(Idea from Farm Collector.)
If you're not for a new block and would find the signs being overused, let's have this instead!
Point your cursor to its beam and its name will be displayed. Great for far recognition when multiple beacons are used.

Show your support!

Copy the following wherever you feel like it
Link RemovedImage Removed

<a href="Link Removed"><img src='Link Removed /></a>

<a href="Link Removed"><img src='Link Removed /></a>

TL;DR

It will make files lighter, should cause less lag, give a lot of customizability, and help type human readable names like

/give player "blue brick stairs" (OR) /place "inverted north red oak stair" ~0 ~0 ~1

The principle

Look at â, from French’s bâtir (to build) - it’s not a new letter but rather a + ^.
You can even have more than one accent like with this cute and evil looking ặ.

Blocks in Minecraft vary in model, texture, colour, and state.
Brick Stairs, heading North? Block id, Data value.
Wool, Red? Block id, Data value.
Oak door opened to the west? Block id, Data value.

This actually works fine for the moment.
Yet… this unclear model-texture and colour-state-texture distinction does not help customization, because, in order to have polished andesite stairs, trapped painted doors, obsidian red painted levers, or whatever your mind can create, one can only play with more and more block id and the same small amount of data value.

So let’s ease block/item/mob/biome addition by making the current system more intuitive and still light.

How?

Varying bytes. Using this way of coding and due to its variable size, quick calculations can be made with great customizability.

Looking at the Chunk Format and NBT structure, block ID and data value are kept in cubic chunks of 16*16*16 block ID under 256 in one list (4'096 bytes of information), block IDs over 256 in another list called "Add" (2'048 bytes of information), and data value in a third list (2'048 as well). Which makes that each cubic chunk weighs between 4 and 8 kilobytes.

I'm proposing differently which can make each cubic chunk weigh between less than 1 kilobyte to (unfortunately but unlikely) up to 20 kilobytes when super hyper customized. Let's...

• separate Y and Z into subcategories inside the cubic chunk
• allow 16 bytes in each Z-lines of each Y-Leaflets for "blocks"
• keep added information in a new 8-bytes "Add" format melting old "Add" and "Data", and there can be multiple "Add" lists.
• have the number of 1 before the zero in bytes from the "Blocks" array represent the number of four-bits related to it in the new "Add" format (At most 8 four-bits per blocks but that's quite unlikely).

This is how it would work:

• 0AAAAAAA 128 blocks where data=0
• 10AAAAAA: BBBB 64 blocks with data value
• 110AAAAA: AAAA BBBB 512 blocks with data value
• 1110?AAA: AAAA BBBB CCCC
128 blocks (A) with data value (B) and colour (C)
or 2'048 blocks (A+B) with data value (C)

• 11110?AA: AAAA AAAA BBBB CCCC
1'024 blocks (A) with data value (B) and colour (C)
OR 4'096 blocks (A+B) and data value (C)

• 111110AA: AAAA AAAA BBBB CCCC CCCC
1'024 blocks (A) with data (B) and 256 textures (C)

• 1111110?: AAAA AAAA AAAA BBBB CCCC DDDD
4'096 blocks (A) with data (B), colour (C), and 16 textures (D)
OR data (B) and 256 textures (C+D)

• 11111110: AAAA AAAA AAAA BBBB CCCC DDDD DDDD
4'096 blocks (A) with data (B), colour (C), and textures (D)

If that is too complex, we can let go of the varying bit idea and simply add a new list for a third set of 4-bits for colours (2'048 bytes per cubic chunk, or 128 bytes per Y-leaflets, or 8 bytes per Z-lines) and a fourth for textures (16 possible texture related to the mix of block ID and data value, which can be hair pulling to prepare the code for it though). Of course blocks that are already coloured (stained clay) can't get coloured again.

Who can do it?

Generalized simplified recipe in survival
The principle (first presented by Alexcamostyle) is simple, really. So that all of this greatness is accessible in survival, the recipes should be simplified. 3 of the same blocks horizontal? Slab. A dye with a block whatever it is? Dye with said block. Can't get much simpler. For this the way recipe works probably has to be changed as well a little. We'll see.

New GUI when in creative
The old separation of blocks/items in creative may or may not continue to exist, but one could be able to make from a three to four sided window, first with model (block ID actually), second with texture, third with color, and fourth with miscellaneous data value and otherwise tags aspects.

Command-accessible only
Or we can leave it to the command savvy, simply doing /give %p 'big cyan obsidian boat' (Link Removed)

Extra customizable ressource pack

So you want a pink-stained golden door? But how does it look?
The program will look first for a file in the ressource pack called "pink.gold.door.png", if absent then "gold.door.png" adding to it a pink tint, and if absent then take the oak door, add gold texture, then pink tint.

You have orange brick stairs? Same thing, if there is an orange brick texture, it will choose it first, otherwise it will tint the existing texture.

Beyond blocks

A similar potential can be done with entities from which the number would never go beyond a relatively small number, thus allowing more modulability to each ones like villagers with strange item exchanges, bigger creepers which could drop a TNT block, friendly spiders... And what about a swamp in which water is poisonous, or a mountain with loads of ore but water-filled caves? the limits are really far
The system for entities and biomes would be a quite different different though, and instead of having 4 bits per additional 1 in front of the first zero, it would have 8:

• 0AAAAAAA for 128 normal unspecific mobs/biomes.)
• 10AAAAAA: AAAABBBB for 1'024 entities/biome/etc. (it can't get more numerous) with 16 different basic changes (that can include the different kind of villagers, guardians, golems, or M/X/whatever other version of biomes)
• 110AAAAA: AAAAABBB BCCCCCCC same thing plus one of 128 predefined add-on (outfit, exchange, poisonous water)
• 1110AAAA: AAAAAABB BBCCCCCC CDDDDDDD same thing plus another 1/128th add-on
• 11110AAA: AAAAAAAB BBBCCCCC CCDDDDDD DEEEEEEE
• 111110AA: AAAAAAAA BBBBCCCC CCCDDDDD DDEEEEEE EFFFFFFF
• 1111110A: AAAAAAAA ABBBBCCC CCCCDDDD DDDEEEEE EEFFFFFF FGGGGGGG
• 11111110: AAAAAAAA AABBBBCC CCCCCDDD DDDDEEEE EEEFFFFF FFGGGGGG GHHHHHHH (you get the principle)

Human Writable Names for ID and data value

Follow the discussion here

Be aware

- It's going to be arduous change yet when it's done it's done for good.
- It may break many mods in their current form yet it will simplify mod making afterwards.
- By separating texture and data value, slabs and stairs for example will have unused bits yet it can be used to have side way stairs or slabs (the latter useful for thinner walls).
- Also, there will be block ID and texture overlapping, so the code is not fully efficient but at least enables future addition of blocks.
By the way, this, if well made, will not screw up existing world, only update it. Of course it's good to make a copy of your world before opening it like after any update.

Show your support

Copy the code below the image into your signature if you like!
Image Removed

<a href="Link Removed"><img src='Link Removed /></a>

<a href="Link Removed"><img src='Link Removed /></a>

I much prefer the model for desert palm tree to the other one.

I am undecided whether deserts should have foods as they should remain hostile but not so much that people don't want to live in them. I guess I support.

Coconut head gear? This sounds a bit lunatic but adds style to the game. Support as well.

But I don't think dates are necessary.

Why not have only one desert palm tree with coconuts? I know it's not realistic, but it keeps it simple - only one tree and one food added.

Quote from swaglord676»

The fact that it doesn't say the crafting recipe. Yep, that's pretty much it.

I disagree as the idea is interesting but needs development.

It would be nice to present textures for pillars and maybe even chiseled and double slab.

As well as, should it be contained in a new block ID, or can it be in minecraft:stone's data value?

And, can we make raw granite stairs or should it be only polished one?

If we consider that granite, diorite and andesite in both raw and polished form, let alone other stones that may be added later on, it makes a lot of addition.

• Polished chiseled and pillars. This fills 4 data value (0:chiseled, 1:pillar vertical, 2:pillar north-south, 3:pillar east-west), so it can be paired with four type of stones.
• Stairs. Since they take 3 bits of data value (0 to 3 gives orientation, +4 inverts it), so the fourth bit can be used to declare polished form.
• Slabs. Since they take 1 bit of data value (0 bottom and 1 top) we can use the 3rd bit for two stone type and the 4th shows polished form.
• Double slabs. There is already one there minecraft:stone2 that has 8 empty slot, so we can fill the gap (0:red sandstone, 1:granite, 2:polished granite, 3:diorite, 4:polished diorite, 5:andesite, 6:polished andesite, 8:smooth red sandstone)
• Walls. We can use the same block ID as cobble stone wall, but I advise creating a new block ID so to follow the same pattern as stone (0 Stone, 1 Granite, 2 Polished Granite, 3 Diorite, 4 Polished Diorite, 5 Andesite, 6 Polished Andesite) and yeah! stone wall as well.

So. total of new block ID: 1 chiseled/pillar (of 3 polished stones and an empty slot for future), 3 stairs (each with raw and polished version), 2 slabs (two stone types each with raw and polished version, and an empty slot for future), and 1 wall: 7!

Quote from XLR87T3»

What does that even mean? There is no "1/4 blocks" in the game, and I sure hope there won't be any in the future.

Well...

Sponges have been around since the beginning, and though they have gone through many stages, they have always returned eventually. However, we have never had a counterpart to the Sponge for soaking up other liquids. Enter the Soul Sponge.

This new utility block is very simple - when it is placed down, all fire and lava blocks nearby will be sucked into the sponge, giving a lava dripping effect. This produces a Burning Soul Sponge, which cannot absorb any more liquid and deals damage like a cactus when touched. However, you can throw it in water to make it usable again. You can also right-click a cauldron with it to get your Soul Sponge back along with a block of obsidian. It is almost identical to the Sponge.

To craft the Soul Sponge, you need Soul Sand and a Sponge.

The Soul Sponge can be used for a variety of purposes, from making Nether Travel easier, to saving a burning house, and much more.

Please like this post to show your support!

well, i liked the idea, 200% support!

Cool Idea! I support as a world type, but not for all generated Minecraft worlds.

PS, the "Islands" Should be ALOT bigger.

PSS, Could you upload that mod you were talking about in the thread? I would like to see that!

Hello everyone,

We could have electric fences in Minecraft. They would be crafted like fences, but you put redstone instead of sticks and iron ingots instead of wooden planks. Electric fences would:

* Conduct redstone current, like redstone dust powered rails.

* Whenever powered, cause 4 1 half-heart per half-second of electrocution damage to any entity touching it. This damage would cause knockback half as forceful as that caused by an attack on a Survival player by an unarmed zombie to all non-flying, non-swimming mobs. This means that squid, currently flying blazes, ghasts, withers, and the Ender Dragon would not be knocked back.

Electrocution damage would be as follows:
* The only entities that exist that are immune to electrocution are Creative players, primed TNT, and items. In practice, though, the wither and the Ender Dragon would never be electrocuted because they would destroy the fence.

* Any mob wearing iron armor or holding an iron tool or sword receives twice as much damage per piece of armor/tool/sword, this multiplier being capped at 16: so someone with an iron helmet holding an iron pick, for example, receives 4 times as much damage, and someone in full iron receives 16 times as much damage. Someone in full iron with an iron sword would receive only 16 times as much damage, not 32 since it is capped at 16. (If you're thinking this is OP, you can escape electrocution by avoiding fences the same way you avoid lava.)

The number of doors would be considered uneven, we could at least earn 4 doors or 2. But that spare door would come in handy if you a zombie came across it and destroyed it, or you could use it to make a new shelter or home.

This might have been mentioned before, but not in too much detail. So the suggestion is, that water needs different colours depending on where it is, how it is and when it is. This is in the game but it is hardly noticeable, it needs be more obvious and needs more types.

For example;

-In swamps it is green/brown

-In Snow biome it is Dark blue

-In Jungle it is Brown

-In Deserts it is Skyblue/oasis colour

-In caves/underground it is transparent

-In villager wells its transparent

-In sunset/sunrise the ocean is red/orange

-In night time the ocean is black

-In rain/storm its grey/dark grey

I Would hate to be a villager... drinking that blue stuff everyday...

If there's any more, please tell me, I will add it to this post.

Quote from AThingWithAThing»

Still, it isn't that hard to use /summon ArmorStand ~ ~ ~ {Marker:1b,CustomName:"Random"} then use /tp @p @r[type=ArmorStand,name=Random].

It is, I and I'm sure others have no idea what that means, to me /summon zombie [chance=50] seems much simpler.

Quote from Broccoli_Monkey»

Wouldn't it be better to make adding a chance optional, or at least not put your chance at the front of the command?
I'll give an example.
Instead of typing: "50% summon Zombie", to have a 50% to summon a Zombie, have it be:
"/summon Zombie [chance=50]" for a 50% chance of spawning. adding no chance to a command will make the game execute that command 100% of the time, while adding a chance value of higher then 100 will cause the command to fail.
That way, randomizing your commands would be completely optional, and would fit in more with the already existing modifications to commands.

I guess I've also been a bit harsh in my earlier comment. What I meant to say is that I don't really like the way you suggested this to be implemented, not that I don't like the idea in general. I should have specified that.

I do apologies, I guess I rushed into posting my idea without thinking about how to word it, I guess I was overexcited that I thought of it.

It would be completely optional and you don't have to add a chance to the command, since I don't use command blocks for much other than /weather clear and /say and other small bits, I wasn't sure how a command would be worded; Typing [chance=XX] seems like a much neater way of wording a command.

Let me know if you chance your mind.