Tagged as: HowTo

Go Plugins and Avoiding Cyclic Dependencies
July 20, 2017 by Noah

The other day, I started a project to eventually replace the backend of with a Go program instead of the current Python one (Rophako). It will support a similar feature set (being modular with even the core functionality, like user accounts and web blogs, being served by built-in "plugins" and allowing users to extend it with their own plugins).

The plugin system will support both compile-time plugins (your main.go imports and registers all the plugins you need when compiling the binary), and run-time plugins using Go's plugins from *.so files support.

This post will focus on the former, compile-time plugins, and how I ran into a cyclic dependency issue and worked around it.


Tags: 0 comments | Permalink
Poor Man's ngrok
May 4, 2017 by Noah

Recently, I was developing a Python/Flask app to implement Web Hooks for a third-party API that I was working with. The API recommended the use of ngrok during local development so that the server running on your local computer could be accessed publicly over the Internet (so that their API could reach yours).

ngrok is cool and all, but for their free plan they randomize the subdomain they give you every time you start the program. This meant I always had to log into my API account and change my Web Hook URL each day.

What ngrok is doing is nothing new: I've written about using SSH to forward ports between machines, and figured it should be easy enough for me to configure a subdomain on my own server that forwards traffic to another port that I could open when I need to.


Tags: 0 comments | Permalink
HTML5 Multi-File Uploader w/ Progress Bar
June 20, 2014 by Noah

The most recent feature I added to my website's CMS: multi-file uploads for the photo albums. I've been wanting to get around to this for a while so I can actually upload photo albums in bulk and make better use of that feature on my site. ;)

So I did some research and found some bits of example code here and there, and put together a pure HTML5 multiple-file uploader with progress bar. No Flash, no Java, no Internet Explorer 9 or lower. ;)

A lot of the existing bits of code I found out there weren't quite written in a way that was useful for my purposes. Their code tended to run the upload immediately after getting ahold of the files, i.e. they'd set up an HTML5 drag-and-drop spot and/or a multiple-file <input> box, and as soon as the user drops their pictures or selects them, the JavaScript would go right to work uploading them one by one to the back-end.

On my CMS I wanted to hold off on the uploading, because there's other form elements to take care of too, i.e. what album to put the pictures into or to apply a caption to them all. So I set up handlers for my file input box and drag-drop site to just put all the File objects into an array and wait for the submit button to be pushed.

So in my implementation, all the pictures are uploaded at once to the back-end, and there's only one progress bar (for the entire upload). It's possible to have one upload event per individual file, and therefore get progress bars on a file-by-file basis, but this didn't fit into my existing code structure.

Something I think is cool though is, on the back-end I'm using the exact same endpoint to handle uploads using Ajax (for those with JavaScript turned on) and when being POSTed to directly, i.e. for users with NoScript enabled. In both cases, they hit the /photos/upload on the server to send the form and images.

When the Ajax is the one doing it, it adds an extra __ajax form parameter. In this case, the back-end responds with a JSON response telling what the next URL is, and the JavaScript initiates a redirect to that URL. In case the user has JavaScript turned off, and the form POSTs to the back-end directly, the web server sends an HTTP redirect to the next URL.

Anyway, I threw together a quick Python/Flask app to mess with this stuff and figure it all out so I didn't have to worry about trying to wrangle existing code into doing something new. I have it hosted on Github here:

The real interesting part is in the JavaScript source - only 184 lines of code, including comments and whitespace. Pretty straightforward. The same basic front-end code could be used regardless of the back-end, i.e. it could be uploading to a PHP script or something instead of a Python app. The Python part of the source is pretty short and sweet too.

Tags: 0 comments | Permalink
Limbo in Vanilla Minecraft
June 3, 2014 by Noah

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.


Tags: 2 comments | Permalink
Minecraft Anti-Griefing in Vanilla
February 13, 2014 by Noah
This is a trick I picked up somewhere from /r/Minecraft that lets you implement anti-griefing on a 100% vanilla Minecraft server.

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 true
When 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:

Hopper Clock

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.

