V0idWa1k3r

Well, show your recipe json. If the recipe doesn't work at all with any saw whatsoever(damaged or not) then show the launch log.

World#setBlockState. For the flags parameter description refer to the javadoc on the method. To get the IBlockState you can use Block#getDefaultState and then change the properties(if needed) of that state.

What would you need a custom factory for? This is perfectly acheivable with MC's default factories - see here and here. @AlmightyElement Either use OreDictonary if you want all logs to be accepted from all mods(that register their logs to the dictionary that is) or specify two items in your ingredient(example) because the game has 2 separate items that represent itemblocks for logs for whatever reason with the data set to the wildcard value. Edit: if you want a separate result per log then you will need one recipe per log, with the data property being incremented by one for each variant. And yes 2 of your recipes will have a different item name than the other 4(for vanilla)

I don't think that matters. Forge will automatically remap obfuscated references in mods in your workspace as far as I am aware. And in any case it shouldn't make your code "uncompilable" because you are not compiling OF, you re using it as a library.

In your client proxy/client only class after the item has been initialized.

You need to rethink your approach. If you don't understand something you need to learn it, not avoid it like a plague. Minecraft is getting more and more data driven and utilizes json for more and more of it's things. If you wish to continue modding you need to learn to use json. It's not very difficult. You've learned to use java after all, that's way more difficult than some json.

If your entry is the only one then the weight does not matter. If you want to add new drops to the pool use json, there is no need to do it from code. Read the official docs on the matter.

This makes no sense. ModelShield is a BipedModel which has nothing to do with baked models. You don't even need to extend ModelShield here at all. First of all the ItemOverrideList has nothing to do with a TEISR. Second of all most models have empty ItemOverrideLists and work just fine. You can't do this in the item's constructor because this method is client-side only. It will crash the server. No I didn't. I told you that you need to register your IBakedModel as the item's new model using either a custom ICustomModelLoader implementation or a ModelBakeEvent. But now when I see your registry... Don't ever use static initializers. Instantinate your things directly in the registry event. IHasModel is stupid and yes, this is a renamed IHasModel. All items need models, no exception and nothing about model registration requires access to private/protected data of the item. Register your models in the ModelRegistryEvent directly.

Why is your Item an instance of IBakedModel? That makes no sense. First of all IBakedModel is client-only while items are common, this will crash the server. Second of all items are not models. You can't return null here, you need to return ItemOverrideList.NONE. You can't return null here, you need to return a particle texture of some kind. At least a TextureMap#getMissingSprite. You can't return null here, return a Collections.EMPTY_LIST. Well, good job. For whatever reason you've overridden the setter for a TEISR. It used to set the TEISR of the item to the one passed as it's parameter. Now it sets the local teisr variable to a new WeaponTeisr. Which gets discarded immediately because that's not how java works. And even if it somehow worked this way you are not even calling this method from anywhere. And you have also provided no code responsible for registering the item's model. You need to do that too.

It depends on which TextureAtlasSprite you want. Do you want a block's/item's texture? Use BakedQuad#getSprite. Do you want a custom sprite? Use TextureStitchEvent, register your sprite using TextureMap#registerSprite, it will return you a TextureAtlasSprite you can store and reference later.

Well you need to update to a modern version of the game. As far as I am aware versions below 1.9 are no longer supported on this forum and you've discovered one of the many reasons as to why.

https://en.wikipedia.org/wiki/Serialization Similar to how the game does that with any other object properties - create the tag and write all fields that you want serialized into the tag. Is the field a primitive? Write it as one using one of the methods provided by NBTTagCompound. Is it an object? Create a new NBTTagCompound, do this procedure for that object. With enough depth anything can be broken down into primitives that can be serialized. Well your IStorage implementation should provide one. You are the one creating the implementation though. The same way you would get anything else from an NBT - with the corresponding get method(NBTTagCompound#getCompoundTag for example). Well, you will have all the data that your capability holds in that tag. Just read the data from the tag and set the fields in your capability to that data. That's called deserialization. You may use those methods, sure. It doesn't really matter which methods you use. No. Don't send the entire stack. Use whatever the base implementation is + your capability data. Well, finish creating the implementation for those methods. You need to write just enough data to be able to reconstruct your capability in the read method. If you are having issues with the concept of NBT and (de)serializing it you may want to try something else, like TIleEntities for example to get the idea on how it works.

What did you not understand? You need to override two methods in your Item class, the Item#getNBTShareTag and Item#readNBTShareTag. In Item#getNBTShareTag you need to serialize your capability to an NBT tag and append that tag to the one provided by the method. In Item#readNBTShareTag you will get the NBT the client received, grab your capability's NBT that you've appended to it and read the capability from it. If you are using the share tag approach the game will do everything for you. You only need to (de)serialize the data in the methods I've told you about.

Is your capability provider an instance of ICapabilitySerializable? When the ItemStack of the EntityItem is added to the player's inventory it's cloned and capabilities are cloned by serializing them in the old stack and deserializing them in the new stack. If your capability provider isn't an instance of INBTSerializable(which ICapabilitySerializable extends) then the capability data will be lost. Capabilities by default are never synced between client and the server but both may have the capability attached. You need to sync the capability yourself. Either use packets or in case of an ItemStack where the item of that stack is an item provided by your mod you can override Item#getNBTShareTag to save the capability into NBT that gets sent to the client and override Item#readNBTShareTag to deserialize the capability from the NBT you've received from the server. If you are not the owner of the Item's class then you have to use packets.

But that commit fixes the issue. You don't need to fix what's already fixed. If a new version isn't released yet then wait for it to be released(although that commit is more than a year old so I would imagine a new version is already out). Or compile the mod from sources yourself, they even have a documentation on how to do that on their github.

Finishing @Animefan8888's response - you've never set this to anything. So it's zero by default and Random.nextInt(0) will crash. And yeah, those field names... Also if you want to add something to the drops of an entity use loottables.

Field f = null; try { //noinspection JavaReflectionMemberAccess f = Blocks.class.getDeclaredField("field_150480_ab"); //The obfuscated field name for the current version of the Blocks class } catch (NoSuchFieldException e) { try { f = Blocks.class.getDeclaredField("FIRE"); } catch (NoSuchFieldException e1) { e1.printStackTrace(); } } Instead of all this you could've just used ReflectionHelper.findField It might just be me but I really dislike magic numbers like this one. Although in this case it is quite easy to understand what this is doing I would still write this with a reference to the constant instead: That's kinda what I thought too but from my debugging the Blocks class gets initialized before the block registry event is fired, so it always grabs the vanilla blocks from the registy even if mods override them later. I will do more debugging later.

What do you mean "fix this"? You've linked a commit, not an issue. A commit that is fixing an issue. What do you need to do exactly?

1.7.10 is no longer supported on this forum. Update to a modern version of minecraft to receive support.

It depends on how your configuration is setup. Are you using the suggested @Config annotation system? If you are it's just a matter of referencing the fields in the annotated class. If you are not however then you can get the data from the configuration using various getters provided by Configuration class, like Configuration#getFloat for example.

Why do you need that exactly? What are you trying to achieve?

Well, you are popping the matrix twice thus completely screwing it up.

I don't think I could provide more detail even if I wanted to. I gave you the method names, their location and even which overload to use.

Well, show what you've tried.

Use the overload of GameRegistry.addSmelting(or FurnaceRecipes#addSmeltingRecipe) that takes an ItemStack as it's first parameter