Minecraft Forums

This mod seems to be really unbalanced.

I'm all for seeds doing more than piling up in chests, but a lot of these recipes make little to no sense to me. For example, slime balls don't need a recipe. They can easily be acquired naturally from slimes; so much so that they can easily pile up in chests almost as much as seeds do. Other recipes - like vines, lily-pads, or grass - are ludicrous considering that shears and bonemeal are capable of getting you these items.

I was disappointed to see that you don't get to watch the buildings being made

Quote from Rawsome83

Bug name: (Overlooked?) Non-stackable food.
Details: More of a suggestion rather than bug, but it looks like it's been overlooked since the stackable food feature was introduced.
There is one foodstuff that don't stack: Mushroom Stew. Any reason why this doesn't stack? It's pretty annoying when all food is stackable, but that one foodstuff isn't.

That was the case in 1.8 as well - I don't think it's a bug (after all, it provides a lot of hunger).

Welcome to the internet, kids

Quote from Birdmanul

Bug name: Redstone wire connection bug
Details: Redstone does not detect when redstone powered items are adjacent while it does detect repeaters.
System: AMD 64 x2 dual core 2.6 ghz, 4 gb ram, nvidia 9600gt, windows 7
Proof:

Redstone, for as a long as I remember, worked this way with literally EVERYTHING. A few updates ago, though, Jens changed the rules to make an exception for repeaters that causes redstone to snap to the back (a single piece turns into a straight piece pointing into the repeater, for instance).

If this were a bug, then why would Jens make a specific exception instead of changing everything?

It seems really odd to me that none of the giant mushroom blocks are in the Creative inventory, especially considering they're actually blocks and not items.

Who else wants these added to Creative by the next update?

**Because I've been asked more than once, I'll be releasing the save once the build is complete, so once the [WIP] is gone, you'll know!**

A few months back I began planning this project. At first this consisted of looking up photos of the existing ruins, because I had no knowledge of any reconstructions whatsoever. Once I found artist renderings, however, I instantly became interested in putting it into Minecraft.



Using a diagram of the ruins and Paint.net, I organized the layout of the ruins to correspond to blocks (thank you, pixel grid <3) by alternating between two different colors. I divided this work into two parts: the perimeter walls (in purple and teal), and everything else (in blue and green).



Of course, as I built more and more of the ruins, I changed little things here and there to better reflect the artistic rendition and to smooth out portions that were difficult to transfer from the diagram into block form (I was basically winging it to begin with, after all).


UPDATE 1

In doing some skimming through my research books (of which I need to get more, which shouldn't be a problem), I've come to realize I may have been a bit hasty with construction. It seems somewhat of an overhaul may be in order, to an extent.

For one, I'm going to need to re-design the kivas (pictures below of my first attempt) with the new information I've gotten, and will continue to refine things as my research progresses. The test I did used the layout of the largest Great Kiva in the site, and it turned out quite nicely, considering the fact that I made it an 18x18 circle rather than a 21x21 circle as it is in my build. I think the actual size will be able to accommodate the new design quite well!

Another possible re-design will be the orientation of the buildings. I'll need to check it again before doing so, of course (don't want to tear things down without reason), but it's a possibility at this point.
Looks like I got it right already! *PHEW*

Other than that, further research will clue me in to how the rooms and buildings are constructed, used, etc. as well as their contents. If need be, I may have to increase the size of the building by a small percentage to accommodate various issues that may arise in my research.

UPDATE 2

I used a layout chart to make a few terraced rooms to see how everything fit together. The chart I used was for Hopi pueblos, and I'll be comparing it to the Anasazi style to make the necessary changes, but I wanted a place to start from. As you'll see in the pictures below, I didn't add much to the rooms - just ladders between floors and a couple furnaces with chimneys. I would have put in the sleeping mats and storage chests, but this is just a preliminary version.

The more I work on this, the more I want to be able to stack different kinds of slabs :tongue.gif: Not to mention having more types of slabs and stairs!

SEMI-UPDATE

The work I've done in the previous update has forced me to revise the flooring throughout the complex. Namely, every part of the floor that is not in a doorway will be replaced with sandstone slabs in order to both create the effect of stepping through the doorways (as they seem to be in the ruins) and to make the rooms have less of a cramped feeling to them (that half of a block can have a very strong effect). Also, provided I'll be able to use them in the future, sandstone stairs will be used in doorways that are offset in order to retain the stepping effect. If so, all the sand blocks on the bottom floor may have to be replaced with sandstone. Maybe it'll look good normally, but I don't know yet xD



