Jump to content

Recommended Posts

Posted

Hey guys,

 

So, I'm working on adding a new block, a campfire, and I want there to be a campfire for each of the different wood types. I believe I've setup the metadata correctly (I basically just copied from BlockPlanks.java).

 

Basically, in game, the ItemBlock has a model and shows textures properly in the inventory and hand, but the block itself doesn't even show a model and instead is the black/purple block instead.

 

Here is my campfire code

Here is my Blockstates.Json file

 

I'm also a little confused as in the vanilla minecraft code I didn't see anywhere where each of the different types of planks are registered programmatically. In the Block.java file, it just registers the base type of planks. However, there is a separate json file for each of the different types rather than a single planks.json that specifies the different EnumType variants.

 

I'm pretty sure there's more I need, but I'm not sure what else I need to do.

Posted

You've extended BlockContainer. Don't do this. It does several things that you don't actually want.

The first of which is setting the ModelType to INVISIBLE.

 

Instead, override getTileEntity() and hasTileEntity() in the Block class.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted (edited)
  On 7/28/2017 at 3:23 AM, Draco18s said:

You've extended BlockContainer. Don't do this. It does several things that you don't actually want.

The first of which is setting the ModelType to INVISIBLE.

Expand  

Is that a global statement? Because extending BlockContainer for one of my other objects that doesn't have metadata works just fine. Or is this statement specific to things with metadata?

 

EDIT: Also, I can't seem to find getTileEntity in the Block.java file from Forge. I did find createTileEntity though. Is that what I should use? (Just checking even though it might just be a semantics difference.)

Edited by DragonFerocity
Posted

I don't see anything useful in the FML, but here you go.

 

  Reveal hidden contents

 

Posted (edited)

I'm only registering one of the variants, here's it's code:

 

BlockHandler::initBlocks

//Campfire
    //Oak
    campfire = createBlock(new ModCampfire(false, "campfire", CreativeTabs.DECORATIONS, 1F, 1F, "pickaxe", 0), event);
    ibCampfire = createItemBlock(new ItemBlock(campfire), campfire);

    litCampfire = createBlock(new ModCampfire(true, "lit_campfire", CreativeTabs.DECORATIONS, 1F, 1F, "pickaxe", 0), event);
    ibLitCampfire = createItemBlock(new ItemBlock(litCampfire), litCampfire);
    
    GameRegistry.registerTileEntity(ModTileEntityCampfire.class, "campfire_tile_entity");

Here's ModCampfire.java

  Reveal hidden contents

 

Edited by DragonFerocity
Posted

BlockHandler::createItemBlock()

  Reveal hidden contents

BlockHandler::registerRenders() snippet

  Reveal hidden contents

This code is located in BlockHandler, which is called from

RegistryHandler.java

  Reveal hidden contents

 

Posted

Thanks for being more specific that time:

BlockHandler::InitItems creates all the items

BlockHandler::InitBlocks creates all the blocks

 

Snippet from BlockHandler::initItems()

  Reveal hidden contents

Here's one of the register functions called from registerRenders (there's multiple, one for each different type):

  Reveal hidden contents

BlockHandler::registerRenders() is called from the ClientProxy()

  Reveal hidden contents

Did I forget anything this time?

Posted (edited)

I'm very confused right now because I don't really know what you're talking about.

 

I added this to my client proxy and it just made things worse: (The item doesn't show a model in my hand, or inventory, and the block still doesn't show a model. Both are the purple/black cube)


  
  @SubscribeEvent
  public static void registerModels(ModelRegistryEvent event) {
    BlockHandler.registerRenders();
  }

I don't know what I'm supposed to do here. The way I currently register renders/models works for everything except for my campfire, and I'm 99% sure it's because I'm trying to use Metadata to make it easier.

Edited by DragonFerocity
Posted (edited)

I upgraded my version of Forge, and the FML has stayed the same.

 

