[1.7.2] How to place a torch or door on a generated structure

[MrMinecraftGoodoo]

I am trying to generate a structure and can't figure out how to add a torch or door to a structure I am generating. I have used different methods, metadata, and flags and nothing seems to work, Any help please?

[jabelar]

Hi.  I think I just ran into a very similar problem -- I was trying to place vines as part of a structure generation (instead of being placed as an item or during world generation).  I'm not sure if your problem has the same cause, but here is how I solved my problem.

 

Basically, there are block types (such as torches, doors, vines, etc.) that have a direction -- they get placed such that they seem to be attached to other blocks around them.  I believe in most of these cases (at least it was true with vines) that you need to assign metadata to the block to indicate the direction.  If you don't assign metadata then it will default to 0 and won't render (I'm not sure if it is actually placed, but certainly wasn't visible).

 

There are actually two different setBlock() methods.  One only takes the position and another takes metadata as well.  So for me the solution was to use the right method, and furthermore assign the right metadata.  Here is my code for creating vines that surround a pillar.  Basically it checks in each direction to ensure the space is free, and then places the vines but does it with different metadata depending on which side I want it to display attached to.

   	        // add vines all around
    	    if(worldObj.isAirBlock(xCoord+1, yCoord , zCoord))
    	    {
    	        worldObj.setBlock(xCoord+1, yCoord, zCoord, MagicBeans.blockMagicBeansVine, 2, 2);	    	        
    	    }   		
    	    if(worldObj.isAirBlock(xCoord-1, yCoord , zCoord))
    	    {
    	        worldObj.setBlock(xCoord-1, yCoord, zCoord, MagicBeans.blockMagicBeansVine, 8, 2);	    	        
    	    }   		
    	    if(worldObj.isAirBlock(xCoord, yCoord , zCoord+1))
    	    {
    	        worldObj.setBlock(xCoord, yCoord, zCoord+1, MagicBeans.blockMagicBeansVine, 4, 2);	    	        
    	    }   		
    	    if(worldObj.isAirBlock(xCoord, yCoord , zCoord-1))
    	    {
    	        worldObj.setBlock(xCoord, yCoord, zCoord-1, MagicBeans.blockMagicBeansVine, 1, 2);	
    	    }   		

 

So I'm wondering if you are using the wrong setBlock() method, or maybe you're using right method but setting wrong metadata.

 

If that is not your problem, then I suggest you look at the code for village generation and see how they place the doors in the buildings that are generated.

[coolAlias]

Hi,

 

I faced this problem before, and it has two facets: the first, jabelar already explained, the other is that you must make sure that there is a block to which the torch or door can attach, or it will 'break' and fall as an item.

 

In my case, I solved it by generating the structure in two steps, one to place all regular 'solid' blocks, and a second pass to place things like torches, paintings, and other things that might rely on the structure already being in place. You could think of it as 'building' and 'decorating'

 

Cheers,

coolAlias

[jabelar]

Yeah, really good point CoolAlias.  My code example above was called after I made the pillar that I was "decorating", so yes it is important to do these in the right order.

 

Furthermore, you should know that the setBlock() methods do a LOT of checking of conditions before allowing placing.  One of them is whether there is something to attach to, there is also checking if whatever is there to attach to is considered a valid thing to place on, the block below is checked (I think) to confirm you can place on, and so forth.  Because of all this, you need to make sure any custom blocks you create will pass all these checks.  For example, in my case I'm attaching the vines to a custom pillar so I had to make sure that the canPlaceBlockOnSide() method in the custom vine class returned true for that pillar block.  If you're making custom blocks in your structure you may need to clear out some of those such issues as well.

[delpi]

I'll add one more thing to the discussion.  It doesn't matter for torches and doors, but some blocks like pistons decide after they are set orientation, so even if you use those methods with the right metadata, it will overwrite it and always point the same direction since no player is involved as the object sees it.

 

To  fix this, create a delay block action list.  Basically setup a list (of block object actions - anotehr class) that a tick call activates once per tick.  Put in this list directions to set the metadata 1 to 2 seconds later.  1 usually works, but found a couple where i needed 2.  Still don't understand why.  Them BAM, you have your piston the right way.

 

 

[MrMinecraftGoodoo]

I can see the block bounds, but when I step on a pressure plate, the door breaks....

 

http://i1166.photobucket.com/albums/q619/ess0523/2014-07-02_103312_zps642a56c5.png

[shadowmage4513]

For the pistons/torches/chests/furnaces/other metadata blocks -- to alleviate the problem that delpi is describing, you can also just re-set the meta after setting it the first time.

 

E.G.

 

world.setBlock(x,y,z,block,meta,flag);//initial assignment, meta is often overriden by blocks' onPlaced methods

world.setBlockMetadataWithNotify(x, y, z, meta);//force-set the meta to your desired meta, this one should stick

world.markBlockForUpdate(x,y,z);//make sure clients will receive the new/updated metadata, generally optional during world-gen as the entire chunk will be sent when client goes in range

 

 

Another way that I found works well (and better performance) is to manipulate the data directly in the chunks.  This bypasses many of the world/block methods..so you have to be careful on what/where you do things, but will allow you to manually set the block / metadata / tile entity without worrying about the vanilla methods overriding them.  I actually do this during my structure generation stuff so that I can generate redstone contraptions with full state-data -- normally the wire/etc would get a neighbor update when placing the next block, and revert its power state / etc -- going through the chunk bypassed the vanilla 'update neighbor blocks on change' code, and allowed me to generate fully active redstone contraptions with the precise state they were scanned in as.

 

[shadowmage4513]

Further edit:

 

Doors are probably the trickiest to get correct, because they come in two halves that must BOTH be set properly, AND be set using the right method.

 

Check out the static method of ItemDoor.placeDoorBlock -- should be able to feed it one of 4 values(for each closed door orientation, 0-3).  It will properly set both the top and bottom of the door.  From there you only need to figure out what orientation number is correct for the doors in your structure (+rotation if generating your structure with multiple rotations).

[coolAlias]

To avoid further block updates like shadowmage4513 mentioned (e.g. for redstone), my solution was to use flag '2' when setting all my blocks, as this flag notifies the client without updating neighbors.

 

For doors, if I remember correctly, the top half has the same metadata value as the bottom half plus 8. The Minecraft wiki "Data Values" section will have more precise information on metadata values for all the blocks, so I would double-check there.

[MrMinecraftGoodoo]

I got it to work using the .placeDoorBlock method! I used metadata 3 and got it to work, with the pressure plates. Thanks everyone!

 

 

 

ItemDoor.placeDoorBlock(world, i + 5, j + 1, k + 10, 3, Blocks.iron_door);
ItemDoor.placeDoorBlock(world, i + 6, j + 1, k + 10, 3, Blocks.iron_door);