Forge explicitly excludes vanilla Items from having their burn time determined by IFuelHandlers, so it's not currently possible to modify the burn time of a vanilla Item.

 

If this PR is merged, you'll be able to modify vanilla burn times using an event.

I explained how to bypass the 3 GB requirement here.

 

It's likely that 1.5 GB won't be enough to decompile Minecraft, though following the instructions in the post I linked will let you try.

The registry system has been overhauled in 1.12, you need to use registry events. Forge's documentation explains them here. You can see some examples in my mod's init classes.

 

Unlocalised names should not be used for anything except display/translation purposes, use the Item's registry name (IForgeRegistryEntry#getRegistryName) as the default model location (since it's the default model that vanilla loads for every Item).

 

Use ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition rather than ItemModelMesher#register to register Item models. Do this in ModelRegistryEvent.

 

The tutorial you followed is outdated and poorly written. None of this is new to 1.12; ModelLoader was introduced in 1.8, registry names were introduced in 1.8.9, IForgeRegistryEntry was introduced in 1.9, registry events were introduced towards the end of 1.10.2.

This hasn't changed. If it's not working, there should be an error in the FML log telling you what went wrong.

 

If you can't figure it out, post your code and the FML log.

 

One thing that has changed is the order of events: Registry events are now fired after preInit instead of before preInit. If you register everything in the appropriate registry event, you shouldn't need to worry about this.

 

Side note: ModelLoader.setCustomModelResourceLocation automatically calls ModelBakery.registerItemVariants, you don't need to call it yourself.

38 minutes ago, DreadHydra said:

I dont know how to post fml log

 

You already did it before. The FML log is the logs/fml-client-latest.log file, I'm asking you to upload it to Gist and link it here.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist.

Post the FML log from a session without OptiFine installed.

One of your mods hasn't been updated to use the new registry system introduced in Forge 1.12-14.21.0.2348. Unfortunately the crash report doesn't say which one, so you'll need to remove mods until this error no longer occurs.

I don't think this is possible, you'd need to use a regular crafting recipe or create your own crafting process (e.g. a machine).

You'll need to create a class that extends StateMapperBase and implements StateMapperBase#getModelResourceLocation to do something similar to StateMap#getModelResourceLocation. Instead of using the Block's registry name as the domain/path of the ModelResourceLocation directly, it should prefix the path with the name of the subdirectory.

 

Register an instance of this for your Block(s) with ModelLoader.setCustomStateMapper in ModelRegistryEvent.

Some people still offer support for 1.7.10 on the Minecraft Forum Modification Development section. I browse that section, but I don't help people with 1.7.10 problems.

 

I strongly recommend updating to 1.11.2/1.12.

Minecraft uses PascalCase for its NBT tag names.

Use the minecraft:item_nbt ingredient type. Set the nbt property to the NBT data you want.

 

I don't have any examples of the minecraft:item_nbt ingredient type, but you can see an example of a recipe output with NBT (which uses the same properties) here.

5 hours ago, hydraefall said:

Okay, I don't know which file to download. Can u give me the default file name, as well maybe a screen shot of what button to hit? I'm looking for version 12.1.

 

Download the Installer file for the Forge version you want.

 

//set isn't a Vanilla or Forge command, it's provided by WorldEdit.

 

WorldEdit hasn't been updated to 1.12 yet.

I'm not sure why it's not working, that class definitely exists.

 

All I can suggest is deleting the Gradle cache with the cleanCache task, deleting the build directory with the clean task and deleting your IDE project with the cleanEclipse/cleanIdea task before setting up the project again by following these instructions exactly.

net.minecraftforge.registries.IForgeRegistryEntry only exists in Forge 1.12-14.21.0.2348 and later (with the overhaul of the registry system), before that it was net.minecraftforge.fml.common.registry.IForgeRegistryEntry. I'm not sure why your IDE let you compile and run your project while referencing a class that doesn't exist.

 

Update to the latest version of Forge.

7 hours ago, Kander16 said:

What is the replacement for OreDictionary.WILDCARD_VALUE to get an item work in a recipe no matter what the damage is?

 

Use its value (32767) directly.

1.7.10 is no longer supported here, update if you want help.

11 minutes ago, dwilby said:

Ya, sorry, I understand where you register the blocks, but where do you call the class that registers the blocks?

 

I don't call it from anywhere, the @Mod.EventBusSubscriber annotation automatically subscribes it to the Forge event bus in the mod construction phase.

I register my Blocks in the ModBlocks.RegistrationHandler class.

 

Which version of Forge are you using? Post your code.

Forge's documentation explains this here.

 

For examples, look at some of my mod's init classes.

19 hours ago, ctbe said:

I did notice that the comparison with instanceof always yields false since you are asking if Item (what is returned) is an instance of ItemSpear. It is not. ItemSpear may be an instance of Item, not the other way around. Meaning the code inside the if will never run. However, I tried by making a comparison with an item's unlocalized name and the code ran, yet it didn't do anything like you said.

 

ItemSpear is (presumably) a subclass of Item, so it's entirely possible for a method with Item as the return type to return an instance of ItemSpear. Checking if an ItemSpear is an instance of Item is pointless, since it will always be true.

 

That part of the OP's code is correct. Using unlocalised names for anything except translation/display purposes is a bad idea, since they're not unique and can change at any time.

There was a major overhaul of the registry system in Forge 1.12-14.21.0.2348, so any mod built for an earlier version of Forge is unlikely to work.

 

Forge for 1.12 isn't yet stable, so breaking changes will be common until the first stable version.

 

If you want help with the freeze, post the new FML log.

6 hours ago, austinboston said:

where is that

 

It's the thread stickied at the top of the Support & Bug Reports section.