Now the problem is that my inventory isn't displayed into the anvil interface. Since I call super() for ContainerRepair, shouln't be the inventory be displayed?
You're creating a new empty InventoryPlayer instead of using the player's actual inventory (EntityPlayer#inventory).
GuiServer overrides ContainerRepair#canInteractWith to always return false, so Minecraft closes the GUI during the next tick of the player.
You need to override it to do what the super method does: check if the block at the specified position is your anvil and that the player is within range of it.
BlockGoldenAnvil#onBlockActivated incorrectly passes the hitX/Y/Z arguments to EntityPlayer#openGUI, these represent the position on the block that the player clicked; not the position of the block in the world. The BlockPos argument is the block's position in the world.
You need to create an NBTTagList and add each position tag to it, before storing it in the NBTTagCompound.
When reading the data, iterate from 0 to NBTTagList#tagCount and use the appropriate getter method from NBTTagList to get each position tag and convert it back to a BlockPos before adding it to childNodeList.
I recommend using NBTUtil.getPosFromTag/NBTUtil.createPosTag to read the positions from and write them to NBT.
I found the ModelDynBucket class, but I don't see how that file connects to a mod. It looks like it's only being referenced within a forge package, which I can't and shouldn't edit. I could imagine making essentially a copy of this class and putting my custom code in it and linking that to an item, but that doesn't look like how this works. It uses ResourceLocations it looks like, and that would point to a .json file, not a baked model class. I guess I just don't know how to "hook into" the model loading process with a class, which I definitely will need and not just a json.
Whenever Forge loads a model, it asks all the registered ICustomModelLoaders if they accept the specified ResourceLocation until it finds one that does. If none do, it asks the default ICustomModelLoaders (ModelLoader.VanillaLoader and ModelLoader.VariantLoader) if they accept it (ModelLoader.VanillaLoader always does).
Once Forge finds an ICustomModelLoader that accepts the ResourceLocation, it calls ICustomModelLoader#loadModel to load the IModel. This could be loaded from a file (e.g. a JSON file loaded by ModelLoader.VanillaLoader) or created entirely in code (e.g. ModelDynBucket.MODEL loaded by ModelDynBucket.LoaderDynBucket).
When a model is loaded by a Forge blockstates file, BlockStateLoader.ForgeVariant#runModelHooks is called so the model can process any custom data, replace textures and enable/disable smooth lighting, GUI 3D and UV lock settings specified in the blockstates file.
When Forge has finished loading every requested IModel, it calls IModel#bake on them all to bake them into IBakedModels.
When Minecraft renders an IBakedModel for an item, it calls ItemOverrideList#handleItemState on the model's ItemOverrideList to allow the model to be replaced by another according to any overrides specified in the item model.
ModelDynBucket.BakedDynBucket uses ModelDynBucket.BakedDynBucketOverrideHandler.INSTANCE as its ItemOverrideList, which uses IModel#process to generate a new ModelDynBucket instance with the item's contained fluid and then ModelDynBucket#bake to bake that into a new IBakedModel. It caches these models so they're not re-baked every time.
You can use an array of ingredients anywhere a single ingredient is expected to create a compound ingredient that matches any of the specified ingredients. Look at the crafting_table.json recipe for an example of this, it uses a compound ingredient that matches any of the valid metadata values of minecraft:planks.
You can also use 32767 (the value of OreDictionary.WILDCARD_VALUE) as the metadata of an ingredient to match any metadata value.
The crash is coming from StatList.initStats, which creates an ItemStack without an NBT tag and calls ItemStack#getTextComponent on it (which calls Item#getItemStackDisplayName/getUnlocalizedName).
You can't assume that an ItemStack always has an NBT tag, you need to handle the case where it doesn't.
Ah, I see. Do you think this will be fixed any time soon or should I look into making a custom implementation?
The main issue may take a while to be fixed, since I'm not entirely sure how it should be implemented. You'll have to wait for LexManos or someone else to get around to fixing it.
The other two issues should be relatively easy to fix, I plan to submit PRs for them soon.
Actually, I just realized that I do need to register my spell parts before the ModelRegistryEvent since when using mesh definitions I need to register all the possible variants during the model registry event and one of my mesh definitions requires the spell affinity registry (basically a hashmap) to be filled when registering the variants with ModelBakery. Is there any way I can do this properly?
The best way to do this would probably be using Forge registries and registry events for your spell classes.
If that's not practical/possible, you can probably get away with firing your custom registry events during RegistryEvent.Register<Item>; though it's a bit hackish. You'll probably want to do this at the start (EventPriority.HIGHEST) or end (EventPriority.LOWEST) of the event.
If your event implements IContextSetter, it will set the active mod container when calling the event handlers. If your event implements IGenericEvent (or extends GenericEvent), event handlers can specify a generic type argument to filter when they're called (like RegistryEvent.Register and AttachCapabilitiesEvent).
I didn't say I wasn't registering my items in RegistryEvent and my ItemMeshDefinitions in ModelRegistryEvent. Rather I was wondering if I could fire my spell registry events before the ModelRegistryEvent, however I now see it is not required since they're accessed only in the getModelLocation method.
There won't be any clean way to fire your own spell registry events between RegistryEvent.Register<Item> and ModelRegistryEvent; but as you said, you shouldn't need to.
So does this mean that I'll have to use RegistryEvent.Register? Or is there another way I can get my mesh definitions to work without using Forge's registry system?
You should be registering your Items in RegistryEvent.Register<Item> and your ItemMeshDefinitions in ModelRegistryEvent, regardless of what you decide to do with your spell classes.
If you create a Forge registry for any of your spell classes, you should register the instances of those in RegistryEvent.Register<T> (where T is the registry type) as well.
If your ItemMeshDefinitions require instances of the spell classes at construction time, the spells will need to be registered before ModelRegistryEvent. If they only require instances of the spell classes in the ItemMeshDefinition#getModelLocation implementation, they can be registered later.
Ah, I forgot about those. I added a static initialization block and it seems to appears to not crash, however I set a sysout to print the HashMap on sync(), and it doesn't appear to read any extra values added from the configuration file, even when the game starts with the new lines in the file. I have this as a test:
But only the ones (stone and wool) that are initialized in the static initialization block are printed out. Do I need to do something to manually load new keys from the file?
It looks like the FieldWrapper.MapWrapper class used by the annotation-based config system for Map fields is a bit broken, I've reported this issue here. I've also reported two other issues with it here and here.
I thought that since my mesh definitions and sub items relied on my spell parts I needed to register them before the items, however I'm not quite sure anymore.
ItemMeshDefinitions should be registered in ModelRegistryEvent, which is fired after RegistryEvent.Register is fired for every registry.
Item#getSubItems generally won't be called until after the initial loading process.
As for forge's registry system, are there any advantages over using regular events? Keep in mind that I have multiple registries and I need specific ones to be fired later than others.
Thanks for your help!
Forge's registry system handles things like ID assignment, name remapping and detecting missing registry entries for you.
Forge fires RegistryEvent.Register in alphabetical order of the registry names (after it's fired for Block and Item), but I think this is considered an implementation detail rather than a documented order.
No, you don't understand. I'm not creating an item for each combination, but rather creating the item stacks with NBT, setting their stack names and setting their item mesh definitions for every spell part (not spell) that are combined into spells during the game (however creating every combination is also quite a good idea for creative users/map makers).
Why does this need to be done before items are registered?
If you use Forge's registry system, RegistryEvent.Register will automatically be fired for you and you can use this to register your spell parts. It will be fired for your register after it's fired for the item registry, though.
You really need to spend some time learning the basics of Java before making a mod.
I use Class#member to refer to non-static fields/methods and Class.member to refer to static fields/methods.
ItemStack#damageItem and ItemStack#shrink are non-static methods, so they need to be called on an instance of ItemStack.
You can't just type a name like instant_health and expect Java to know what you mean, you need to reference an actual field. The Instant Health Potion object is stored in the MobEffects.INSTANT_HEALTH field.
Ok thanks will try it for at least one thing but, do coded recipes get overridden via resource pack I know the .jsons would
Files loaded by the server (e.g. recipes, loot tables and structures) can't be overridden via resource packs, but Mojang plans to add data packs in 1.13 to allow this.
0
You're creating a new empty InventoryPlayer instead of using the player's actual inventory (EntityPlayer#inventory).
1
GuiServer overrides ContainerRepair#canInteractWith to always return false, so Minecraft closes the GUI during the next tick of the player.
You need to override it to do what the super method does: check if the block at the specified position is your anvil and that the player is within range of it.
BlockGoldenAnvil#onBlockActivated incorrectly passes the hitX/Y/Z arguments to EntityPlayer#openGUI, these represent the position on the block that the player clicked; not the position of the block in the world. The BlockPos argument is the block's position in the world.
1
You need to create an NBTTagList and add each position tag to it, before storing it in the NBTTagCompound.
When reading the data, iterate from 0 to NBTTagList#tagCount and use the appropriate getter method from NBTTagList to get each position tag and convert it back to a BlockPos before adding it to childNodeList.
I recommend using NBTUtil.getPosFromTag/NBTUtil.createPosTag to read the positions from and write them to NBT.
0
Whenever Forge loads a model, it asks all the registered ICustomModelLoaders if they accept the specified ResourceLocation until it finds one that does. If none do, it asks the default ICustomModelLoaders (ModelLoader.VanillaLoader and ModelLoader.VariantLoader) if they accept it (ModelLoader.VanillaLoader always does).
Once Forge finds an ICustomModelLoader that accepts the ResourceLocation, it calls ICustomModelLoader#loadModel to load the IModel. This could be loaded from a file (e.g. a JSON file loaded by ModelLoader.VanillaLoader) or created entirely in code (e.g. ModelDynBucket.MODEL loaded by ModelDynBucket.LoaderDynBucket).
When a model is loaded by a Forge blockstates file, BlockStateLoader.ForgeVariant#runModelHooks is called so the model can process any custom data, replace textures and enable/disable smooth lighting, GUI 3D and UV lock settings specified in the blockstates file.
When Forge has finished loading every requested IModel, it calls IModel#bake on them all to bake them into IBakedModels.
When Minecraft renders an IBakedModel for an item, it calls ItemOverrideList#handleItemState on the model's ItemOverrideList to allow the model to be replaced by another according to any overrides specified in the item model.
ModelDynBucket.BakedDynBucket uses ModelDynBucket.BakedDynBucketOverrideHandler.INSTANCE as its ItemOverrideList, which uses IModel#process to generate a new ModelDynBucket instance with the item's contained fluid and then ModelDynBucket#bake to bake that into a new IBakedModel. It caches these models so they're not re-baked every time.
0
You can use an array of ingredients anywhere a single ingredient is expected to create a compound ingredient that matches any of the specified ingredients. Look at the crafting_table.json recipe for an example of this, it uses a compound ingredient that matches any of the valid metadata values of minecraft:planks.
You can also use 32767 (the value of OreDictionary.WILDCARD_VALUE) as the metadata of an ingredient to match any metadata value.
0
The crash is coming from StatList.initStats, which creates an ItemStack without an NBT tag and calls ItemStack#getTextComponent on it (which calls Item#getItemStackDisplayName/getUnlocalizedName).
You can't assume that an ItemStack always has an NBT tag, you need to handle the case where it doesn't.
0
The main issue may take a while to be fixed, since I'm not entirely sure how it should be implemented. You'll have to wait for LexManos or someone else to get around to fixing it.
The other two issues should be relatively easy to fix, I plan to submit PRs for them soon.
0
The best way to do this would probably be using Forge registries and registry events for your spell classes.
If that's not practical/possible, you can probably get away with firing your custom registry events during RegistryEvent.Register<Item>; though it's a bit hackish. You'll probably want to do this at the start (EventPriority.HIGHEST) or end (EventPriority.LOWEST) of the event.
If your event implements IContextSetter, it will set the active mod container when calling the event handlers. If your event implements IGenericEvent (or extends GenericEvent), event handlers can specify a generic type argument to filter when they're called (like RegistryEvent.Register and AttachCapabilitiesEvent).
0
There won't be any clean way to fire your own spell registry events between RegistryEvent.Register<Item> and ModelRegistryEvent; but as you said, you shouldn't need to.
0
You should be registering your Items in RegistryEvent.Register<Item> and your ItemMeshDefinitions in ModelRegistryEvent, regardless of what you decide to do with your spell classes.
If you create a Forge registry for any of your spell classes, you should register the instances of those in RegistryEvent.Register<T> (where T is the registry type) as well.
If your ItemMeshDefinitions require instances of the spell classes at construction time, the spells will need to be registered before ModelRegistryEvent. If they only require instances of the spell classes in the ItemMeshDefinition#getModelLocation implementation, they can be registered later.
Edit: Missed a word.
0
It looks like the FieldWrapper.MapWrapper class used by the annotation-based config system for Map fields is a bit broken, I've reported this issue here. I've also reported two other issues with it here and here.
0
ItemMeshDefinitions should be registered in ModelRegistryEvent, which is fired after RegistryEvent.Register is fired for every registry.
Item#getSubItems generally won't be called until after the initial loading process.
Forge's registry system handles things like ID assignment, name remapping and detecting missing registry entries for you.
Forge fires RegistryEvent.Register in alphabetical order of the registry names (after it's fired for Block and Item), but I think this is considered an implementation detail rather than a documented order.
0
Why does this need to be done before items are registered?
If you use Forge's registry system, RegistryEvent.Register will automatically be fired for you and you can use this to register your spell parts. It will be fired for your register after it's fired for the item registry, though.
0
You really need to spend some time learning the basics of Java before making a mod.
I use Class#member to refer to non-static fields/methods and Class.member to refer to static fields/methods.
ItemStack#damageItem and ItemStack#shrink are non-static methods, so they need to be called on an instance of ItemStack.
You can't just type a name like instant_health and expect Java to know what you mean, you need to reference an actual field. The Instant Health Potion object is stored in the MobEffects.INSTANT_HEALTH field.
0
Files loaded by the server (e.g. recipes, loot tables and structures) can't be overridden via resource packs, but Mojang plans to add data packs in 1.13 to allow this.