[1.8.9] Custom Walls issues

[Erfurt]

Hey guys,

 

So I have been working on a small mod for the past week or so. Now I have some problems that I can't seem to fix myself.

My first problem is, that I can't place torches on my custom walls, I have tried to use canPlaceTorchOnTop(), but that didn't work at all.

 

Here's my custom walls class.

public class BlockWall2 extends BlockWall
{

public BlockWall2(Block block)
{
	super(block);
	this.setResistance(10.0F);
	this.setHardness(1.5F);
}

public int damageDropped(int meta)
{
	return meta;
}

public boolean canConnectTo(IBlockAccess worldIn, BlockPos pos)
    {
        Block block = worldIn.getBlockState(pos).getBlock();
        return block == Blocks.barrier ? false : (((block != this && !(block instanceof BlockFenceGate) && !(block instanceof BlockWall2) && !(block instanceof BlockWall))) ? (block.getMaterial().isOpaque() && block.isFullCube() ? block.getMaterial() != Material.gourd : false) : true);
    }
}

 

My second problem is that for every new custom wall I make there's two blocks in the creativeTab, there should just be one. Minor thing but I want to fix it...

 

My last problem is, that vanilla walls don't want to connect to my custom walls, but my custom walls want to connect to vanilla walls. I want them to connect. I have no idea how to make that happen, so if anyone could give me some advice I would apriciate it.

[jeffryfisher]

1) Return true from canPlaceTorchOnTop. Use the @Override annotation to guarantee that you're really overriding it.

 

2) You're not showing enough code to say why you appear twice in menu. Where's registration etc?

 

3) I don't think you can fix the vanilla walls willingness to connect. What I ended up doing was recreating cobble and mossy cobble walls in my own mod. Player who want connections must avoid vanilla walls.

 

4) My own walls mod stopped extending BlockWalls when I ported to mc 1.8 and its blockstates. Now that I know a little more about blockstates, I might be able to extend BlockWalls again without encountering the issues that fazed me last year. Then at least your walls could connect to mine and vice versa.

[Erfurt]

1) Return true from . Use the @Override annotation to guarantee that you're really overriding it.

 

2) You're not showing enough code to say why you appear twice in menu. Where's registration etc?

 

3) I don't think you can fix the vanilla walls willingness to connect. What I ended up doing was recreating cobble and mossy cobble walls in my own mod. Player who want connections must avoid vanilla walls.

 

4) My own walls mod stopped extending BlockWalls when I ported to MC 1.8 and its blockstates. Now that I know a little more about blockstates, I might be able to extend BlockWalls again without encountering the issues that fazed me last year. Then at least your walls could connect to mine and vice verse.

 

1) I have tried that, sadly it didn't work.

 

2) I believe that they appear twice because I extend BlockWall. BlockWall is working in subBlocks, and have two variants, and that is why. At least that's my theory. I just don't know how to remove the subBlock from the code.

 

3) That's a bummer, I was hoping that I could add some piece of code somewhere, so they could connect. Oh well guess I can't have everything

 

4) I have had no real problem extending BlockWall in 1.8 and using Forge's Blockstates, makes it pretty easy to make the blockstates for custom walls.

 

Link for Forge's Blockstates.

http://mcforge.readthedocs.org/en/latest/blockstates/forgeBlockstates/

[Draco18s]

1) I have tried that, sadly it didn't work.

 

What do you mean it "didn't work"?

[Erfurt]

1) I have tried that, sadly it didn't work.

 

What do you mean it "didn't work"?

What I mean is that I still can't place a torch on my custom wall.

[jeffryfisher]

Time to set some break points and step through the torch placement in the debugger (trying again to return true from  canPlaceTorchOnTop).

 

I am revisiting my own walls mod to see if I can coax it back into being an extension of BlockWalls. Maybe I'll run into a gotcha and remember exactly what made me extend from class Block.

[Erfurt]

Time to set some break points and step through the torch placement in the debugger (trying again to return true from  canPlaceTorchOnTop).

 

I am revisiting my own walls mod to see if I can coax it back into being an extension of BlockWalls. Maybe I'll run into a gotcha and remember exactly what made me extend from class Block.

