Sorry, I missed that.

 

This is very odd, including your mod ID in the sounds.json event name should result in a Sound being registered for the ResourceLocation with <modid> as the domain and <modid>:<name> as the path.

 

Could you post a Git repository of your mod? I'd like to see if I can reproduce and debug this locally.

You're calling Item.getItemFromBlock before you actually create and register the ItemBlocks, so it returns Items.AIR. You need to create and register the ItemBlocks in the RegistryEvent.Register<Item> handler method.

41 minutes ago, oa10712 said:

There also seems to be a related issue, Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/multiplayer/WorldClient, at https://github.com/16ColorGames/SuperTechTweaks/blob/master/src/main/java/com/sixteencolorgames/supertechtweaks/ModBlocks.java#L33.

Is this going to be fixed by switching to registry events as well?

 

Switching to registry events won't actually fix either problem itself, it's just something you should do to prepare for updating to newer versions. Moving model registration to a client-only class will fix the first problem.

 

The issue here is that BlockOre references the client-only class Minecraft. You use it in two places (getDrops and getExtendedState) for the same purpose (getting a World when you only have an IBlockAccess), but the replacement will be slightly different in each method due to where they're called from.

 

Since getDrops will usually be called with a World as its IBlockAccess argument, cast it to World (after checking that it is a World) and use that to get the ore data.

 

Since getExtendedState will usually be called with a ChunkCache as its IBlockAccess argument, you can't just cast it to World. Instead, create a method in your proxy classes to get the client World and use this to get the ore data. It's probably best to check if the IBlockAccess is a World first and use that directly, just in case someone calls the method with a World.

 

This would be a lot easier if you just used a TileEntity to store per-position block data.

 

If you're going to stick with the current system, OreSavedData should use a Map with BlockPos keys instead of using nested Maps for each coordinate.

 

Is there a reason you're storing everything as integers rather than storing the Material instances directly?

Minecraft automatically uses your mod ID as the domain for the top-level sound event names in sounds.json, don't specify it yourself.

 

Change redplusplus:item.redstone_sandwich.eat to item.redstone_sandwich.eat in your sounds.json file.

57 minutes ago, oa10712 said:

Are there any good guides/tutorials/examples for registry events?

 

The documentation page I linked explains them. You can see some examples of them in my mod's init classes.

30 minutes ago, Kitsune_Ultima said:

Have the same problem how do I go about fixing this?

In code preferably

 

Did you read the thread?

 

You need to use registry events.

That line references ModFluids, which references the client-only classes StateMapperBase (which references IStateMapper) and ModelLoader, causing this error.

 

All model registration must be done in client-only classes. I recommend switching to registry events now so you can more easily update your code to 1.12.

1 hour ago, MsGeburt said:

1.) How do you know how the new names are? then i don't have to ask anymore and

 

I looked at where they were called in the old version and looked for the same code in the new version. I then looked at the methods called in that section in the new version to see which ones did roughly the same thing as the old ones.

 

Other resources include this issue tracker, which documents most renames in 1.8+ and MCPBot, which you can use to find the new name of a field/method/parameter from the old one. I explain how to use MCPBot in more detail here.

 

 

1 hour ago, MsGeburt said:

2.) in earlier versions i used player.sendPacket() but this doesn't work anymore either. And i don't find the new way to send packets to the server

 

NetHandlerPlayClient#sendPacket can be used to send vanilla client-to-server packets. You can get the NetHandlerPlayClient instance from Minecraft#getConnection or EntityPlayerSP#connection.

The FML log is the file called fml-client-latest.log in the logs directory of the Minecraft game directory. When asking for help in future, please upload it to Gist or Pastebin and link it in your post.

 

That said, 1.7.10 is no longer supported on this forum. Update if you want help.

Post the FML log (logs/fml-client-latest.log) using Gist or Pastebin.

No, you should post the FML log like I asked.

Post the FML log (logs/fml-client-latest.log) using Gist or Pastebin.

