ModelRenderRegistry.addItemToRegistry with custom ModID
Kovak opened this issue ยท 15 comments
It looks like at the moment it expects all item model files to be under the spartanweaponry domain. It would be nice if we could specify a modid in addItemToRegistry so that our custom models could be under their own mod id.
Sorry for the late response. I need to set up notifications for issues received.
How is it that you are registering your item models? Because it looks like you are using the internal Spartan Weaponry method of doing this. That hasn't been exposed as part of the API.
I can provide a method to put in your model registration class if you like that you can call in the same class to put the correct model files in your mod domain. You will need to however provide the model names yourself to use it.
public static void registerItemRender(Item item, String modelName)
{
ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(modelName, "inventory"));
}
Let me know if this helps.
Oh yes I have been using the internal model registration. Something like:
Item katana = SpartanWeaponryAPI.createKatana(
mat.material,
SpartanFire.MODID,
DamageHelper.getDamage(DamageHelper.WeaponType.KATANA,
mat.material.getMaterial().getAttackDamage()),
CreativeTabsSW.TAB_SW
);
ModelRenderRegistry.addItemToRegistry(katana, "katana_" + mat.material.getUnlocName());
item_set.add(katana);
How do you envision us registering our models?
I think my example I provided didn't fully summarize the problem since it uses a custom texture.
If I'm going to use the default ToolMaterialEx color property based rendering, I've been calling:
ModelRenderRegistry.addItemToRegistry(throwing_axe,"throwing_axe_" + mat.material.getUnlocName(), mat.material);
How are we to use the ColourHandler system if these parts aren't exposed?
oh i didnt notice that, I see so we we should have our own render registry but then use the colour handler
I think you should reconsider leaving this entirely up to mods that want to use the SpartanWeaponry api.
You have a lot of custom rendering registration code that I am having to duplicate internally and it would be very easy to go from:
ModelResourceLocation modelLoc = new ModelResourceLocation("spartanweaponry:" + StringHelper.stripUnlocalizedName(unlocName), "inventory");
to
ModelResourceLocation modelLoc = new ModelResourceLocation(modId + ":" + StringHelper.stripUnlocalizedName(unlocName), "inventory");
which is really the only thing getting in the way from other mods just making use of the same exact model registry methods that SpartanWeaponry itself uses right now.
That has been directly exposed as part of the API now. See below:
SpartanWeaponryAPI.registerColourHandler(Item... items)
I'll have to see about doing that. I'll also will have to expose it to the API itself, so you wouldn't have to decompile the mod itself.
I have updated the API on GitHub, adding a way to register the Item model, either directly, only requiring the Item class, or another version that requires the Item class, your Mod ID, and the model name. You will need version "beta-1.2.1" of Spartan Weaponry (now available) to use it however. Hopefully that helps you out.
Sorry to re-open this I just got around to trying to update another one of the compat mods.
While you exposed registerItemRender with a modID api, this is actually not the part that was most helpful imo. My idea was allowing the compat mods to piggy-back off your registry in the first place making it so they do not need to include any registries other than the items themselves by changing:
@SubscribeEvent
public static void registerItemRenders(ModelRegistryEvent ev) {
registerMultiItemRender(ItemRegistrySW.material);
Iterator var1 = models.iterator();
while(var1.hasNext()) {
ModelRenderRegistry.ModelRegistryEntry entry = (ModelRenderRegistry.ModelRegistryEntry)var1.next();
registerItemRender(entry.getItem(), "spartanweaponry", entry.getModelLocation());
}
models.clear();
LogHelper.info("Registered all item renders!");
}
}
to
@SubscribeEvent
public static void registerItemRenders(ModelRegistryEvent ev) {
registerMultiItemRender(ItemRegistrySW.material);
Iterator var1 = models.iterator();
while(var1.hasNext()) {
ModelRenderRegistry.ModelRegistryEntry entry = (ModelRenderRegistry.ModelRegistryEntry)var1.next();
registerItemRender(entry.getItem(), entry.getModId(), entry.getModelLocation());
}
models.clear();
LogHelper.info("Registered all item renders!");
}
}
and then there would be method variants like:
public static void addItemToRegistry(Item item, String modelLoc, String modId) public static void addItemToRegistry(Item item, String modelLoc, ToolMaterialEx material, String modId)
This makes them lean, mean, and means they don't have to duplicate the whole ModelRegistryEntry structure or worry about getting their rendering initialization exactly right (especially when its reading/copying half-obfuscated code).
At the moment all my compat mods will have to have a complete copying of your ModelRenderRegistry to just swap out the hardcoded modid provided for the location of the models. It would be a lot easier to maintain these mods if all they had to do was register their items and pass them to your SpartanWeaponry's own ModelRenderRegistry so that code doesn't become sharded across all the implementors. All of this already works if you use the current endpoints and put the model json under spartanweaponry instead of the modid.
Sorry about the late response. I've just moved house recently and got internet set up again. Unfortunately it is rather crappy internet than what I'm used to.
Anyway, just for clarity's sake, is the way you want this to be done is so that Spartan Weaponry adds the model entry to the mod's internal registry, and then let Spartan Weaponry do all the registration internally, rather than directly calling the registration function? If I've read the above correctly, I believe that's what you want to do right?
Yes my goal is that I can call addItemToRegistry, like I was doing here with the old version:
But be able to provide my own modid so that the model files can be kept in the right asset directory. This way the compatibility mods only need to have their own item registries and let your ModelRegistry do all the registration.
Hi. Sorry for the very late response. I had to deal with a few stressful things in real life that took my time away from my mod development.
Anyway, I've got a progress update for you. What I've done in my development build of the mod is change how my internal class ModelRegistryEntry()
holds it's model location. It has been changed from a String
to a ResourceLocation
in my current development build. I've done this because the ResourceLocation
class allows specifying a domain for resource files, which, in most cases is the mod's ID.
What I intend on doing with this is exposing this method to the API directly, using the following method name and it's overloads
AddItemModelToRegistry(Item item)
AddItemModelToRegistry(Item item, String modId, String modelLocation)
AddItemModelToRegistry(Item item, ResourceLocation modelLocation)
and mark the previous ones that I made for this issue as deprecated.
These methods will allow you to add the Item models to Spartan Weaponry's internal model registry, and let my mod do the registering. As such, you will need to use the methods before Spartan Weaponry's ModelRegistryEvent
fires though, which I believe happens before the init phase. To be safe, just use it as soon as your items have been created.
This will mean I'll be uploading a new version of the API when that is done. I'll let you know when it's up.
Hey there. I've updated the API to version 3 which replaced the first method of directly registering Item Models with the new ones I've described above. Let me know if that suits your needs.
Also, I've released a new version of the mod that uses the API, Spartan Weaponry version "beta 1.2.2", to go with it.