Here's the progress so far:

_________

Initial stage (2/1/11-2/14/11):
_________

Kiva stage (2/15/11-2/19/11):
_________

Right after sandstone half-blocks were added (I was so happy xD) (2/22/11):
_________

**exceedingly long break**

_________

Further construction (7/26/11-7/27/11):
_________

Structural lattices completed (7/27/11-7/28/11):
_________

Skeletal reconfiguration and roofing

East wing (7/28/11-8/3/11):

West wing (7/29/11-8/4/11):

South wing (7/29/11-8/3/11):

North wing (7/29/11-7/30/11):
__________

Farmland (8/1/11-9/15/11):
__________

Interior walling and flooring (8/2/11-):
__________

New Kiva design test (8/9/11)

Before sandstone casing (ignore the stair texture - it's a placeholder for the material that would have been used at the site):
After sandstone casing:
__________

Terraced pueblo test (8/10/11):
__________

Current state (as of 9/15/11)

After seeing the utility of glass panes, they could make this little invention of yours even better!

Simply place them above both the plates and pistons so that they center the player between the two as is required, but without player error :biggrin.gif:

I'd love to know why people like the Bashcraft video - it's just a dunce character being annoying for a few minutes. The only humorous thing in it to me is a visual here and there.

My vote goes to FyreUK - they never disappoint :biggrin.gif: The Last Minecraft deserves love, too

Bashcraft deserves nothing. It's unfunny and annoying.

I was writing up a response to Weceo's thread about "True Redstone Mechanics" http://www.minecraft...tone-mechanics/ when I got really into it and started writing a comprehensive explanation of my understanding of Redstone Signal Transmission. For reasons having nothing at all to do with self-aggrandizement, I decided that my response would be better of as the topic of its own thread (easier to find and link to).

This is a "brief" summary of my understanding of "Redstone Theory". I'm sure it would benefit from Images, but I don't feel like doing that just yet. Probably at some point, but for now here are just the words.

I view redstone interactions as having 4 main interactions:

-Emission of Charge (Also called "Strongly Powered")
-Conduction of Charge (Wiring, with all its mysterious connections)
-Reception of Charge (Powered block)
-Detection of Charge (any Device)

Emission: Blocks which "Emit" charge cause all redstone wire adjacent to them (including above and below) to light up. Redstone Torches are the most prominent example of this, but Solid Blocks can become "Emitters" as well if they have a torch beneath them, have a repeater pointing into them, or serve as the anchor-points for a Lever, Button, Pressure-Plate or Detector Rail. Those last 4 "Input devices" are also themselves Emitters, and so in combination with their anchor-block form a two-block chunk of emissive material.

Conduction: Redstone wire. That's what it does. It conducts charge coming from an Emitter out to 15 blocks of distance. Redstone wire will automatically link up and form chains of conduction with wire adjacent to it and any wire which is "adjacent" up or down a step. Conduction "up a step" can be broken by any solid block interfering diagonally, which piston-based logic makes heavy use of. In addition to connecting to itself, Redstone Wire will "connect" to torches and input-devices (which is pointless since they are emitters anyways and in any case can't receive signals directly from wire) and will also connect to the input and output of a Repeater (but not its sides). Non-solid blocks such as Glass, Glowstone, and Pistons will not interfere with its connectivity up/down stairs, although Glowstone will appear to do so visually (as glass used to). For unknown reasons, when Wire is placed on a "non-solid" block like Glowstone, it will not conduct charge "downstairs", leading to a Diode effect.