Tags: 67 comments | Permalink
Vanilla Minecraft Tricks
November 20, 2013 by Noah
I run a couple of Minecraft servers, and I always prefer to run the default vanilla server as provided by Mojang - mainly because the custom servers like Bukkit always lag behind by weeks or sometimes months every time a new version of Minecraft is released, and partly because there's just way too many custom plugins for Bukkit, many of which do the same things in different ways while being incompatible with each other and it's a huge mess.

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.

Spawn Region Mechanics

Most of these tricks involve command blocks and understanding a few quirks about how Minecraft vanilla servers work.

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 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. ;)

Command Blocks

Clever use of command blocks can enforce "rules" on a server, for example if you want to ban the use of TNT, you can have a command block be executed very rapidly that removes TNT from all player inventories, by running the command /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.

Griefer Protection

The easy way to prevent players from breaking your structures is to build everything important within the protected spawn radius. If you also turn off mob griefing, and use a command block to remove TNT from player inventories, it's highly unlikely they'll find a way to break things in the spawn region.

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 5
This 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.

Controlling the Spawn Location

In certain maps, you might like to have much finer-grained control over where exactly users on your server will spawn. In vanilla Minecraft, users will spawn somewhere within a 20x20 radius area centered around where the compass points. See Spawn/Multiplayer Details.

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 Z
Substitute 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".

Adventure Mode

Adventure Mode might be considered for certain circumstances as a method of anti-grief protection. On one of my servers, I built a huge Parkour course in the End Dimension, and I hadn't heard about using Mining Fatigue V to prevent players from griefing the parkour course, and things in The End aren't protected by the world spawn region, obviously.

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:

  • Players in Adventure Mode can't break or place **any** blocks by default, even if they have the correct tool (e.g. with a pickaxe, they can **not** mine stone blocks by default).
  • The exception is that items have new `CanDestroy` and `CanPlaceOn` tags, so for example you could `/give` an Adventure Mode player a pickaxe with a `CanDestroy:["stone"]` tag, and that pickaxe can *only* destroy stone blocks but nothing else that isn't explicitly listed in the `CanDestroy` tag.
So, Adventure Mode as a way to grief-protect an area is even better in Minecraft 1.8 because it stops them from being able to break anything at all, and you don't have to /clear their inventory either!

Helpful Links

Tags: 36 comments | Permalink
Google Music Manager Fix for Linux
October 30, 2013 by Noah
There seems to be a problem with the Google Play Music Manager on Linux, where once you set up the Music Manager for the first time, it's impossible to get its main window to appear after that. The tray icon is there, and it can be right-clicked on to bring up a menu, but clicking "Options" in the menu does nothing, and double-clicking the icon (which should bring up the Options window) also doesn't do anything.

I ran into this problem a couple different times on different machines running Fedora over the span of about the last 6 months. I had to Google it both times to find a solution (which wasn't easy to find), so here's the solution that ended up working for me each time.

  1. Stop the Music Manager by right-clicking the tray icon and clicking "Quit."
  2. Delete the folder ~/.config/google-musicmanager
  3. Optional step: the Music Manager is horrible at detecting duplicates, so I recommend you completely clear out your ~/Music folder (if you already downloaded songs from Google, move them to some other place). You'll see why in step #8.
  4. Open the Music Manager again from your applications menu.
  5. Log in to your Google account, etc.
  6. Choose "Upload music", not Download.
  7. Don't use the default "Music Folder" option, but explicitly browse to your Music folder and add it manually.
  8. Ignore any warnings about "less than 10 songs in the folder" etc. Also, if you already have music in your Music folder, the Music Manager will upload them anyway, and it sucks at detecting duplicates so you'll end up with a ton of duplicates on your Play Account in the cloud. This is why I recommend to clear out your Music folder in step 3.
For some reason, choosing to upload rather than download during the initial setup fixes the problem of the Options window not appearing from then on. Hopefully Google will fix the Music Manager soon, but it's been broken for ~6 months already so in the mean time this is the work-around. I eventually found this solution both times from a thread on the Ubuntu forums. Uninstalling and reinstalling the app is unnecessary, simply deleting the config folder does the same job.

Also, if you can't get the Music Manager to start at all in the first place, try running it from a terminal window with the google-musicmanager command and see what it says. On Fedora, it told me "error while loading shared libraries:", and I just had to yum install qtwebkit to fix it (the MusicManager RPM didn't correctly list this dependency). When you see this or similar errors in Fedora, you can use a command similar to yum provides '*/' and see what packages provide the missing file, and know what to install from there.

