ok looking at the font renderer class I could override it but, I don't understand from where vanilla is calling the color integer that's where I really need to override
/**
* Draws the specified string.
*/
public int drawString(String str, int x, int y, int color)
{
return this.drawString(str, x, y, color, false);
}
That overload of FontRenderer#drawString is called from most GUIs to draw a string, the color argument is whatever the GUI wants the base colour of the text to be. Any colour codes in the string will change the text colour until the next colour code or reset code.
I don't really understand this ObjectHolder thing, what is it used for?
Ok, I found the problem, you were right, Items were being initialized before blocks. The init methods are called in the main mod class, and they were in the wrong order. I still would like to know what object holders are though, as I've seen them before but didn't understand their purpose.
@ObjectHolder is used to inject registry entries (e.g. Blocks, Items, Biomes, SoundEvents) into fields.
You can use this to inject your own registry entries or those from vanilla or other mods.
If a registry entry is overridden, the field will be injected with the new value instead of the original one.
Hm... anyway I can send the information of the items to the other clients?
I assume through packets, which is the best method?
You'll need to scan each player's inventory for changes every tick on the server and then send any changes to all players tracking that player entity.
Use a capability to store the list of items that need to be synced/rendered for each player. Note that you can't use IItemHandler directly, since EntityPlayer already provides that capability itself.
I wrote this pseudocode example of how you could handle the syncing. In the packet's handler, you'd want to apply the changes from the packet to the client-side player entity's item list.
Where do you call ModBlocks.init and ModItems.init from?
Don't initialise and register your Blocks/Items in two separate methods. Either initialise and register them in the registry event handler method (recommended) or initialise them in static field initialisers and register them in the registry event handler method.
If you initialise them in the registry event handler method, initialise the fields to null and use @ObjectHolder to inject the Blocks/Items into them. Forge's documentation explains this here.
ModItems should not extend Item, it's a class that stores items; it's not an item itself.
Model registration should be handled in a dedicated client-only class rather than in common code.
I came up with a concept and uploaded it to github, but it crashes with a "NoClassDefFoundException". Maybe I missed something simple, but capabilties are quite frankly terribly explained from the sources I've looked at, especially when they store non-primitives.
That's not a NoClassDefFoundException.
This crash happens because you try to call a method on your Capability instance in a static initialiser of the HeroProvider class (the same class containing the field that the instance will be injected into), but this happens before Forge has had a chance to inject the Capability instance into that field.
The instance field should not be static, otherwise every instance of your provider would share the same instance of IHeroCapability.
You're registering the model for an ItemBlock instance that's never registered and never used outside of the ClientProxy#preInit method, you need to register the model for the ItemBlock instance that you actually register.
Use Item.getItemFromBlock to get the Item form of a Block.
You need to register your models in ModelRegistryEvent, not preInit.
There's no reason to have a "common" proxy, proxies are only for sided code. Common code belongs in your @Mod class or classes called from it.
I have an explanation of the model loading process and how model locations are mapped to model files here.
If you're using an OBJ model, you need to include the .obj extension in the path of the ModelResourceLocation you pass to ModelLoader.setCustomModelResourceLocation.
I knew you should add it as a dependency (which I had) but I didn't know you should run the "idea" task afterwards. There was also a bug in my build.gradle.
You shouldn't use the idea task. When creating the project, import build.gradle directly. When updating the project (e.g. adding/removing dependencies), refresh it from IDEA's Gradle window.
The ICustomModelLoader should return the base state of the model. The broken state can be handled by the ItemOverrideList.
The textures can either default to null (like ModelDynBucket) or be manually loaded from a file (like Tinkers' Construct's ToolModelLoader).
If the model is loaded from a blockstates file, IModel#retexture will be called with the textures specified in it; allowing you to return a new model with those textures.
ICustomModelLoader#accepts should only return true for a specific location (if you're using a single instance like ModelDynBucket) or extension (if you're loading data from a file like Tinkers' Construct). Look at the implementations of this method in ModelDynBucket.Loader and ToolModelLoader for examples. models/item isn't specific enough.
0
I explained that in post #29.
You'll need to add a new escape code for the custom colours, probably something like WoW's |cAARRGGBB.
0
When do you call this? It needs to be done before init (i.e. in preInit), otherwise it does nothing.
0
That overload of FontRenderer#drawString is called from most GUIs to draw a string, the color argument is whatever the GUI wants the base colour of the text to be. Any colour codes in the string will change the text colour until the next colour code or reset code.
0
@ObjectHolder is used to inject registry entries (e.g. Blocks, Items, Biomes, SoundEvents) into fields.
You can use this to inject your own registry entries or those from vanilla or other mods.
If a registry entry is overridden, the field will be injected with the new value instead of the original one.
1
You'll need to scan each player's inventory for changes every tick on the server and then send any changes to all players tracking that player entity.
Use a capability to store the list of items that need to be synced/rendered for each player. Note that you can't use IItemHandler directly, since EntityPlayer already provides that capability itself.
I wrote this pseudocode example of how you could handle the syncing. In the packet's handler, you'd want to apply the changes from the packet to the client-side player entity's item list.
0
Where do you call ModBlocks.init and ModItems.init from?
Don't initialise and register your Blocks/Items in two separate methods. Either initialise and register them in the registry event handler method (recommended) or initialise them in static field initialisers and register them in the registry event handler method.
If you initialise them in the registry event handler method, initialise the fields to null and use @ObjectHolder to inject the Blocks/Items into them. Forge's documentation explains this here.
ModItems should not extend Item, it's a class that stores items; it's not an item itself.
Model registration should be handled in a dedicated client-only class rather than in common code.
0
Are you rendering this for the client player or other players?
The client only knows the inventory contents of the client player, all it knows about the other players is their held items and armour.
0
You're probably creating the ItemBlocks before the Blocks have been created.
Post your ModItems and ModBlocks classes and the class that calls them.
0
That's not a NoClassDefFoundException.
This crash happens because you try to call a method on your Capability instance in a static initialiser of the HeroProvider class (the same class containing the field that the instance will be injected into), but this happens before Forge has had a chance to inject the Capability instance into that field.
The instance field should not be static, otherwise every instance of your provider would share the same instance of IHeroCapability.
0
You're registering the model for an ItemBlock instance that's never registered and never used outside of the ClientProxy#preInit method, you need to register the model for the ItemBlock instance that you actually register.
Use Item.getItemFromBlock to get the Item form of a Block.
You need to register your models in ModelRegistryEvent, not preInit.
There's no reason to have a "common" proxy, proxies are only for sided code. Common code belongs in your @Mod class or classes called from it.
0
I have an explanation of the model loading process and how model locations are mapped to model files here.
If you're using an OBJ model, you need to include the .obj extension in the path of the ModelResourceLocation you pass to ModelLoader.setCustomModelResourceLocation.
1
You shouldn't use the idea task. When creating the project, import build.gradle directly. When updating the project (e.g. adding/removing dependencies), refresh it from IDEA's Gradle window.
0
You should be adding dependencies through Gradle rather than directly adding them to your IDE project.
CoFH mods are hosted on maven.covers1624.net, which you can add as a Maven repository in Gradle. You can see how CoFHCore depends on the RF API here.
1
The ICustomModelLoader should return the base state of the model. The broken state can be handled by the ItemOverrideList.
The textures can either default to null (like ModelDynBucket) or be manually loaded from a file (like Tinkers' Construct's ToolModelLoader).
If the model is loaded from a blockstates file, IModel#retexture will be called with the textures specified in it; allowing you to return a new model with those textures.
ICustomModelLoader#accepts should only return true for a specific location (if you're using a single instance like ModelDynBucket) or extension (if you're loading data from a file like Tinkers' Construct). Look at the implementations of this method in ModelDynBucket.Loader and ToolModelLoader for examples. models/item isn't specific enough.
You probably don't need a cache here.
0
Forge's documentation explains how to set up projects in both IDEs here.