Yeah, I just suck at debugging, oh well only one way to get better

[Erfurt]

After doing some tinkering, I got the torch thing to work, after adding this piece of code to my custom wall class

public boolean isSideSolid(IBlockAccess world, BlockPos pos, EnumFacing side)
{
	IBlockState state = this.getActualState(world.getBlockState(pos), world, pos);

        if (this instanceof BlockWall2 && side == EnumFacing.UP)
        {
            return true;
        }
	return false;
}

public boolean canPlaceTorchOnTop()
{
	return true;
}

[Draco18s]

I was going to take a guess at isSideSolid, earlier, but I would have thought that BlockWall did that already.

[Erfurt]

I was going to take a guess at isSideSolid, earlier, but I would have thought that BlockWall did that already.

Yeah, I thought so too. But I managed to figure it out

[Erfurt]

I'm on a roll today

 

After some more tinkering I was able to remove the unneeded extra blocks, from the CreativeTab, I used this code to fix the problem

@SideOnly(Side.CLIENT)
    public void getSubBlocks(Item itemIn, CreativeTabs tab, List<ItemStack> list)
    {
        for (int i = 0 ; i < 1 ; i ++)
        {
        	if (i == 0)
        	{
            	list.add(new ItemStack(itemIn, 1, i));
        	}
        	else
        	{
        		list.remove(new ItemStack(itemIn, 1, i));
        	}
        }
    }

 

It's probably not the best way to do it, but it works.

 

And that leaves me with the last problem with the connecting to vanilla walls failure, I'll leave this one open if someone knows of a way to get it working, otherwise this post is solved. Thanks for the help guys, I really appreciate it

[Draco18s]

 for (int i = 0 ; i < 1 ; i ++)

 

That can be simplified.  E.g. by removing it entirely, because you're only going to get 1 item stack from that loop, so why bother with a loop?

[Erfurt]

That can be simplified.  E.g. by removing it entirely, because you're only going to get 1 item stack from that loop, so why bother with a loop?

You are absolutly right all I really need is this.

@SideOnly(Side.CLIENT)
    public void getSubBlocks(Item itemIn, CreativeTabs tab, List<ItemStack> list)
    {
          list.add(new ItemStack(itemIn, 1, 0));
    }

 

To be fair I wasn't sure if that would work, when BlockWall has two in its getSubBlocks, so I just figured that I had to add one, and still remove the other one, but that isn't the case. Thanks mate

[jeffryfisher]

Walls do not have "solid" sides because they don't occupy whole blocks (and therefore you can't put torches on the sides of wall blocks).

 

I wonder if the trouble with torch-on-top is peculiar to 1.8.9... or maybe it's something about extending BlockWall in 1.8+ (which might be why I changed my design when porting from 1.7.10). I'll be looking at that today.

 

PS: Add an @Override annotation to your getSubBlocks method so you'll always be sure that you're really overriding the vanilla one. This annotation becomes especially valuable when porting to a new MC release in which some methods change their parameter lists, breaking override matchups. When that happens, your annotated methods all get flagged for immediate fixing. Non-annotated methods simply sit there not being called anymore and it might take you much hair-pulling to figure that out. Long story short: Always annotate every override.

[Erfurt]

Walls do not have "solid" sides because they don't occupy whole blocks (and therefore you can't put torches on the sides of wall blocks).

 

I wonder if the trouble with torch-on-top is peculiar to 1.8.9... or maybe it's something about extending BlockWall in 1.8+ (which might be why I changed my design when porting from 1.7.10). I'll be looking at that today.

 

PS: Add an @Override annotation to your getSubBlocks method so you'll always be sure that you're really overriding the vanilla one. This annotation becomes especially valuable when porting to a new MC release in which some methods change their parameter lists, breaking override matchups. When that happens, your annotated methods all get flagged for immediate fixing. Non-annotated methods simply sit there not being called anymore and it might take you much hair-pulling to figure that out. Long story short: Always annotate every override.

 

I think the problem came with forge 1.8 or 1.8.9 as I remember it working fine in 1.7.10.

 

Most of the time when I use the @Override annotation, my eclipse tells me to remove it again, I don't really know why. But does it have any impact to use it anyway, and ignore eclipse in this case? Because if it has no impact and will work fine with the annotations being there, I will definitely add them

 