EDIT: I should probably also point out that my register renders function is what registers Items and ItemBlocks. Isn't that supposed to be called in the Init of the ClientProxy?

 

EDIT: Also, if models must be registered in the ModelRegistryEvent, why does RegistryEvent.Register<Item> and RegistryEvent.Register<Block> exist?

Edited by DragonFerocity
Posted

Okay, thanks for letting me know all of this. It's been helpful.

 

One last question, how do I get all of the other variants in the game? I made a crafting recipe for one of the acacia variants, and the item produced was just a black/purple square with no model (but it had the same name as the default campfire "campfire.name"), and when I placed it, it placed a normal version of the campfire with the normal model rather than using the acacia version.

 

Do I need to go through and register all of the different models like I am with the default version?

campfire = createBlock(new ModCampfire(false, "campfire", CreativeTabs.DECORATIONS, 1F, 1F, "pickaxe", 0), event);
    ibCampfire = createItemBlockWithoutAddingToList(new ItemBlock(campfire), campfire);

    litCampfire = createBlock(new ModCampfire(true, "lit_campfire", CreativeTabs.DECORATIONS, 1F, 1F, "pickaxe", 0), event);
    ibLitCampfire = createItemBlockWithoutAddingToList(new ItemBlock(litCampfire), litCampfire);

I thought that using Metadata would make it so I wouldn't have to, but I might be wrong.

 

The reason I wanted to use metadata is because of this function in ModCampfire.java

public static void setState(boolean active, World worldIn, BlockPos pos)
  {
      IBlockState iblockstate = worldIn.getBlockState(pos);
      TileEntity tileentity = worldIn.getTileEntity(pos);
      keepInventory = true;

      if (active)
      {
          worldIn.setBlockState(pos, BlockHandler.litCampfire.getDefaultState().withProperty(TYPE, iblockstate.getValue(TYPE)), 3);
          worldIn.setBlockState(pos, BlockHandler.litCampfire.getDefaultState().withProperty(TYPE, iblockstate.getValue(TYPE)), 3);
      }
      else
      {
          worldIn.setBlockState(pos, BlockHandler.campfire.getDefaultState().withProperty(TYPE, iblockstate.getValue(TYPE)), 3);
          worldIn.setBlockState(pos, BlockHandler.campfire.getDefaultState().withProperty(TYPE, iblockstate.getValue(TYPE)), 3);
      }

      keepInventory = false;

      if (tileentity != null)
      {
          tileentity.validate();
          worldIn.setTileEntity(pos, tileentity);
      }
  }

If I have to register each variant separately, I'm either going to have to find another way to change the blockstate of each variant from the same file, or just create a new file for each variant.

 

Is there a way around this?

Posted (edited)

I believe I am really close to the solution:

 

Now the itemblocks when held in hand have no textures, which I'm actually not sure how to fix but I'm looking into it (I'm thinking this is because I don't have any textures defined in the campfire.json model file), and then whenever I try to place an acacia campfire, it places an oak one and the onscreen debugger shows that it's type is oak not acacia.

 

I have updated my code on GitHub to the latest as well.

 

I also found this post which helps a little and let's me know i'm doing things fine, but it's for v1.10.2, and so some of the things aren't correct anymore.

According to this post, I have everything I need in my code to get it working.

Edited by DragonFerocity
Posted

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted
  On 7/30/2017 at 4:01 PM, Draco18s said:
Expand  

That's because this code is now in my RegistryHandler.java file:

  Reveal hidden contents

 

  On 7/30/2017 at 4:01 PM, Draco18s said:
Expand  

See above

  On 7/30/2017 at 4:01 PM, Draco18s said:

On top of that: what the **** is this noise? Why do you have 14 functions that all do the same thing?

https://github.com/DragonFerocity/expandedaesthetics/blob/master/src/main/java/com/DragonFerocity/expanded/handlers/BlockHandler.java#L1283-L1335

Expand  