Reception: A block which is receiving Redstone charge is considered "Powered". All solid blocks which carry Redstone Wire on top of them are will "Receive" charge from that wire. Additionally, any solid block which has straight piece of redstone pointing directly at it is now a "Receiver" (Corner-wire doesn't work). Unconnected redstone (a single tile of it represented by a dot) "points" to ALL adjacent blocks, and can make them "Receivers". Placing or removing blocks to modify wire-connectivity can change which blocks adjacent to wire are receptive to its signal. Although "Receiver" blocks will not transmit charge to adjacent wire, Solid "Emitter" blocks are "Receivers" in addition to their emission of charge.

Detection: Redstone controlled devices (doors, pistons, torches) must detect whether a nearby block is receiving charge or not in order to respond to it. For the most part, they will respond to a "Receiver" in ANY direction, or to any signal which would make themselves into a receiver. Many devices have directionally specific detection rules. Redstone Torches will only react to the block they are anchored to. Repeaters will react only to blocks at their input-end (including bent wire). Pistons will not respond to signals coming in from their "pusher" direction, but WILL react to charge that is 1 block above what is directly adjacent (even in the pusher direction). This "+1 detection range" to blocks above them means that pistons can actually respond to charge that is beyond their UPDATE detection range, and so will often fail to respond normally to charge above them unless prompted by another component (I'm not going to go deeply into Update Theory though, just know that pistons can exhibit interactions beyond the "classic" rules of redstone).
Solid Blocks like Dispensers and Lamps when receiving a signal will often trigger their neighbors as well, forming a + shape of activation. This is because when they receive the signal from a wire or repeater, all of their neighbors detect THEM as a signal-source, because they now act as a "Receiver Block". Pistons avoid this adjacent interaction by being transparent blocks, and thus cannot become "receivers" that trigger their neighbors.


In Summary: There are 4 different kinds of block-interaction which transmit a Redstone Signal. Emission which lights up wires, Conduction which transmits it along wires, Reception which creates a target block that can be reacted to, and Detection where a block reacts to a neighboring receiver.

Most signals go Emitter->Conductor->Receiver->Detector, but the fact that all Emitters act as Receivers as well means that you can bypass the conductor step entirely and make Emitter->Detector chains. This is the principle by which torch-stacks work.

------

I hope that you will find this article helpful in understanding the theory behind redstone connectivity and allow you to plan out even more elaborate circuits than before. If you liked this, please comment/rate/subscribe and...um...wait, this isn't youtube. Anyways, If I'm sufficiently motivated, I'll make explanatory diagrams for the article to succinctly illustrate the properties explained. Stuff like why placing blocks before/after a repeater gives it longer range and showing the total area affected by an emitter. Good stuff like that.

Here we go again.....

As always... Up & Down, Any Height, In a Car, SMP Compatible Piston Elevators
But these also have No Visible Redstone and the "Ultimate" Call Then Go control system

**Updated** New Mk7+ with Piston Doors, Arrival Chimes and Call Indicators
**Updated Again** New 1.8-friendly World Save which now includes a "Tutorial Zone"


Mk6: 1x1 car, 8x9 Footprint
Mk7: 2x1 car 10x12 Footprint
Mk7+ 2x1 car 10x13 Footprint, Piston Doors, Arrival Chimes, Call Indicators


Updated World Download: 1.8 friendly World Save
Contains all my elevators so far, and the stuff from the tutorials.. go, look, learn... copy if you want.

IGN gave this third place in their minecraft youtube video contest!

Now available for download!

The Duomo in Florence, aka Santa Maria del Fiore, as seen IRL and in Assassin's Creed 2. I built this originally in SMP with my buddy Marfa (who is helping here too) at 1:2 scale. Not quite satisfied, I am redoing it in 1:1, with the ground level at 10 blocks above the void. Current status posted here, otherwise it's all in order, with the newest pics at the bottom



The original: (and its thread )

Outside done:


Inside Done:






This is using a slightly modified version of Steelfeather's AssassinCraft/Renaissance texture pack. I wish she'd hurry up with her ongoing update so I can be using (and modifying) the latest version :wink.gif:

*EDIT* shrunk old WIP shots and moved the first two to my second post in the thread

It seems zombies are attracted to any wooden door, so I set one up outside my house. Just the door, no walls no nothing. Zombies flock to it like moths to a light. Next day I place another door outside, but this time with 2 trap doors on either side connected with a redstone circuit to my house with a switch. I just look out the window, push the button, and they fall into a small 3 deep put. Its amazing how many will fit in the same hole. Then when the sun comes up I head out with my sword and wail on them for a while, I think the sunlight took out a few too. Now if i can find some lava, I will set up a mob trap with a sign. The zombie meat is good to heal dogs.

In this thread on sending signals between universes fredklein had the brilliant idea of using my portal ejector to push a player not into a pit of fiery death, but onto a pressure plate to send a signal.

Essentially this lets you use players, including AFK ones, as a way of transmitting data between the Overworld and the Nether.

That gave me the idea for how to build an Interdimensional Portal Clock, using 4 portals and 2 portal ejectors:

Portal A & B on earth link to portal 1 in the nether.

Portal 1 & 2 in the nether link to portal A on earth.

On earth a player materializes in portal A and gets ejected. They fall on a plate, which activates a piston that pushes them into portal B. Portal B sends them to Portal 1.

In the nether a player materializes in portal 1 and gets ejected. They fall on a plate, which activates a piston that pushes them into portal 2. Portal 2 sends them to portal A on earth.

Repeat cycle forever.

This allows you to make a clock that generates signals by shuffling a player endlessly back and forth between the two worlds.

EDIT: Here are the pics! The earth side and nether side needed slightly different designs. I'll explain exactly what's going on in a new post below.













EDIT: P.S. This doesn't have to be used as a clock, constantly shuffling the player back and forth. You could keep the player in one dimension for as long as you want until a signal activates the piston to send them to the other dimension. You could use this to send messages between computers in each world.

EDIT 2:

Check out the TRANSWORLD CONDUIT! This design allows you to automatically send players between different places on Earth through the nether.

Today I was thinking about death in Minecraft. Although it's supposed to be bad it's also a form of limited teleportation. And that can be useful.

I did some tests and discovered that if you build a solid pillar on your spawn point you'll always spawn on the top. If you create a hole in this pillar you'll spawn in that gap instead.

Basically, you can control the altitude you respawn at by determining what y coordinate isn't blocked at your spawn point.

If you made a tower of pistons, and retracted select ones two at a time, you basically can make an elevator that lets players teleport to a precise and changeable altitude at their spawn. By dying.

Here's a basic illustration. It doesn't have the circuitry to actually control it, but that's just a bunch of simple NOT gates. The piston heads are extended into the spawn points x & z coordinates. If all piston heads are extended you'll appear on top of the tower after respawning. If you retract any two of them, you'll appear in that gap instead.



Obviously dying isn't a very practical way to travel, since you lose your xp and items. But it could be an interesting part of a challenge map. You'd have to kill yourself to reach otherwise inaccessible areas.

It could be a way of forcing the player to give up any tools and materials they acquired in the last area, sort of like the emancipation fields in Portal. Or you could use the 5 minute despawn time of items to set up a race against the clock, forcing you to complete an objective with 5 minutes, die again, and return next to your items before they vanish.

And unlike a regular elevator you can reach it from anywhere in the game. A challenge map might have you battle and solve puzzles across a big dungeon, at the end have you flip a switch to activate the next level the elevator leads to (by retracting just the two pistons for that level), then jump into lava to instantly teleport there.

EDIT: I've made some interesting discoveries that might allow horizontal teleportation too. Read posts #17 & #18 below.

Well, hello there!
I just wanted to share with you my latest version of the G line, the first version to go public.
This is the most compact minecart station I've ever seen featuring:
Separate arrival and departure platforms
Cart availability indicator
Cart calling system
2 Automatic PEZ cart dispensers holding 8 carts each.
Empty cart detector
and a cart overflow system.

All that fitting inside 3 plots of 9x9x9

Video:
Schematics:
http://db.tt/0bmqPRD

You all know that joke when somebody is showing off their brand new Redstone Computer and somebody asks: "Can it run Minecraft?" You have a chuckle at how clever you are while people variously chime in "LOL" or "It's impossible numbskull!!!".

I was one of the people in the latter group, continuously annoyed by people who don't understand the orders of magnitude of difference in computing power between a Redstone Computer (they are on par with 1930's technology) and a modern computer. After a fresh session of apoplectic rage however, I began to ponder: "What sort of program could you feasibly run on a Redstone Computer that would still retain the essence of Minecraft?" And thus a dream was born.

That was 3 months ago. After months of planning and sporadic construction work, I have finally completed this great and grand project which I intend to be my "Magnum Opus". I have made "Minecraft in Minecraft", or "Mini-Minecraft".

Features:
-2D Graphics!
-8x8 Pixel Screen
-64 bits of Landscape Data
-Blinking Lights!
-Directional Control Interface
-Solid Terrain
-Gravity
-Moderate Signal Latency (4,000ms)
-Color-Coded Circuitry!

And now to show that I'm not just full of ****, I give you screenshots:

Display viewed from control-box

Here you're staring at the crazed mish-mash of all the terrain created/destroyed in my debugging attempts. Player position is not visible, since that square is currently OFF in its blink-cycle.

Display Side-View

The orange and pink lines are carrying the Vertical Position data from its register to the display. The sharp-eyed will notice that there is a torch lit on right side of the middle pink line. That's the current height of the player. I placed those torches there for debugging purposes when I was having problems with data corruption.

High view of back of Display

Light and Dark Green helixes carry new data to the Display, one Bit per column. Purple lines in the background carry the "Write" command to an individual Row to update its D Flip-Flops when a block there is placed or removed.

Guts of the machine

Here you see all the parts of the machine that do the actual calculations. Underneath the green lines is the 64 bits of RAM (the green lines are its input) that store the terrain information for calculations. In Blue at the far end are the Horizontal positional controls which both keep track of the player's horizontal position and govern interaction with blocks. The Gray stuff to the left is the circuitry needed for the "Jump" command, and underneath it is the rest of the Vertical positional controls.

Control-Bits

Here you can see 4 of the 9 Control-Bits that govern the machine. Combining "Shift Up" with "Place/Remove Block" results in the block above your current position toggling between ON and OFF. Note the long chains of Repeaters on some lines: It was necessary to introduce carefully tuned signal-delays to ensure that the Positional/Terrain actions don't happen until they have already been pointed to the right location. Getting the signal-delays synchronized like this took many hours of frustrating debugging even after I thought I was "95% done!". Well, I'm done NOW.

Wires Leading to Command Decoder

Here you see the wires from the Control-Box going down to be converted into signals sent to the Control-Bits that actually govern the machine. Pink/Orange are Down/Up and Light Blue/Teal are Left/Right. They split into 2 lines in the decoder: one for Movement, the other for Block manipulation. The Red line is in charge of triggering an extra "Move Downward" command after every action you perform in order to simulate gravity. A solid block underneath you will prevent this downward motion.

Control Panel

Here are the 5 controls that will let you move through the world. 4 directional controls and a switch to toggle between Movement and Block Placement/Removal. It's humbling to realize just how much work is required to convert a simple button-press into an executable command. It takes about 4 seconds for the effects of a button-press to be visible on the screen.

So, that's the sneak-preview of my machine.
I'm calling this a "Sneak Preview" because the real presentation is going to be the Youtube Video I'm planning on making which will show this thing in action, accompanied by mad laughter and melodrama and will get its own dedicated thread. My intention is for that video to go viral and explode the internets.

Oh, and also I'd like to give thanks to Conundromer for deciding not to beat me to completion of this project while I was on vacation, even though he probably could have if he'd set his mind to it(he's good).

If you think that "Minecraft in Minecraft" is totally awesome then feel free to +1 my Reputation. The higher it gets, the sooner my video comes out!

Edit: The video is out as of Aug 31st.
See this thread:http://www.minecraftforum.net/topic/590096-hans-lemurson-makes-minecraft-in-minecraft/

We will be remaking the city of Balur's Gate, from the popular PC game "Baldur's Gate" of 1998. We started September 7th, 2011.

One of the largest buildings, the Hall|High House of Wonders:


The ingame map taken from Baldur's Gate (the game [you lost]):


Please support our, already high, enthusiasm by liking and sharing our project minecraft page with your friends, and leaving comments and suggestions.

Also, if you would like to build and submit some of the smaller areas, just submit it here telling us which house it is (or about where it is).
Remember: please keep it as close to the original as possible, and try to keep it to scale (based off the height of a person). A good indicator of scale is the size of doors.
Another thing, we will be doing only 90 degrees on most things, so don't worry about doing weird angled buildings and such.

This video is outdated but the elevator still works the same way.

A fully automatic 3-Floor 2x2 Piston Elevator created by modifying ThisHampsterman's Design.

V.2 Was inspired after seeing DaftasBrush's Elevators.

Map Download V.2.1 + Tutorial
Final Build, including explanations of how it works. Made it as compact as I could, final dimensions are 9x9x31. It gives access to 3 3-high floors with the elevator cab accessible from any floor no matter where it is.