Several new mods.
I've put up descriptions above; it appears at least one of them is making the Nether not work properly. I'm crashing when I leave it, which sometimes necessitates a server restart.
It's a little too late to figure out which one is causing it (assuming it's just one, and not a conflict between two) -- that's what I'll do tomorrow. Not looking forward to it, my server hoster's GUI is truly terrible, so I'll be doing a lot of copy + pasting, file deltion, intentionally crashing Minecraft, then undoing my changes and trying it again. Fortunately, there's only 5 mods, so only like 30ish configurations.
On the bright side, bugs aside, I was able to implement about 99% of what I wanted to do on the server. I'd like to allow Admins to set warp points for free, without having to give themselves the cash to do it, but that's neither here nor there.
The next step? Well, bug-fixing, obviously, then number-smoothing. After that, I'll look at some fun mods (maybe dinos) and play with them, and if I'm really happy with how it turns out, I'll start recruiting users from the forums.
Monday, June 6, 2011
Friday, June 3, 2011
Redstone Fortress
I really, really like redstone. It's a quirky logic puzzle and it's utterly ridiculous -- both things that make something great, in my book. (It's the same reasons I like Dungeons & Dragons 3rd edition, even though it's perhaps the least-elegant gaming system I've ever run across.)
In any case, I'll be making some changes to my server (50.23.67.132:25617 -- contact me for a whitelist to join us!) with Bukkit and other mods. Among the changes:
●We'll be adding monsters, but disabling or altering Creeper explosions. Dankcraft turned off their explosions entirely, which is kind of a shame -- they don't inspire much terror there, but their ability to level hard work and allow monsters to stream into your base is incredibly frustrating.
●John really wants furniture. (I do too, but he really, really wants furniture.) We'll be looking for a mod that adds some decent-looking cobble, wooden, etc. chairs and tables.
●There's a great-looking dinosaur mod that I absolutely adore, but I hate its rules -- it spawns aggressives in packs (and server lag means that's essentially a death sentence) and it gives T-Rexes the ability to eat through blocks to get to a character. It also only spawns dinos near a rare block that it adds. If I can change the mod's properties, so dinos are more common, less lethal and can't break blocks, I'll go ahead with it.
●I'd like to have an iConomy plugin replace OP spawning abilities -- the idea being that you could trade in your extra goods for items from the server. Something like 512 cobble: 1 diamond (which is honestly too low, but it's about right for a tiny operation more interested in building than mining). I like mining, but I hate having to mine, if that makes sense. I'll probably have too-high cobble:other values, though -- let people trade in their extra iron, Lapis and cactus for building material, dontcha know.
Finally, I'll be clearing a 30,000ish square meter area to begin work on a massive redstone fortress. The idea is to have a mob-impregnable, self-sealing exterior and a fully automated interior; I want to base it on a real-world castle, but with fantastic, steampunk elements. A centralized rail-cart system will replace the basic one for new players at the Spawn Tower, which will be relegated to "interesting building" status. The ground level -- which will be at sea level -- will be the ground floor, but I plan on dedicating basement levels to redstone circuitry. If you've got an idea for the castle, post it here -- or if you have a suggestion for an interesting real-world castle to base it on.
In any case, I'll be making some changes to my server (50.23.67.132:25617 -- contact me for a whitelist to join us!) with Bukkit and other mods. Among the changes:
●We'll be adding monsters, but disabling or altering Creeper explosions. Dankcraft turned off their explosions entirely, which is kind of a shame -- they don't inspire much terror there, but their ability to level hard work and allow monsters to stream into your base is incredibly frustrating.
●John really wants furniture. (I do too, but he really, really wants furniture.) We'll be looking for a mod that adds some decent-looking cobble, wooden, etc. chairs and tables.
●There's a great-looking dinosaur mod that I absolutely adore, but I hate its rules -- it spawns aggressives in packs (and server lag means that's essentially a death sentence) and it gives T-Rexes the ability to eat through blocks to get to a character. It also only spawns dinos near a rare block that it adds. If I can change the mod's properties, so dinos are more common, less lethal and can't break blocks, I'll go ahead with it.
●I'd like to have an iConomy plugin replace OP spawning abilities -- the idea being that you could trade in your extra goods for items from the server. Something like 512 cobble: 1 diamond (which is honestly too low, but it's about right for a tiny operation more interested in building than mining). I like mining, but I hate having to mine, if that makes sense. I'll probably have too-high cobble:other values, though -- let people trade in their extra iron, Lapis and cactus for building material, dontcha know.
Finally, I'll be clearing a 30,000ish square meter area to begin work on a massive redstone fortress. The idea is to have a mob-impregnable, self-sealing exterior and a fully automated interior; I want to base it on a real-world castle, but with fantastic, steampunk elements. A centralized rail-cart system will replace the basic one for new players at the Spawn Tower, which will be relegated to "interesting building" status. The ground level -- which will be at sea level -- will be the ground floor, but I plan on dedicating basement levels to redstone circuitry. If you've got an idea for the castle, post it here -- or if you have a suggestion for an interesting real-world castle to base it on.
Wednesday, June 1, 2011
Little errors
Blogger's not the worst thing in the world, but it's got some glitches. For example, it doesn't seem to like Java 1.7 -- I can't edit posts once they're published. When I find errors later -- like "card" rather than "cart," or missing quotation marks in "on," I can't fix them. They live on forever. Sure, I could copy the entire post, make a new post, copy the text in, delete the original post and then republish the copied text, but that's tiresome (and comes with a slew of its own unintendeds).
What's this got to do with Minecraft, you ask?
Well, it's eerily similar to the game's portal system. Redstone circuits are a logic puzzle, but they're straightforward in the sense that they're predictable and always follow the same ruleset. (Aside from server restarts -- which can introduce some really unusual bugs into redstone circuitry. Nothing's easy, you know.) Portals, though, are unintuitive and cumbersome things. Here, I'll show you.
You hop into one --
And you end up in the Nether. It's a miserable place, full of angry ghosts, zombie pigmen and unpleasant blocks of all kinds. The most common, netherrack -- that red stone you see everywhere -- has the useful property of staying ablaze if you light it. It's a great component for mob grinders, particularly ones that harvest piggies -- pigs killed by fire drop cooked porkchops, rather than raw ones.
Turn around, and you see this vista. This is honestly the most amazing Nether spawn I've ever seen; it actually feels ominous and terrifying, rather than blocky and annoying. But we're not here to sightsee or to get attacked by angry ghosts, we're here to set up portals.
And here's a pair of portals I built. The reason they're so great is that the Nether's cardinal directions correspond to the normal world's at an 8:1 ratio. For every step you take in the Nether, you travel eight steps in the normal world (though it's a 1:1 match vertically -- which doesn't matter usually). This means that you can travel very quickly by moving through the Nether. However, portals aren't linked. (That's the first unintuitive thing about them.) Rather, when you hop into a portal going either direction, the game searches a certain number of squares in each cardinal direction for a portal in the other world. (That "certain number" is a 256 by 256 square in the Nether or a 2,048 by 2,048 square in the real world.) It checks in a spiral, starting with the square you're at; vertical location seems to be the tiebreaker for two equidistant portals. This means that portals typically bias toward overland travel; this feels intuitive at first, until you try making portals match up. Then it feels lunatic barmy crazy. It only gets worse when you're putting bunches of tightly packed portals to travel vertically, as I'm doing here. Two things can happen in that situation -- the first is that the portal's proximity means that even a single square can change a portal's destination. (You avoid that by giving some cardinal distance between your normal world portals, but it happens sometimes.) The second is that two portals are separated vertically enough that the destination gets thrown off -- and then you have to whip out the old Pythagorean theorem and figure out how far down you gotta bury your portal to make it work. Another frustration is that, when a portal has nowhere to connect to (as your first portal won't), it creates a portal in a seemingly random fashion to connect to. This creates even more unintuitive behavior -- the first time I created a second overland portal, it linked my right back to the same Nether portal. That kind of behavior sets up an expectation -- that portals will create links to each other -- and then dashes it when they don't. It's kind of the definition of unintuitive. Here's the kicker -- because of the semi-random nature of portal placement, you often have to tear down your auto-generated portal to make your placed ones work. The whole thing is a mess of "huh"-inspiring rules!
So here's where the Blogger comparison comes in -- it takes something like 15 or 20 seconds to break down an obsidian block with a diamond pick. When you misplace a portal -- as I did earlier when I got some poorly labeled coordinates mixed up -- you have to break down 10 obsidian squares. It's only like two minutes to break down a portal, but I dread it. It's the most excruciating timesink in the game (though it's nowhere near the worst one). I COULD just rip down one square in a portal and then cheat in the next one, which I don't have a problem doing on the multiplayer server -- but I hate leaving that obsidian up. It looks tacky and it's confusing. On a legitimate server, obsidian's a precious resource, so leaving it behind is an economic issue.
This is the new portal. It correctly links to my mineshaft, meaning I can leave that particular normal-world eyesore hidden completely underground. I was fortunate that I only had to move one portal, and it was user error, not finnicky-game-mechanics error, that caused the misdirect. Blogger isn't so fortunate -- its Javascript:void(0) errors are finnicky nonsense that I refuse to bother with.
Man, this really is a pretty Nether. All that blue sky is a huge bug; on multiplayer 1.6 servers, when you portal to someplace, whatever world you logged into -- Nether or normal -- will be rendered in the distance. (The normal world looks very unusual with Nether skies.) When you travel back to your point of origin, you get disconnected; it's a little aggravating. As pretty as this Nether is, I'm looking forward to a bug fix.
What's this got to do with Minecraft, you ask?
Well, it's eerily similar to the game's portal system. Redstone circuits are a logic puzzle, but they're straightforward in the sense that they're predictable and always follow the same ruleset. (Aside from server restarts -- which can introduce some really unusual bugs into redstone circuitry. Nothing's easy, you know.) Portals, though, are unintuitive and cumbersome things. Here, I'll show you.
You hop into one --
And you end up in the Nether. It's a miserable place, full of angry ghosts, zombie pigmen and unpleasant blocks of all kinds. The most common, netherrack -- that red stone you see everywhere -- has the useful property of staying ablaze if you light it. It's a great component for mob grinders, particularly ones that harvest piggies -- pigs killed by fire drop cooked porkchops, rather than raw ones.
Turn around, and you see this vista. This is honestly the most amazing Nether spawn I've ever seen; it actually feels ominous and terrifying, rather than blocky and annoying. But we're not here to sightsee or to get attacked by angry ghosts, we're here to set up portals.
And here's a pair of portals I built. The reason they're so great is that the Nether's cardinal directions correspond to the normal world's at an 8:1 ratio. For every step you take in the Nether, you travel eight steps in the normal world (though it's a 1:1 match vertically -- which doesn't matter usually). This means that you can travel very quickly by moving through the Nether. However, portals aren't linked. (That's the first unintuitive thing about them.) Rather, when you hop into a portal going either direction, the game searches a certain number of squares in each cardinal direction for a portal in the other world. (That "certain number" is a 256 by 256 square in the Nether or a 2,048 by 2,048 square in the real world.) It checks in a spiral, starting with the square you're at; vertical location seems to be the tiebreaker for two equidistant portals. This means that portals typically bias toward overland travel; this feels intuitive at first, until you try making portals match up. Then it feels lunatic barmy crazy. It only gets worse when you're putting bunches of tightly packed portals to travel vertically, as I'm doing here. Two things can happen in that situation -- the first is that the portal's proximity means that even a single square can change a portal's destination. (You avoid that by giving some cardinal distance between your normal world portals, but it happens sometimes.) The second is that two portals are separated vertically enough that the destination gets thrown off -- and then you have to whip out the old Pythagorean theorem and figure out how far down you gotta bury your portal to make it work. Another frustration is that, when a portal has nowhere to connect to (as your first portal won't), it creates a portal in a seemingly random fashion to connect to. This creates even more unintuitive behavior -- the first time I created a second overland portal, it linked my right back to the same Nether portal. That kind of behavior sets up an expectation -- that portals will create links to each other -- and then dashes it when they don't. It's kind of the definition of unintuitive. Here's the kicker -- because of the semi-random nature of portal placement, you often have to tear down your auto-generated portal to make your placed ones work. The whole thing is a mess of "huh"-inspiring rules!
So here's where the Blogger comparison comes in -- it takes something like 15 or 20 seconds to break down an obsidian block with a diamond pick. When you misplace a portal -- as I did earlier when I got some poorly labeled coordinates mixed up -- you have to break down 10 obsidian squares. It's only like two minutes to break down a portal, but I dread it. It's the most excruciating timesink in the game (though it's nowhere near the worst one). I COULD just rip down one square in a portal and then cheat in the next one, which I don't have a problem doing on the multiplayer server -- but I hate leaving that obsidian up. It looks tacky and it's confusing. On a legitimate server, obsidian's a precious resource, so leaving it behind is an economic issue.
This is the new portal. It correctly links to my mineshaft, meaning I can leave that particular normal-world eyesore hidden completely underground. I was fortunate that I only had to move one portal, and it was user error, not finnicky-game-mechanics error, that caused the misdirect. Blogger isn't so fortunate -- its Javascript:void(0) errors are finnicky nonsense that I refuse to bother with.
Man, this really is a pretty Nether. All that blue sky is a huge bug; on multiplayer 1.6 servers, when you portal to someplace, whatever world you logged into -- Nether or normal -- will be rendered in the distance. (The normal world looks very unusual with Nether skies.) When you travel back to your point of origin, you get disconnected; it's a little aggravating. As pretty as this Nether is, I'm looking forward to a bug fix.
Tuesday, May 31, 2011
Updates, updates
Weeklong delay comes from the absolutely insane update schedule Mojang went through this week. I upgraded, got locked out of both servers I play on, goofed off with 1.6, then downgraded back to 1.5, then got my server upgrade to 1.6 and had to BLARG
I know the game's in beta, but goodness. The up-and-down insanity cost me my cache of screenshots (a hasty deletion coupled with an accidental recycle bin emptying. I know, I know, and my dog ate my homework). In any case, I began doing some redstone work on Dankcraft and realized I had no clue what I was doing. Being ever sensible, I split the difference -- I created a clunky, expensive non-redstone cart-boosting system for ol' Danks, then experimented on a single-player map until I got a redstone system that works.
If you're unfamiliar, here's the deal with making your minecart zoom:
1. Powered rails, the legitimate (read: intended) system to power minecarts, got a significant boost in 1.6. This is because the efficient, but goofy, booster bug -- which was used to power carts previously -- was removed in that patch, and powered rails require a _lot_ of gold.
2. Gold is the second-rarest ore in the game. At the old exchange rate of gold: boost from powered rails, you'd have to turn a continent upside-down to get your minecart to go any significant distance. It wasn't favorable at all, and God forbid if you wanted to go uphill.
So, being the jump-right-in type, I skipped the obvious first step (that is, testing how far powered rails can shoot a minecart up an unpowered incline). In other words, I honestly have no clue how excited I should be about my system.
But, in other news: the system works!
Here's a snap of the heart of the system -- a toggle switch. (A warning to those sensitive to such things -- this redstone wiring is very, very inefficient and awkward. My next pass will tidy up / look to maximize space. I can probably halve the square feet this monster takes up.)
A toggle switch takes up about 36 square meters to do one thing -- whenever you feed a charge of redstone power into it (in this case, via a card going over a pressure plate) its output will switch to "on" or "off."
This is the launch pad. It does two things -- it provides an initial jolt to get the minecart going, and switches that curved rail momentarily to put the cart onto a loop. The powered rail on the loop is always turned on (hence the torches) so the loop would have no end if it weren't for nearly 1,000 square feet of wiring.
Here's a view of the loop. The two raised sections are pressure-plate rails; whenever the cart passes over one, it sends a pulse of redstone charge through redstone lines. The loop is necessary because of how Minecraft adds momentum to moving items -- the more powered rails a minecart passes over, the higher its momentum. A high-momentum minecart will lose speed at a slower rate, which means you can rocket to silly heights by building up momentum in a setup like this.
Here's the first cringe-inducing wiring. The far detector rail -- behind the camera and to the right in this photo -- powers the toggle switch, seen here, via underground wiring that leads to that turned-off torch on the left. This is terrible and inefficient and miserable and you shouldn't do it; this is what happens when you design things as you go. Version 2.0 will be much cleaner, and version 3.0 will be far more compact. (That's the version that'll go on Dankcraft once the server updates to 1.6.)
This is how I track the number of times I've gone in a circle. This 3x3 setup -- of two torches that feedback into themselves -- is a 1-bit memory cell. This cell can hold one piece of data -- "on" or "off." It's "off" now; when you feed a charge into the lit torch closest to the camera, it lights the darkened torch in the center. (That's "on," if you were in suspense still.) To reset the circuit, feed a redstone charge to the center torch while it's lit. When this circuit is "on," it then sends a charge to a logic gate ...
That looks like this. This might be a little confusing, but this logic gate is actually in the "off" state. When the two torches on the stone blocks are depowered, it turns on the darkened torch in the front -- that's "on." One torch is depowered when our memory circuit from above is on; the other is depowered when the toggle switch from above is turned "on." When properly calibrated, this logic gate gets turned "on" after 1 revolution on the loop. It's connected to another memory circuit, which connects to another logic gate, which connects to wiring to switch the track. This chain is only limited by your space and patience -- redstone circuits aren't instant, but this system has a built-in resilience to desynchronization. However, it's space-hungry. (I'm going to try tinkering with a binary system. The upside to that system is that, with similar space, you can record many, many more revolutions; the downside is that it's very complicated and offers a poor return on your space / redstone investment until you're looking at 3+ memory circuit / logic gate combinations.)
When both my memory circuits / logic gates are lit, a final memory circuit provides an uninterrupted flow of power through this redstone ...
To this curved rail, forcing it to change to allow the cart to escape onto the new track.
This track has a third detector rail; when the cart passes over this, it resets all my memory circuits to "off." This also closes the loop again; if I had an odd number of rotations, I'd also want to wire this detector rail into a logic gate shared with the first detector rail. That way, this would reset the toggle switch to the default "off" position to keep the system synced up. (A desynced system won't matter when you're doing an even number of revolutions, but it would add half a revolution to systems designed for an odd number of revolutions. The end result would actually be an additional full revolution, meaning that a desynced three-revolution system would send the rider on four revolutions -- which would generate power while saving space, and may be worth considering if I can get a more-compact track.)
Back to the stars!
This system feels incredibly powerful -- I shot up these 18 points of vertical ascent without breaking a sweat. However, I don't know how good simple powered rails are now, and I didn't bother testing because I'm a tweedle-dum; I'll go back and check that later. This ramp will also get extended up another 70ish meters to see if this system can hit the ceiling of the map. Also, if it's not apparent from my items, this was all legitimately harvested and created. From start to finish -- loading up the map to end of experiment -- was about a 4-hour process. In other words, once there's an established blueprint, any miner worth his or her salt could get this guy up and running from scratch in about 2 hours. There's another system I'm going to try, in which the initial push-button booster triggers a delayed redstone charge circuit on a tiny, 8-square track. It's nowhere near as cool, but it's guaranteed to use far fewer resources and take up a ton less space.
And John's discovered the joy of taking everything in the game underground. Unlike myself -- who was hard at work updating then downdating then upgrading then downgrading -- John was hard at work on his dwarven fortress on our server. Pics, and my Nether portals experiments (they only crash the game half the time!) next time.
Remember, if you want to play with us, just shoot me a message and I'll add you to the whitelist. The IP? It's 50.23.67.132:25617, thanks for asking. (That port at the end -- the :25617 -- is necessary, because we're on a virtual server.)
I know the game's in beta, but goodness. The up-and-down insanity cost me my cache of screenshots (a hasty deletion coupled with an accidental recycle bin emptying. I know, I know, and my dog ate my homework). In any case, I began doing some redstone work on Dankcraft and realized I had no clue what I was doing. Being ever sensible, I split the difference -- I created a clunky, expensive non-redstone cart-boosting system for ol' Danks, then experimented on a single-player map until I got a redstone system that works.
If you're unfamiliar, here's the deal with making your minecart zoom:
1. Powered rails, the legitimate (read: intended) system to power minecarts, got a significant boost in 1.6. This is because the efficient, but goofy, booster bug -- which was used to power carts previously -- was removed in that patch, and powered rails require a _lot_ of gold.
2. Gold is the second-rarest ore in the game. At the old exchange rate of gold: boost from powered rails, you'd have to turn a continent upside-down to get your minecart to go any significant distance. It wasn't favorable at all, and God forbid if you wanted to go uphill.
So, being the jump-right-in type, I skipped the obvious first step (that is, testing how far powered rails can shoot a minecart up an unpowered incline). In other words, I honestly have no clue how excited I should be about my system.
But, in other news: the system works!
Here's a snap of the heart of the system -- a toggle switch. (A warning to those sensitive to such things -- this redstone wiring is very, very inefficient and awkward. My next pass will tidy up / look to maximize space. I can probably halve the square feet this monster takes up.)
A toggle switch takes up about 36 square meters to do one thing -- whenever you feed a charge of redstone power into it (in this case, via a card going over a pressure plate) its output will switch to "on" or "off."
This is the launch pad. It does two things -- it provides an initial jolt to get the minecart going, and switches that curved rail momentarily to put the cart onto a loop. The powered rail on the loop is always turned on (hence the torches) so the loop would have no end if it weren't for nearly 1,000 square feet of wiring.
Here's a view of the loop. The two raised sections are pressure-plate rails; whenever the cart passes over one, it sends a pulse of redstone charge through redstone lines. The loop is necessary because of how Minecraft adds momentum to moving items -- the more powered rails a minecart passes over, the higher its momentum. A high-momentum minecart will lose speed at a slower rate, which means you can rocket to silly heights by building up momentum in a setup like this.
Here's the first cringe-inducing wiring. The far detector rail -- behind the camera and to the right in this photo -- powers the toggle switch, seen here, via underground wiring that leads to that turned-off torch on the left. This is terrible and inefficient and miserable and you shouldn't do it; this is what happens when you design things as you go. Version 2.0 will be much cleaner, and version 3.0 will be far more compact. (That's the version that'll go on Dankcraft once the server updates to 1.6.)
This is how I track the number of times I've gone in a circle. This 3x3 setup -- of two torches that feedback into themselves -- is a 1-bit memory cell. This cell can hold one piece of data -- "on" or "off." It's "off" now; when you feed a charge into the lit torch closest to the camera, it lights the darkened torch in the center. (That's "on," if you were in suspense still.) To reset the circuit, feed a redstone charge to the center torch while it's lit. When this circuit is "on," it then sends a charge to a logic gate ...
That looks like this. This might be a little confusing, but this logic gate is actually in the "off" state. When the two torches on the stone blocks are depowered, it turns on the darkened torch in the front -- that's "on." One torch is depowered when our memory circuit from above is on; the other is depowered when the toggle switch from above is turned "on." When properly calibrated, this logic gate gets turned "on" after 1 revolution on the loop. It's connected to another memory circuit, which connects to another logic gate, which connects to wiring to switch the track. This chain is only limited by your space and patience -- redstone circuits aren't instant, but this system has a built-in resilience to desynchronization. However, it's space-hungry. (I'm going to try tinkering with a binary system. The upside to that system is that, with similar space, you can record many, many more revolutions; the downside is that it's very complicated and offers a poor return on your space / redstone investment until you're looking at 3+ memory circuit / logic gate combinations.)
When both my memory circuits / logic gates are lit, a final memory circuit provides an uninterrupted flow of power through this redstone ...
To this curved rail, forcing it to change to allow the cart to escape onto the new track.
This track has a third detector rail; when the cart passes over this, it resets all my memory circuits to "off." This also closes the loop again; if I had an odd number of rotations, I'd also want to wire this detector rail into a logic gate shared with the first detector rail. That way, this would reset the toggle switch to the default "off" position to keep the system synced up. (A desynced system won't matter when you're doing an even number of revolutions, but it would add half a revolution to systems designed for an odd number of revolutions. The end result would actually be an additional full revolution, meaning that a desynced three-revolution system would send the rider on four revolutions -- which would generate power while saving space, and may be worth considering if I can get a more-compact track.)
Back to the stars!
This system feels incredibly powerful -- I shot up these 18 points of vertical ascent without breaking a sweat. However, I don't know how good simple powered rails are now, and I didn't bother testing because I'm a tweedle-dum; I'll go back and check that later. This ramp will also get extended up another 70ish meters to see if this system can hit the ceiling of the map. Also, if it's not apparent from my items, this was all legitimately harvested and created. From start to finish -- loading up the map to end of experiment -- was about a 4-hour process. In other words, once there's an established blueprint, any miner worth his or her salt could get this guy up and running from scratch in about 2 hours. There's another system I'm going to try, in which the initial push-button booster triggers a delayed redstone charge circuit on a tiny, 8-square track. It's nowhere near as cool, but it's guaranteed to use far fewer resources and take up a ton less space.
And John's discovered the joy of taking everything in the game underground. Unlike myself -- who was hard at work updating then downdating then upgrading then downgrading -- John was hard at work on his dwarven fortress on our server. Pics, and my Nether portals experiments (they only crash the game half the time!) next time.
Remember, if you want to play with us, just shoot me a message and I'll add you to the whitelist. The IP? It's 50.23.67.132:25617, thanks for asking. (That port at the end -- the :25617 -- is necessary, because we're on a virtual server.)
Sunday, May 22, 2011
Added a whitelist
A whitelist is a list of who can and can't jump into my server. I'd left it off before, but I got at least one random today, and really don't want to have to do a restore because someone thinks it's cute to wreck the place up.
SO: If you wanna jump in, feel free, but you'll have to shoot me an email at joe.simmons.ii@gmail.com (the best way), shoot me a chat request over gmail (also good), comment on Facebook (not the best, but I check about 1/day), or leave a comment on the blog (probably the worst, I might not ever see it).
SO: If you wanna jump in, feel free, but you'll have to shoot me an email at joe.simmons.ii@gmail.com (the best way), shoot me a chat request over gmail (also good), comment on Facebook (not the best, but I check about 1/day), or leave a comment on the blog (probably the worst, I might not ever see it).
Saturday, May 21, 2011
Come play, 50.23.67.132:25617
This is my multiplayer server. This is my tower ...
Here's one of my train tracks and a slaad. Nom, slaad, nom.
And that's the storm god. He's made of wool, which means that he's kind of in danger of bursting into flame if there's a storm. Mmm, oversight I guess.
Anyway, IP is 50.23.67.132:25617. (The port is necessary -- enter it exactly as you see there.)
My mines, meows
These are my basic mining supplies -- a diamond pickaxe, several torches (I typically carry about 100), a pail of water (to turn lava squares into harmless obsidian squares) and an iron shovel to quickly clear sand, dirt and gravel. I'm looking for iron, gold, diamond and cobblestone; if you mine correctly, you'll find more than 3 diamonds for every pickaxe you wear out while mining. I'm working on my second full stack, and I never use iron pickaxes. (So why iron shovels? I feel it's the best compromise on speed, durability and rarity of materials.)
This is my workstation and base of operations. The forges are typically in use, either making smooth stone from cobblestone, smelting iron and gold or making glass. These chests are all a little more than half full -- some with tools and building supplies, one with cobblestone, another with animal products, like wool.
This is my very technological elevator. The, eh, boat is the elevator car; that waterfall is the elevator shaft.
Boats are very awkward. Though you couldn't tell which way is forward -- at least I can't, I suppose there may be fine differences in the grain I haven't studied -- the boat not only has a front and a back, but it spins in the direction you're heading. That means every time you hit a current, you're spun to face the direction it's flowing. This becomes very problematic when you're using currents to hold a boat in one place (or when you suddenly hit the top of a waterfall).
Going down the shaft. This shaft is wide enough for the boat to sail into and drop; the water at the bottom keeps the boat (and yours truly) from shattering from the impact. Like I said in my first post, water works oddly in Minecraft.
This is the base of the falls. It's about a 100-meter drop; when I want to go back up, I hop in my boat, sail into the waterfall and let the boat's buoyancy do the rest. About 4 seconds later, I'm at the top of the map again.
I want to love minecarts, but they're horrible. Without glitched boosters -- which will be fixed next week with patch 1.6 -- the maximum speed is slightly less than double walking speed. It's hard to recoup the time spent laying the mine tracks. Granted, you're constantly walking about 10 mph, so you move at a good clip. Still, I'm covering a lot of ground. My next mine in this world will be using a zig-zag pattern that minimizes walking distances.
To get an idea of how large my mines are, this minetrack starts at x=185 ...
and ends at -945, or 1130 meters -- just over 1 kilometer. This branch extends another kilometer, along with three perpendicular branches that extend between 700 and 800 meters each.
The branches aren't terribly exciting, unfortunately. They sometimes break into larger caves, which are typically confusing deathtraps with plenty of ores. (Ores aren't more likely to spawn in caves, it's just that you see a lot of squares very quickly -- law of averages and all.) Once I got tired of walking half a mile to begin mining, I started with new main branches and perpendicular branches. I've got two more main branches and about 12 side ones; in total, it's about 15 kilometers of mine shafts.
Subscribe to:
Comments (Atom)