Tags: 36 comments | Permalink
Installing Windows 8 on a Samsung Series 5
May 19, 2013 by Noah
Here's some info on installing Windows 8 Pro on a Samsung Series 5 Ultrabook, in case anybody else has one and they wanna reinstall Windows from scratch.

To get the basics out of the way first:

  • Computers that ship with Windows 8 pre-installed usually have the Windows 8 Core Edition on them by default.
  • Also, the product key for the Core Edition install is baked in to the BIOS ROM.
  • If you boot a "vanilla" DVD or USB for Windows 8 Pro, it will fail, because Windows 8 looks for the product key in the BIOS ROM and will see that it is not a valid Pro key.
  • Some people say you can't install Windows from a USB on this laptop. You can do it, it's just tricksy.
The method that I found worked involves a dual-boot setup, where I have Windows 8 and Fedora Linux installed on the same laptop (you can substitute Fedora with any Linux distro of your choice... Ubuntu, Mint, etc.). If you want only Windows 8 on your laptop, this guide isn't for you. Sorry.

My particular laptop (the 13.3" variety) includes a 500GB hard drive and a 32GB SSD drive, which apparently is the ExpressCache drive. This is important.

So first, how to get Windows 8 to actually attempt to install. You can't just boot a vanilla DVD or USB, because the installer will see the OEM product key baked into the BIOS, and complain because it's for Core Edition and you're trying to install Pro Edition.

You need to make a USB installer for Windows 8 using the "Windows 7 DVD/USB Tool" (Google it). This is because you have to add a text file to the USB. You might be able to modify an ISO to add the text file to it, but you're on your own there.

Open Notepad, and create a text file named "PID.txt", and put this in as its contents:

Substitute the X's for your Windows 8 Pro product key. Place the text file in the Win8 USB under the "sources" directory, for example D:\sources\PID.txt

Now when you boot from the USB, Windows will use that product key instead of looking in the BIOS. And the installation will continue as normal.

But, it won't boot from disk after the installation is done. This is because the Windows Installer saw the 32GB ExpressCache disk, and it installed its bootloader onto that disk instead of onto the primary hard drive. The problem with this is that the BIOS on the laptop can't see the ExpressCache disk, and so it can't boot Windows from it.

I saw a couple solutions floating around the Internet for this. One solution said to format the ExpressCache disk with a Mac OS X file system, so that Windows wouldn't make use of it for its bootloader. You could probably format it with a Linux filesystem as well and get the same result. In this case, Windows 8 would've installed the bootloader directly onto the primary hard drive, and the BIOS would be able to boot it. This isn't much help to you, though, if you don't already have Windows installed to be able to format this partition.

What I did instead when I got to this point was... go ahead and install Linux. When I installed Windows 8, I gave it a 128GB partition on the hard drive. I gave Linux the remaining space to partition up as it pleases. When Linux installs the GRUB bootloader, it installs it onto the primary hard drive. This means the BIOS is able to boot GRUB... and, GRUB is able to see the Windows 8 Bootloader on the ExpressCache disk. Score! So now you can boot either Linux or Windows from GRUB.

This is what worked for me, anyway. If you don't wish to dual-boot Linux on your laptop, you may want to just boot a Linux LiveCD/USB, format the ExpressCache disk (/dev/sdb, probably) with a Linux filesystem like ext4, and then run the Windows installer again. Theoretically, Windows won't touch the ExpressCache disk to install its bootloader, and will install it on the primary disk. No guarantees that will work, though, as I haven't tested it.

Tags: 3 comments | Permalink
Fun with Command Blocks
April 10, 2013 by Noah
It's high time for my first Minecraft mini tutorial!

I tend to prefer playing vanilla Minecraft and try to get away with it as much as I can, and as such I've been electing not to run Bukkit or any other custom servers ever since about Minecraft 1.4 came out.

Minecraft has Command Blocks nowadays, and you can do a lot of creative things with them to replicate the behavior you could get by using Bukkit plugins. I recently started a new "Swampcore" server... the name is borrowed from a popular server on Reddit when they set up a swamp superflat temporarily while they waited for Bukkit plugins to get updated for the latest version of Minecraft.

Their version of Swampcore had you spawn in a small enclosed room, lined with pressure plates by the walls which would teleport you to an unpredictable location within a large radius on the overworld. The idea was to evenly distribute the players, so that people wouldn't build too close to the spawn point and therefore be open to griefing by newly joining players. Also, Swampcore had a 24/7 thunderstorm, which prevents mobs from burning up during the day and even allowed them to spawn in the middle of the day. I've managed to more or less copy all of this behavior using nothing more than the vanilla server, and here's how I did it:

First, the superflat preset I'm using is this:

Put simply, from the bottom up you have: 1 layer of air, 1 layer of obsidian, 1 layer of stone, 2 layers of bedrock, 1 layer of dirt, and 1 layer of grass. It's set in a swamp biome, with lakes and lava lakes, and sometimes the stone blocks (around lava lakes for example, or in the stone layer) might spawn ores.

So, go into creative mode and find the world's spawn point (give yourself a compass and go to where the needle points to, until you get to the point where the needle flips the opposite direction when you cross onto the next block). This is the center of the spawn point.

The server's spawn protection radius should be reasonably large (16 blocks should do). The protection radius basically prevents any users who aren't the operator from being able to change any blocks (destroy or place any). It also prevents them from activating any redstone devices except for pressure plates. They couldn't even open wooden doors in the protection zone.

Build a bunker out of bedrock. Here's what mine looked like:

(Click this and other screenshots for full size versions)

I put an iron door on my bunker and have a stone button that opens it. The button couldn't be activated by a non-operator, and as you'll see shortly, it should be unreasonably difficult for a non-operator to grief your bunker by having a creeper explode next to it.


Inside the bunker, build a redstone circuit designed to run on an infinite loop. I put a bunch of repeaters around, all set to the longest delay (right click 3 times), to keep the loop from bunching up on itself. When you're ready (not yet!), you'll place a redstone torch on the raised bedrock block and then immediately destroy it, so that it's only there long enough to give a quick pulse to the circuit and get it started.

Pro Tip: the 5x5 chunk radius surrounding the spawn point is always loaded in memory. Any redstone circuit that runs there will never be unloaded from memory even if all the players wander far away, so it's a good place to put your infinitely looping circuits that enforce "rules" on your server. The spawn protection radius is icing on the cake as well, as it automatically protects your circuit from being interfered with by other players (note that creepers and TNT launched from outside the protected zone can still damage the protected blocks).


In part of the circuit, make sure the redstone runs over the top of a command block. Use /give <your name> 137 to give yourself a command block to place. You'll definitely need to be an operator and in creative mode to set the command on the block. Hint: you can place redstone on top of the block by holding down the Shift key while you place the redstone.


The command I have here is this:

/tp @a[m=0,r=36] -336 202 179
This command will teleport all Survival Mode players (m=0), within a radius of 36 blocks from this command block, up to the coordinates -336, 202, 179. These coordinates in my case are, the spawn point, 202 blocks up into the sky.

The radius is set to 36 to make sure it fully encompasses the entire spawn region of the server. So anybody who joins the server or dies without a bed, they'll spawn on the surface (probably) within this radius and be immediately sniped up to the teleport spot. Players in Creative Mode are not affected, so that the operator can still get into the bedrock bunker to restart the redstone circuit in case it fails for any reason, or whatever.

Up in the sky above the spawn point, I built this floating room:


The floor of this room is at Y=200... I set the command block on the surface to teleport players to Y=202 just to have them off the floor a little bit. YMMV.

This room is a lot like their Swampcore server. It's a radially symmetrical room (looks the same on all 4 sides) with command blocks surrounding the perimeter. This is so that when you die and respawn and come back to this room, it won't be easy to know which pressure plate you used the last time. Even if you remember you "used the one in the middle", you still only have a 25% chance of guessing the same exact one as last time. The pressure plates are all rigged to command blocks to teleport players to a spot within a large radius, to evenly distribute them across the overworld.


Here is a view of this floating room from above. I put a roof area and a hole to drop down into the room just in case a user happens to spawn on top of the roof, instead of somewhere on the surface near the bedrock bunker. Hey, it happens. Note that since this room is still within the spawn protection zone, the blocks can't be destroyed or altered by the players unless they're operators. And since the room is so high in the air, the odds of getting a creeper up here, or launching TNT into the spawn region from outside to damage the room are extremely low.


Just like with the bedrock bunker, I have an iron door with a stone button for maintenance work (if needed) for the server operator. Even if a survival mode player spawns on the roof and drops down to this door, they can't get inside because of the protection radius.


This is a view from inside the maintenance room, directly below the main spawn room. These are all the command blocks that are positioned underneath the pressure plates above. I placed wooden signs under each command block that tells me the coordinates that the block will teleport you to. I also placed stone buttons on the side of the block (hint: hold down Shift to place the buttons), for testing purposes. Both the button and the pressure plate above will activate the command block.

The commands I used on these blocks are along these lines:

/tp @p 500 7 -1000
This teleports them to Y=7 (the level of the surface in my world), at the X/Y coordinates that are mentioned on the wooden signs below the command block. The @p targets the nearest player, which will usually be the one standing on the pressure plate above.

And that's all there is to it. If players find their way back to the spawn region, they can't get anywhere near the bunker without being teleported back up to the welcome room. The only way they could attack the bunker would be to somehow fling TNT over 36 blocks towards the bunker (an amazing feat in itself), but it being made of bedrock they wouldn't be able to do a whole lot of damage to it. The only way they could attack the welcome room would be to build up a super large tower to the top of the world, build a bridge as close as they're allowed to (within what the spawn protection radius will allow), and then fling TNT from all the way over there. If you set your radius high enough, even this will be highly impractical.

As for the 24-hour thunder storm... you could use another command block down in the bedrock bunker that does /weather thunder to make sure the weather stays tempestuous. Personally, I have a cron job that runs my make-it-rain script every 2 minutes. This is my cron entry for anyone interested:

*/2 * * * * /home/minecraft/bin/make-it-rain swampcore thunder 9000
Tags: 23 comments | Permalink
Install PAR::Packer on Windows
March 13, 2013 by Noah
I recently had need to install PAR::Packer on Windows (for those that don't know, pp is the best fully-open-source way to build a stand-alone .exe file from a Perl script, which doesn't require a Perl installation to run). I had installed pp on Windows a long time ago, but the process seems to have changed a bit so here's my experience doing it now, what problems I ran into, and how I fixed them.


  • Windows: Windows XP Professional, 32-bit
  • Perl: ActivePerl 5.16.2 for Windows 32-bit
  • PAR::Packer: 1.014
  • Module::ScanDeps: 1.10
The Makefile.PL from PAR::Packer lists what other dependencies it has. These were all available in ActivePerl's PPM repository so they were easy to install, for example, ppm install Win32-Exe.

nmake 1.5?

A long time ago, you used to be able to download this stand-alone nmake binary from Microsoft, which replaced the usual make command from Unix. But, it seems Microsoft has pulled this download offline and they want you to install some kind of Visual Studio Express app that provides a newer version of nmake. I ended up finding a copy of nmake somewhere else on the Internet, which I've hosted here: (NOTE: You might not need nmake, I later found out ActivePerl comes with dmake which worked for installing other modules, YMMV).

The only modules I needed to manually install (perl Makefile.PL; nmake; nmake install) were Module::ScanDeps and PAR::Packer, but running nmake gave this rather cryptic error message:

to undefined at C:/Perl/lib/ExtUtils/ line 1208
I found this relevant Perlmonks article. What I needed to do was open the Makefile (not Makefile.PL; the one with no extension) in Wordpad, and do a Find/Replace of {{@ARGV}} to {@ARGV}, and then nmake ran just fine.

For my project I needed to manually install Template::Toolkit, and the Makefile.PL told me to run dmake. Running this worked just fine without requiring me to manually modify the Makefile. If this is available, I imagine it would probably work better for you then nmake.

Anyway, after installing PAR::Packer's dependencies, PAR::Packer installed and ran just fine.

Tags: 1 comment | Permalink