32 minutes ago, Stroam said:

I fixed what I thought was causing the issue with placing the painting and it didn't work. So now I'm tired and clueless. The en_us.lang I know is and easy fix but I can't for the life of me figure it out. The repo is up to date. Going to keep beating my head against the wall till I pass out or it starts working. If I don't reply withing 15 minutes of a post, assume I passed out.

 

You have two lang files, but neither is correct. You have one with the right name in the wrong location and one with the wrong name in the right location.

The correct location and name is assets/<modid>/lang/en_us.lang (when you have a pack.mcmeta file with pack_format set to 3).

Where do you call ModRenderers.register from? Where do you register your item models?

 

Post a screenshot of the item.

There aren't any model errors in the log.

 

What does the item render as? Where are you registering the model? Post your code.

The FML log (logs/fml-client-latest.log) should tell you why the models failed to load. Upload it to Gist or Pastebin and link it here.

Which Minecraft version are you using? 1.11+ requires all resource file names to be lowercase.

 

If you don't have a pack.mcmeta file or you do and it sets pack_format to 2, lang files will be loaded with the old mixed-case names (e.g. en_US.lang) because Forge wraps your mod's IResourcePack in a LegacyV2Adapter.

 

If you have a pack.mcmeta file that sets pack_format to 3 (the current resource pack version), lang files will be loaded with the new lower-case names (e.g. en_us.lang).

 

It's best to convert to pack_format 3 and lowercase names now in case Forge stops special-casingpack_format 2 resource packs in a future version.

EntityLivingBase#swingItem has been replaced by EntityLivingBase#swingArm.

PlayerControllerMP#sendUseItem has been replaced by PlayerControllerMP#processRightClick.

 

5 minutes ago, Stroam said:

Currently the new issue is Attempted to register a entry with a null name: I'm trying to figure that out. It's a strange setup that Chroonster has.

 

You need to set the registry name of an IForgeRegistryEntry before registering it. I do this in the constructors of my Items/Blocks.

Your title is a bit vague, what exactly are you trying to do?

 

If it's your own Entity and it doesn't extend EntityLiving, override Entity#processInitialInteract. If it does extend EntityLiving, override EntityLiving#processInteract instead.

 

If it's not your Entity, subscribe to PlayerInteractEvent.EntityInteract or PlayerInteractEvent.EntityInteractSpecific.

So it's working now?

If you missed it, please see the edit to my previous post. You're registering models for multiple instances of ItemGreen instead of the single instance you registered.

11 minutes ago, WildHeart said:

Im not have a fml-client-latest.log

 

That's strange. I'm not sure why the FML log wouldn't be created.

 

If you use ModelLoader.setCustomModelResourceLocation in ModelRegistryEvent, do you get any model errors in the log? Do your items render as the missing model (pink and black cube with the model location string overlayed) or as the desired model with the missing texture (pink and black squares)?

 

Edit: I just noticed you're creating multiple new ItemGreen instances in the renderRegister method, don't do this. Items (like other IForgeRegistryEntry singletons) need to be created once and registered in RegistryEvent.Register<Item>. You need to use the same Item instance that you registered when registering models.

 

This is probably the source of your problems.

Gist and Pastebin are simply websites that allow you to upload text files for other people to view. You need to link the uploaded file here so we can read it and tell you what the problem is.

1 hour ago, WildHeart said:

So, i use my old code:

Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item, meta, new ModelResourceLocation(item.getRegistryName() + "_" + name, "inventory"));
ModelBakery.registerItemVariants(item, new ResourceLocation(item.getRegistryName() + "_" + name));

And he not work. 1.11.2 in this code works and is already on 1.12 no. latest.log

 

The FML log is fml-client-latest.log, not latest.log.

 

ModelLoader methods need to be called in ModelRegistryEvent (or preInit, but that's not recommended). They won't work if called in init or later.

 

If you want help, post more of your code. We need to see when you're registering your models.