i have an error "The method getAttributeUnlocalizedName() is undefined for the type IAttribute" in this line:
final Collection<AttributeModifier> modifiers = modifierMultimap.get(attribute.getAttributeUnlocalizedName());
The only thing i can do is add cast to 'attribute'. When i did it the line that i gave u turned into:
final Collection<AttributeModifier> modifiers = modifierMultimap.get(((Object) attribute).getAttributeUnlocalizedName());
And now error is: "The method getAttributeUnlocalizedName() is undefined for the type Object"
Programming by quick-fixes won't get you anywhere, you need to have a solid understanding of Java to make a mod.
According to MCPBot, IAttribute#getAttributeUnlocalizedName was renamed to IAttribute#getName on 2016-11-16.
When you find old code with methods that don't exist any more, you can try looking in the class for similarly-named methods or look at MCPBot's history for the method.
You can look at the latest version of my code on GitHub by selecting a branch from the tree/branch dropdown near the top of the page.
this is an old thread for 1.7, but it discusses something i have a question on. i am not a modder. but today i noticed wood from trees added by the biom o'plenty mod aren't treated as wood by thermal dynamics filters. how do i add the woods added by the mod in the ore dictionary? is there a simple document explaining it for non-programmers?
note that i am playing on a 1.12 modpack (direwolf)
The Ore Dictionary is generally configured by mods, not users.
You may be able to use something like CraftTweaker to add items to the Ore Dictionary, but I'm not very familiar with it myself.
If you're sure that they aren't in the Ore Dictionary, you may want to report this to the authors of BoP so that they can fix it themselves.
There should be some errors in the log (logs/latest.log in the game directory) explaining what went wrong, upload it to Gist and link it here.
You may want to install Forge while you're working on the model, since it greatly improves the error reporting of the model loading process. If you do, upload the FML log (logs/fml-client-latest.log in the game directory) instead of the Vanilla log.
You should also upload the model file itself and post the paths of your texture files.
Each property in the textures block defines the value of a texture name. The block/cube model uses one texture per side, with the side's name as the texture name. The up texture is displayed on the top of the block, the east texture is displayed on the east side of the block, etc.
The texture paths are in the format "<domain>:<path/to/texture>", which corresponds to assets/<domain>/textures/<path/to/texture>.png. If you don't specify a domain, it defaults to minecraft.
Two questions with this: First, is there a better way than using getDefaultState? I get the feeling this won't support blocks with metadata like
stone, for example, that have multiple sub blocks.
Store the full IBlockState rather than just the Block.
Second, how can I get a BufferedImage from the TextureAtlasSprite? Is it possible to get a ResourceLocation or DynamicTexture from the TextureAtlasSprite? I will use the BufferedImage to create the entity texture by duplicating the block's texture multiple times over the entity texture.
JEI has code to get a TextureAtlasSprite from an IBlockState or ItemStack (this returns the particle texture) and to get a BufferedImage from a TextureAtlasSpritehere.
You'll need to get the IBakedModel for the block and then get the texture locations from that. Either use the model's particle texture or the texture from one of the model's BakedQuads.
These texture locations are actually the names of sprites on the block texture atlas, they don't necessarily correspond to texture files on disk. This means you should get the textures from the atlas rather than reading them from a file.
Very good points both of you make. However, I guess the part that confuses me is that I am working with a custom Container object so it's loaded on both server and client side (client loads it behind a Gui), and I'm doing something on another thread and need to schedule something back on the main thread for thread safety b.s., and I the only thing I've found to be able to do so is use Minecraft.getMinecraft().addScheduledTask() or player.getWorldServer().addScheduledTask(). I can't use the Minecraft class because it will make the server side fail with the container loads with that import (because it doesnt exist server side), so I'm using the WorldServer method because even in single player the game is running a server instance. The method I posted earlier is backed by a sidedDelegate instance that can hold the data I need for either case safely. Or am I fundamentally missing some basic knowledge here?
A client-side Container shouldn't be directly interacting with the server (or scheduling a task to run on the server thread) as that would be reaching across logical sides.
On the physical client (i.e. in the client proxy), check which logical side the thread belongs to:
If it belongs to the logical client, schedule a task to run on the client thread using the Minecraft instance.
If it belongs to the logical server, schedule a task to run on the server thread using the MinecraftServer instance or a WorldServer instance (which delegates to the MinecraftServer instance anyway).
On the physical server (i.e. in the server proxy), check which logical side the thread belongs to:
If it belongs to the logical client, throw an exception as something has gone wrong (the physical server doesn't run the logical client).
If it belongs to the logical server, schedule a task to run on the server thread using the MinecraftServer instance or a WorldServer instance.
As explained in the documentation I linked, World#isRemote is the way to tell which logical side code is running on.
Are you sure you need a separate thread? Can you not run this code on the main client/server thread directly?
If you have a server-side player, their World (Entity#world / Entity#getEntityWorld) is server-side as well; so it's already an instance of WorldServer. All you need to do is cast it.
Have your block extend BlockContainer and spawn your tile entity by overriding BlockContainer'screateNewTileEntity method.
Don't extend BlockContainer or implement ITileEntityProvider, these are outdated. Instead, override Block#hasTileEntity(IBlockState) and Block#createTileEntity.
To load capability data from and save it to NBT, your ICapabilityProvider needs to implement INBTSerializable (or ICapabilitySerializable, a combination of the two interfaces). Forge will automatically call the INBTSerializable methods on your ICapabilityProvider when the object it's attached to (the ItemStack in this case) is loaded from or saved to NBT.
You can attach an inventory to an item through the capability system. You'll need an ICapabilityProvider implementation to store and provide the inventory, you can then create and return an instance of this from Item#initCapabilities.
I also used your code, virtually unchanged, to register the sounds. The main question is: Where are you calling your registerSounds from? It can't be from any of the proxies, as they use FMLInitializationEvents, not Events. The game doesn't crash, but neither does it play any sounds for the mob. I'm SOOOO close!!
The code Melonslise linked uses registry events. It looks like they have a separate class subscribing to the event and calling the SoundList.register(RegistryEvent.Register<SoundEvent>) method, but that's not necessary; the SoundList class could subscribe to the event itself.
according to Item.registerItems the name is minecraft:skull (unless you dont need the minecraft prefix), but thats not working. Maybe I'm missing something related to the head type?
That's the correct registry name.
One possible error you're encountering is that you haven't specified the metadata value using the data JSON property. Since the skull has subtypes (i.e. it returns true from Item#getHasSubtypes), this is required.
Otherwise there should be an error in the log telling you what went wrong. If you don't understand it, post the FML log using Gist or Pastebin.
Look at the Block.registerBlocks method for the registry names of vanilla Blocks (and their ItemBlocks) and look at the Item.registerItems method to see the registry names of vanilla Items (including block items that don't extend ItemBlock, like ItemSkull).
2. Is it possible to, within one json, to define a recipe that can take multiple different ingredients in the same slots, as in you can use sticks or blaze rods as a handle for a pickaxe. Is there a way to do it without using the ore dictionary?
You can use an array of ingredient objects anywhere a single ingredient is expected to create a compound ingredient that matches any of the items matched by the component ingredients.
Vanilla uses this for recipes accept multiple possible items per slot (e.g. minecraft:crafting_table accepts any plank).
0
Programming by quick-fixes won't get you anywhere, you need to have a solid understanding of Java to make a mod.
According to MCPBot, IAttribute#getAttributeUnlocalizedName was renamed to IAttribute#getName on 2016-11-16.
When you find old code with methods that don't exist any more, you can try looking in the class for similarly-named methods or look at MCPBot's history for the method.
You can look at the latest version of my code on GitHub by selecting a branch from the tree/branch dropdown near the top of the page.
0
The Ore Dictionary is generally configured by mods, not users.
You may be able to use something like CraftTweaker to add items to the Ore Dictionary, but I'm not very familiar with it myself.
If you're sure that they aren't in the Ore Dictionary, you may want to report this to the authors of BoP so that they can fix it themselves.
1
There should be some errors in the log (logs/latest.log in the game directory) explaining what went wrong, upload it to Gist and link it here.
You may want to install Forge while you're working on the model, since it greatly improves the error reporting of the model loading process. If you do, upload the FML log (logs/fml-client-latest.log in the game directory) instead of the Vanilla log.
You should also upload the model file itself and post the paths of your texture files.
1
You should create a resource pack rather than editing the vanilla files directly.
The JSON model format is documented here.
Each property in the textures block defines the value of a texture name. The block/cube model uses one texture per side, with the side's name as the texture name. The up texture is displayed on the top of the block, the east texture is displayed on the east side of the block, etc.
The texture paths are in the format "<domain>:<path/to/texture>", which corresponds to assets/<domain>/textures/<path/to/texture>.png. If you don't specify a domain, it defaults to minecraft.
0
You're passing EnumFacing.NORTH to IBakedModel.getQuads, so it's returning the quads for the north face of the model.
1
Store the full IBlockState rather than just the Block.
JEI has code to get a TextureAtlasSprite from an IBlockState or ItemStack (this returns the particle texture) and to get a BufferedImage from a TextureAtlasSprite here.
1
You'll need to get the IBakedModel for the block and then get the texture locations from that. Either use the model's particle texture or the texture from one of the model's BakedQuads.
These texture locations are actually the names of sprites on the block texture atlas, they don't necessarily correspond to texture files on disk. This means you should get the textures from the atlas rather than reading them from a file.
1
A client-side Container shouldn't be directly interacting with the server (or scheduling a task to run on the server thread) as that would be reaching across logical sides.
You need to handle this through the sided proxy system:
As explained in the documentation I linked, World#isRemote is the way to tell which logical side code is running on.
Are you sure you need a separate thread? Can you not run this code on the main client/server thread directly?
0
If you have a server-side player, their World (Entity#world / Entity#getEntityWorld) is server-side as well; so it's already an instance of WorldServer. All you need to do is cast it.
0
Don't extend BlockContainer or implement ITileEntityProvider, these are outdated. Instead, override Block#hasTileEntity(IBlockState) and Block#createTileEntity.
0
To load capability data from and save it to NBT, your ICapabilityProvider needs to implement INBTSerializable (or ICapabilitySerializable, a combination of the two interfaces). Forge will automatically call the INBTSerializable methods on your ICapabilityProvider when the object it's attached to (the ItemStack in this case) is loaded from or saved to NBT.
0
You can attach an inventory to an item through the capability system. You'll need an ICapabilityProvider implementation to store and provide the inventory, you can then create and return an instance of this from Item#initCapabilities.
0
The code Melonslise linked uses registry events. It looks like they have a separate class subscribing to the event and calling the SoundList.register(RegistryEvent.Register<SoundEvent>) method, but that's not necessary; the SoundList class could subscribe to the event itself.
0
That's the correct registry name.
One possible error you're encountering is that you haven't specified the metadata value using the data JSON property. Since the skull has subtypes (i.e. it returns true from Item#getHasSubtypes), this is required.
Otherwise there should be an error in the log telling you what went wrong. If you don't understand it, post the FML log using Gist or Pastebin.
1
Look at the Block.registerBlocks method for the registry names of vanilla Blocks (and their ItemBlocks) and look at the Item.registerItems method to see the registry names of vanilla Items (including block items that don't extend ItemBlock, like ItemSkull).
You can use an array of ingredient objects anywhere a single ingredient is expected to create a compound ingredient that matches any of the items matched by the component ingredients.
Vanilla uses this for recipes accept multiple possible items per slot (e.g. minecraft:crafting_table accepts any plank).