I've created a downloadable Minecraft map that implements "Swampcore" (older blog post about Swampcore). It's a superflat swamp biome preset with a 24/7 thunderstorm, making for an extremely hostile map where you have to scratch and claw your way into having so much as a simple dirt shack to call "home".
It runs on vanilla Minecraft (no mods or anything needed) and was created on Minecraft v1.8.3, but will probably work on later versions too.
These are just some of my thoughts on things that a Minecraft clone should probably do differently to Mojang's (well, Microsoft's) Minecraft, since a clone would be starting from scratch anyway and would be in a good position to fix some of the fundamental problems in the original game that are impossible/unlikely to be fixed by Microsoft.
Some of the Minecraft clones I'm familiar with so far are Terasology, Minetest, and Michael Fogleman's Craft. So far, Craft seems to do the most things "right" (as far as my list of fundamental improvements on Minecraft go) such as only storing changes to the blocks to disk rather than whole entire chunks, but more on that in a minute.
Disclaimer: I'm not a game developer. I am a software developer and have a particular interest in the technology used in games, i.e. I have the knowledge to write code for most given game mechanics and spend countless hours thinking about these sorts of things. I've read a lot about the technical internals of Minecraft and have read some of the source code to these clones, so this blog post is full of my own educated opinions on things. I may, at some point, take on the challenge of creating a Minecraft clone of my own, but until then these are just the things I've been thinking about over the last several months.
Time for another Minecraft tutorial using command blocks to do something pretty neat using the vanilla version of the game (no plugins necessary). I used Minecraft version 1.7.9.
In this mini tutorial, I'm showing off how I created a "Limbo Dimension" that players are sent to after death, where they must remain for 60 minutes before being respawned in the overworld again.
It requires you to have operator rights on the server, and it involves command blocks. Give yourself a command block by typing the command /give your_name command_block
, and place it somewhere in the center of the area you don't want being griefed. I usually will hide it just below the ground, or in a small hidden-away room in the middle of a building or something. Right-click it, and enter this command:
effect @a[m=0,r=36] 4 2 5 trueWhen activated, this command will apply a status effect to all Survival Mode players (
m=0
), within a radius of 36 blocks from the command block (r=36
). The effect will be Mining Fatigue (effect ID 4
), level 5
, which will last for 2
seconds. The word "true" at the end will hide the particle effects (supported in Minecraft 1.8+; for older versions, remove the word "true" from the command). See Status effect on the Minecraft wiki for details.Mining Fatigue slows down the player's mining speed by 20% per level, so at level 5 your speed is slowed by 100%. What this basically means is that nobody can break anything while under Mining Fatigue 5. You can't even break a dandelion using a diamond axe. It makes the area completely grief-proof.
Adjust the radius to however large you think you'll need to cover the entire area you want protected. If the area is very large (i.e. so that the command block might end up being unloaded from memory when its chunk goes away), you'll need multiple command blocks positioned around the area to make sure the Mining Fatigue is still in effect.
Anyway, now you just need to hook up the command block to a redstone clock so that it's triggered repeatedly. My favorite is to just use a hopper clock. A comparator clock has too fast of a pulse and the command block will never be executed.
With a hopper clock, just place two hoppers that connect to each other. For example, place a normal block like stone, and then with a hopper, right-click on the side of the stone block so the bottom of the hopper connects to the side. Remove the stone block, go to the side where it used to be, and hold down Shift and right-click the hopper to attach the second one.
Edit for 1.8: It seems the timing has been changed in hoppers on Minecraft 1.8, and a two-hopper clock is "too fast" and won't trigger the command block repeatedly (it will trigger it one time and then never again). Instead of using 2 hoppers that feed into each other, you can use 4 hoppers that feed in a circle, each one connecting to the next one. This slows down the rate that the command block gets executed by 50% but it still works in Minecraft 1.8.
Put a single item into one of the hoppers. If it worked, the item should disappear from the hopper's GUI and then reappear shortly after; the item is being passed back and forth between the hoppers. Now, pick one hopper and put a comparator and then a repeater next to it. Whenever this hopper has the item, the comparator will get a signal and the repeater will amplify it. And there you go. Here's a screenshot of the full setup:
What about creepers and endermen?
Even if you prevent players from destroying blocks manually, they could still lure a creeper in and cause it to explode and damage the nearby blocks. In Minecraft 1.8+ you can select entities by type using command blocks, so you may wanna add some more command blocks to killl any creepers or endermen that get too close (the endermen are optional, but if your build involves a lot of natural blocks like dirt and sand you may wanna keep them away too):
Creepers: kill @e[type=Creeper,r=36]
Endermen: kill @e[type=Enderman,r=36]
You may also be able to do the same for the `PrimedTnt` entity but that may be trickier considering the speed at which TNT can be launched. You'd need a particularly fast redstone clock to keep up.
It's a Python app that wraps the Minecraft server and makes the server console available over a separate TCP socket (with password authentication, of course).
This allows you to telnet in to this TCP port, provide the password (or a challenge-response hashed version of it), and then you get access to the Minecraft server console. Anything the server outputs is broadcasted to all authenticated clients, and anything the clients send is sent to the Minecraft server. But the real strength in this isn't necessarily just being able to see and type commands into the server console (you can do this at the local shell running the server normally); it's for programs to do this automatically!
For example, you can have a whitelist of users who aren't operators, but you want them to be able to say for example !creative
in the server chat window, and have their game mode switched to creative. This is one of the example scripts I included in my project, actually!
And as a more eccentric example, I connected a simple RiveScript bot to this so that it can chat with players using the in-game chat system:
You can get the source code and play around with this yourself at minecraft-control on GitHub!
You can read the rest of this blog post for all the examples, but the main key difference is that the EntityId
tag has been removed and you need to do SpawnData:{id: EntityIdHere}
instead, replacing "EntityIdHere" with the entity ID you want (Zombie, Skeleton, PigZombie, VillagerGolem, etc.)
So, for the /setblock command:
Old way: | /setblock ~ ~ ~ mob_spawner 0 replace {EntityId:Zombie} |
New way: | /setblock ~ ~ ~ mob_spawner 0 replace {SpawnData:{id:Zombie}} |
And for the /give command:
Old way: | /give @p mob_spawner 1 0 {BlockEntityTag:{EntityId:Skeleton}, display:{Name:Skeleton Spawner}} |
New way: | /give @p mob_spawner 1 0 {BlockEntityTag:{SpawnData:{id:Skeleton}}, display:{Name:Skeleton Spawner}} |
So when you see examples below, translate them into the new format for Minecraft 1.9. I may eventually write a new version of this blog post that contains only 1.9 commands, but for now you'll have to rewrite them manually.
Edit 2: there seems to be a bug in 1.9 where a spawner given with the /give
command will only spawn its monster one time before reverting to a pig spawner. The SpawnPotentials
seems to be the culprit; when the block is placed it gets initialized to a list that only includes pigs. The list is supposed to be empty by default, so explicitly setting it to empty seems to work:
/give @p mob_spawner 1 0 {BlockEntityTag:{SpawnData:{id:Skeleton},SpawnPotentials:[]}}
The original blog post follows.
--Updated on 3/17/2016
/summon
, /setblock
, and an extended syntax for /give
, so that you could summon any entity, and attach a ton of NBT Tags on it to control attributes like what equipment it's wearing or whether it's invulnerable. ;)I was excited about this because not only could I spawn an Enderdragon in the overworld (this never ends well), but it would open up the possibility to just give myself custom monster spawners, like those typically found in a zombie/skeleton/spider dungeon.
Unfortunately, the Update: since writing this I found the syntax for giving a mob spawner with /give
command doesn't seem to allow you to add a monster spawner to your inventory. At most, you'll get a Pig Spawner, which has always been the default monster if you would /give
yourself a spawner in the past. But, if you use /setblock
you can just set a block to be a monster spawner and do it that way./give
. Example:
/give @p mob_spawner 1 0 {BlockEntityTag:{EntityId:Skeleton}, display:{Name:Skeleton Spawner}}This gives a Skeleton Spawner in your inventory. The
display:
stuff is just to give it a custom name, otherwise it will call itself "Mob Spawner" in your inventory. If you're gonna carry multiple spawners, the names will help differentiate them. Everything inside the BlockEntityTag
part are the same tags from the /setblock
examples below.Now back to the original post...
Pictured above are your "naturally occurring" monster spawners along the bottom: Blaze (in Nether Fortresses), Skeleton, Zombie, Spider, and Cave Spider (in abandoned mineshafts). I've also created spawners along the top for: Magma Cube, Slime, Zombie Pigman, Creeper, and Enderman.
The basic command syntax is along these lines:
/setblock ~ ~ ~ mob_spawner 0 destroy {EntityId:Zombie}Replace the value for
EntityId
for any other valid entity. There's a list of Entity IDs on the Minecraft Wiki. You can create a monster spawner for pretty much every monster in the game, including the bosses like the Enderdragon and Wither./setblock ~ ~ ~ mob_spawner 0 destroy {EntityId:EnderDragon} /setblock ~ ~ ~ mob_spawner 0 destroy {EntityId:WitherBoss}Things to watch out for: the Enderdragon will destroy every block it touches except for Bedrock, Obsidian, and End Stone (a.k.a. the only three types of blocks that naturally occur in the End Dimension), so it will destroy its own spawner, and if you create one in the overworld or the Nether, it will ruin everything it touches. You can mitigate this by turning off monster griefing with the command
/gamerule mobGriefing false
.
With this command you can also create a spawner for the Giant. This monster has been in the game for ages but never officially used. It's a super-huge zombie. However, I couldn't get this spawner to actually create a Giant for me. :( Your mileage may vary. You'll probably be better off summoning it directly with /summon Giant
.
/setblock ~ ~ ~ mob_spawner 0 destroy {EntityId:Giant}
You can also create a mob spawner for horses! (edit/warning: this worked for me when I originally wrote this post, but others have reported that horse spawners tend to crash their games. I can reproduce this behavior now too in Minecraft 1.7.10 and a few others I tried (1.7.9, 1.7.2). There's a Minecraft bug ticket for this. YMMV. It seems to work in snapshot 14w31a (screenshot) so may be fixed for 1.8)
The zombie and skeletal horses aren't naturally occurring in-game, and they cannot be tamed normally like other horses. You'll want to make sure the "Tame" flag is set when spawning these so that players can ride them. They can equip saddles, but not armor.
Zombie: /setblock ~ ~ ~ mob_spawner 0 destroy {EntityId:EntityHorse,SpawnData:{Type:3,Tame:1}} Skeletal: /setblock ~ ~ ~ mob_spawner 0 destroy {EntityId:EntityHorse,SpawnData:{Type:4,Tame:1}}Again, warning: horse spawners with SpawnData may crash your game. It's a known bug in several versions of Minecraft. If this happens, and your game managed to save the world before the crash, so that it instantly crashes again when rejoining the game, you'll have to use a third-party tool like MCEdit to delete the offending spawner.
That "SpawnData" attribute from the previous command is how you can attach NBT data to the spawned entity. Horses take a Type attribute and Tame, among some others. You can see all the relevant NBT tags at "Chunk format" on the Minecraft Wiki.
Here's a more advanced command that creates a Zombie spawner where the zombies are all equipped with Diamond Swords. I found this one from the Minecraft forums (I don't know or care too much about the NBT format; I usually just create simple spawners as listed above in this post).
/setblock ~ ~1 ~ minecraft:mob_spawner 0 replace {EntityId:Zombie,SpawnData:{Equipment:[{id:276,Count:1}]},SpawnPotentials:[{Type:Zombie,Weight:1,Properties:{Equipment:[{},{},{},{},{id:46,Count:1}]}}],SpawnCount:2}Note: You'll have to paste that into a Command Block (
/give <your_name> command_block
) because the command is too long for the chat console. Attach a button to the command block with Shift+RightClick, push it and the spawner will appear above the block.I liked the idea of some of Bukkit's plugins, though, so I'm always trying to find creative ways to get similar results using just the vanilla server. Here's a few tricks I figured out myself or heard about from Reddit.
Upon creating a new world, give yourself a compass and follow it to find the center of the world spawn region. I usually put a block here to visually remind myself where the center is, because the spawn region is important for a couple of reasons.
Firstly, the spawn region is always kept loaded in memory, along with the 5x5 chunk radius surrounding the spawn point (where a chunk is a 16x16 block section of the world). This is important because it means that if you set up any Redstone devices that run on a loop, they'll run all the time even if all the players wander far away from the spawn area. So it's a good place to incorporate command block circuits to enforce global "rules" on your server.
The other important thing is the spawn protection radius, which is the number of blocks around the spawn point (where the compass points) in which non-operator players are not allowed to place or destroy blocks, or interact with most items. By default the radius is set to 16 blocks, and is configurable in the server.properties
file.
In the spawn protection radius, non-op players can't place or destroy blocks, and they can't use any devices except for pressure plates and trip wires. They can't even open or close wooden doors, they can't use crafting tables or furnaces, etc. Only the server operators have rights in the protection radius.
However, the protected area is not safe from monsters or outside interference, so for example if a player lures a Creeper into the spawn region it can still blow up blocks (unless you turn off mob griefing with /gamerule mobGriefing off
, which prevents Creepers and other mobs from changing blocks). Clever players can also fling TNT in from outside the protected region to destroy blocks inside. When in doubt, encase your Redstone circuits in bedrock bunkers and keep them hidden away from view. ;)
/clear @a minecraft:tnt
.All your command block redstone circuits should use a clock circuit of some kind (one that will run in an infinite loop). Ideally, the circuit should be self-starting, especially if the circuit is NOT within the 5x5 chunk spawn radius. This is because when the chunks that contain a redstone circuit are unloaded, the circuit stops running, and when the chunks are reloaded (because a player walks closer to them), you want your circuit to automatically start back up.
See clock circuits for some ideas. An example I use is where you have a redstone torch that powers a circuit, and the circuit eventually extends a piston over an earlier part of the circuit to interrupt its own power. With the power interrupted, the piston retracts, allowing the circuit to be powered again by the redstone torch, and so on.
Outside the spawn region, a useful tip I saw on Reddit is to apply the Mining Fatigue V effect to all players within a certain radius of your building. For example, create a redstone clock near the middle of your building that runs a command block to run this command:
/effect @a[r=60,m=0] 4 3 5This will apply an affect to all players (
@a
), who are within 60 blocks of the command block and who are in Survival Mode (m=0
), the Mining Fatigue effect (ID 4), for 3 seconds, at level 5. Mining Fatigue level 5 basically makes it 100% impossible for the player to mine a block, even if they have a diamond pickaxe, even if it's enchanted. The player can't even break a flower under this condition.The 3 second interval would be adjusted depending on how frequently your clock runs the command. You want it to only affect players while they're within the general area of your building, and lift the effect quickly if they leave.
On one of my servers, I wanted all players to appear in the center of a room when they joined the server (or died without a bed) so that I could somewhat randomly disperse them around the world by having them pick a pressure plate that would teleport them somewhere. See my blog post "Fun with Command Blocks".
Basically, if you go this route, the actual world spawn point will not be used. Instead you'll just have a command block running on a clock that teleports anyone who appears in the spawn region to a destination somewhere else (you should make sure you teleport them far away from the spawn region, so that they'll be outside the radius of the command block that teleported them... otherwise you get caught in an infinite loop of teleportation!)
Example command for this command block to run:
/tp @a[m=0,r=25] X Y ZSubstitute X, Y and Z for the coordinates to teleport to. This command would snipe all users within a 25 block radius of the command block and teleport them off to those coordinates. Also make sure to include the "
m=0
" -- this will make it only teleport Survival Mode players away. This way, you (the operator) can switch your mode to Creative and be able to get close enough to the command block to edit it or whatever you need to do. But it will keep all the other players away by teleporting them to your designated "spawn location".
What I did was encased the End Dimension Spawn Platform in bedrock, with the only exits to either go back through the Exit Portal, or step on a pressure plate that would teleport them into the Parkour course (if somebody destroys the pressure plate, then nobody can get into the parkour course, but it's better than allowing them to vandalize the course itself).
The pressure plate would run a few command blocks - one would clear all their inventory with /clear
, another one would change their game mode to Adventure with /gamemode 2 @p
, and the last one would finally teleport them into the course.
A command block clock in the overworld would set all adventure mode players back to survival in case they died and respawned, with /gamemode 0 @a[m=2]
.
The thing to know about Adventure Mode, though, is that it's basically "Strict" Survival Mode. If a block requires a specific class of tool to break it (stone needs a pickaxe, wood needs an axe), then only that tool is allowed to be used. If you swing an axe at stone, or a pickaxe at dirt, then your player just swings once as if hitting air, and then nothing.
You don't necessarily need to use the right material of tool, just the right tool. For example Adventure Mode allows you to destroy obsidian using a wooden pickaxe, even though the wooden pickaxe won't drop the obsidian block. So for Adventure Mode to work, you basically need to remove ALL tools from their inventory.
Even without tools, blocks that can be broken by hand are still vulnerable. So avoid using glass, torches, flowers, redstone devices (including buttons) which are in reach of the player, etc., as they can break these without needing any tools at all.
Update (8/14/15): As of Minecraft 1.8, the Adventure Mode behavior has been changed. Briefly:
/clear
their inventory either!
One of the big features of the Raspberry Pi edition of Minecraft was that they provided a scripting API, so that you could write Python code to manipulate the blocks in the MineCraft world.
The scripting API hasn't officially come to the desktop version of Minecraft, but version 1.7 includes a handful of fun new server commands, like /setblock
, /summon
, and an extended interface for /give
, so you can now summon any type of entity you want, including Ender Dragons, or summoning a Wither Skeleton riding on top of a Skeleton Horse while wearing fully enchanted diamond armor and holding a diamond sword.
But this post is going to focus on the /setblock
command, which lets you change a block somewhere in your map by giving the coordinates to it and setting what type of block you want to put there.
When you're running a Minecraft server, you can enter server commands either in-game (if you're the operator), or directly into the terminal that's running the server. Using the latter, you can have a third party program (a Python script for example) write stuff into the terminal running the server, to automatically run server commands!
I made a quick proof-of-concept Python script to demonstrate this. This script will create a cube of stone of any dimensions you want somewhere in your Minecraft 1.7 server.
#!/usr/bin/python
# makecube.py - Proof of concept for scripting Minecraft 1.7
#
# Usage: makecube.py <screen_name> <size> <x> <y> <z>
#
# Works for Unix-like OS's only and depends on the `screen` command.
# Setup:
# [bash]$ screen -S minecraft
# [screen]$ java -jar minecraft_server.jar
# (in another terminal)
# [bash]$ makecube.py minecraft 25 0 60 0
from sys import argv
import os
material = "stone"
if len(argv) != 6:
print "Usage: makecube.py <screen_name> <size> <x> <y> <z>"
quit()
screen = argv[1]
size, x, y, z = map(lambda arg: int(arg), argv[2:])
def setblock(x, y, z):
cmd = "screen -x {0} -X stuff '/setblock {1} {2} {3} stone 0 replace\x0D'"\
.format(screen, x, y, z)
os.system(cmd)
# Generate the cube's coords.
coords = list()
x1 = int(x - size/2)
y1 = int(y - size/2)
z1 = int(z - size/2)
for x2 in range(x1, x1 + size):
for y2 in range(y1, y1 + size):
for z2 in range(z1, z1 + size+1):
coords.append([ x2, y2, z2 ])
# Send all the /setblock commands.
for coord in coords:
setblock(*coord)
It also has a feature to import a heightmap file, which is a grayscale image where brighter shades of white represent higher mountains, and lower shades are the lower elevations of the map. With this, you could design a terrain in a variety of different tools, export a heightmap of your terrain, and through WorldPainter, convert it into a Minecraft map. You can paint in the biomes and other features first in WorldPainter, of course.
I decided to test this using a heightmap I found of Myst Island (I found it on this Myst Online forum thread). Here's the original heightmap:
The image is 500x500 pixels, and the brightest shade of white is about 253, so if we imported this into WorldPainter as-is, half the island would be flooded (with the default water level of 62), and that mountain would reach higher than the clouds. So, first, I adjusted the levels in GIMP (Photoshop or something could've been used instead) to raise the lowest shade of black to just below the water level and lower the brightest shade to something more reasonable.
Because the heightmap included some underwater hilly structures, I brought the lowest level up to 52 instead of 0, and lowered the highest level down to 120 from ~255. This resulted in the following image:
After importing it into WorldPainter (via File->Import->Height map), this is how the map looked:
I exported the map immediately to see how it would look in-game. I found that the original scale of the heightmap made the island a little bit too large, so I tried again but scaled it down to 50% when importing the heightmap. Here you can see the difference (click for larger versions):
It's all a trial-and-error kind of thing. I had to tweak the levels of the heightmap a handful of times to get it to look just right, and scaling it down to 50% might not even be the perfect scale either (but you wouldn't know until you started trying to build on it). This is a pretty neat tool anyway. I'd probably recommend making your own terrains rather than trying to use someone else's (for example Myst Island), because then you'll get a lot fewer headaches when trying to build on the map and trying to get the scale just right and everything.
My Minecraft servers are being rearranged as well. This new machine has 5 IPv4 addresses, and each of my MC servers will get its own IP and hostname instead of having to juggle port numbers.
0.0018s
.