Wew! After a lot of fighting with Sony Vegas, I finally got this thing uploaded. I had to upload a few segments and I used the YT video editor to splice them together to fix Vegas not rendering some clips, but it works!
For every new episode that goes up, I'll swap out the youtube embed with that one!
I recently had an idea to start a series about starting in Alpha minecraft, and ending in the current build of minecraft, updating periodically throughout the series. The main goal would to adapt your play style and actions according to the new features (and bugs!) that hit you every time you update.
I've always wanted to do a lets play, but could never really think of a unique idea to make mine different from others, but still fun for me. As I was browsing the old minecraft version history, it hit me: None of the lets players I've watched have ever really kept their old worlds. I thought, wouldn't it be a fun idea to have a world start in Alpha and and play through, update, and continue and keep the same world. A couple friends said that was actually a really neat idea so off I went. I began in Alpha 1.0.4, however due to the new launcher really not working well with the sound loader, I had to unfortunately push all the way to alpha 1.1.2.
So, with that, is this mashed up goodness of a pilot episode for Minecraft Evolution.
Now with twitch streaming inbetween epiodes! Join me at http://twitch.tv/mprock3 (Live status will be in the thread title!)
The most up to date episode will always be shown! Swear Level: One outburst!
This is a wonderful mod for map makers and servers who like to add custom things. Is it possible to link this in the main post? It's the wiki page showing all NBT tags for minecraft.
It's the correct version, both minecraft and modloader. It's an intermittent problem I've seen on random modloader versions since 1.0. I'll see if there's any relation between JRE 7 and JRE 6, and I'll see what MC patcher can do, although not sure if it will have any effect.
I've both manually installed and used magic launcher in case you were wondering.
I've been trying to get the modloader to work so I can use the X-ray mod, but everytime I go to delete the META-INF in the rar file, It either says "Not Implemented" (7Zip) Or says it's corrupted (WinRar). I also don't know how to add the modloader, don't know what files to add, and where to put them. I;ve tried to add files to the .minecraft rar, but I get the same "Not implemented" message, any help?
Make sure your client hasn't been ran while the archive is open. if so, reopen the archive.
Onto my stack trace, I'm not sure what's causing this, i've seen others post similar ones, but never acknowledged.
Exception in thread "Thread-5" java.lang.VerifyError: (class: alj, method: c signature: (Lxd;IIILjava/util/Random;)V) Incompatible argumentto function
at pb.<clinit>(SourceFile:138)
at qa.<init>(SourceFile:14)
at net.minecraft.client.Minecraft.<init>(SourceFile:173)
at n.<init>(SourceFile:33)
at net.minecraft.client.MinecraftApplet.init(SourceFile:33)
at net.minecraft.Launcher.replace(Launcher.java:134)
at net.minecraft.Launcher$1.run(Launcher.java:78)
There's no external mods installed, nor anything else modloader manually added into the clean jar.
I was working on a generic passive system when a idea hit me. We waste a ton of space, time and effort channeling mobs away to a centralized point, killing them and dragging all the loot somewhere. This is not only slow, but inefficient as well. Mobs can clog up grinders, and the longer they're alive, the less loot you get.
This brings me to wasted space. Spawning pads are large areas, with a lot of wasted space under them. Why not, instead of channeling mobs down a long chute or up an elevator, kill them right under the pads they spawn at? Not only does this create 100% clog free systems, it creates a very quick and efficient killing system. Since they all die relatively quick after spawning, with little travel time, less chance of despawning, and even more important, the quicker a new mob can take its place.
Keep in mind, this is a first revision prototype. I'm not even sure if it's been done before or not It's not yet complete, but the mechanics for each mob is pretty much the same. There is, however, an unfortunate downside to this. Stacking pad rooms becomes very, time consuming. There is a very large vertical space in which the system needs to use. Also, the loot chutes CANNOT be at the pads, thus, stacking isn't recommended. In all reality however, a legitimate world wouldn't need that many pads to begin with, so I'm not that worried.
Here is some screenshots of it in sections.
The top layer is most obvious, the grassy spawning pads for passives.
There is a 3x2 pad over top the canal to force mobs into a 2x2 area, and to stop pigs and chickens from leaking into the bigger mob canals. I haven't tested this in actual conditions, just with the spawn mob command in SPC. I've had no mishaps so far, but that doesn't mean it's perfect. There is a two block area under the pads in which water flows into diagonally. This filters out pigs and chicken first, into one of eight pig grinders. Chickens continue down the chute to a chicken processor.
Here is a cross section of the whole thing. It shows all the layers currently.
Here is the pig/chicken sorter. Notice the faint outline of the spawning pads above. Remember, this is only one block high when under the pads.
That leads them into this secondary canal which forces pigs into lava, and chickens down. Keep in mind, chickens WILL hit the lava once, but will not die. I currently don't have a fix for this, but since 25/25 chickens lived, I sought no reason to fix it (helps kill them faster later).
This is all I have so far, my plans are to wrap cows and sheep around the outer pads and utilize the rest of the area inside the pads. It's a very possible idea I'll implement a switch to send sheep to a holding pen for dye. I'll update the thread when I've completed this. In the mean time, try this out yourself, see what improvements/redesigns you can come up with.
P.S. Yes, this a redstone test world, so no, this was not built legitimately. I have no reason to believe however, this could not just as easily be built legitimately however.
So I was wondering if there were any quirks or limitations to pistons like there are to mine cart rails, thus I went and did some tests.
Pistons follow different rules according to the piston used, and the actions taking place.
Here's a set up I did, of four sticky pistons in the four compass directions. To our left, is north, to our right is south, etc.
Each of the pistons are wired to go off on the same tick as one another, so any bias will be in the redstone itself (still proving valid behaviors since all pistons are subject to redstone behaviors anyway).
When all four sticky pistons are set on, and retracted, the northern piston always gets priority over pulling the block it's attached too.
By removing the pistons, I've noticed that pulling rules favor a north west south east rule (nwse)
However, when testing out the behaviors of normal pistons, I found an entirely different priority pattern of south north east west (snew).
Continuing the snew pattern:
Even though the south piston had to push two blocks, and the north piston had no work, south still was prioritized:
In the case of piston vs piston (I'm not sure where this will be practical, but I decided to do it anyway)
It once again follows the NWSE rule.
Vertical pistons facing downwards will always be priority over upward facing ones.
However, upward facing sticky pistons will always gain priority in pulling the block between the two.
Sticky pistons relate with the following objects as follows:
They will break cacti upon extending if right next to one.
Normal blocks are pulled, anything redstone related is left alone. Doors, torches and signs are untouched, however, rails and trap doors are pulled. Trapdoors are completely functional after being pulled, however, if you push them, they will break.
Rails cannot be placed on pistons by any means, even pushing them onto a piston will break them.
Rails pushed by pistons will reorient, but the set up below will break upon retracting:
That's all I've had thoughts on testing, and some of this you already knew. If you have any ideas, or anything to contribute, that would be great!
So much for getting a release out soon, I can't get it to work right after injecting into the jar for testing.
Some duplicate entry error in which I can't for the life of me find out what's causing it in the RenderGuard.class. I'll work on this, and get it out ASAP. If I'm too late, I'll wait untill MCP 2.8 comes out after Minecraft 1.3 is released. However, if I can't make any headway, I'll start working on better zombies/skeletons mod.
0
I'll be streaming for two hours if all goes well over at twitch.tv/mprock3
0
For every new episode that goes up, I'll swap out the youtube embed with that one!
1
I recently had an idea to start a series about starting in Alpha minecraft, and ending in the current build of minecraft, updating periodically throughout the series. The main goal would to adapt your play style and actions according to the new features (and bugs!) that hit you every time you update.
I've always wanted to do a lets play, but could never really think of a unique idea to make mine different from others, but still fun for me. As I was browsing the old minecraft version history, it hit me: None of the lets players I've watched have ever really kept their old worlds. I thought, wouldn't it be a fun idea to have a world start in Alpha and and play through, update, and continue and keep the same world. A couple friends said that was actually a really neat idea so off I went. I began in Alpha 1.0.4, however due to the new launcher really not working well with the sound loader, I had to unfortunately push all the way to alpha 1.1.2.
So, with that, is this mashed up goodness of a pilot episode for Minecraft Evolution.
Now with twitch streaming inbetween epiodes! Join me at http://twitch.tv/mprock3 (Live status will be in the thread title!)
The most up to date episode will always be shown! Swear Level: One outburst!
0
0
0
0
Not the most wonderful of video makers, but it gets the point across of what it's capable of.
1
0
I've both manually installed and used magic launcher in case you were wondering.
0
Make sure your client hasn't been ran while the archive is open. if so, reopen the archive.
Onto my stack trace, I'm not sure what's causing this, i've seen others post similar ones, but never acknowledged.
There's no external mods installed, nor anything else modloader manually added into the clean jar.
0
This brings me to wasted space. Spawning pads are large areas, with a lot of wasted space under them. Why not, instead of channeling mobs down a long chute or up an elevator, kill them right under the pads they spawn at? Not only does this create 100% clog free systems, it creates a very quick and efficient killing system. Since they all die relatively quick after spawning, with little travel time, less chance of despawning, and even more important, the quicker a new mob can take its place.
Keep in mind, this is a first revision prototype. I'm not even sure if it's been done before or not It's not yet complete, but the mechanics for each mob is pretty much the same. There is, however, an unfortunate downside to this. Stacking pad rooms becomes very, time consuming. There is a very large vertical space in which the system needs to use. Also, the loot chutes CANNOT be at the pads, thus, stacking isn't recommended. In all reality however, a legitimate world wouldn't need that many pads to begin with, so I'm not that worried.
Here is some screenshots of it in sections.
The top layer is most obvious, the grassy spawning pads for passives.
There is a 3x2 pad over top the canal to force mobs into a 2x2 area, and to stop pigs and chickens from leaking into the bigger mob canals. I haven't tested this in actual conditions, just with the spawn mob command in SPC. I've had no mishaps so far, but that doesn't mean it's perfect. There is a two block area under the pads in which water flows into diagonally. This filters out pigs and chicken first, into one of eight pig grinders. Chickens continue down the chute to a chicken processor.
Here is a cross section of the whole thing. It shows all the layers currently.
Here is the pig/chicken sorter. Notice the faint outline of the spawning pads above. Remember, this is only one block high when under the pads.
That leads them into this secondary canal which forces pigs into lava, and chickens down. Keep in mind, chickens WILL hit the lava once, but will not die. I currently don't have a fix for this, but since 25/25 chickens lived, I sought no reason to fix it (helps kill them faster later).
This is all I have so far, my plans are to wrap cows and sheep around the outer pads and utilize the rest of the area inside the pads. It's a very possible idea I'll implement a switch to send sheep to a holding pen for dye. I'll update the thread when I've completed this. In the mean time, try this out yourself, see what improvements/redesigns you can come up with.
The entire album can be found here: http://mprock3.imgur.com/passive_mob_system
P.S. Yes, this a redstone test world, so no, this was not built legitimately. I have no reason to believe however, this could not just as easily be built legitimately however.
0
1
Pistons follow different rules according to the piston used, and the actions taking place.
Here's a set up I did, of four sticky pistons in the four compass directions. To our left, is north, to our right is south, etc.
Each of the pistons are wired to go off on the same tick as one another, so any bias will be in the redstone itself (still proving valid behaviors since all pistons are subject to redstone behaviors anyway).
When all four sticky pistons are set on, and retracted, the northern piston always gets priority over pulling the block it's attached too.
By removing the pistons, I've noticed that pulling rules favor a north west south east rule (nwse)
However, when testing out the behaviors of normal pistons, I found an entirely different priority pattern of south north east west (snew).
Continuing the snew pattern:
Even though the south piston had to push two blocks, and the north piston had no work, south still was prioritized:
In the case of piston vs piston (I'm not sure where this will be practical, but I decided to do it anyway)
It once again follows the NWSE rule.
Vertical pistons facing downwards will always be priority over upward facing ones.
However, upward facing sticky pistons will always gain priority in pulling the block between the two.
Sticky pistons relate with the following objects as follows:
They will break cacti upon extending if right next to one.
Normal blocks are pulled, anything redstone related is left alone. Doors, torches and signs are untouched, however, rails and trap doors are pulled. Trapdoors are completely functional after being pulled, however, if you push them, they will break.
Rails cannot be placed on pistons by any means, even pushing them onto a piston will break them.
Rails pushed by pistons will reorient, but the set up below will break upon retracting:
That's all I've had thoughts on testing, and some of this you already knew. If you have any ideas, or anything to contribute, that would be great!
the entire gallery (not too many more images) can be found here:
http://mprock3.imgur.com/piston_logic
0
http://download.oracle.com/javase/tutor ... index.html
I won't humor you with simple hello worlds, since you do code in VB already.
These are things you need to know before you even think about Minecraft mods.
0
Some duplicate entry error in which I can't for the life of me find out what's causing it in the RenderGuard.class. I'll work on this, and get it out ASAP. If I'm too late, I'll wait untill MCP 2.8 comes out after Minecraft 1.3 is released. However, if I can't make any headway, I'll start working on better zombies/skeletons mod.