Also I might have found a way to get vanilla walls to connect to my custom walls by using IExtendedEntityProperties, I just need to learn a bit more about how to use it, but I'll have to wait till tomorrow to do so.

[jeffryfisher]

Sometimes Eclipse will complain about a brand new @Override because its cache is dirty. Do the "clean" action from the project menu. If it still complains, then (like D7 said), you probably have some disagreement between your method and what it's supposed to override.

 

BTW, sometimes that disagreement is that the super method is private or final. In those cases, stronger measures (e.g. reflection) are required, and some just aren't worth the effort (unless you get an emotional payoff simply from overcoming such obstacles  )

 

Incidentally, I was able to revise my own wall class in MC 1.8 (Forge 1450) as an extension of BlockWall (and will port such to 1.9). It was not straightforward. To handle my metadata subtypes as well as connection geometry with a minimum of JSON fuss, I had replaced vanilla's many boolean connection properties with my own integer geometry property. This created havoc inside the mandatory super constructor where none of the vanilla properties existed. I hacked my way around that obstacle in a brute-force manner that I won't describe here because it might nauseate some readers.

 

Long story short: My next Anystone Walls revision should connect to other mods' walls that are extensions of BlockWall and programmed to likewise connect with instances of BlockWall. I encourage all modders to eschew vanilla's "block == " tests and instead use "instanceof <vanilla parent class>" in order to play nice with other mods that add blocks like yours (unless you have a special reason to be exclusive).

[Erfurt]

Just coming with a small update on the 'problem' with vanilla wall blocks not connecting to my custom walls. I have made a fix, that was almost to simple to be true. I added this piece of code to my custom wall class. And it's working. However I'm not sure if this have any impact on the wall aspect of my blocks, but so far I have seen no issues.

@Override
public boolean isFullCube()
{
	return true;
}

 

Maybe someone will correct me if this is bad or the wrong way to do this. I do know that the vanilla BlockWall class has isFullCube() return false. But all I know is that everything seems to be working fine. I still have to do some more testing to see if returning isFullCube() true, gives any problems, but so far there's been none.

[Erfurt]

Never mind. I have already seen a lot of problems with doing so. Stuff like fences now also want to connect, a bit of a brain fart to think that there wouldn't be problems when doing so. Guess it's been a long day, and maybe I should just go to bed

[jeffryfisher]

Being a "full cube" might also do things to lighting and graphics occlusion. It's better to just add your own versions of cobble and mossy cobble to your list of variants.

 

BTW, Set yourself up to do more than one set of walls (separate your walls into an abstract class and a child set of walls). Then you can add another 16 compatible wall types by writing another extension of the abstract class. Mine is up to 2 sets (32 walls), and I have contemplated a 3rd set. Mine even have variable hardness, blast resistance etc, and a few give off light. My glowstone and sea-lantern walls are quite useful.

[Erfurt]

Being a "full cube" might also do things to lighting and graphics occlusion. It's better to just add your own versions of cobble and mossy cobble to your list of variants.

I guess I have to, I'm just not very happy to 'remove' vanilla stuff just to add in the same thing. I'm thinking more as a compatibility factor with other mods that might use cobble or mossy cobble in crafting. Personally I haven't found a mod that does this yet, but you never know.

 

BTW, Set yourself up to do more than one set of walls (separate your walls into an abstract class and a child set of walls). Then you can add another 16 compatible wall types by writing another extension of the abstract class. Mine is up to 2 sets (32 walls), and I have contemplated a 3rd set. Mine even have variable hardness, blast resistance etc, and a few give off light. My glowstone and sea-lantern walls are quite useful.

I don't think it will be necessary, as I'm only going to add about 10 new walls

[jeffryfisher]

I've heard of cobble and mossy cobble blocks being used in crafting, but not their walls.

 

I distinguished my walls recipes by taking 7 input blocks to produce 7 walls (add top-center to the vanilla wall recipe). That lets me use the same materials that would otherwise make vanilla stuff (like those cobbles, and window panes, and nether-brick fences). I can now contemplate a full set of wooden walls that won't be confused with fences either.