You're right in that I can find a better way to do things. It's on my list of things to do but for now it works and I'm not really going to change this until I get my currently problem resolved.

  On 7/30/2017 at 4:01 PM, Draco18s said:
Expand  

See above

  On 7/30/2017 at 4:01 PM, Draco18s said:
Expand  

I was told that this has to happen during the ModelRegistryEvent event, thus I have put it during that event, in which it actually works. Again see above

 

  On 7/30/2017 at 4:01 PM, Draco18s said:
Expand  

Yes, that import is left over from 1.11.2

 

Sorry that my code is a mess right now. I haven't gone through to clean it up yet. It's what I plan on doing next as soon as I figure this problem out (unless I can't, in which I'll just scrap it)

Posted (edited)

ModelRegistryEvent is still a client-side event:

import net.minecraftforge.client.event.ModelRegistryEvent;

Just because it isn't called on the server doesn't mean that the class even exists. Ditto with the ModelLoader class.

Edited by Draco18s
  • Like 1

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted

What are you trying to tell me?

 

If I move 

@SubscribeEvent
  public static void registerModels(ModelRegistryEvent event) {
    BlockHandler.registerModels();
  }

to ClientProxy.java, none of my items have item models anymore.

Posted

You haven't registered your proxy as an event handler class.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted (edited)

Okay, thanks!

 

I found a way to make the individual campfire items have models: I just have to pass a custom resource location when I call ModelLoader.SetCustomModelResourceLocation instead of passing the registry name of the item.

 

ie, instead of using this (which doesn't work):

ModelLoader.setCustomModelResourceLocation(ibCampfire, 4, new ModelResourceLocation(ibCampfire.getRegistryName().toString(), "acacia"));

I can do this (which does work)

ModelLoader.setCustomModelResourceLocation(ibCampfire, 4, new ModelResourceLocation("expanded:acacia_campfire"));

 

Is there something wrong with this json (This corresponds to the first setCustomModelResourceLocation)?

  Reveal hidden contents

(Also, the items still place the wrong variant when used in a world... I'm investigating that still)

 

EDIT: Here's the error output:

  Reveal hidden contents

Which, I realize what it's saying, I just don't understand why it's saying it.

  Quote

Exception loading model for variant expanded:campfire#acacia for item "expanded:campfire", blockstate location exception:
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model expanded:campfire#acacia with loader VariantLoader.INSTANCE, skipping

Expand  

Why can't it load the model? I believe my blockstate json is correct, yet it seems it can't find it. Why?

Edited by DragonFerocity
Posted
Caused by: java.io.FileNotFoundException: expanded:models/item/campfire.json

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted
  On 7/30/2017 at 10:48 PM, DragonFerocity said:

That fixes it not having a model. But it has no textures. And it still only places the oak variant no matter which type I use.

Expand  

Are you using ItemBlock?

That's your problem. ItemBlock always places meta-0.  You need ItemMultiTexture or your own ItemBlock class.

Not sure about the textures off-hand.

  • Like 1

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted (edited)

Oh! That fixed it! Thanks!

 

When looking around online, I found this, which is for MC 1.8, and he references ItemBlockWithMetadata. So I guess that class got renamed and slightly remade into ItemMultiTexture?


EDIT:

Also, I know how to fix the item's not having textures by doing what I described above

This doesn't work:

  On 7/30/2017 at 10:20 PM, DragonFerocity said:

ModelLoader.setCustomModelResourceLocation(ibCampfire, 4, new ModelResourceLocation(ibCampfire.getRegistryName().toString(), "acacia"));

Expand  

But this does:

  Quote
ModelLoader.setCustomModelResourceLocation(ibCampfire, 4, new ModelResourceLocation("expanded:acacia_campfire"));
Expand  

 

Which just means I need a different blockstate json file for each which isn't a problem, it's just strange to me.

Edited by DragonFerocity
Posted

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

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



×
×
  • Create New...

Important Information

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