Jump to content

Recommended Posts

Posted

Hi, I'm updating my mod from forge 1.6.4 to forge 1.7.2 and I'm following some tutorials online. In almost all the tutorial I've seen, the blocks are registered under the init method. But whenever I did that, the block texture wouldn't show. The only way I could get the block texture to load was to register my block the my main mod class constructor. Which is the better way to do it?

 

Here is what I have:

 

public SoulCraft(){      //This is my constructor

   

    GameRegistry.registerBlock(infusedStone, "infusedstone");

   

    }

Posted

My blocks are registered in the static method of my main class(technically inside the static method of a different class that is initialized by the static method of my main class), but the init method should be equally valid. Can't imagine why it would effect your textures but, if for curiosity's sake, you tried registering them in preInit I would like to know if you get the same problem.

Posted

Here is an example modfile:

package com.kwibble.mod;

// imports. I can't remember what they are

@Mod(modid = "dummymod", name = "Dummy Mod", version = "1.0.0")
public class ModDummy
{
        @Mod.Instance("dummymod")
        public static ModDummy instance;

        public static Block dummy_block;

        @EventHandler
        public void preInit(FMLPreInitializationEvent event)
        {
                dummy_block = ( new BlockDummy()).setCreativeTab(CreativeTabs.tabBlock);
        }
}

 

Here is BlockDummy:

package com.kwibble.mod.block;

// imports

public class BlockDummy extends Block
{
        public BlockDummy()
        {
                this.setBlockName("dummy_block");
                this.setTextureName("dummy_block");
                // Other stuff you/need to make this block. Or you could chain them when you instantiate the dummy_block variable
                GameRegistry.registerBlock(this, "block_dummy_block");
        }

        // Other block stuff if you want it
}

 

This is basically the setup that I use (aside from the bad coding practise shown in that example... Bad Kwibble) and it works perfectly fine for me.

We all stuff up sometimes... But I seem to be at the bottom of that pot.

Posted
  On 7/4/2014 at 1:36 AM, MoxEmerald said:

My blocks are registered in the static method of my main class(technically inside the static method of a different class that is initialized by the static method of my main class), but the init method should be equally valid. Can't imagine why it would effect your textures but, if for curiosity's sake, you tried registering them in preInit I would like to know if you get the same problem.

 

Okay, first thins first. NONE OF YOUR INITLIAZATION EVENTS (PRE, POST, OR OTHERWISE) SHOULD BE STATIC.

Now that that is taken care of... Always register your blocks/items in the PRE initialization event, unless they are reliant on another mods items/blocks.

 

 

@OP I also forgot to mention, you don't need a constructor in your mod class. At all. Forge "constructs" your class via the initialization methods, so a constructor is not needed (at least to my knowledge).

We all stuff up sometimes... But I seem to be at the bottom of that pot.

Posted

Well its all good then. They way you said it made it sound as if it was a static method.

We all stuff up sometimes... But I seem to be at the bottom of that pot.

Posted

If I register the block in the preInit method, the texture doesn't show up, also, If I create the object in the preInit method the texutre doesn't show up either. To get the texture to work, I either have to do this line - "GameRegistry.registerBlock(this, "infusedstone");" in the constructor for the block, or the constructor of the Main mod class.

 

This is what I have now and it works, is this the bad way of doing it, and is there a better way?

 

Main Mod Class - http://pastebin.com/kbPPv4Ee

 

Block class - http://pastebin.com/69haC0bu

Posted

I've been told that registering your block during construction is technically incorrect. You can get around this by having a method

public Block register(){
    GameRegistry.register(this, this.getUnlocalizedName());
    return this;
}

and when you create your block:

    public static final Block myBlock = new MyBlock().register();

because you can guarantee that the Block is created before you call GameRegistry.register(args).

Posted

That's why I always have my register call at the very end of the constructor, everything about the item has been finished up.

We all stuff up sometimes... But I seem to be at the bottom of that pot.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Hello all. I'm currently grappling with the updateShape method in a custom class extending Block.  My code currently looks like this: The conditionals in CheckState are there to switch blockstate properties, which is working fine, as it functions correctly every time in getStateForPlacement.  The problem I'm running into is that when I update a state, the blocks seem to call CheckState with the position of the block which was changed updated last.  If I build a wall I can see the same change propagate across. My question thus is this: is updateShape sending its return to the neighbouring block?  Is each block not independently executing the updateShape method, thus inserting its own current position?  The first statement appears to be true, and the second false (each block is not independently executing the method). I have tried to fix this by saving the block's own position to a variable myPos at inception, and then feeding this in as CheckState(myPos) but this causes a worse outcome, where all blocks take the update of the first modified block, rather than just their neighbour.  This raises more questions than it answers, obviously: how is a different instance's variable propagating here?  I also tried changing it so that CheckState did not take a BlockPos, but had myPos built into the body - same problem. I have previously looked at neighbourUpdate and onNeighbourUpdate, but could not find a way to get this to work at all.  One post on here about updatePostPlacement and other methods has proven itself long superceded.  All other sources on the net seem to be out of date. Many thanks in advance for any help you might offer me, it's been several days now of trying to get this work and several weeks of generally trying to get round this roadblock.  - Sandermall
    • sorry, I might be stupid, but how do I open it? because the only options I have are too X out, copy it, which doesn't work and send crash report, which doesn't show it to me, also, sorry for taking so long.
    • Can you reproduce this with version 55.0.21? A whole lot of plant placement issues were just fixed in this PR.
    • Necro'ing that thread to ask if you found a solution ? I'm encountering the same crash on loading the world. I created the world in Creative to test my MP, went into survival to test combat, died, crashed on respawn and since then crash on loading the world. Deactivating Oculus isn't fixing it either, and I don't have Optifine (Twilight forest is incompatible)
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.