[Solved][1.10.2] Registring Blocks[Solved]

[SHsuperCM]

Currently after a whole day of setting my new mod(2nd;but 1st was clientside mod)

i finally managed to make a block exist in my mod; but, to register im using:

GameRegistry.registerBlock(Block)

and it seems that this method is deprecated which my understanding of deprecated is

that this is not suppost to be in forge and it will get deleted eventually....

so, how can i register it without this method?

[FireController1847]

The new way of registering blocks is mainly you have to register the item and then the block. So first off, you have to register an item. Make a function where you get an item from the block, and then make a function that renders the blockitem like you would an item.

 

Ex. function1 : RegisterBlockItem()

 

Ex. function2 : RegisterItem(Item item)

 

And then, from wherever (suggested to put in the block file), you have to give it a registry name, and use ModelLoader.SetCustomResourceModelLocation() to register the item. You can get an item from a block by doing item.getItemFromBlock(Block)

 

And then you register the block and item like you would normally register something.

 

This is how I would set up my InitBlocks file:

 

http://vignette1.wikia.nocookie.net/minecraft-forge-tutorials/images/2/26/Code1-1.png/revision/latest?cb=20160606015651[/img]

This is an image from this wiki.

[Choonster]

I explain how to properly register

Block

s and other

IForgeRegistry

implementations in 1.9+ here.

[Draco18s]

I run all the registration through my common/client proxies myself.  It lets me handle the various cases once just by passing a Block/Item and string like the old GameRegistry.registerBlock methods.  It sets the registry and unlocalized name, registers the block, and registers the rendering as well.

[SHsuperCM]

thanks alot for the fast response but can someone please give a dumber working example that i would understand? me' brain iz stuck on that IForgeRegistryEntry or whatever...

[Choonster]

  On 7/28/2016 at 5:10 PM, SHsuperCM said:

thanks alot for the fast response but can someone please give a dumber working example that i would understand? me' brain iz stuck on that IForgeRegistryEntry or whatever...

 

IForgeRegistryEntry

is an interface implemented by all vanilla singleton classes, e.g.

Block

,

Item

,

Biome

,

Enchantment

. To register instances of any of these classes, simply set the registry name by calling

setRegistryName

and then register it by calling

GameRegistry.register

.

[FireController1847]

  On 7/28/2016 at 5:10 PM, SHsuperCM said:

thanks alot for the fast response but can someone please give a dumber working example that i would understand? me' brain iz stuck on that IForgeRegistryEntry or whatever...

 

It is not recommended by me, but you can if you'd like go to my wiki here. It's kind of confusing and unstable, but it should get you to understand how all this new nonsense works.

 

And I am sorry all you forge modders who didn't want me to do this... To be honest soon I will be improving that wiki so it's not to a point of utter horribleness. And don't tell me to update the official one; personally I hate the layout of it and it doesn't match the way I like to do things.

[SHsuperCM]

Soooo... to everyone that want to know how idiot can a person be(btw its me)

i just took a quick look at the Deprecated

registerBlock

and i think i actually

found what i need....

 

    @Deprecated
    public static Block registerBlock(Block block)
    {
        register(block);
        register(new ItemBlock(block).setRegistryName(block.getRegistryName()));
        return block;
    }

 

and from my understanding its just doing what i want it to do and, well, its open source.. soo.. i can just use that...

im sorry but im still not understanding the

IForgeRegistryEntry

and i think without the proxies i wouldnt even

know what an interface is, im really new to all this..

 

can i get a confirmation that it is safe to use this:

//block.modBlock.getBaseBlock() is returning a Block object..
GameRegistry.register(block.modBlock.getBaseBlock());
GameRegistry.register(new ItemBlock(block.modBlock.getBaseBlock()).setRegistryName(block.getModBlock().getBaseBlock().getRegistryName()));

 

[Choonster]

That will work.

 

Is there a reason why you need such a complex chain of methods to get the

Block

? Is it not just stored in a public field?

 

Is

block

a class? If it is, it should be named using

PascalCase

.

[SHsuperCM]

  On 7/28/2016 at 5:42 PM, Choonster said:

That will work.

 

Is there a reason why you need such a complex chain of methods to get the

Block

? Is it not just stored in a public field?

 

Is

block

a class? If it is, it should be named using

PascalCase

.

 

the block is from an for loop that i do to register:

for(MTFBlock block : MTFBlock.values()){

and it loops through an enum that stores Blocks im creating and sets registryName and unlocalizedName to them..

i have the same thing but for items as well and it seems to simplify a whole bunch when adding items and blocks..

its set to register the items on a loop and register renders on a loop(of course processed only with the clientside)...

 

thanks anyways guys!

 

 

[Draco18s]

  On 7/28/2016 at 5:27 PM, SHsuperCM said:

block.modBlock.getBaseBlock()

block.getModBlock().getBaseBlock()

 

Why are these two different?

[SHsuperCM]

  On 7/28/2016 at 6:39 PM, Draco18s said:

  Quote

block.modBlock.getBaseBlock()

block.getModBlock().getBaseBlock()

 

Why are these two different?

i have the ModBlock itself and the getter, i didnt notice that on some im using one another... thanks for letting me know...

[Draco18s]

If a field is public you don't need a getter...

[SHsuperCM]

  On 7/29/2016 at 4:46 AM, Draco18s said:

If a field is public you don't need a getter...

Well, yeah, that i know... its again not hurting to have a getter and from my eyes as the one who is coding this, a getter looks a bit better in terms of just looking from above at all the code..  if i cant i could of made alot of stuff in my mod shorter by just calling the fields, but getters looking more pleasent to the eye... i really cant explain why.....

#phonekeyboardiswierd

[Draco18s]

Method calls have overhead, but sure, if you want to go that way for aesthetic reasons, go for it.  I'm not going to stop you, I just think its weird.